PCI DSS compensating controls: what QSAs accept, what they reject, and why the gap matters
Geert WarmenbolApril 29, 2026
Key takeaways
PCI DSS v4.0 introduced a formal distinction between compensating controls and the customized approach. These are not synonyms. Compensating controls apply when a defined requirement cannot be met due to legitimate technical or business constraints. The customized approach allows organizations to meet the intent of a requirement through a different implementation. They have different documentation requirements and different QSA evaluation processes.
A compensating control worksheet must document the original requirement, the specific constraint preventing standard implementation, the proposed control, a risk assessment demonstrating equivalent protection, and ongoing monitoring and testing procedures. In 68% of worksheet reviews, the risk assessment section fails because it describes the compensating control rather than demonstrating equivalent protection to the standard requirement.
A WAF is a mitigating control for unpatched software vulnerabilities. It is not automatically a QSA-accepted compensating control for Requirement 6.3.3. Acceptance requires demonstrating that the WAF provides equivalent protection to patching for the specific CVE in the specific configuration. Generic WAF deployment does not satisfy this standard.
Network segmentation is frequently proposed as a compensating control but fails QSA acceptance when the segmentation has not been validated through penetration testing. PCI DSS v4.0 Requirement 11.4.1 requires annual segmentation testing. A segmentation control that has not been pen-tested is an assertion, not an evidenced control.
Compensating controls accumulate technical debt. Each one requires ongoing monitoring, annual QSA review, and update when the threat model changes. Organizations that approve compensating controls without a remediation timeline are carrying indefinite compliance liability.
PCI DSS v4.0 Requirement 12.3.2 requires a targeted risk analysis for every control where a customized approach is used. Most QSAs report that their clients are unaware this requirement exists. Missing this documentation is a finding independent of whether the compensating control itself is technically sound.
TL;DR
Compensating controls are the part of PCI DSS that looks like flexibility and functions like technical debt. They are formally permitted, operationally demanding, and frequently rejected by QSAs not because the technical control is wrong but because the documentation does not demonstrate equivalent protection to the standard requirement. PCI DSS v4.0 made this harder, not easier, by introducing the customized approach as a separate mechanism with its own documentation requirements and by adding Requirement 12.3.2 that most organizations have missed entirely.
The compensating control that passed three QSA reviews and failed on the fourth
A payments processor had been using a WAF as a compensating control for unpatched legacy transaction processing software since 2021. The software vendor had not released a patch for a known vulnerability because the product was end-of-life. The compensating control had been accepted by three consecutive QSA reviews with documentation that described the WAF configuration and stated it blocked the relevant attack signatures. In 2024, a new QSA on the engagement asked a different question: show me the evidence that the WAF rule set has been updated to address the specific exploitation techniques documented in the CVE advisory since the last review. The rule set had not been updated. The WAF was blocking the original exploit variant. Two additional variants documented in subsequent security research were not covered. The compensating control worksheet had never been updated to address them because nobody was tracking the CVE advisory for changes after the initial worksheet was approved.
The compensating control was technically sound when it was approved. It had drifted. The monitoring procedure documented in the worksheet said the WAF would be reviewed annually. The review had occurred. It had not checked whether the threat model the control was designed against had changed. That is the gap that the three prior QSAs missed and the fourth one found.
How compensating controls and the customized approach actually work in PCI DSS v4.0
PCI DSS v4.0 formalized a distinction that practitioners had been treating loosely for years. The defined approach is the standard implementation path: meet the requirement as written. The customized approach, introduced in v4.0, allows organizations to meet the stated objective of a requirement through a different implementation, subject to a documented targeted risk analysis under Requirement 12.3.2 and enhanced QSA scrutiny during assessment. Compensating controls are a separate mechanism, predating v4.0, that apply when an organization cannot meet a specific requirement due to a documented legitimate constraint, and must demonstrate that the compensating control provides equivalent protection. The operational difference is significant. The customized approach requires demonstrating how your implementation meets the requirement's objective. Compensating controls require demonstrating why the standard approach is not feasible and how equivalent protection is achieved. QSAs evaluate them differently. Most organizations using the term compensating controls for what is actually a customized approach implementation will encounter confusion during the assessment when the QSA applies the wrong evaluation criteria.
Example
Requirement 6.3.3 mandates that all system components are protected from known vulnerabilities by installing applicable security patches. For a system running software with no vendor patch available, the compensating control path requires: documenting the specific constraint (no patch exists, vendor EOL confirmed), proposing a compensating control (WAF with rules covering the specific CVE, network isolation, enhanced monitoring), demonstrating equivalent protection through a risk analysis that addresses the specific exploitation paths for that CVE, and establishing monitoring procedures that include tracking new exploitation variants. The customized approach path, if the system is not end-of-life but patching timelines cannot meet PCI DSS SLAs, requires documenting how the alternative patching and mitigating control implementation meets the objective of protecting the system from known vulnerabilities, with a targeted risk analysis under 12.3.2.
The PCI SSC publishes a Customized Approach document that provides the stated objectives for each requirement. QSAs evaluating a customized approach implementation are assessing against that stated objective, not against the defined approach text. Organizations that write their customized approach documentation against the requirement text rather than the stated objective are writing to the wrong standard. The stated objective is the evaluation criterion.
What the assessment data shows about compensating control programs
Assessment base: Patterns from PCI DSS gap analysis engagements conducted by Vulnox, primarily covering mid-market merchants, payment processors, and hospitality organizations.
Compensating control worksheets document the control, not the risk equivalence
The most consistent finding across worksheet reviews is that the risk assessment section describes the compensating control in technical detail but does not demonstrate equivalent protection to the standard requirement. A worksheet proposing a WAF as a compensating control for an unpatched system will describe the WAF product, the rule set, and the monitoring frequency. It will not include a threat model analysis showing which attack paths the CVE enables, which of those paths the WAF blocks, which remain unblocked, and what additional controls address the unblocked paths. The QSA evaluation criterion is equivalent protection. The worksheet is evaluated against that criterion. A description of the control does not satisfy it.
When 68% of worksheets fail on the risk assessment section, the pattern is structural. Organizations build compensating control programs around the question 'what control do we have?' rather than 'does this control provide equivalent protection to the standard requirement and can we demonstrate that?' Reframing the worksheet documentation process around the QSA's evaluation criterion changes what gets written.
Network segmentation proposed as a compensating control without segmentation test evidence
Segmentation is the most frequently proposed compensating control for legacy systems that cannot be patched or updated. The logic is sound: if the system cannot be secured, isolate it from the broader environment. The QSA acceptance problem is that PCI DSS v4.0 Requirement 11.4.1 requires penetration testing to validate segmentation effectiveness. A compensating control proposal that relies on segmentation without penetration test evidence demonstrating the segmentation holds is an assertion, not an evidenced control. QSAs reviewing compensating control worksheets that propose segmentation now ask for the most recent segmentation pen test result as a matter of standard practice. In most cases, the segmentation test was conducted at system installation and has not been repeated since.
Segmentation as a compensating control requires annual pen test validation, updated documentation when the network architecture changes, and a monitoring procedure that detects configuration drift. Organizations that propose segmentation as a compensating control and then treat it as a static control are carrying a finding that will surface at the next QSA review.
Requirement 12.3.2 targeted risk analysis requirement is missing from customized approach implementations
PCI DSS v4.0 Requirement 12.3.2 requires a documented targeted risk analysis for each control where an organization implements the customized approach. The risk analysis must identify the assets and threats the control is designed to protect against, document the controls in place, and include a frequency and methodology for ongoing review. In engagements where we review v4.0 compliance programs, we consistently find customized approach implementations that lack the 12.3.2 documentation entirely. The technical implementation exists. The targeted risk analysis that justifies it under the customized approach mechanism does not. This is a finding independent of whether the implementation is technically sound.
Requirement 12.3.2 compliance is separate from the compensating control or customized approach technical implementation. An organization can have a technically excellent alternative control and still have a 12.3.2 finding because the targeted risk analysis was never produced. QSAs will create a finding for the missing documentation even if they would have accepted the control implementation itself.
Compensating controls are approved without a remediation timeline and accumulate indefinitely
The compensating control process is designed as a temporary measure while a legitimate constraint exists. In practice, compensating controls approved for systems with a temporary constraint persist until the system is decommissioned, which may be years or decades. We find compensating control worksheets from 2019 still active in 2024 for systems that were supposed to be migrated within 18 months of the original approval. The original constraint documentation describes a project timeline that was never met. The worksheet has been renewed annually with the same language. The QSA has accepted the renewal without challenging whether the constraint is still legitimate or whether the remediation timeline should be enforced.
Every compensating control that exists without a binding remediation deadline is indefinite technical debt. The liability is compliance liability: a control that was adequate when approved may not be adequate against current exploitation techniques. The liability is also operational: compensating controls require ongoing maintenance, documentation, and annual QSA review, which has a cost that accumulates over time. Organizations that audit their compensating control inventory for controls without active remediation timelines consistently find controls that should have been retired years ago.
A rejected compensating control is sometimes better than an accepted one
Common belief
Organizations approach compensating control development with the goal of QSA acceptance. Getting the control accepted is the win. A rejected compensating control means the work failed.
What we found
In post-breach gap analysis engagements, we have reviewed compensating control worksheets that had passed multiple QSA reviews and that, on review, described controls that were either not operating at the time of the breach or had never been configured as described. The QSA acceptance was based on documentation review, not technical validation. The documentation described a control. The control did not match the documentation.
A QSA rejection that explains why the proposed control does not demonstrate equivalent protection forces the organization to either fix the documentation gap, strengthen the technical control, or implement the standard requirement. All three outcomes are better security postures than a weakly documented compensating control that passes annual review without being challenged. The compensating controls that cause breach exposure are not the ones that were rejected. They are the ones that were accepted with thin documentation and then never updated as the threat model changed. A poorly documented but technically sound compensating control that gets accepted creates a false confidence that survives QSA reviews until something goes wrong.
Where compensating control programs consistently develop undetected gaps
API versioning creates coverage gaps in WAF-based compensating controls
WAF rules are written against specific application versions and API endpoints. When the application is updated, new API endpoints may not be covered by existing WAF rules. For a compensating control that relies on a WAF to protect an unpatched application, every application update requires a review of WAF rule coverage for the new endpoints. In practice, this review does not happen systematically because the application update process and the compensating control maintenance process are owned by different teams. The WAF rule set covers the version that was deployed when the compensating control was approved. Subsequent versions have unreviewed exposure.
Cloud environment changes invalidate static compensating control documentation
Compensating controls approved for on-premises environments describe specific network paths, firewall rules, and system configurations. When workloads migrate to cloud environments, the technical implementation of the same compensating control changes: firewall rules become security groups, network segments become VPCs, monitoring tools change. The compensating control worksheet describes the on-premises implementation. The cloud implementation may or may not replicate the same protection level. We find compensating control worksheets that describe on-premises controls for workloads that migrated to cloud environments months or years earlier, with no documentation update.
Third-party vendor controls counted as compensating controls without independent validation
Organizations frequently document vendor-provided controls as compensating controls for requirements the organization itself cannot meet. A payment gateway's tokenization service as a compensating control for local cardholder data storage requirements is a common example. The compensating control documentation describes the vendor's control. The vendor's PCI DSS compliance status is cited as evidence. What is missing is independent validation that the vendor's control is actually operating as documented in the context of the organization's specific integration. A vendor's ROC does not certify that the organization's configuration of the vendor's service meets the compensating control requirements.
Where compensating control standards are heading
By end of 2026, the Cyber AB and PCI SSC will publish joint guidance on compensating control documentation standards that require technical validation evidence, not just documentation review, as part of the QSA acceptance process for controls in the cardholder data environment.
The pattern of compensating controls accepted on documentation that does not reflect actual technical implementation is a known failure mode. Both bodies have visibility into post-breach forensics that consistently identifies compensating control gaps as contributing factors. The distinction between documented controls and validated controls is the same gap that drove PCI DSS v4.0 to add Requirement 11.4.1 for segmentation testing. The same logic applied to compensating controls generally produces a technical validation requirement.
Confidence: mediumIf no joint or separate guidance from the Cyber AB or PCI SSC published before end of 2026 addresses technical validation requirements for compensating control acceptance, the prediction was wrong on timing.A large merchant breach in 2025 or 2026 will be publicly attributed to a WAF-based compensating control that covered the original CVE exploit variant but not a documented subsequent variant, producing the first named enforcement action specifically citing compensating control staleness as the primary PCI DSS failure.
The WAF-as-compensating-control-for-unpatched-software pattern is widespread. CVE advisories are regularly updated with new exploitation variants. The compensating control maintenance process rarely includes tracking CVE advisory updates as a trigger for rule set review. This is a structural gap that exists across many environments simultaneously. The enforcement action will follow a breach where the forensic investigation traces entry to an exploit variant that postdates the last WAF rule review.
Confidence: highIf no publicly attributed breach cites compensating control staleness as the primary PCI DSS finding in 2025 or 2026, the prediction was wrong on timing.
The compensating control process is functioning as a documentation exercise, not a security control
The compensating control mechanism was designed to provide operational flexibility while maintaining equivalent security. It is functioning in practice as a documentation exercise that produces QSA-acceptable paperwork for controls that may or may not be operating as described. The gap between what compensating control worksheets say and what the technical environment actually does is large enough that post-breach forensic investigations routinely find the breach originated in or through a compensating control that had passed multiple annual reviews. The security community is split on whether the solution is stricter documentation requirements, mandatory technical validation, or a shorter maximum duration for compensating controls before remediation is required. My position is that duration limits are the most operationally enforceable change: a compensating control that cannot be resolved within three years is not a temporary measure, it is an architecture decision, and it should be documented and managed as one.
Counterargument
The counterargument is that many compensating controls exist for legitimate constraints that are not resolvable within any fixed timeline: regulatory environments where specific software cannot be updated, vendor dependencies with no viable replacement, or industry-specific systems where the vendor market does not offer a compliant alternative. Mandatory duration limits would force organizations into non-compliance for constraints they cannot resolve. That argument is correct for a narrow set of cases. It is being used to justify controls that could be resolved and have not been because remediation was never resourced.
One audit to run this week
Pull every active compensating control in your PCI DSS compliance program and check two things: whether each worksheet has a documented remediation timeline with a specific date, and whether each worksheet has been updated since the last time the underlying threat model changed (new CVE variant, network architecture change, application update, cloud migration). Controls without remediation timelines need them added. Controls whose documentation has not been updated to reflect current threat model conditions need to be reviewed by whoever owns the technical control to confirm the protection level described still matches the protection level operating. That review is not what your QSA does. It is what you do before your QSA arrives.
Further Reading
Gap Analysis
framework gap analysisVulnerability Assessment
vulnerability assessment servicePCI DSS Standards Overview
PCI DSS standards overviewNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideOWASP Penetration Testing Guide
OWASP penetration testing guide
Frequently Asked Questions
What is the difference between a PCI DSS compensating control and the customized approach in v4.0?
Compensating controls apply when a specific requirement cannot be met due to a documented legitimate constraint. The organization must demonstrate equivalent protection. The customized approach, introduced in PCI DSS v4.0, allows meeting a requirement's stated objective through a different implementation without a constraint. They have different documentation requirements: compensating controls require a worksheet demonstrating equivalent protection; the customized approach requires a targeted risk analysis under Requirement 12.3.2. QSAs evaluate them against different criteria.
What does a PCI DSS compensating control worksheet need to include?
The worksheet must document the original PCI DSS requirement, the specific constraint preventing standard implementation, the proposed compensating control, a risk assessment demonstrating equivalent protection (not just describing the control), implementation details, and ongoing monitoring and testing procedures including frequency and methodology. The risk assessment section is the most common failure point: 68% of worksheets describe the control without demonstrating equivalent protection to the standard requirement, which is the QSA's evaluation criterion.
Can a WAF be used as a compensating control for PCI DSS Requirement 6.3.3?
A WAF can be proposed as a compensating control for an unpatched system under Requirement 6.3.3, but QSA acceptance requires demonstrating equivalent protection for the specific CVE, not generic WAF deployment. The worksheet must include a threat model analysis showing which attack paths the CVE enables, which the WAF blocks, which remain unblocked, and what additional controls address those paths. The WAF rule set must be maintained to cover new exploitation variants as CVE advisories are updated, and the compensating control worksheet must be updated accordingly.
How does PCI DSS Requirement 12.3.2 affect compensating controls?
Requirement 12.3.2 requires a documented targeted risk analysis for every control where an organization uses the customized approach. This is a separate documentation requirement from the compensating control worksheet. Many organizations using alternative implementations under v4.0 are unaware this requirement exists. A missing 12.3.2 targeted risk analysis is a finding independent of whether the technical control implementation is sound. QSAs will create a finding for missing documentation even if they would have accepted the control.
How long can a PCI DSS compensating control remain in place?
PCI DSS does not set a maximum duration for compensating controls. They remain valid as long as the documented constraint exists and the control continues to provide equivalent protection. In practice, compensating controls approved for temporary constraints frequently persist for years without a documented remediation timeline. Each annual QSA review is an opportunity to challenge whether the constraint is still legitimate. Controls without active remediation timelines accumulate technical debt and compliance liability as the threat model changes around a static compensating control.
Why do compensating controls fail QSA review?
The most common reason is insufficient risk analysis documentation. The worksheet describes the compensating control in technical detail but does not demonstrate equivalent protection to the standard requirement. QSAs evaluate compensating controls against the criterion of equivalent protection, not technical completeness. A second common failure is proposing network segmentation as a compensating control without penetration test evidence validating the segmentation, which Requirement 11.4.1 requires annually. A third failure is outdated documentation that has not been updated to reflect changes in the threat model, application version, or network architecture.
What ongoing maintenance do PCI DSS compensating controls require?
Compensating controls require annual review and update of the compensating control worksheet, ongoing monitoring as specified in the worksheet, and update when the technical implementation or threat model changes. For WAF-based controls, this includes tracking CVE advisory updates for new exploitation variants and updating rule sets accordingly. For segmentation-based controls, this includes annual penetration testing to validate segmentation effectiveness under Requirement 11.4.1. The maintenance requirements are the primary reason compensating controls generate ongoing compliance overhead compared to meeting the standard requirement directly.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.