Put every firewall rule on a review cycle — attach owners and business justification, let usage, expiry, and compliance findings trigger reviews, and certify or decertify each rule through an append-only, audited workflow that becomes your periodic-review evidence.
Firewalls accumulate rules faster than anyone removes them. A change ticket from three years ago leaves behind an any-service allow that no one remembers, the person who requested it has left, and no auditor can tell you why it still exists. Recertification closes that gap: every rule gets an owner and a business justification, and every rule comes up for periodic review, where a human either re-attests that it is still needed or sends it for decommission. The whole thing is captured as an append-only audit trail — which is exactly the evidence a PCI DSS periodic-review requirement asks for.
Recertification is the lifecycle half of Versus's firewall governance stack. Its companion, the Rule Findings engine, tells you which rules are unused, expired, or overly permissive; recertification is the workflow that decides what to do about them. In the Versus UI it lives under FW Governance → Recertification.
Recertification adds a Versus-side layer on top of your ingested rulebase. None of it is written back to the device — it is governance metadata that lives alongside the rule.
Every firewall rule can carry a rule metadata record that holds the business context a raw device config never captures:
| Field | Meaning |
|---|---|
owner | The user accountable for the rule |
business_justification | Free-text reason the rule exists |
ticket_ref | The originating change ticket |
created_via | versus (provisioned through automation) or discovered (found on the device) |
expires_at | Recertification anchor — when the rule is next due |
last_certified_at / last_certified_by | Timestamp and user of the most recent certification |
certification_status | Where the rule sits in its review cycle (see below) |
suggested_owner / suggested_owner_confidence | A proposed owner and confidence score to accelerate bulk assignment |
Rules provisioned through Versus's firewall automation arrive with owner, justification, and ticket reference already stamped. Discovered rules — everything that predates Versus — start as never_reviewed with no owner, which is why bulk ownership assignment (below) is usually the first thing you do on a newly onboarded device.
The certification status of a rule is one of:
| Status | Meaning |
|---|---|
never_reviewed | No review has ever been completed |
certified | Reviewed and re-attested as still needed |
due | Review cycle has come around |
overdue | Past its expires_at without being certified |
decertified | Reviewer determined the rule should be removed |
A recertification review is the unit of work — one open review per rule at a time. Each review records:
scheduled, usage_based, compliance, or manual).Reviews move through a fixed set of states:
open → assigned → ( certified | modify_requested | decertified ) → closed
| Status | Meaning |
|---|---|
open | Created by a trigger, not yet picked up |
assigned | Claimed by or routed to a reviewer |
certified | Reviewer attests the rule is still valid |
modify_requested | Reviewer wants the rule changed before it can be certified |
decertified | Reviewer determined the rule should be removed |
closed | Terminal |
Every transition writes an append-only event: who acted, the old→new transition, the decision, the justification text, and a snapshot slot for the findings attached at decision time. Events are never edited or deleted — the event stream is the audit record. When an auditor asks "prove this rule was reviewed in the last twelve months and show who signed off," the answer is the review's event history.
Reviews are created by triggers, evaluated on a schedule and on relevant events. Four trigger types exist:
expires_at has been reached, or a tenant-wide cadence has come around (whichever is sooner).unused (no hits for the configured window, by default 90 days) and that finding has persisted.Because each review carries a unique idempotency key derived from the rule and its review cycle, re-running trigger evaluation is safe: a rule that already has an open review does not get a second one.
The usage and finding signals that feed the first two trigger types come from the same background analyzer that powers Rule Findings. It collects hit counts from supported firewalls (Palo Alto PAN-OS, Fortinet FortiGate, and Zscaler) roughly every six hours, rolls them up into 30/90/365-day windows, and runs a deterministic analysis pass nightly. See Rule Findings for the detection detail.
Operators work reviews from the Recertification Reviews page, which is filtered into four tabs:
Each review row exposes the actions available for its current state. Under the hood these are POST actions on the review, and you can drive them from the API just as the UI does.
Claim a review (or route it to another user). This sets the assignee, moves the review to assigned, and records an open→assigned event.
POST /api/policy/recert/{id}/assign/
Content-Type: application/json
{ "user_id": 42 }
Omit user_id to assign the review to yourself.
Attest that the rule is still needed. Certifying transitions the review to certified, closes it, and writes the decision to the event trail. It also updates the rule's metadata: last_certified_at and last_certified_by are stamped, and certification_status becomes certified.
POST /api/policy/recert/{id}/certify/
Content-Type: application/json
{ "justification": "Required for the quarterly settlement batch; owner confirmed 2026-08." }
The justification you supply is stored on the event — this is the reviewer's attestation, and it is what a periodic-review audit reads back.
Send the rule back for change before it can be certified. This transitions the review to modify_requested and closes it, recording the decision and any justification. Use this when a rule is legitimate but too broad — the reviewer's note becomes the brief for the follow-up firewall change.
POST /api/policy/recert/{id}/request-modify/
Content-Type: application/json
{ "justification": "Narrow source from any to the app subnet before recertifying." }
Determine that the rule should be removed. Decertifying transitions the review to decertified, closes it, records the decision, and sets the rule's certification_status to decertified.
POST /api/policy/recert/{id}/decertify/
Content-Type: application/json
{ "justification": "Server decommissioned; no business owner claimed the rule." }
A decertified review is the system-of-record signal that a rule is slated for removal. The actual removal is carried out as a firewall change through Versus's workflow engine, so the disable-then-delete is itself planned, approved, and audited rather than done by hand.
Discovered rules start with no owner, and you cannot run a meaningful recertification program against unowned rules. Rather than editing rules one at a time, assign an owner across a set of rules in a single call:
POST /api/policy/rule-meta/bulk-assign-owner/
Content-Type: application/json
{ "rule_ids": [1201, 1202, 1203], "owner_id": 42 }
You can select the rule set however you like — by zone pair, by a naming convention, or from a filtered Rule Findings view — and hand the resulting IDs to this endpoint. The suggested_owner field on rule metadata exists to make this faster: where Versus can propose an owner, it records the suggestion and a confidence score you can review before committing.
Rule metadata is also directly queryable and filterable, so you can pull, for example, every rule that has never been reviewed:
GET /api/policy/rule-meta/?certification_status=never_reviewed
certification_status, last_certified_at, and last_certified_by are read-only over the metadata API — they are set by the certify and decertify actions on a review, never by hand, so the certified state always traces back to a recorded decision.
Recertification is Module B of Versus's firewall policy governance, and it is deliberately wired into the pieces around it rather than standing alone:
The payoff is that "when was this rule last reviewed, by whom, and why is it still here" stops being an archaeology project. Every rule has an owner, a review cycle, and an append-only record of every decision ever made about it — which is both good hygiene and, for regulated environments, the audit evidence itself.