What PCI DSS 1.2 requires for NSC configuration and why assessors focus on it
When a QSA or internal assessor asks how your firewall and network security control (NSC) rulesets are configured and kept in order, they are testing Requirement 1.2 of PCI DSS v4.0.1, the only active version of the standard. The purpose of this requirement is simple to state: every NSC in the cardholder data environment (CDE) path should run from a defined configuration standard, change only through approved steps, match an accurate picture of how the network and cardholder data actually flow, and stay that way over time. Its eight sub-requirements, numbered 1.2.1 to 1.2.8, cover ruleset standards, change control, a current network diagram, a current data-flow diagram, approved services, protocols and ports, security features for insecure services, periodic ruleset reviews, and protection of the files that configure the NSCs.
Assessors focus here because 1.2 is where paper and reality most often diverge. Rules get added for a short-term project and never removed. Changes go in through an emergency window with no ticket. The network diagram was drawn during an earlier migration and no longer shows the current segmentation. Nobody has reviewed the ruleset since the last audit. Each gap is small on its own, but together they make the rest of Requirement 1 impossible to rely on, because every control that depends on the ruleset inherits the drift. Before your assessment, ask your team to pick three NSCs at random and show, for each, the approved standard, the change record behind its latest rule, the diagram it matches and the date of its last review.
Requirement 1.2 also covers the configuration files behind the rulesets, including infrastructure as code, scripts and backed-up or remotely stored settings. Confirm with your assessor early which of these files exist in your environment, where they are stored, who can change them, and how you show that they match the active configuration. Organizations that treat these files as ordinary code, with version history, access control and review, usually find this part of the assessment far easier to evidence.
Which NSCs, diagrams and teams fall under requirement 1.2
Requirement 1.2 applies to every network security control that protects the cardholder data environment, wherever it runs and whoever manages it. The cards below cover the components, diagrams, owners and automation that an assessor will trace back to the same configuration set, so gaps in one area show up in the others.
Perimeter and internal firewalls
Physical and virtual firewalls at the CDE boundary and between internal segments are the most visible NSCs under 1.2. Each one needs a documented ruleset configuration standard, and every rule must trace to an approved business purpose. Check that the firewall inventory matches what the network diagram shows, including HA pairs, management interfaces and out-of-band paths. For illustration, a firewall added for a project and never listed in the diagram is a common finding. Open-source options such as OPNsense can produce rule-level logs for review, but the entity still owns the ruleset.
Cloud security groups and network ACLs
Cloud security groups, network ACLs, and managed firewall services are NSCs even though no appliance sits in the data center. Assessors look for the same change control and six-monthly review applied to them as to on-premises firewalls. Ask who can edit security groups from the console, and whether those edits flow through the same approval path. Inherited default rules, such as broad egress or open management ports, should be listed and justified or removed.
Host-based and container controls
Host firewalls, Kubernetes network policies and container runtime rules restrict traffic into and out of CDE workloads. Where these controls enforce the segmentation the diagrams describe, they fall under 1.2 like any other NSC. Confirm which hosts and clusters carry CDE workloads, which policies apply to each, and whether the policy objects are versioned alongside the application manifests. A node that accepts traffic outside the documented policy set is a configuration gap regardless of what the appliance shows.
Network and data-flow diagrams
Requirement 1.2 requires an accurate network diagram and an accurate data-flow diagram. The network diagram shows every connection between CDE, trusted and untrusted networks, while the data-flow diagram shows how account data moves through systems. Both must match the NSC rules in force, not the design from the original project. Ask who updates them, what triggers an update after a change, and whether a rule without a matching diagram line is treated as a finding.
Ruleset owners across network, cloud and platform
Rules are often split across the network team, the cloud team and platform engineering, and each team may own a different NSC type. Assign a named owner for each NSC family, and record who approves changes to each ruleset. Gaps appear where a platform team opens a port for a service that the network team never reviews. Map each owner to the NSCs they control so the six-monthly review has a clear reviewer for every ruleset.
Third parties that manage NSCs
Managed firewall providers, hosting companies and MSPs that administer NSCs on the entity's behalf still leave the rules under 1.2 with the entity. The entity must see the rulesets, approve changes and retain the change records, even when the provider runs the console. Confirm the contract covers change approvals, access to configuration history and how the provider's changes reach the entity's change control. Responsibility matrices should name exactly which NSCs the provider touches.
Infrastructure as code and automation
Terraform modules, Ansible playbooks, CI pipelines and scripts that push NSC configurations are configuration files under 1.2.8. The SAQ D notes treat them as in scope: they must be protected, backed up or stored remotely in a controlled way, and kept consistent with the active configuration. Check that a pipeline cannot deploy a ruleset that bypasses the change approval, and that drift between code and running state is detected and reported. Automated rulesets that differ from the repository are a finding even if no person made the change.
How a QSA tests each part of requirement 1.2
This table compares each part of Requirement 1.2 by what the assessor examines, the evidence usually requested and the findings that appear most often. Read it as a preparation checklist: for each row, confirm that the evidence exists, is current and matches the live network. The main takeaway is that assessors compare documents against the running configuration, so a diagram or standard that does not match production is usually a finding.
| Sub-area | Test approach | Evidence requested | Common findings |
|---|---|---|---|
| Ruleset configuration standards (1.2.1) | Confirm documented standards exist and are applied to each NSC type in scope | Approved configuration standards, sample NSC rulesets compared against them | Standards cover one vendor or site but not all NSCs, or are out of date |
| Change control for NSCs (1.2.2) | Sample recent network and ruleset changes and trace each to an approval | Change tickets linked to the change control process in Requirement 6.5.1, approvals, test records | Emergency changes applied with no approval record, or approvals given after the change |
| Network diagram accuracy (1.2.3) | Compare the diagram with live network paths and walk through it with staff | Current network diagram with labeled segments, the CDE boundary and connections to other networks | Diagram missing wireless, cloud or third-party connections, or showing retired segments |
| Data-flow diagram accuracy (1.2.4) | Trace sample cardholder data paths from entry to storage and transmission | Current data-flow diagram that matches observed paths and the account data it carries | Diagram omits payment channels, backups or outbound integrations |
| Approved services, protocols and ports (1.2.5 and 1.2.6) | Compare open rules against the approved list, then review each insecure service with its justification and added security features | Approved service and port list, business justifications, documented security features for any insecure service | Ports open with no owner or justification, or insecure protocols kept without documented controls |
| Six-monthly ruleset review (1.2.7) | Check the review dates and sample a review to confirm it tested relevance and effectiveness | Signed review records at least every six months, with actions and removed or updated rules | Reviews missed, or recorded as done without evidence of rule-level checks |
| Protection of configuration files (1.2.8) | Check access controls and consistency between stored settings, scripts and the active configuration | Access lists for configuration files, backups, version history, sync or drift checks, including infrastructure as code | Backups or code repositories readable by too many people, or stored settings that differ from production |
Implementing 1.2 step by step, with the output of each step
This sequence moves an organization from an unclear picture of its network controls to a configuration set that is documented, approved through change control, reviewed on a fixed cycle and protected from tampering. Each step produces an artifact that an assessor can read and test against Requirement 1.2.
Inventory every network security control in scope
Start by listing every network security control (NSC) that sits between the cardholder data environment and any other network, including physical firewalls, cloud security groups, virtual firewalls, web application firewalls and routers that filter traffic. For each device, record its owner, location, management interface, the networks it separates and the person accountable for its ruleset. Work with the network and cloud teams, and check the list against asset records and cloud account exports so nothing is missed. The output is a controlled NSC inventory that every later step references. You know it is done when each NSC maps to a named segment and a named owner, and the team can explain any device that is not on the list.
Build or correct the network and data-flow diagrams
Draw the network diagram from the inventory, showing every connection to the cardholder data environment, wireless networks, untrusted networks and third parties. Then draw the data-flow diagram showing how account data enters, moves through, is stored in and leaves the environment. The two diagrams must agree with each other and with the inventory. Engineers should verify the drawings against live configuration and routing tables, not against old design documents. The output is a current, dated pair of diagrams with a version history and an owner. You know it is done when a reviewer can trace any cardholder data path from entry to exit using only the diagrams and the NSC inventory.
Write ruleset configuration standards
Define a configuration standard for each type of NSC in the inventory. The standard states the approved baseline for rule ordering, default deny behavior, logging, administrative access, management protocols, and the documented justification required for every allowed rule. Keep one standard per device family rather than one per device, so that new devices of the same type inherit the baseline. Security and network engineering should approve the standards, and the approver's name and date should appear on each document. The output is an approved set of configuration standards. You know it is done when every NSC in the inventory is assigned to a standard and any deviation is recorded with a reason.
Define change control and link it to Requirement 6.5.1
Write the procedure that governs every change to a network connection or NSC configuration. It should cover request, risk assessment, approval, testing where practical, implementation, verification against the approved standard, and closure. Requirement 1.2.2 points to the change control process in Requirement 6.5.1, so the procedure must reference that process explicitly and must not create a parallel one. Test a sample of recent changes against the procedure to confirm each has an approval and a verification record. The output is a change control procedure with a cross-reference and a sample of completed change records. You know it is done when every recent change can be traced to an approval and a post-change check.
Document approved services, protocols and ports
For every rule that permits traffic, record the business reason, the service, the protocol, the port, the source and destination, and the owner who approved it. Include a documented justification for each insecure service, protocol or port that remains in use, together with the security features applied to compensate for the risk. Rules that cannot be justified should be removed or scheduled for removal through change control. The output is an approved services, protocols and ports register linked to the rulesets. You know it is done when every allowed rule in the NSC configurations has a matching register entry and every insecure service has a documented justification and mitigations.
Set the six-monthly ruleset review cycle
Schedule a review of every NSC configuration at least once every six months. Each review compares the live ruleset to the approved standard, checks each allowed rule against the register, and confirms that the rules still serve a current business need. Record the reviewer, the date, the findings and the actions raised. Reviews that are missed cannot be backfilled, so the cycle needs a calendar, a named owner and an escalation step when a review slips. Log-based tooling can help: for example, OPNsense can log each rule match for review, and configuration assessment tools such as Wazuh can flag drift from a baseline, but confirm each capability in your own environment before relying on it. The output is a review calendar and a set of signed review records. You know it is done when the last two review cycles are evidenced and the next one is scheduled.
Protect configuration files, backups and automation
Identify every file, backup, script, infrastructure-as-code template and automated control that configures or synchronizes an NSC. Restrict access to these files to named roles, store backups and remote copies under the same access controls as the live settings, and keep them consistent with the active configuration. Put infrastructure-as-code under version control with review before merge, and confirm that automated pipelines cannot push changes that bypass change control. Run a periodic comparison between each backup or template and the live device, and record any drift. The output is an access list for configuration files, a backup register and a drift comparison record. You know it is done when a sample of backups and templates matches the live configuration and no one outside the defined roles can alter them.
Why the six-monthly ruleset review cannot be backfilled
Requirement 1.2.7 asks for NSC configurations to be reviewed at least once every six months to confirm they are still relevant and effective. The cadence is the control. A missed review cannot be fixed after the fact: PCI SSC FAQ 1572 uses a missed six-monthly NSC configuration review as its example of a periodic activity that cannot be performed retroactively or covered by a compensating control. An assessor who finds a gap will not accept a review run later and dated back to the due date, and a compensating control will not stand in for the review that never happened. The gap stays visible for the whole assessment period, so the only real protection is making sure the review happens on time. Confirm the FAQ wording and the current compensating control guidance directly on the PCI SSC FAQ 1572 page before you write your procedure.
A review record needs to show more than a date. For each NSC, such as the firewalls, routers and cloud security groups that protect the cardholder data environment, record who performed the review, the ruleset version or export that was examined, and the checks made against the approved services, protocols and ports list and the current network and data-flow diagrams. Each rule that is no longer needed should show as removed, and each rule that stays should carry a documented business justification and an owner. Where the reviewer finds a configuration that no longer matches the diagrams, the record should show the discrepancy and the change ticket that corrects it. Keep the evidence with the rest of your Requirement 1.2 artifacts so an assessor can trace a review to a specific configuration.
Schedule the review as a recurring task with a named owner, a due date and an escalation step, rather than relying on someone remembering it. Tie the calendar entry to the change control process so that reviews and changes are visible together, and set a reminder well before each due date so a delay does not turn into a missed period. Configuration files for the NSCs, including infrastructure as code and backed-up settings, should be included in the review scope so the reviewed state matches the active configuration. If a review slips, record it openly, escalate it, and perform it immediately, because the missed period itself will still need to be explained to the assessor.
Evidence that satisfies 1.2 and how to keep it current
Requirement 1.2 is tested by documents and records that show how network security controls were configured, changed and reviewed over time. The cards below cover the artifacts an assessor usually asks for and the routines that keep each one accurate between assessments.
Ruleset configuration standards
A written standard for how each network security control (NSC) is built, including default deny stance, rule naming, logging and the approved management interfaces. Assessors compare live rulesets against this standard, so the document must describe what the systems actually run. Keep it under version control, record the owner and approval date, and re-check it whenever a platform version or vendor baseline changes. Ask your assessor which configuration baseline they will accept as the reference.
Change tickets linked to rule changes
Each change to a network connection or NSC configuration should trace to an approved ticket that shows the request, the business reason, the approver and the test result. Requirement 1.2.2 ties these changes to the change control process in Requirement 6.5.1, so the ticket system and the firewall audit log must agree. Check periodically that no rule changed without a matching ticket by comparing a sample of rule modification timestamps against the change register.
Current network and data-flow diagrams
Accurate network and data-flow diagrams show where cardholder data travels and which NSCs control each boundary. Each diagram should carry an owner, a version and a review date, and be updated when segments, cloud accounts or connections change. Assessors often test diagrams against live configuration, so walk a sample path from diagram to rule. Confirm with your assessor how they expect diagrams to be dated and approved.
Approved services, protocols and ports
A register of every permitted service, protocol and port, with the business justification and the owner who approved it. Insecure services need documented security features or a recorded reason for their use, as Requirement 1.2.6 and 1.2.5 expect. Compare the register with the active rules at each review, because rules that outlive their approval are a common finding. Aliases in your firewall can make this comparison easier to automate.
Six-monthly ruleset review records
Requirement 1.2.7 requires NSC configurations to be reviewed at least once every six months to confirm they remain relevant and effective. Keep signed review records that list the rulesets examined, the findings, the reviewer and the follow-up tickets. PCI SSC treats a missed review as a periodic activity that cannot be fixed retroactively, so calendar the next review before closing the current one and alert the owner in advance.
Configuration backups and IaC history
Requirement 1.2.8 treats backups, infrastructure as code, scripts and automated settings that configure NSCs as protected configuration files. Store them in a version-controlled repository with restricted write access, enforced review of merges, and logged access. Confirm that the stored configuration matches the active configuration by comparing hashes or diffs at each review. Ask your team and your assessor which backup retention period applies, because the standard does not fix one for you.
What meeting requirement 1.2 costs in money and effort
This table compares the cost components of Requirement 1.2 by who is paid, whether the cost is one-time or recurring, and what drives it up or down. No figures are given because none were supplied, so use the drivers and the quote checklist to compare proposals on equal terms. The main takeaway is that the recurring six-monthly review and change control work usually costs more over time than the one-time cleanup.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it |
|---|---|---|---|
| Tooling or licenses | Software vendor or open-source project, plus any support contract | Recurring if licensed, one-time if deployed open source | Number of NSCs, licensing metric, support tier. Self-hosted open source can remove license spend but not operating effort |
| Ruleset cleanup and documentation | Internal network engineers or an implementation partner | One-time, repeated after major network changes | Rule count, rule age, undocumented exceptions, number of firewall vendors and platforms |
| Network and data-flow diagrams | Internal architects, with an outside partner if the team lacks time | One-time to create, recurring to keep accurate | Number of network segments, cloud accounts, third-party connections and how often topology changes |
| Approved services and ports register | Internal security and network owners | One-time to build, recurring to maintain | Number of approved services, protocols and insecure-service exceptions that need justification |
| Change control process work | Internal change board and engineers; tooling if the workflow is automated | One-time to design, recurring to run | Change volume, approval steps, emergency change frequency, and whether tickets link to configuration records |
| Six-monthly ruleset review | Internal reviewers, sometimes with an outside reviewer for independence | Recurring, at least every six months | Number of NSCs and rules, quality of prior records, and whether reviews can reuse automated reports |
| Configuration file protection | Internal platform or infrastructure team | One-time setup, recurring checks | Use of infrastructure as code, backup locations for settings, and number of automated scripts that touch NSCs |
| External review or QSA time | Qualified Security Assessor or internal assessor, paid by the assessed entity | Recurring at each assessment | Size of the environment, evidence quality, and how many samples the assessor selects |
| Assessor sampling effort | Internal staff who pull change tickets, review records and screenshots during the assessment | Recurring at each assessment | Number of change tickets sampled, how easily records can be retrieved, and whether evidence is stored in one place |
Who owns, implements and validates requirement 1.2
Your organization owns requirement 1.2 in full. The standard places the duty on the entity being assessed, so no partner or assessor can accept that accountability on your behalf. Your security and network teams approve every ruleset change, sign off the standards that NSC configurations must follow, and carry out the six-monthly review that confirms each configuration is still relevant and effective. Your change control process must be the one that Requirement 6.5.1 defines, and it must cover network connections as well as NSC settings.
- Ruleset ownership: Named people approve each NSC ruleset and its business justification, and they keep the record of who approved what and when.
- Change approval: Every change to a network connection or NSC configuration passes through your change process before it reaches production.
- Six-monthly reviews: Your team runs and documents the review of each NSC configuration at least once every six months.
- Approved services and ports: Your team decides which services, protocols and ports are permitted and records the reason for each insecure one that remains.
- Configuration file custody: Your team controls who can read and change the stored, backed-up or code-defined settings that configure NSCs.
Before you engage anyone, confirm that each of these duties has a named owner and a recurring calendar entry.
An implementation partner helps you build the artifacts that requirement 1.2 asks for and keeps them consistent with the live environment. A partner such as DeployOpen can plan and implement self-hosted open-source platforms inside your own cloud accounts, data centers or networks, then prepare the diagrams, standards and configuration evidence that your team reviews. The partner works on systems and documentation. It does not approve changes, accept risk on your behalf, or issue any validation report.
- Network and data-flow diagrams: The partner drafts accurate diagrams from the live environment, which your team checks and approves.
- Configuration standards: The partner drafts hardened ruleset standards for your firewalls and equivalents, such as OPNsense, for your team to adopt.
- Configuration as code: The partner can place NSC settings under version control so that changes are traceable and reproducible.
- Monitoring of drift: Tools such as Wazuh Security Configuration Assessment or Fleet policies can show when endpoints stray from a defined baseline, and the partner configures and tunes them.
- Evidence packs: The partner assembles exported configurations, change tickets and review records for the assessor to sample.
Confirm in writing which of these artifacts the partner delivers, who maintains them after handover, and who approves them before they become evidence.
The Qualified Security Assessor (QSA) or the internal assessor tests whether requirement 1.2 is in place and writes the findings into the Report on Compliance or the relevant self-assessment documentation. An assessor must be independent of the work it tests. If the same firm designed the diagrams, wrote the ruleset standards and then judged them, the result is a conflict of interest that a QSA cannot resolve by disclosure alone. The assessor samples your records, interviews staff and inspects live configurations, and it reports what it finds.
- Sampling: The assessor selects rulesets, changes and review records and traces each one back to its approval.
- Diagram testing: The assessor compares the network and data-flow diagrams against observed traffic and configurations.
- Configuration inspection: The assessor reviews live NSC settings and the protection of configuration files.
- Independence limits: A QSA may not prepare the evidence it tests, so partner-built artifacts must be reviewed by your team before the assessor sees them.
- Internal assessors: Where your organization uses an internal assessor, that person must still be separate from the people who built the controls being tested.
Before your assessment starts, ask the assessor which artifacts it will sample and whether the partner's role has been disclosed in writing.
Open-source tools that produce 1.2 evidence
Requirement 1.2 is proven with records: approved rulesets, change history, review outcomes and configuration checks. The tools below can generate several of these records from a self-hosted platform, but each one produces evidence only for the components it actually runs against, so confirm the match before an assessor asks.
OPNsense rule logging and aliases
OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Aliases group addresses and ports so the approved services list in 1.2.5 can be read straight from the ruleset rather than reconstructed from memory. Enabling per-rule logging gives you match records that support the six-monthly review in 1.2.7. Confirm that the firewall in scope is the one exporting these logs, and that rule changes are tied to approved change tickets under 1.2.2.
Wazuh configuration assessment checks
Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, most of them based on CIS benchmarks, and reports pass or fail results with remediation advice. Custom policies can check files, directories and running processes that hold NSC management settings. Its output shows configuration drift on hosts that manage or sit beside NSCs. Confirm that every system that stores or manages NSC configuration is enrolled, and that custom policies match your approved ruleset standard.
Fleet policies for device settings
Fleet policies ask yes or no questions of devices, written as osquery queries, and the policies page lists which devices in each fleet pass or fail each one. You can use them to confirm that managed admin workstations, jump hosts and other devices that reach NSC management interfaces hold the settings your standard requires. Failing devices give a traceable list for remediation. Confirm that the queries cover the settings in your own standard, since Fleet reports only what you ask it to check.
Coraza web application firewall rulesets
Coraza is an Apache-2.0 licensed web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It has integrations for Caddy, HAProxy, Traefik and Nginx, and it can block attacks such as SQL injection and cross-site scripting at the application edge. Version-controlled rulesets give 1.2.2 and 1.2.8 a clear change history. Confirm that the WAF is inside the NSC inventory and diagrams, because a WAF that is not documented as an NSC will not satisfy the requirement on its own.
Questions buyers ask about requirement 1.2 before hiring help
How much effort does requirement 1.2 take to meet?
The effort depends mainly on how many network security controls you run, how many rules they hold, and how well those rules are documented today. Requirement 1.2 covers eight sub-requirements, so the work spans configuration standards, change control, an accurate network diagram, an accurate data-flow diagram, approved services and ports, security features for insecure services, a six-monthly review and protection of configuration files. Most of the effort is one-time cleanup and documentation, followed by recurring work: every change must go through change control, and every six months each NSC configuration must be reviewed. Ask any provider to split its quote into the one-time cleanup and the recurring review cycle so you can see what continues after the first pass.
Can an in-house team meet requirement 1.2 without outside help?
Yes, many organizations do, provided the team has people who understand firewall configuration, change management and network topology, and has time to review rules with the owners of each business service. The common gap is not technical skill but the documentation: an accurate network diagram and data-flow diagram must match the live environment, and the team must be able to explain why each approved service and port is needed. If the team has never reconciled rules against diagrams, the first pass usually reveals stale rules and undocumented exceptions. Outside help is most useful for that first reconciliation and for building the configuration standard, while the recurring reviews can stay in-house.
What does requirement 1.2 need from engineering and network owners?
It needs named owners who can approve changes and confirm business need. Network engineers must hold the current NSC configurations and explain each rule. Application and service owners must confirm which services, protocols and ports their systems use. Engineering teams that manage infrastructure as code, scripts or automated controls must treat those files as configuration files, secured and kept consistent with the live settings. Security or compliance staff usually own the change control process and the six-monthly review record. Agree on these roles in writing before the work starts, because the review cannot be backdated and gaps in ownership show up quickly during assessment.
How long does ruleset cleanup take, and what drives the time?
The timeline depends on drivers rather than a fixed number: the count of rules across all NSCs, the number of rules with no documented owner or business reason, the number of environments and cloud accounts involved, and whether the diagrams need to be rebuilt from scratch. Rules that permit broad source or destination ranges take longer because each one needs a justification or a narrower replacement, and each change must be tested against the services that depend on it. Ask a provider to show how it will sequence the work, which environments it covers first, and what it needs from your team to keep the timeline, instead of relying on a single duration figure.
Can a consultant prepare 1.2 evidence without affecting assessor independence?
Yes, if the consultant prepares systems, documentation and evidence for your team to own, and the assessor independently tests them. Independence is preserved when the consultant does not sign off on the compliance conclusion, does not produce the report on compliance, and does not issue the attestation. Only the qualified security assessor issues the report and attestation for your organization. Ask the consultant to document in the engagement scope which artifacts it prepares, who approves them, and how the assessor will receive them, so the separation is clear from the start.
What will a QSA sample when testing requirement 1.2?
A qualified security assessor typically tests the documents against the live environment. Expect samples of the NSC configuration standards, a selection of recent changes traced through change control, the current network and data-flow diagrams compared with actual connections, the approved services and ports list checked against live rules, and the record of the most recent six-monthly configuration reviews. Assessors also look at how configuration files for infrastructure as code and automated controls are protected and whether they match the active settings. Confirm the exact sample sizes and evidence format with your assessor, because the assessor sets the sample, not the consultant.
Which parts of requirement 1.2 are hardest to fix after the fact?
The six-monthly review is the part most often missed, and it cannot be performed retroactively. The PCI SSC treats a missed periodic activity as something a later compensating control does not cover, so a gap in review history stays visible to the assessor. Diagram accuracy is the other frequent problem: a diagram that was correct last year but no longer matches the live environment will fail the test even if the rules are sound. Plan the review calendar and the change control record first, so that every later cleanup step produces evidence on time.
Official PCI SSC sources for requirement 1.2
Before you change a ruleset, rebuild a diagram or agree a review cadence for requirement 1.2, read the requirement text in the official standard. The PCI Data Security Standard page on the PCI SSC website is the authoritative starting point, and it is where you confirm that you are working from the current version, PCI DSS v4.0.1, rather than a retired release or a secondary summary. Keep a dated copy of the version you assess against, because your evidence for the network security control configuration standards, change approvals and six-monthly reviews must match the wording your assessor uses. Note that the PCI SSC publishes the standard but does not enforce it, so confirm with your acquirer or the payment brands which validation route applies to your organization.
If you are a service provider, or you maintain network security controls on behalf of one, the PCI DSS v4.0 Self-Assessment Questionnaire D for Service Providers is the next read. Its notes on requirement 1.2 show how the assessor expects you to treat infrastructure as code, scripts, automated controls and backed-up or remotely stored settings that configure network security controls, which means those files need the same protection and consistency checks as the active configuration. Use the questionnaire to build a checklist of the eight sub-requirements, then ask your team which artifacts already exist for each one and where they are stored. Confirm the questionnaire version currently listed on the PCI SSC site before you rely on it, since the document is a version-specific file.
How DeployOpen prepares NSC configuration evidence for requirement 1.2
DeployOpen prepares the network security control configuration records that Requirement 1.2 expects, inside your own infrastructure. The organization still owns its controls, and only an independent assessor can validate them.
How we scope
- Agree in writing which firewalls, cloud security groups and other NSCs fall under the 1.2 review, with the systems each one protects.
- Confirm which network and data-flow diagrams exist, and list the gaps the written scope will close.
- Define the configuration files, scripts and backed-up settings that count as NSC configuration under 1.2.8 for your environment.
How we build
- Set up configuration baselines for each NSC type, with approved services, protocols and ports documented in the ruleset standards.
- Route ruleset changes through the change control process your organization already uses, so each change carries an approval record.
- Store configuration files under access control with version history, and check that the backed-up copies match the active settings.
How we hand over
- Deliver the written configuration standards, diagrams, change records and file inventory in a format your assessor can review.
- Provide a documented six-monthly ruleset review procedure with a template for recording each review and its outcome.
- Walk your team through the evidence set so the organization can keep it current after the engagement ends.
How we support
- Offer ongoing support as a retainer for ruleset reviews, configuration drift checks and updates to the diagrams.
- Ask the assessor, or your QSA, to confirm which evidence formats they accept before the work is finalized.
- Revisit the scope when systems, connections or payment flows change, so the evidence stays aligned with the cardholder data environment.
