The Compensating Controls Register Auditors Accept

Q: Can a compensating control fix a control gap retroactively?

No. PCI DSS v4.0 clarified in Appendix B that compensating controls cannot be used to retroactively address a requirement missed in the past. A compensating control is a forward-looking substitute chosen because of a real constraint, not a way to paper over a lapse discovered during the audit. The same principle holds under NIST and SOC 2.

Q: How does NIST SP 800-53 define a compensating control?

NIST defines it as a management, operational, or technical control employed in lieu of a recommended control in the low, moderate, or high baselines that provides equivalent or comparable protection. NIST expects the organization to select the control with documented rationale and to formally assess and accept the residual risk.

Q: How does SOC 2 handle a control that cannot be met as designed?

SOC 2 does not use a compensating-controls worksheet. When a control does not operate as described, the auditor records an exception, and the collective weight of exceptions drives the opinion. A well-documented alternative control is how you keep an exception from escalating into a qualified opinion.

This article is general risk-management guidance, not legal, audit, or compliance advice. Confirm every control decision with your QSA, auditor, or counsel. Some links to vendor tools may be affiliate links; that never changes what we recommend.

Why this matters right now

Risk-based programs keep telling teams the same thing: you do not have to meet every control as written, as long as you offset the risk with something else. We made that argument ourselves in the piece on defending risk-based patching to an auditor, where the advice was to attach a compensating control to every deferral. That advice is only half the work. The half that decides the audit finding is whether the compensating control you named would actually survive an assessor reading it.

Most do not. A team defers multi-factor authentication on a legacy admin console and writes “network segmentation” in the register. An assessor asks whether that segmentation was already required elsewhere in scope, whether it defends against the same threat the missing control addressed, and whether anyone with authority signed off on the residual risk. If the answers are missing, the compensating control is not a control at all — it is a note. This article turns the note into a register entry that PCI, SOC 2, and NIST assessors accept, using the exact tests each framework applies.

What a compensating control actually is

Frameworks are specific here, and the definitions differ in useful ways. PCI DSS is the most structured process of any major standard. Its worksheet states that compensating controls “may be considered for most PCI DSS requirements when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other, or compensating, controls” (PCI Security Standards Council SAQ B).

NIST is broader. Its glossary defines a compensating security control as “a management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system” (NIST CSRC glossary). The operative words in both definitions are the same: in lieu of the original, and equivalent protection. A compensating control is a substitute that carries the same defensive load, not a consolation prize.

SOC 2 does not use the phrase “compensating control” as a formal artifact. Instead, when a control does not operate as described, the auditor records an exception, and the collective weight of exceptions drives the opinion. A report carries one of four opinions — unmodified (clean), qualified, adverse, or disclaimer — and the exceptions listed in the report are distinct from that overall conclusion (Linford & Co. on SOC report opinions). A well-documented alternative control is how you keep an exception from escalating into a qualified opinion.

The four tests PCI applies, in plain terms

PCI DSS is worth studying even if you never touch cardholder data, because it writes down the reasoning every assessor uses. A compensating control must satisfy four criteria (PCI Security Standards Council SAQ B):

Meet the intent and rigor of the original requirement. Not the letter — the purpose. If the original control exists to stop clear-text credential interception, your substitute has to stop that same thing.
Provide a similar level of defense, so that it “sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against.”
Be “above and beyond” other requirements. This is the criterion teams fail most. PCI states plainly that “simply being in compliance with other PCI DSS requirements is not a compensating control,” and that an existing requirement “CANNOT be considered as compensating controls if they are already required for the item under review.”
Be commensurate with the additional risk imposed by not meeting the requirement as stated.

The third test is where “network segmentation” collapses so often. If segmentation is already required elsewhere in your assessment, it cannot be reused as the compensating control for a different gap. PCI allows you to combine an existing requirement with a new control to build something above and beyond, but the existing requirement alone never qualifies. NIST reaches the same place by a different route: it expects the compensating control to be selected with documented rationale and the residual risk formally assessed and accepted, rather than assumed away.

Two mistakes that void the entry immediately

Beyond the four tests, two errors turn a register entry into a finding regardless of how good the control is.

The first is using a compensating control to fix something retroactively. PCI DSS v4.0 added an explicit clarification in Appendix B that “compensating controls cannot be used to retroactively address a requirement that was missed in the past.” As the standards council put it, “it was never the intent that compensating controls could be used, for example, where a task that should have been performed, was not performed, and no action was taken at that time” (PCI SSC blog on v4.0 compensating controls). A compensating control is a forward-looking substitute chosen because of a real constraint, not a way to paper over a lapse discovered during the audit. This rule holds across frameworks: an alternative control invented the week before fieldwork, dated to look older, is the fastest way to lose auditor trust for the entire engagement.

The second is confusing a compensating control with PCI’s customized approach. They solve different problems. Compensating controls live inside the defined approach and apply when you cannot meet a requirement as written because of a constraint. The customized approach is for entities that choose to meet a requirement differently and instead satisfy a stated Customized Approach Objective, with the design, testing, and maintenance evidence to prove it (PCI SSC blog). Filing a customized-approach control on a compensating-controls worksheet, or the reverse, signals to an assessor that the team does not understand which mechanism it is using.

The tests above are not unique to payment security. When you line up PCI DSS, NIST SP 800-53, and SOC 2 against the questions an assessor actually asks, the frameworks agree on the substance and differ mostly in how explicitly they write it down. The chart below is our own reading of the three standards side by side.

Crosswalk table comparing how PCI DSS v4.0, NIST SP 800-53, and SOC 2 treat six tests for a compensating control, from documented constraint to formal management risk acceptance

Three rows are worth calling out. Every framework demands equivalent protection and formal risk acceptance — those are non-negotiable everywhere. Every framework forbids the retroactive fix. And only PCI DSS states the “above and beyond” test explicitly; NIST does not frame it that way at all, which is why a team moving from a PCI mindset to a federal one sometimes over-documents. The practical takeaway is that a register entry built to PCI’s four tests will satisfy the other two frameworks, because PCI is the strictest of the three on what counts.

The register entry an assessor signs off on

A compensating-controls register is not a spreadsheet of good intentions. Each entry is a small, dated case file. Build every row to answer the assessor’s questions before they are asked, and tie the affected asset to its importance tier using the same method from our guide to asset criticality scoring.

The requirement or control you cannot meet, named precisely — the PCI requirement number, the NIST control identifier, or the SOC 2 Common Criteria reference.
The legitimate constraint, stated as a technical or documented business reason, not “we did not get to it.” A legacy appliance that cannot run the required cipher is a constraint; a missed sprint is not.
The compensating control itself, and an explicit note on how it meets the intent, provides equivalent defense, and goes above and beyond what you are already required to do.
The threat mapping, showing the control defends against the same risk the original addressed — not an adjacent one.
The residual-risk assessment and management acceptance, with the approver’s name and date. This is the signature that converts a technical note into an accepted risk decision.
A review or expiry date. A compensating control is temporary by nature; an entry with no expiry tells an assessor you have stopped trying to fix the real constraint.
Supporting evidence links — configuration exports, test results, monitoring dashboards — so the assessor can verify the control operates, not just that it was written down.

Before an audit, pressure-test each entry the way an assessor will: use our free change risk score to sanity-check whether the residual risk you accepted matches the blast radius of the asset it protects. If a register entry protects a top-tier asset with a low-effort control and a vague sign-off, expect it to draw a question.

Frequently asked questions

What makes a compensating control acceptable to an auditor? It is tied to a documented legitimate constraint, provides protection equivalent to the control it replaces, goes above and beyond what you are already required to do, and carries a dated management risk acceptance (PCI SSC SAQ B). A control that only restates an existing requirement or backfills a gap after the fact gets flagged.

What are the four PCI DSS compensating control criteria? Meet the intent and rigor of the original requirement; provide a similar level of defense that offsets the same risk; be “above and beyond” other requirements; and be commensurate with the additional risk of not meeting the requirement as stated (PCI SSC SAQ B). An existing requirement already needed for the item under review cannot serve as its own compensating control.

Can a compensating control fix a control gap retroactively? No. PCI DSS v4.0 clarified that compensating controls cannot be used to retroactively address a requirement missed in the past (PCI SSC blog). A compensating control is a forward-looking substitute chosen because of a real constraint, not a way to paper over a lapse found during the audit.

What is the difference between a compensating control and PCI’s customized approach? Compensating controls apply when you cannot meet a requirement as written because of a constraint; the customized approach is for entities that choose to meet a requirement differently by satisfying a Customized Approach Objective, with full evidence (PCI SSC blog). They are different mechanisms.

How does NIST SP 800-53 define a compensating control? As a management, operational, or technical control used in lieu of a recommended baseline control that provides equivalent or comparable protection, selected with documented rationale and formal risk acceptance (NIST CSRC glossary).

How does SOC 2 handle a control that cannot be met as designed? The auditor records an exception, and the collective weight of exceptions drives the opinion — unmodified, qualified, adverse, or disclaimer (Linford & Co.). A documented alternative control keeps an exception from escalating into a qualified opinion.

What belongs in a compensating controls register entry? The requirement you cannot meet, the legitimate constraint, the compensating control with a note on how it goes above and beyond, the threat mapping, a dated management risk acceptance, a review or expiry date, and links to supporting evidence. For the change-management side of audit evidence, see our guide to SOC 2 change-management controls.

For the full set of GRC and compliance workflows we cover, see the compliance pillar.

Sources

#compensating-controls #compliance #pci-dss #soc-2 #nist-800-53 #audit

Published August 24, 2026.