PCI DSS 2.1.1: All security policies and operational procedures that are identified in Requirement 2
PCI DSS v4.0.1 control 2.1.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 2.1.
Requirement 2: Apply Secure Configurations to All System Components › Section 2.1
All security policies and operational procedures that are identified in Requirement 2 are:
- Documented.
- Kept up to date.
- In use.
- Known to all affected parties.
Summary
The policies and procedures behind Requirement 2 are written down, current, followed, and known to the people they apply to.
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 | |
|---|---|
| 2.1.1 | Examine documentation and interview personnel to verify that security policies and operational procedures identified in Requirement 2 are managed in accordance with all elements specified in this requirement. |
Requirement 2 already mandates its own central document: the configuration standards in 2.2.1. That leaves 2.1.1 covering the procedures around those standards, which is where the gaps are: how a new system is built to standard, how drift from it is detected, and how a standard is revised when a new vulnerability appears. The element that has quietly broken is "known to all affected parties". Configuration standards were written when a platform team built servers. In an environment using infrastructure as code, the people applying them are developers committing Terraform or container definitions, and a standard that lives in the platform team's document repository never reaches the person actually deciding a base image.
What to prepare
- The Requirement 2 documents as a set: the configuration standards, the build procedure, the drift-detection process, and the update process.
- An owner and a review date on each.
- Who the affected parties are, named as roles, including anyone who defines infrastructure in code.
- Evidence they are in use, meaning built systems match the standard.
How to implement it
1. Find out who actually configures systems now. If it is developers, the standard has to reach a repository and a pipeline, not a document library.
2. Express the standard where it will be applied. A hardened base image or a policy-as-code rule is a configuration standard that enforces itself, and it satisfies "in use" in a way a document cannot.
3. Give the update process a trigger. Standards go stale between assessments unless something says when to revise them, and new vulnerabilities affecting a platform are the natural prompt.
4. Cover cloud service configuration. Storage, databases and managed services all have security parameters and are configured by whoever provisions them.
Where this commonly fails
- Standards written for a server build team that no longer builds servers.
- Infrastructure defined in code with no reference to the configuration standards at all.
- A standard that is documented and not applied, which fails "in use" while passing "documented".
- Cloud managed services outside the standards entirely, because they were not thought of as systems.
Related controls
Others in section 2.1:
| Control | What it requires |
|---|---|
| 2.1.2 | Roles and responsibilities for performing activities in Requirement 2 are documented, assigned… |
← 1.5.1 · All controls · 2.1.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.