The control you are leaning on is usually untested
A risk acceptance was approved with a compensating control in place. The compensating control pulled its population data from the same upstream feed as the control it replaced. When the original control failed because that feed stopped refreshing, the compensating control failed for the same reason — quietly, on the same day, with no separate alert. The acceptance remained open. No one tested whether the substitute actually worked.
This scenario is not an edge case. In programs where the compensating control gets documented at acceptance time and never revisited, the test coverage gap is structural — not incidental. The compensating control is often the least-tested control in the inventory and the one the most decisions rest on, because an approved risk acceptance records it as active evidence that residual risk is managed.
What a compensating control has to achieve
PCI DSS requires that a compensating control meet the intent and rigor of the original requirement, provide a similar level of defense, go above and beyond other existing requirements, and address the additional risk created by not meeting the original requirement (Source: PCI DSS, https://www.pcisecuritystandards.org/standards/pci-dss/). That is a four-part threshold, and each part is independently testable. A control that satisfies the letter of two conditions but not all four does not meet the standard.
The control does not need to be a technical equivalent of what it replaces. It does need to cover the same population, the same period, and the same risk scenario. If the original control was preventive and the compensating control is detective, the substitution is not automatically invalid — but it changes the timing of protection, and that timing gap is material to the risk acceptance it supports.
Audit treatment reinforces this. Under PCAOB AS 2201, an auditor evaluating whether a control deficiency rises to a material weakness must consider the effect of compensating controls (Source: PCAOB AS 2201, https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201). This means the auditor is asking the same question you should be asking before the audit: does this compensating control actually reduce the risk, or does it only appear to reduce the risk?
Testing against the original objective not the substitute design
The failure mode in most compensating control assessments is testing what the substitute does rather than what the original was supposed to prevent. A manual review process installed to replace an automated access certification does things a manual review does. Testing that it runs on schedule, reviewers sign off, and results are retained confirms operation — it does not confirm that the manual review catches the same conditions the automated certification was designed to catch.
The test design should start from the original control's objective statement, not from the compensating control's procedure document. The question to anchor on: what population of events, transactions, or states was the original control designed to detect or prevent, and does this substitute cover that population with comparable completeness?
Where the original objective is ambiguous or undocumented, recovering it before designing the test is work that cannot be skipped. An objective you cannot state cannot be tested against.
Coverage gaps between the two controls
Coverage gaps appear on three dimensions: population, period, and response latency. The compensating control may cover a narrower scope — fewer systems, fewer user accounts, a subset of transaction types. It may run less frequently, creating windows where risk is unmitigated. And if it is detective rather than preventive, it identifies a condition after it has already occurred rather than blocking it.
Each gap should be evaluated against the risk scenario the acceptance is managing. A population gap in a low-volume environment with manual oversight may represent tolerable residual risk. The same gap in a high-volume environment with no secondary review likely does not. The risk tolerance and operating context should drive that judgment — not the gap's existence alone.
The compensating control that shares a dependency with what it replaces
A compensating control that shares an upstream dependency with the control it replaces does not provide independent mitigation of the failure scenario. If the original access review failed because the identity provider feed stopped refreshing user status, and the compensating control also reads from that feed, both controls fail together under the same condition.
Dependency mapping should be part of the compensating control design review, not discovered during testing. In practice, mapping the compensating control's data sources, infrastructure dependencies, and process owners against those of the failing control surfaces shared failure modes before they are locked into an acceptance record.
Independence from the failing control's owner is a related concern. A compensating control operated by the same team — or approved by the same individual — that owns the deficient control does not provide organizational separation. Whether that matters depends on the nature of the original failure: a technical failure in a system the team does not control is different from a process failure where the control owner also controls the compensating measure.
How long a compensating control test is good for
A test result establishes that a control was operating as designed during the period tested. It does not establish ongoing operation. The gap between the test period and the current date is untested time.
How long a test result remains sufficient to support an open acceptance depends on several factors: the volatility of the environment the control operates in, the duration of the acceptance, and whether the compensating control is subject to continuous evidence collection. In a stable environment with a short acceptance period, a single test result may remain relevant. In a high-change environment with an acceptance that runs twelve months or more, a single test at inception is likely insufficient.
The decision about retesting cadence belongs to the program and should be driven by the same factors: risk tolerance, control volatility, and acceptance period length. A defined retest interval — whatever the program determines is appropriate — should be documented in the acceptance record before it is approved, not decided when the next audit cycle starts.
The compensating control test
The table below organizes testing across the six dimensions that matter most when evaluating whether a compensating control actually holds. For each dimension, it separates what must be established from how to test it, and is explicit about what a passing result does not prove — because the most common failure in compensating control assessments is treating a partial pass as a full one.
Compensating Control Test Table
| Dimension | What Must Be Established | How It Is Tested | What a Pass Does Not Establish | Effect on the Acceptance It Supports |
|---|---|---|---|---|
| Original control's objective | The compensating control addresses the same risk condition and population the original was designed to cover | Map the original objective statement to the compensating control's scope; sample from the full population the original covered | That the compensating control matches the original control's mechanism or speed of response | Acceptance can record active mitigation only for the objectives the test confirms are covered |
| Coverage of the same population and period | The compensating control applies to every system, account, or transaction type in scope under the original | Pull the original scope definition and compare it to the compensating control's configured scope; document any exclusions | That excluded scope carries no residual risk | Any population not covered remains unmitigated; the acceptance should reflect that as unmanaged residual risk |
| Detective versus preventive substitution | The compensating control's response type — detective or preventive — is understood and the timing difference is accounted for | Determine the original control type; determine the compensating control type; document the latency gap if substitution is detective for preventive | That detection is equivalent to prevention for the risk scenario | Acceptances that assume equivalence between control types without documenting the latency gap are incomplete |
| Shared dependencies or shared failure modes | The compensating control does not fail under the same conditions as the failing control | Map each control's upstream data sources, infrastructure components, and process dependencies; identify any overlap | That the compensating control is resilient to all other failure modes — only the overlapping ones are tested here | An acceptance supported by a compensating control that shares a dependency with the failing control records no independent mitigation for that failure scenario |
| Independence from the failing control's owner | The compensating control is operated or reviewed by a party without a conflict of interest relative to the original deficiency | Confirm operational ownership and approval authority; verify neither belongs to the individual or team accountable for the deficient control | That the control design is sound — ownership independence is separate from design adequacy | An acceptance with an owner conflict does not demonstrate independent assurance; an auditor may discount the compensating control entirely |
| Tested life of the result | The test result covers the period and conditions relevant to the current acceptance | Document the test period, the date tested, and the environmental conditions at the time of testing | That the control continues to operate after the test period ends — especially in high-change environments | Acceptances that extend beyond the reasonable coverage period of the test result should require a defined retest schedule documented in the acceptance record before approval |
