# Firewall Rule Review: [Rule set or device group] [Review period]

> Periodic review record for network security control rule sets
> (firewalls, cloud security groups, network ACLs, Kubernetes network
> policies): every rule has an owner, a business justification, a
> decision and, where temporary, an expiry. Aligned with PCI DSS v4.0.1
> Requirement 1.2.7 (review of network security control configurations
> at least once every six months, cited by number only), NIST SP 800-53
> Rev. 5 (Release 5.2.0) SC-7(4) and SC-7(5), and NIST SP 800-41 Rev. 1.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Run one review per rule set or device group per cycle. Export the
  rules on the review start date and freeze that export as evidence.
- Send each rule to its owner for confirmation before the review
  meeting; rules without an owner go straight to the escalation list.
- Decisions are Keep, Modify, Remove or Escalate. Changes go through
  normal change control (ops/change-request); the review never edits
  production directly.
- Track the result, not only the meeting: a review is complete when
  every Remove and Modify decision is implemented and verified.
- Common pitfall: rubber-stamping. Reviewers confirm "still needed"
  without checking hit counts or whether the application still exists.
-->

## Document control

<!-- Guidance: The review date and the export hash prove when the review happened and what was reviewed. Keep the record with the PCI DSS or ISMS evidence. -->

| Field | Value |
|---|---|
| Review ID | [FWR-YYYY-NN] |
| Version | [0.1] |
| Status | [Planned / In review / Actions open / Complete] |
| Owner (network security) | [@network-security-lead] |
| Reviewers | [@app-owner-1], [@app-owner-2], [@security-assessor] |
| Scope | [Device group, cloud account, cluster] |
| In PCI DSS scope? | [Yes: CDE / connected / No] |
| Review cycle | [Every six months / quarterly] |
| Previous review completed | YYYY-MM-DD |
| This review completed | YYYY-MM-DD |
| Rule export file and SHA-256 | [file name, hash] |
| Classification | [Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Network security lead | [@name] | [Approve results] | YYYY-MM-DD |
| Information security manager | [@name] | [Approve results] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Export taken, rule list prepared |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Review decisions recorded |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* All removals implemented and verified |

## 1. Scope and cadence

<!-- Guidance: Name the devices and rule sets covered, why the cycle length was chosen, and how the review date relates to the last one. A missed cycle is an audit finding: record the dates. -->

| Item | Value |
|---|---|
| Devices or rule sets | *Example:* `edge-fw-a/b` (perimeter pair), `dc-core-fw` (internal), cloud security groups in account `prod-payments` |
| Rule export date | *Example:* 2026-10-01 |
| Previous review completed | *Example:* 2026-04-15 |
| This review completed | *Example:* 2026-10-14 (182 days after the previous one) |
| Basis for cycle | *Example:* PCI DSS v4.0.1 Requirement 1.2.7 for in-scope devices; internal standard NSS-3 for the rest |
| Out of scope and why | *Example:* Lab network, isolated and covered by its own quarterly review |

## 2. Review criteria

<!-- Guidance: Agree the questions before the review so every rule gets the same test. NIST SP 800-53 SC-7(4) expects each exception to the traffic flow policy to carry a business need and a duration, and to be removed when the need ends; SC-7(5) sets deny by default. -->

Ask these questions for every rule:

1. Does the rule have a named owner who confirmed it in this cycle?
2. Is the business justification still true, and does the application or partner still exist?
3. Is the rule as narrow as it can be (source, destination, port, protocol, direction)?
4. Does it allow an insecure protocol, and if so is there a documented security feature or compensating control (PCI DSS v4.0.1 Requirement 1.2.6 covers this)?
5. Has the rule been hit since the previous review? Zero hits is a strong removal signal, not proof.
6. Is it temporary, and if so has its expiry date passed?
7. Is it shadowed or duplicated by another rule?
8. Does the rule set still end in an explicit deny-all?

## 3. Rule review register

<!-- Guidance: One row per rule from the frozen export. Use the device rule ID so changes can be traced. Record hit counts for the period between reviews. Keep long lists in an attached spreadsheet and summarise here. -->

| Rule ID | Source | Destination | Service | Owner | Justification | Hits since last review | Expiry | Decision |
|---|---|---|---|---|---|---|---|---|
| FW-EDGE-0012 *(Example)* | Any | Web load balancer VIP | TCP 443 | [@web-owner] | Public storefront | 41,882,120 | None | Keep |
| FW-EDGE-0047 *(Example)* | Partner range 198.51.100.0/24 | SFTP gateway | TCP 22 | [@integration-owner] | Daily settlement files from acquirer | 182 | None | Modify: restrict to two partner hosts |
| FW-CORE-0310 *(Example)* | App subnet | Legacy reporting DB | TCP 1433 | [@reporting-owner] | Old reporting tool | 0 | None | Remove: tool retired 2026-06 |
| FW-CORE-0388 *(Example)* | Vendor VPN pool | Payment API hosts | TCP 8443 | [@payments-owner] | Vendor support for go-live | 1,204 | 2026-08-31 | Remove: temporary rule expired |
| SG-PAY-0021 *(Example)* | 0.0.0.0/0 | Bastion host | TCP 22 | None found | Unknown | 3,910 | None | Escalate: no owner |

## 4. Results summary

<!-- Guidance: Totals must equal the number of rules in the export. Show the trend against the previous review; a growing rule base with few removals points to a weak request process. -->

| Decision | Rules | Share of total |
|---|---|---|
| Keep *(Example)* | 318 | 77.2% |
| Modify *(Example)* | 41 | 10.0% |
| Remove, no longer needed *(Example)* | 37 | 9.0% |
| Remove, expired temporary rule *(Example)* | 9 | 2.2% |
| Escalate, no owner *(Example)* | 7 | 1.7% |
| **Total in export** *(Example)* | **412** | **100%** |

*Example:* 46 rules (11.2% of the export) are marked for removal. Shares are rounded to one decimal, so they add to 100.1%. The previous review removed 19.

```mermaid
flowchart LR
  E["Freeze rule export"] --> O["Owners confirm rules"]
  O --> R["Review meeting applies criteria"]
  R --> D{"Decision"}
  D -->|Keep| K["Record justification"]
  D -->|Modify or Remove| C["Change request"]
  D -->|Escalate| X["Security manager assigns owner or removes"]
  C --> V["Verify on device and close"]
  X --> C
```

## 5. Actions

<!-- Guidance: Every Modify, Remove and Escalate decision becomes an action with a change reference and a due date. The review stays open until the last action is verified on the device. -->

| Action ID | Rules | Action | Change ref | Owner | Due | Verified |
|---|---|---|---|---|---|---|
| FWA-01 *(Example)* | FW-CORE-0310 and 36 others | Remove unused rules | CHG-2026-1180 | [@network-engineer] | 2026-10-28 | YYYY-MM-DD |
| FWA-02 *(Example)* | FW-CORE-0388 and 8 others | Remove expired temporary rules | CHG-2026-1181 | [@network-engineer] | 2026-10-21 | YYYY-MM-DD |
| FWA-03 *(Example)* | FW-EDGE-0047 and 40 others | Narrow source, destination or port | CHG-2026-1185 | [@network-engineer] | 2026-11-11 | YYYY-MM-DD |
| FWA-04 *(Example)* | SG-PAY-0021 and 6 others | Find owner within 10 working days or remove | Not yet raised | [@security-manager] | 2026-10-28 | YYYY-MM-DD |

## 6. Process findings

<!-- Guidance: Look beyond single rules. Record causes such as temporary rules created without expiry, or owner fields left blank in the request form, and fix them at the source. -->

| Finding ID | Finding | Root cause | Improvement | Owner |
|---|---|---|---|---|
| FWF-01 *(Example)* | Nine temporary rules outlived their expiry | Expiry stored only in the change ticket, not on the rule | Add expiry tag to rule comments and alert 14 days before | [@network-security-lead] |
| FWF-02 *(Example)* | Seven rules had no owner | Owner field optional in the request form | Make owner and justification mandatory fields | [@itsm-owner] |

## 7. Glossary and references

<!-- Guidance: Keep terms aligned with the network security standard and PCI DSS scoping document. -->

| Term | Meaning |
|---|---|
| Network security control (NSC) | PCI DSS term for firewalls and other technologies that control traffic between network segments |
| Shadowed rule | Rule that never matches because an earlier rule handles all its traffic |
| Hit count | Number of times a rule matched traffic in a period |
| Deny by default | Rule set allows only listed traffic and blocks everything else |
| CDE | Cardholder data environment |

References (check the current official versions):

- PCI DSS v4.0.1 (PCI Security Standards Council, June 2024), Requirements 1.2.5, 1.2.6 and 1.2.7. Official text: PCI Security Standards Council, free download under the PCI SSC licence agreement: https://www.pcisecuritystandards.org/document_library/
- NIST SP 800-53 Rev. 5, Release 5.2.0: SC-7 Boundary Protection with enhancements (4) and (5), CM-7 Least Functionality, CA-9 Internal System Connections: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy (September 2009): https://csrc.nist.gov/pubs/sp/800/41/r1/final
- Related templates: compliance/pci-dss-scoping-segmentation, security/zero-trust-architecture, ops/change-request, ops/change-enablement-policy, ops/access-review, security/security-exception-request

## Standard and licence note

Structure aligned with PCI DSS v4.0.1 Requirements 1.2.5 to 1.2.7, cited
by requirement number only; no requirement or testing procedure text is
reproduced. Official text: PCI Security Standards Council, licensed
access at https://www.pcisecuritystandards.org/document_library/. Based
on NIST SP 800-53 Rev. 5 (Release 5.2.0) and NIST SP 800-41 Rev. 1, US
government publications. The template text and examples are original;
all organisations, rules and figures are fictional, and the example
addresses use documentation ranges. Check the current official
versions before use. Template licence: MIT.