PCI DSS Firewall & NSC Ruleset Review

PCI DSS says review your firewall rules
every six months. Automate it.

PCI DSS v4.0.1 renamed “firewalls” to network security controls (NSCs) — Requirement 1.2.7 still means the review buyers have always called a firewall audit. Upload a sanitized config, get a rule-by-rule ruleset review, and export evidence your QSA can use. A 175-check scan takes about 60 seconds.

Start Free ScanSee Demo

No agent, no firewall credentials. Config parsed in memory and discarded. CRWLR isn't a QSA — it documents the NSC configuration-review portion of Requirement 1.2.

🔀

Firewall or NSC — same review

PCI DSS 4.0 renamed the control, not the requirement. Whatever your team calls it, CRWLR audits the FortiGate, Palo Alto, Sophos, Check Point, or Cisco ASA sitting at the edge of your CDE.

🗓

The six-month cadence, on rails

Requirement 1.2.7 sets a semi-annual minimum. Schedule a re-scan every six months and each run produces a dated posture report you can point to when the assessor asks.

📦

Evidence your QSA can use

Every scan exports a structured, dated evidence package — posture score, per-rule findings, remediation status. Supporting evidence for 1.2.7, not an Attestation of Compliance.

What Requirement 1.2 covers, and how CRWLR maps to it

RequirementWhat it requiresHow CRWLR helps
1.2.1Configuration standards for NSCs are defined, documented, and kept currentVendor-aware checks encode hardening baselines per platform; findings cite the exact line that deviates
1.2.2Changes to network connections and NSC configs go through change controlScheduled re-scans + scan history give you a dated record to reconcile against your change log
1.2.5Every allowed port, protocol, and service has a defined business need and is approvedRule-by-rule review flags services with no obvious justification, plus any-any and broad-port rules
1.2.7NSC configurations reviewed at least once every six months to confirm they’re relevant and effectiveScheduled re-scans on a six-month cadence, each producing a dated posture report you can point to
1.2.8Configuration files for NSCs are secured and kept consistent with what’s actually runningFindings are generated straight from your live exported config, so results reflect the deployed state
1.3.1 / 1.3.2Inbound and outbound CDE traffic is restricted to what’s necessary, with a default-deny postureZone-aware analysis flags rules that don’t restrict traffic to necessity and missing default-deny

Paraphrased for readability — refer to your copy of PCI DSS v4.0.1 for the authoritative requirement text.

What a CRWLR ruleset review checks

✓Every rule checked for a documented business justification — flagged when the 'why' isn't obvious from the rule itself
✓Overly permissive rules — any-source, any-destination, and broad port ranges that undermine a default-deny posture
✓Unused and redundant rules — rules nobody has touched that quietly widen the attack surface without adding value
✓Shadowed rules — a broad rule earlier in the policy silently swallowing a narrower rule meant to restrict it
✓Insecure services — Telnet, unencrypted management, and other protocols with no place in a policy protecting a CDE
✓Config drift from hardening standards — findings cite the specific line that deviates from the platform baseline
✓Change-control traceability — scan history and diffs give you something concrete to reconcile against your change log
✓Management exposure — admin and API interfaces reachable from broader sources than they should be
Sample finding— what you get per issue
HIGH

Any-any inbound rule to DMZ web tier has no documented business justification

Policy 14 allows any source, any destination, and all services from WAN into the DMZ. No comment field, no ticket reference, and no scoping to the actual web service being published. This is the exact pattern PCI DSS 1.2.5 requires you to justify and 1.3.1 expects you to restrict — right now it's neither.

config firewall policy
    edit 14
        set srcaddr "all"
        set dstaddr "web-dmz-01"
        set service "HTTPS"
        set comments "CHG-1042: restrict WAN->DMZ to HTTPS only, approved 2026-06-02"
    next
end

Every finding ships with the exact CLI block above (vendor-specific), the rule that triggered it, the PCI requirement it maps to, and a plain-English explanation of why it matters — ready to paste into a change ticket for 1.2.2 traceability.

Frequently asked

How often does PCI DSS require firewall ruleset reviews?

PCI DSS v4.0.1 Requirement 1.2.7 sets the floor: configurations of network security controls (NSCs) must be reviewed at least once every six months to confirm they remain relevant and effective. Many QSAs also expect a review after any major network or policy change, but six months is the minimum compliance cadence.

What is an NSC (network security control) in PCI DSS 4.0?

NSC is the PCI DSS 4.0 term for what earlier versions of the standard called a firewall or router. It covers firewalls, routers, and cloud security groups that control traffic into and out of the cardholder data environment. In most SMB environments the NSC is simply the firewall — CRWLR audits configs from the five vendors that most commonly fill that role: FortiGate, Palo Alto, Sophos, Check Point, and Cisco ASA.

What does a firewall ruleset review actually include?

A proper review checks that every rule has a documented business justification, flags overly permissive rules (any-any, broad port ranges), identifies unused or redundant rules that have outlived their purpose, catches insecure services like Telnet or unencrypted management access, and reconciles rule changes against your change-control record. The underlying configuration standards themselves also need to be current — the review checks the ruleset against those standards, not just against itself.

Can I automate the PCI DSS firewall review?

Yes — that's what CRWLR automates. Upload a sanitized export of your firewall configuration and 175 automated checks run against it, including rule hygiene (permissive rules, unused rules, risky services, exposed management interfaces), producing a graded finding per rule plus vendor-specific CLI remediation. Schedule a re-scan every six months and the semi-annual cadence takes care of itself.

Does CRWLR produce evidence my QSA will accept?

CRWLR is not a QSA and doesn’t issue an Attestation of Compliance — it automates and documents the NSC configuration-review portion of Requirement 1.2. Each scan produces a posture score, per-rule findings, and an exportable, dated evidence package you hand to your QSA or internal assessor as supporting evidence for 1.2.7. It’s evidence for the review, not a replacement for the assessment.

Does CRWLR check that my config files match what’s actually deployed?

Partially. Requirement 1.2.8 expects configuration files for NSCs to be secured from unauthorized access and kept consistent with the active configuration. CRWLR analyzes the config you export directly from the device, so findings reflect what’s actually deployed at scan time — but securing that file in storage and controlling who can access it is a process control on your side, not something a config scanner enforces.

Get your 1.2.7 evidence in the next 60 seconds.

No credit card. No agent to install. The raw export never touches our storage. No demo, no sales call.

Start Free Scan →
HomeFortiGate auditPalo Alto auditSophos auditCheck Point auditCisco ASA auditSanitize your configCyber insurance firewall auditPricingLive demo
PCI DSS Firewall Ruleset Review — Requirement 1.2.7 | CRWLR