PCI DSS Compensating Controls: Why the Worksheet Fails Before the Control Does
PCI DSS compensating controls are documented alternative controls that can stand in for a requirement only when a legitimate technical or business constraint makes it impossible to meet the requirement as stated. The PCI SSC requires the constraint, a risk analysis, and evidence the control operates effectively and is maintained. Most fail on the constraint documentation, not the control.
Your legacy commerce server is two versions behind the vendor's supported line. The fix is a major upgrade your release calendar cannot absorb this year, and your assessor has asked how you are meeting the requirement as stated. This is the moment organizations reach for a PCI DSS compensating control, and the moment most of them start losing.
In our assessments, the alternative control is usually fine. What falls over is the paragraph before it, the one that has to prove the standard control is genuinely impossible, because it was written by whoever owned the deadline, not by whoever understands the constraint.
The timing of this question is not accidental. On June 10, 2026, the PCI SSC published a new information supplement, PCI DSS v4.x: Guidance for Compensating Controls and the Customized Approach, developed with the assessor community, and its central warning is that incomplete documentation can leave an assessor unable to validate the control at all [1]. IBM's 2026 Cost of a Data Breach data, covering 602 organizations between March 2025 and February 2026, puts the global average breach cost at $4.99 million and financial services breaches at $6.3 million [2]. On September 8, 2026, CISA added four known exploited vulnerabilities to its catalog, including a template engine flaw in Adobe Commerce and Magento and a code injection flaw in N-able N-central [3]. New guidance, rising breach costs, and exploited legacy software: all three point at the same constraint.
Clone Systems' position, from the assessment side of this: a compensating control submission almost never fails because the alternative control is weak. It fails in the constraint field, where the documented reason reads like a budget memo instead of a technical or business impossibility. Below we cover what the standard requires, the four failure modes we see in rejected worksheets, how a compensating control differs from the customized approach, and the self-test to run before you submit.
What Is a PCI DSS Compensating Control?
A PCI DSS compensating control is a documented alternative control that can stand in for a requirement only when a legitimate technical or business constraint makes it impossible to meet the requirement as stated. It is an option within the defined approach, not a general exception mechanism, and the assessor has to be able to validate it before the exception counts.
The word doing the work is legitimate. The PCI SSC's June 2026 guidance is explicit that compensating controls apply when an organization cannot meet a defined requirement because of a constraint, and it makes documentation quality the linchpin: if the documentation is incomplete, the assessor may be unable to validate that the control is in place and operating effectively [1]. In practice the worksheet has to carry three things together. The constraint, with evidence. The risk that the missing control creates. And the proof that the alternative control covers both, now and on a schedule.
Where legitimate constraints actually come from
- Unsupported or unpatchable software. The vendor has stopped releasing a fix for your version, or the fix lands in an upgrade the environment cannot absorb inside the compliance window. The September 8, 2026, CISA catalog additions are the live example: a template engine flaw in Adobe Commerce and Magento and a code injection flaw in N-able N-central are the class of exposure that legacy commerce and management software carries [3].
- Change dependencies. Meeting the requirement as stated would force a change to something else that is in scope, a payment terminal fleet on a certified firmware line, or an integration that would require revalidation.
- Physical or business conditions. The control cannot be deployed where it is supposed to run, and the condition is verifiable rather than asserted.
Cost, inconvenience, and "we plan to fix it next year" are not constraints in this sense. They are deferrals, and an assessor will read them that way. When the constraint is an unpatched system, the evidence that makes it real is the same evidence that closes a scanner finding: a vendor advisory naming the version, the installed release, and a connecting statement. We wrote that out in why your vulnerability scanner flags patched systems [5].
Why Do PCI DSS Compensating Controls Fail Review?
We have reviewed enough rejected worksheets to pattern them, and the alternative control is rarely the problem. We call this The Clone Systems 4 Failure Modes of the Compensating Control Worksheet, because every fix is a document fix, not an engineering fix.
Failure mode 1: The cost constraint. The documented reason is budget, timeline, or effort. The standard's test is a technical or business constraint [1], and a budget line is not one. The fix is to state the actual technical condition: which version, which patch, which change the environment cannot absorb, with evidence attached.
Failure mode 2: The borrowed control. The worksheet names a control from another requirement and claims it covers this one, without the mapping. "We monitor the environment" covers almost nothing by itself, unless the worksheet shows what is monitored, what the alert means, and who acts on it.
Failure mode 3: The orphaned risk. The risk analysis names a risk the missing control creates, and the compensating control reduces a different one. The two halves of the worksheet do not connect, and the assessor sees a claim of equivalence with no mapping of objectives.
Failure mode 4: The maintenance gap. The control was validated once at submission and never revisited. The standard expects the control to keep operating effectively, and the next audit finds a control that quietly drifted: a feed that stopped, an alert nobody owns, a review that was never scheduled. Incomplete documentation is what keeps the assessor from validating [1], and a control that is no longer operating cannot be documented as operating.
If you are building a compensating control around an unpatched system, keep the scanning side of your evidence current while you do. As a PCI SSC Approved Scanning Vendor, Clone Systems' PCI ASV external vulnerability scanning keeps the attestation file clean while the constraint story is built, and our team can review your draft worksheet before it reaches your assessor.
PCI DSS Compensating Controls vs the Customized Approach: Which Do You Need?
A compensating control is for a requirement you cannot meet as stated because of a constraint. The customized approach is for a requirement you choose to meet differently, and the PCI SSC's June 2026 guidance now spells out the difference between the two [1].
| Compensating control | Customized approach | |
|---|---|---|
| Triggers | A legitimate technical or business constraint | A deliberate choice to meet the requirement differently |
| Position in PCI DSS | An option within the defined approach | A separate approach with its own objectives [1] |
| Capability expected | A documented constraint and a validated alternative control | A mature risk function with the capacity to design, document, test, and maintain novel controls [1] |
| Validation | The assessor tests the alternative control against the requirement's objectives | The assessor validates against the stated customized approach objective [1] |
| Coexistence | Yes, both can apply to the same requirement, documented separately [1] | Yes, documented separately [1] |
The practical read: most organizations writing a worksheet for one legacy system are doing a compensating control, and reaching for the customized approach is a different commitment with a different bar. The guidance is direct that the customized approach is not universally appropriate. It is designed for entities with robust risk management practices and the internal capacity to own the control over time [1].
How Do You Know if Your Constraint Is Legitimate?
Run this 4-Question Draft Self-Test before the worksheet leaves your building. It is the same test we apply when a client brings us a draft, and it takes about ten minutes.
- Could a technically competent team meet the requirement as stated, with the tools and timeline available? If yes, you have a preference, not a constraint, and no worksheet survives that sentence.
- Does the constraint statement name a specific technical or business condition, with evidence? The version, the vendor's support status, the change dependency, the affected systems. Not a budget line.
- Does every element of the requirement's objective map to a specific element of the alternative control? The gaps in the mapping are where the assessor will find the risk.
- Is the alternative control on a maintenance cycle with retained evidence? A dated revalidation, an owner, and a stored result. If the answer is "we will do that later," the worksheet is not done.
One structural rule surprises most clients, and it is in the guidance: an assessor involved in designing or implementing the control cannot validate that same control [1]. If your integrator built the workaround, the assessor who validates it has to be a different pair of eyes, and that needs to be in the plan before the assessment starts. The monitoring layer that many worksheets lean on is also the part teams assume is working. IBM's 2026 data found that only 18% of organizations had applied AI agents to vulnerability management [2], which is a reminder that the "we monitor it" line in a worksheet needs the same evidence as anything else.
How Clone Systems Can Help
We run both sides of this file. On the scanning side, our PCI ASV external vulnerability scanning keeps Requirement 11.3.2 evidence current while your constraint is documented, with remediation and rescans handled until the result passes [7]. On the documentation side, we review your compensating control worksheet against the four failure modes above before your assessor sees it, and where the constraint involves unpatched software, the same evidence pack that closes a scanner finding, a vendor advisory, an installed release, and a connecting statement, is what makes the constraint defensible [5].
If you are not sure whether you have a constraint or a preference, the four-question self-test takes ten minutes. If the answer is unclear, talk to our team before the worksheet goes out.
Frequently Asked Questions
What is a PCI DSS compensating control? A documented alternative control used when a legitimate technical or business constraint makes it impossible to meet a requirement as stated. The assessor must be able to validate that it meets the requirement's objectives before the exception counts.
When can you use a PCI DSS compensating control? Only when a legitimate technical or business constraint genuinely prevents meeting the requirement as stated, not when it would be cheaper or faster to skip it. The PCI SSC's June 2026 guidance is explicit that the constraint must be technical or business in nature [1].
Do PCI DSS compensating controls need QSA approval? The assessor validates them as part of the assessment, and the validation has to be independent. An assessor who helped design or implement the control cannot validate that same control [1].
What is the difference between a compensating control and the customized approach? A compensating control covers a requirement you cannot meet as stated because of a constraint, while the customized approach is for organizations that choose to meet a requirement differently through a novel control design [1]. Both can apply to the same requirement if each instance is documented separately [1].
Does a compensating control cure a requirement you already missed? No, the worksheet is part of your compliance plan and does not retroactively close a period of non-compliance. If a requirement was unmet without documentation, the recovery is the gap note, the remediation, and the current passing evidence, the same discipline we wrote out for a lapsed scan quarter [6].
Conclusion
A compensating control is not an escape route and it is not a penalty box. It is a documented argument: here is the condition that makes the standard control impossible, here is the risk that creates, and here is the control that covers both, with evidence of operating and being maintained. The PCI SSC's June 2026 guidance makes the bar explicit, and the submissions that survive review are the ones whose constraint field would survive a stranger's reading [1]. Run the four-question self-test, fix the constraint before you touch anything else, and keep the scanning evidence current while you build the case [6]. Start the conversation at www.clone-systems.com.
References
[1] PCI SSC: PCI SSC Publishes New Guidance on Compensating Controls and the Customized Approach, June 10, 2026 (compensating controls apply only under a legitimate technical or business constraint; incomplete documentation may leave an assessor unable to validate that the control is in place and operating effectively; assessor independence must be preserved; both options can coexist for the same requirement, documented separately). https://blog.pcisecuritystandards.org/pci-ssc-publishes-new-guidance-on-compensating-controls-and-the-customized-approach
[2] IBM (Ponemon Institute): IBM Study: One in Four Malicious Breaches are AI-Enabled, Costing Companies $6 Million on Average, July 29, 2026 (global average breach cost $4.99 million; financial services $6.3 million; one in four malicious breaches AI-enabled at an average of $6 million, up 56% year over year; 602 organizations, March 2025 to February 2026; only 18% of organizations apply AI agents to vulnerability management). https://newsroom.ibm.com/2026-07-29-ibm-study-one-in-four-malicious-breaches-are-ai-enabled,-costing-companies-6-million-on-average
[3] CISA: CISA Adds Four Known Exploited Vulnerabilities to Catalog, September 8, 2026 (four KEV additions, including CVE-2026-75650, an Adobe Commerce and Magento template engine flaw, and CVE-2026-86218, an N-able N-central code injection flaw). https://www.cisa.gov/news-events/alerts/2026/09/08/cisa-adds-four-known-exploited-vulnerabilities-catalog
[4] Clone Systems: In our assessments, a compensating control submission almost never fails because the alternative control is weak. It fails in the constraint field, where the documented reason reads like a budget memo instead of a technical or business impossibility. The rejected worksheets we have reviewed almost always carry an adequate alternative control and a missing or under-evidenced constraint statement.
[5] Clone Systems: Why Your Vulnerability Scanner Flags Patched Systems (And What Actually Closes the Finding). www.clone-systems.com/blog/why-your-vulnerability-scanner-flags-patched-systems
[6] Clone Systems: What Happens When You Miss a Quarterly PCI ASV Scan. www.clone-systems.com/blog/what-happens-when-you-miss-a-quarterly-pci-asv-scan
[7] Clone Systems: PCI ASV External Vulnerability Scanning service page. www.clone-systems.com/pci-asv-scan-external-vulnerability-scanning/
[8] Clone Systems: Contact and consultation. www.clone-systems.com/contact