As a QSA, one of the most common struggles I see in assessments is around PCI DSS Requirement 2.2: configuration standards. Most organizations have a patchwork of hardening efforts, but few can show a complete, documented, and enforced approach across all system components.
Configuration standards are more than just a policy document—they’re a living baseline that needs to be consistently applied to servers, network devices, laptops, and even cloud resources.
Industry-Accepted Hardening Standards
PCI DSS doesn’t dictate which standard to use—it requires you to adopt one that’s industry-accepted. Common options include:
- CIS Benchmarks – Practical and widely adopted; cover servers, databases, cloud platforms, and more.
- DISA STIGs – Very detailed, used in defense and government environments.
- Vendor Guidelines – Microsoft Security Baselines, Red Hat hardening guides, etc.
Most organizations lean on CIS Benchmarks since they map well to PCI DSS and are broadly recognized.
This is critical for remote users who connect to the CDE.
What Should be in a Configuration Standard Document
A good configuration standard should include:
- Purpose & Scope
- Roles & Responsibilities
- Baseline Settings (password policies, local admin restrictions)
- Services (disable legacy protocols like SMBv1, telnet, ftp)
- Patch Management (SLA matching 6.3 requirements)
- Logging & Monitoring
- Network Settings (Coverage of 1.2.1, 1.3.1, 1.3.2, 1.4.1, also can be a good place to include a table of ACLs)
- Tools for Enforcement or Review (e.g., Group Policy, Intune, Ansible, SecurityHub, CIS-CAT)
- References (CIS Benchmark link, vendor docs)
Enforcing Configuration Standards with Tools
This is where many organizations fail: they document the baseline but don’t monitor or enforce it.
Tools that can help:
- CIS-CAT – A tool from CIS that scans systems against CIS Benchmarks. Great for generating evidence during audits.
- AWS Security Hub – Aggregates findings across AWS accounts/services, including CIS Benchmark checks.
- Azure Defender for Cloud – Provides built-in hardening recommendations, including CIS-based baselines.
- Google Security Command Center – GCP’s native tool for security posture management.
These tools provide automated validation and continuous compliance—something manual checklists simply can’t keep up with.
Common Pitfalls I See as a QSA
- Config standards exist, but aren’t applied consistently.
- Drift happens—standards aren’t checked after deployment.
- Only servers are covered—laptops, network gear, and cloud get ignored.
- Evidence of enforcement is missing (auditors will want reports or system samples, not just a policy doc).
Conclusion
Configuration standards are a cornerstone of PCI DSS compliance, but they only work if they’re documented, implemented, and enforced. Aligning with industry-accepted standards like CIS, using tools like CIS-CAT and cloud-native security hubs, and applying the baseline across servers, endpoints, and networks is the only way to meet Requirement 2.2 and avoid nasty surprises in your next assessment.