Every organization that stores, processes, or transmits cardholder data is subject to PCI DSS. Most IT teams know that. What catches them in assessments is the gap between having a hardening policy and being able to show a Qualified Security Assessor (QSA) that the policy is enforced, continuously, across every system in the Cardholder Data Environment (CDE).
PCI DSS v4.0, now fully mandatory as of March 31, 2025, made that gap harder to paper over. The standard explicitly rejects point-in-time compliance and requires continuous security monitoring as a business-as-usual process. This page covers what that means for server configuration controls specifically — what Requirement 2.2 requires, what changed under v4.0, what QSAs are looking for in 2026 assessments, and where CHS fits.
What Is PCI DSS?
The Payment Card Industry Data Security Standard (PCI DSS) is a global security framework developed by the PCI Security Standards Council (PCI SSC), a body founded by American Express, Discover, JCB, Mastercard, and Visa. It sets technical and operational requirements for any organization that stores, processes, or transmits cardholder data — merchants, payment processors, service providers, and the technology vendors serving them.
PCI DSS is not a government regulation. It’s a contractual requirement enforced by the card brands through your acquirer. Non-compliance consequences include fines, breach liability, higher transaction fees, and in serious cases, loss of the ability to process card payments.
The current version is PCI DSS v4.0.1, which has been mandatory since March 31, 2025. v3.2.1 was retired in March 2024. If your last assessment was against v3.2.1, your next one will be against v4.0.1 — and 51 requirements that were optional best practices under v4.0 are now enforceable.
What Changed in v4.0 That Matters for Server Hardening
The most significant shift in v4.0 is not a specific requirement. It’s a change in how compliance is defined.
Under v3.2.1, organizations could treat PCI DSS as an annual compliance event: assess, remediate, submit the Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ), and return to business as usual until the next cycle. PCI DSS v4.0 explicitly rejects this model. The standard now requires security as a continuous, business-as-usual process — controls must be enforced and monitored on an ongoing basis, not restored for assessment and then allowed to drift.
For configuration management specifically, this changes the conversation with a QSA from “here’s our hardening policy” to “here’s evidence our hardened configurations are consistently enforced across the CDE right now.” The distinction matters: point-in-time hardening that drifts between assessments no longer satisfies the standard.
Other v4.0 changes relevant to server configuration teams:
Targeted Risk Analysis (TRA). Organizations can now set the frequency of certain activities — scans, log reviews, configuration reviews — through their own risk analysis rather than following fixed PCI-prescribed intervals. The flexibility is real, but it comes with a documentation burden: the risk reasoning has to be recorded and defensible to a QSA.
Requirement 6.3.3. All system components must be protected from known vulnerabilities by installing applicable security patches/updates. For organizations with large server estates, this makes automated patch-and-configuration tracking more important, not less. [Flag: verify Requirement 6.3.3 language against v4.0.1 standard before publishing.]
Requirement 12.3.2. A Targeted Risk Analysis must be performed for each PCI DSS requirement that provides flexibility in how frequently it is performed. This is new documentation overhead that didn’t exist under v3.2.1. [Flag: verify requirement number against v4.0.1 standard before publishing.]
Requirement 2.2: What It Actually Says
Requirement 2.2 requires organizations to develop and implement configuration standards for all system components. The standard must:
- Address all known security vulnerabilities
- Be consistent with industry-accepted hardening standards (CIS Benchmarks, DISA STIGs, vendor security guidance)
- Be updated as new vulnerability issues are identified
- Be applied when new systems are deployed and verified at intervals defined by a Targeted Risk Analysis
“Develop configuration standards for all system components that address all known security vulnerabilities and are consistent with industry-accepted definitions. Update system configuration standards as new vulnerability issues are identified.” — PCI DSS v4.0.1, Requirement 2.2 [Flag: verify this exact quote against the v4.0.1 standard document — carried forward from the current live page, needs confirmation against the v4.0.1 text specifically.]
What QSAs are looking for under 2.2 in 2026: not the policy document, but evidence the policy is enforced. The difference between a v3.2.1 assessment and a v4.0.1 assessment on this requirement is that “we have a hardening standard” is no longer sufficient on its own. The QSA wants to see that the standard is applied consistently across in-scope systems and that there’s a process for detecting and remediating drift.
What Qualifies as a CDE System
Scope creep is one of the most common sources of unexpected PCI findings. Under v4.0, the CDE includes:
- Systems that store, process, or transmit cardholder data
- Systems that can impact the security of those systems (connected systems, authentication systems, management infrastructure)
- Systems in network segments that are not isolated from the CDE
Every system in scope for the CDE must meet Requirement 2.2. If your scoping is wrong — if systems you thought were out of scope turn out to be connected — your hardening gap is larger than you planned for. QSAs will test scope boundaries.
What QSAs Check: The Evidence Gap
The most common Requirement 2.2 finding is not a missing hardening standard. It’s a hardening standard that exists on paper and can’t be demonstrated on the systems.
A typical assessment scenario: the QSA asks for evidence that specific hardening controls — disabling unnecessary services, removing default accounts, restricting remote access protocols — are applied across CDE systems. The IT team produces the policy document and the initial deployment checklist. The QSA asks for the current configuration state of the actual systems, across the full CDE, today. If that requires manually checking a sample and hoping nothing has changed since the last push, the finding writes itself.
QSAs are also now asking about the continuous monitoring piece explicitly under v4.0. “How do you know when a configuration changes?” and “What happens when drift is detected?” are standard questions. “We’d notice” is not an answer.
Checklist: What You Should Have Ready Before a QSA Engagement
- Configuration standards documented per system role — servers, databases, network devices treated separately, with specific hardening requirements for each
- Standards mapped to a recognized baseline: CIS Benchmarks, DISA STIGs, or vendor-published security guidance
- Evidence that standards are applied to new systems before deployment, not retrofitted afterward
- Point-in-time configuration state evidence for CDE systems — scan output, GPO reports, or agent-collected data showing current state, not policy intent
- Change log with timestamp, account, modified setting, and before/after value for every configuration change on CDE systems
- Drift detection process with documented remediation workflow — alert to resolution, not just alert to inbox
- Targeted Risk Analysis documentation for any Requirement 2.2 activities where you’ve set custom frequencies
- Scope documentation showing which systems are in the CDE and why connected systems are or aren’t in scope
- Evidence package organized by system/asset ID — not assembled from tickets, emails, and spreadsheets the week before the QSA arrives
[Gated download CTA]
Insert existing gated checklist asset here. Suggested CTA copy: “Download the PCI DSS server hardening checklist — organized by system role, mapped to Requirement 2.2, ready to hand to a QSA.” [Confirm asset title and landing page URL before publishing.]
For MSPs and IT Service Providers
If you manage IT infrastructure for merchants or payment processors, PCI DSS Requirement 2.2 applies to the systems you manage on their behalf. Your clients’ QSAs will expect you to produce evidence of enforced hardening on CDE systems — and “our MSP handles that” is not a sufficient answer without the supporting documentation.
Under v4.0’s continuous monitoring expectation, MSPs managing PCI-scoped infrastructure need a defensible answer to how configuration drift is detected and remediated between assessment cycles, not just at assessment time. Managing that manually across multiple client environments creates a sampling problem: if a QSA pulls a random selection of CDE systems and finds drift, the finding reflects on the entire estate, not just the sampled systems.
CHS gives MSPs a single console to enforce and evidence baseline configuration state across multiple client CDE environments without per-client manual checks.
How CHS Fits
CHS automates the server and system hardening layer that Requirement 2.2 calls for: enforced baseline configurations, continuous drift detection, change logging with before/after values, and audit-ready evidence exports. Learning Mode lets teams preview the impact of a policy change before pushing it to production — relevant for CDE systems where untested configuration changes can cause outages.
For QSA engagements specifically: CHS produces the evidence package QSAs ask for under v4.0’s continuous compliance model. Current configuration state by system, change history with timestamps and account attribution, and drift detection records showing when deviations occurred and when they were remediated.
CHS is not a QSA, doesn’t scope your CDE, doesn’t manage your ROC or SAQ, and doesn’t cover the full 12 requirements. PCI DSS compliance requires people, process, and often a QSA firm for level 1 merchants. CHS closes the gap between having a Requirement 2.2 policy and being able to evidence it is enforced — which is consistently where configuration findings originate.
PCI DSS v4.0 moved the goalposts on configuration compliance. Annual hardening checks don’t satisfy a standard that explicitly requires continuous enforcement. If you want to see what CHS evidences automatically versus what your team is still producing by hand before a QSA engagement, contact us to speak to an expert.
