PCI DSS 1.2.1: Configuration standards for NSC rulesets
PCI DSS v4.0.1 control 1.2.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 1.2.
Requirement 1: Install and Maintain Network Security Controls › Section 1.2
Configuration standards for NSC rulesets are:
- Defined.
- Implemented.
- Maintained.
Summary
Write down how your firewalls and security groups are supposed to be configured, make the live rules match that document, and keep both current.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 1.2.1.a | Examine the configuration standards for NSC rulesets to verify the standards are in accordance with all elements specified in this requirement. |
| 1.2.1.b | Examine configuration settings for NSC rulesets to verify that rulesets are implemented according to the configuration standards. |
Note the two halves. 1.2.1.a tests the document; 1.2.1.b tests reality against it. Producing a polished standard that does not match your live rules fails this control just as surely as having no standard at all, and it is the more common failure, because the document is written once and the rules keep moving.
What to prepare
- A written configuration standard for each type of NSC you run. One document covering "the firewall" is not enough if your cardholder data environment actually sits behind cloud security groups.
- An export of the live ruleset for each NSC, dated, so it can be compared against the standard.
- The mapping between them: for each rule in production, the clause of the standard that permits it.
- Version history for the standard, showing it is maintained rather than written once.
How to implement it
1. Decide what counts as an NSC in your environment. v4.0.1 deliberately stopped saying "firewalls and routers". Anything enforcing network policy qualifies: cloud security groups and network ACLs, on-premise firewalls, host-based firewalls, container network policies, service mesh authorisation rules. Enumerate them before writing anything. The gap assessors find most often is a standard that describes a perimeter appliance while the CDE runs in a cloud account nobody documented.
2. Write the standard so it constrains real decisions. A standard that says "firewalls will be securely configured" is unusable and untestable. State the default posture (deny inbound and outbound, permit by exception), which protocols and ports are permitted and in which zones, that every rule carries a business justification and an owner, the naming conventions for rules, and who approves a change.
3. Implement it in a way that makes drift visible. For cloud environments, define the rules in infrastructure-as-code and treat the repository as the implementation of the standard. The comparison 1.2.1.b asks for then becomes a diff rather than a manual audit, and drift shows up as an unreviewed commit. Where rules are managed by hand, schedule an export-and-compare instead, but expect that to decay.
4. Maintain it deliberately. Version the document, record who reviewed it and when, and route every ruleset change through the change control process required by 1.2.2, which in turn points at Requirement 6.5.1. A standard with no revision history reads to an assessor as one nobody uses.
Where this commonly fails
- The standard covers the datacentre firewall but not the AWS security groups the CDE actually sits behind.
- The standard is vendor boilerplate that does not describe the rules in production, so 1.2.1.b fails even though 1.2.1.a passes.
- Rules accumulate with no justification recorded, so nobody can say why a rule exists or safely remove it.
- The document was approved once at the last assessment and has no revisions since.
Related controls
Others in section 1.2:
| Control | What it requires |
|---|---|
| 1.2.2 | All changes to network connections and to configurations of NSCs are approved and managed… |
| 1.2.3 | An accurate network diagram(s) is maintained that shows all connections between the CDE… |
| 1.2.4 | An accurate data-flow diagram(s) is maintained that meets… |
| 1.2.5 | All services, protocols, and ports allowed are identified, approved… |
| 1.2.6 | Security features are defined and implemented for all services, protocols… |
| 1.2.7 | Configurations of NSCs are reviewed at least once every six months to confirm they are relevant… |
| 1.2.8 | Configuration files for NSCs… |
← 1.1.2 · All controls · 1.2.2 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.