PCI DSS 2.2.1: Configuration standards are developed, implemented, and maintained
PCI DSS v4.0.1 control 2.2.1: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 2.2.
Requirement 2: Apply Secure Configurations to All System Components › Section 2.2
Configuration standards are developed, implemented, and maintained to:
- Cover all system components.
- Address all known security vulnerabilities.
- Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.
- Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.
- Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.
Summary
Write down how each type of system is to be built and hardened, base it on a recognised standard, and keep it current as new vulnerabilities appear.
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.2.1.a | Examine system configuration standards to verify they define processes that include all elements specified in this requirement. |
| 2.2.1.b | Examine policies and procedures and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.3.1. |
| 2.2.1.c | Examine configuration settings and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before or immediately after a system component is connected to a production environment. |
The foundation of Requirement 2: almost everything else in it is a specific instance of a configuration standard being applied. Three procedures, and they escalate. 2.2.1.a examines the standards. 2.2.1.b examines the sources they are based on, so a hardening document written from memory rather than from a recognised baseline fails here. 2.2.1.c examines whether new system components are actually configured to them. The last is where most entities lose the control: the standard exists and is good, and the machine built last month does not match it.
What to prepare
- The configuration standards themselves, one per system type you run.
- The industry baseline each is derived from, named: CIS Benchmarks, a vendor hardening guide, or equivalent.
- Evidence of the update process, showing standards changed when new vulnerabilities appeared.
- Build evidence for recently provisioned systems, showing they match the standard.
How to implement it
1. Start from a published baseline rather than a blank page. CIS Benchmarks and vendor hardening guides exist for almost everything, and 2.2.1.b asks what yours is based on. Deriving from one and documenting your deviations is far less work than writing one, and far easier to defend.
2. Record deviations with reasons. Every real environment departs from a benchmark somewhere. A standard that claims full compliance and does not match production is worse evidence than one that lists five documented exceptions.
3. Enforce the standard at build time. Configuration management, a hardened image, or infrastructure as code turns 2.2.1.c from an audit into a property of the build. Hardening applied by hand after provisioning is hardening that drifts.
4. Cover every system type, including the ones nobody owns. The build server, the jump host, the monitoring box and the developer laptop that reaches production are all system components. Coverage gaps are usually ownership gaps.
Where this commonly fails
- A standard written once, dated years ago, with no evidence it was revisited as new vulnerabilities appeared.
- Hardening that exists in a wiki page rather than in the build, so new systems inherit whatever the installer defaulted to.
- Cloud resources treated as out of scope for configuration standards because they are not servers.
- No named baseline, so 2.2.1.b has nothing to examine.
Related controls
This control refers to 6.3.1.
Others in section 2.2:
| Control | What it requires |
|---|---|
| 2.2.2 | Vendor default accounts… |
| 2.2.3 | Primary functions requiring different security levels… |
| 2.2.4 | Only necessary services, protocols, daemons, and functions are enabled… |
| 2.2.5 | If any insecure services, protocols, or daemons are present… |
| 2.2.6 | System security parameters are configured to prevent misuse |
| 2.2.7 | All non-console administrative access is encrypted using strong cryptography |
← 2.1.2 · All controls · 2.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.