NSC Configuration Review

PCI DSS requires you to review configurations of all network security controls (NSCs) at least every six months, and to confirm those configurations are still relevant and effective for protecting the cardholder data environment (CDE) (PCI DSS v4.0.1 Requirement 1.2.7). Operationalize this by scoping in every NSC, running a documented configuration review against baselines and current network/data flows, remediating gaps, and retaining evidence that the review occurred and drove changes.

Key takeaways:

• Maintain a complete NSC inventory and ensure it matches your CDE scope and network diagrams.
• Run a documented, repeatable semi-annual review against approved baselines and current threats/changes.
• Preserve audit-ready evidence: who reviewed, what was checked, exceptions, remediation, and approvals.

“NSC configuration review requirement” under PCI DSS 4.0.1 is straightforward on paper and easy to fail in practice. The failure mode is rarely “we didn’t look at the firewall.” It’s usually scoping drift (an NSC was added or moved and never included), shallow checks (a screenshot of a rulebase without analysis), or missing proof that the review confirmed effectiveness for the CDE.

PCI DSS uses “network security controls” broadly. In most environments, that includes firewalls, virtual firewalls and security groups, WAFs, network intrusion detection/prevention systems, segmentation gateways, routers/ACLs used for segmentation, and cloud-native network controls that enforce boundaries around the CDE. The intent is to force a periodic reset: confirm that the controls you rely on still match how the environment actually works today, including routes, permitted services, administrative access paths, and segmentation assumptions.

This page gives requirement-level implementation guidance you can execute quickly: who must comply, what to review, how to structure the review, what artifacts to retain, and what assessors commonly challenge. It is written for a Compliance Officer, CCO, or GRC lead coordinating NetSec, Cloud, and PCI stakeholders.

Regulatory text

Requirement: “Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.” (PCI DSS v4.0.1 Requirement 1.2.7)

What the operator must do:
You must (1) identify the NSCs that protect and segment the CDE, (2) perform a configuration review at least semi-annually, and (3) document that the review confirmed the NSC configurations still fit the environment (“relevant”) and still protect as intended (“effective”), including evidence of follow-up changes when gaps are found (PCI DSS v4.0.1 Requirement 1.2.7).

Plain-English interpretation (what the requirement really means)

A semi-annual NSC configuration review is not a “check-the-box” export of firewall rules. It’s a structured review that answers four questions:

1. Do we have the right controls? The set of NSCs in scope matches the current CDE boundaries and segmentation design.
2. Are they configured as intended? Configuration aligns to an approved baseline/standard (allowed services, management access, logging, encryption where applicable, and segmentation rules).
3. Do the configurations still match reality? Business services, IP ranges, routes, cloud accounts/VPCs/VNETs, and third-party connections changed; rules should reflect those changes.
4. Do the controls still work? The NSCs still enforce intended restrictions and segmentation assumptions, with exceptions formally approved and time-bounded where appropriate.

The output should look like an internal control: defined scope, reviewer(s), review steps, findings, remediation actions, and closure evidence.

Who it applies to (entity and operational context)

Entity types: Merchants, service providers, and payment processors that must comply with PCI DSS (PCI DSS v4.0.1 Requirement 1.2.7).

Operational contexts where this requirement usually lands:

• On-prem CDE with perimeter firewalls, internal segmentation firewalls, IDS/IPS.
• Hybrid CDE where segmentation depends on VPNs, cloud gateways, and security groups.
• Fully cloud CDE where “firewalls” are cloud-native controls plus WAF and gateway products.

Who owns execution (typical RACI):

• Accountable: CISO/Head of Security or PCI Program Owner.
• Responsible: Network Security / Cloud Security engineering.
• Consulted: PCI QSA (during readiness), App owners, Infrastructure, IAM team, SOC.
• Informed: GRC/compliance, Internal Audit.

What you actually need to do (step-by-step)

Step 1: Define and document “NSC” for your environment

Create a short internal definition aligned to PCI’s intent: any control that enforces or monitors network traffic boundaries for the CDE, including segmentation controls.

Deliverable: NSC scope statement, tied to CDE segmentation design and diagrams.

Step 2: Build an NSC inventory tied to CDE scope

Make a single list of all in-scope NSCs with:

• Name, type (firewall/WAF/IDS/security group), environment (prod/non-prod if in scope), owner, management plane, and where it sits relative to the CDE.
• Data flow or boundary it protects (internet → DMZ → CDE, corporate → CDE admin, third party → CDE, etc.).
• Source of truth for config (device manager, IaC repo, cloud policy, centralized firewall manager).

Practical tip: If an NSC is configured by Infrastructure-as-Code, the “configuration” for review is the code, plus the deployed state you validate in the platform.

Step 3: Establish configuration baselines (what “good” looks like)

For each NSC class, define minimum baseline checks. Keep it short enough to run every cycle, and strict enough to catch drift. Examples:

• Rule review expectations (least privilege, explicit deny strategy where relevant, no “any-any” rules without compensating justification).
• Administrative access restrictions (who can change rules, MFA where applicable, management interfaces restricted).
• Logging/monitoring enabled and forwarded to a monitoring system (don’t claim SIEM coverage unless you can prove it).
• Segmentation enforcement rules for CDE boundaries (documented “allow list” of required ports/protocols).

Deliverable: Approved NSC baseline standard(s), versioned and dated.

Step 4: Run the semi-annual configuration review (repeatable checklist)

For each NSC in inventory, perform and document:

1. Config snapshot for the review period
   • Export rulebase/policy, object groups, NAT, routing/security policies, WAF policies, IDS/IPS policies, and cloud security group rules as applicable.
2. Change review since the last cycle
   • Pull change tickets, merge requests, and emergency changes affecting the NSC. Confirm each change has approval and justification tied to a service or request.
3. Relevance checks (alignment to current environment)
   • Compare against current CDE diagrams and data flows.
   • Validate that permitted sources/destinations still exist and are still required.
   • Identify stale objects, decommissioned IP ranges, expired third-party connections.
4. Effectiveness checks (still protects the CDE)
   • Confirm segmentation rules still enforce the boundary claims you make for PCI scoping.
   • Verify management plane restrictions are still in place.
   • Confirm alerts/logging settings are still enabled and not silently failing.
5. Exception handling
   • Document each exception: business justification, risk acceptance, compensating controls, owner approval, and revisit criteria.

Deliverable: A completed “NSC Configuration Review Report” per review cycle, with annexes for evidence.

Step 5: Remediate findings and record closure

Track findings to closure like any other audit issue:

• Severity (risk-based), owner, target remediation date, actual closure date, validation steps.
• If you can’t remediate quickly, document temporary mitigations and an approved exception.

Deliverable: Remediation tracker with closure evidence attached (tickets, PRs, screenshots/exports, approvals).

Step 6: Prove the cadence and governance

Assessors look for a system, not heroics:

• Calendarized review events.
• Named reviewers with appropriate access and competence.
• Management sign-off (security leadership and, where relevant, PCI program owner).

Deliverable: Review schedule, sign-off records, and evidence repository structure.

Required evidence and artifacts to retain

Keep evidence in a single audit package per cycle. Minimum set:

• NSC inventory (dated) and mapping to the CDE boundaries/segmentation design.
• Network/CDE diagrams and data flow documentation used during the review.
• Baseline configuration standards/checklists (approved and versioned).
• Review report(s) showing:
  • Scope (which NSCs), period covered, reviewers, date performed.
  • What checks were performed.
  • Findings, exceptions, and remediation actions.
• Configuration exports/snapshots (or immutable references):
  • Firewall policies/rules, WAF policies, IDS/IPS policies, cloud security group rules.
  • If IaC-driven, include repo commit references plus evidence of deployed state validation.
• Change management evidence:
  • Tickets/approvals for significant rule changes, emergency change documentation.
• Sign-offs and risk acceptances for exceptions.

Retention approach: Keep it long enough to support your next assessment cycle and demonstrate consistent operation. Store in a controlled system with access logging.

Common exam/audit questions and hangups

Expect these questions and prepare the artifacts to answer them fast:

• “Show me all NSCs in scope for the CDE.”
  Hangup: missing cloud-native controls or segmentation ACLs because the inventory only lists “firewalls.”
• “Prove you did the review within the required cadence.”
  Hangup: review performed, but no dated report, no sign-off, or evidence scattered across chats.
• “How did you confirm the configurations are effective?”
  Hangup: providing config exports without analysis tied to data flows and segmentation claims.
• “What changed since the last review, and how was it approved?”
  Hangup: rule changes exist without tickets, or tickets exist but don’t match the implemented change.
• “How do you handle exceptions?”
  Hangup: informal “temporary rules” that became permanent and were never re-approved.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Treating the review as a rule dump	Doesn’t show relevance/effectiveness	Use a checklist tied to diagrams, flows, and baseline standards
Incomplete NSC scope	PCI scoping breaks, segmentation claims weaken	Tie inventory to CDE diagrams, cloud accounts, and third-party links
No baseline standard	Review becomes subjective	Write minimum baselines per NSC class and get them approved
Exceptions without re-review	Drift becomes “normal”	Require exception owner, expiry/revisit trigger, and sign-off
IaC environments only reviewing code	Deployed config may drift	Validate deployed state against intended state and record proof

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so don’t build your program around anecdotal penalty narratives.

The real risk is operational and assessment-driven:

• Operational: NSC drift creates unintended exposure paths into the CDE (new services, admin ports, expanded source ranges, stale third-party access).
• Assessment: If you rely on segmentation to reduce PCI scope, weak evidence of semi-annual NSC configuration review can trigger deeper sampling, expanded scoping, or findings against requirement 1.2.7 (PCI DSS v4.0.1 Requirement 1.2.7).

A practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Assign an owner and define NSCs for your environment (PCI DSS v4.0.1 Requirement 1.2.7).
• Build the NSC inventory tied to current CDE diagrams and data flows.
• Draft baseline checklists for each NSC type (firewall, WAF, IDS/IPS, cloud security groups).
• Stand up an evidence repository structure and a review report template.

By 60 days (Run the first full review cycle)

• Execute the configuration review across all in-scope NSCs using the checklist.
• Create findings with clear owners and remediation actions.
• Collect change-management evidence for prior and current period changes.
• Hold a sign-off meeting and store dated approvals with the report.

By 90 days (Make it repeatable and audit-ready)

• Close or formally exception any high-risk findings with approvals and compensating controls documented.
• Automate config snapshotting where feasible (exports, policy backups, IaC state capture).
• Add triggers so major network changes force an out-of-cycle mini-review (new connectivity, new CDE segment, major third-party connection).
• If you use a GRC system like Daydream, map the control to owners, schedule the semi-annual task, and attach evidence requirements so reviews don’t depend on institutional memory.

Frequently Asked Questions

What counts as an NSC for PCI DSS 1.2.7?

Any network security control that enforces or monitors network boundaries or segmentation for the CDE, including firewalls, WAFs, IDS/IPS, and cloud network policies used to restrict traffic (PCI DSS v4.0.1 Requirement 1.2.7).

Can we satisfy the requirement with continuous monitoring instead of a semi-annual review?

The requirement explicitly calls for a review at least once every six months (PCI DSS v4.0.1 Requirement 1.2.7). Continuous monitoring helps, but you still need a documented periodic review with evidence and sign-off.

Our network team reviews firewall rules quarterly. Does that meet PCI?

A quarterly review can meet the “at least once every six months” cadence, but only if it covers all NSCs in scope and documents relevance and effectiveness for the CDE, not just rule hygiene (PCI DSS v4.0.1 Requirement 1.2.7).

How do we handle cloud security groups managed by multiple teams?

Centralize ownership for the review process even if implementation is federated. Your inventory should identify each security group/policy protecting the CDE, the owning team, and how you will collect and validate configuration evidence.

What evidence is most persuasive to an assessor?

A dated review report that ties each NSC to the CDE boundary, shows the checks performed against a baseline, lists findings and exceptions with approvals, and includes config snapshots or immutable references (PCI DSS v4.0.1 Requirement 1.2.7).

What if we discover a legacy “temporary” allow rule during the review?

Treat it as a finding. Either remove it, or document an exception with explicit business justification, compensating controls, owner approval, and a defined revisit trigger, then track it to closure in your remediation log.