What Is a Compensating Control, and When Will an Assessor Accept One?

A compensating control is "an alternative control implemented where an entity cannot meet a requirement as stated because of a legitimate technical or documented business constraint, and that sufficiently mitigates the risk the original requirement addresses." That is our glossary definition, and the word carrying all the weight in it is constraint. The PCI Security Standards Council, which defines the concept most strictly, says compensating controls "are still an option within the defined approach for entities that have a legitimate and documented technical or business constraint that prevents them from meeting the Defined Approach Requirement as stated" (PCI SSC blog, 18 July 2022). Here is the part most explainers get wrong: there is no single, cross-framework thing called a compensating control. PCI DSS, the NIST baselines, the HIPAA Security Rule, the DFARS clause and the CMMC rule each have their own version, with a different trigger, a different approver and a different document. Treat them as one concept and the first assessor who reads your worksheet will tell you which regime you copied it from.

This article gives the acceptance test for each regime from the text that sets it, separates a compensating control from the three things it gets confused with, and ends with the six-part record that survives review.

Key takeaways

• The trigger is a constraint you cannot remove, not a control you would rather not run. Cost, convenience and a project schedule are not constraints in any regime that recognizes the concept.
• PCI DSS is the strictest: a Compensating Controls Worksheet with six required sections, no use under the customized approach, and no retroactive use for a requirement missed in the past.
• The NIST definition is a tailoring decision: a control "employed by an organization in lieu of a recommended security control" in a baseline that "provides equivalent or comparable protection."
• Under DFARS, a variance from NIST SP 800-171 is requested in writing and adjudicated by the DoD CIO. Under CMMC, the nearest concepts are the enduring exception and the temporary deficiency, and a POA&M is a deferral rather than a substitute.
• HIPAA never uses the phrase. Its addressable implementation specifications allow an "equivalent alternative measure" once you have documented why the specification is not reasonable and appropriate.

The definition, and why constraint is the load-bearing word

Every regime that accepts a compensating control accepts it for the same reason: the requirement as written cannot be met, and the risk it addresses still has to be. The substitute earns its place by mitigating that risk, not by being easier.

That is why the two words that appear in every serious definition are constraint and risk. The note at the top of the PCI DSS v4.0 SAQ D worksheet reads "Only entities that have a legitimate and documented technological or business constraint can consider the use of compensating controls to achieve compliance" (SAQ D for Merchants, April 2022, Appendix B). The NIST definition is about "equivalent or comparable protection." The HIPAA text asks whether the alternative is "reasonable and appropriate." The DFARS clause asks for an "equally effective" measure. Four regimes, one structure: name the constraint, then prove the risk is still covered.

The Council's own blog adds the two limits people miss. Compensating controls "are often used in situations where there is a legacy system or process that cannot be updated to meet the requirement," and they "cannot be used to retroactively address a requirement that was missed in the past" (same July 2022 post). A compensating control is a design decision made before assessment about a requirement you know you cannot meet. It is not an explanation offered afterwards for one you forgot.

PCI DSS: the worksheet, and the approach it is not allowed in

PCI DSS is the regime with a form, which is why the phrase is usually learned there first.

In the v4.0 SAQ D, every requirement is answered with one of six responses, and one of them is "In Place with CCW": "the requirement has been met with the assistance of a compensating control." The instruction under that column reads, "All responses in this column require completion of a Compensating Controls Worksheet (CCW) in Appendix B of this SAQ," and it points to the standard itself for the rules: "Information on the use of compensating controls and guidance on how to complete the worksheet is provided in PCI DSS Appendices B and C."

The worksheet has six numbered rows, and each is a question the assessor will ask in that order:

Row 3 carries a note worth reading twice: the objective you name "can be, but is not required to be, the stated Customized Approach Objective listed for this requirement in PCI DSS." That sentence is the bridge to the most common v4 confusion.

PCI DSS v4 has two ways to meet a requirement. The defined approach is the requirement as written. The customized approach, in the Council's words, "is for entities that choose to meet the requirement differently than is stated. In this case, the entity must meet the stated Customized Approach Objective instead of the stated requirement." Compensating controls belong to the defined approach only. Asked whether they can be used with the customized approach, the Council's answer is one word: "No. Compensating controls are not an option with the customized approach." The two can coexist inside one assessment, though: "An entity can use compensating controls for certain system components and the customized approach to meet that same requirement for other system components."

The Council published an information supplement on the two in June 2026, "PCI DSS v4.x: Guidance for Compensating Controls and the Customized Approach" (announcement), which restates the split: compensating controls "apply when an organization cannot meet a defined requirement due to a legitimate technical or business constraint," while the customized approach is for entities that "choose to meet a requirement differently by satisfying its stated Customized Approach Objective through a novel control design." The supplement and the standard's own Appendices B and C sit behind the Council's licence agreement, so if your assessor quotes a sentence from either, ask to see the page.

NIST: a tailoring decision, not an exception

In the NIST vocabulary the compensating control is a baseline concept, and the definition is older and calmer than the PCI one. The NIST computer security glossary carries it, sourced to SP 800-30 Rev. 1 and SP 800-39, 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." The CNSSI 4009 and SP 800-137 variants on the same page say the same thing with the SP 800-53 baselines named.

Two things follow. First, in a NIST-shaped programme the compensating control is part of tailoring the baseline to the system, which is a documented, authorized act rather than a confession. Second, the standard of acceptance is "equivalent or comparable protection," which is a judgement an authorizing official makes on the record, not a worksheet an assessor validates. If your organization inherits its control language from NIST, use those words and expect that process.

Defense contractors: DFARS variances, and what CMMC calls the same problem

The DFARS clause that puts NIST SP 800-171 into contracts has its own route, and it is not called a compensating control. 48 CFR 252.204-7012(b)(2)(ii)(B) says: "The Contractor shall submit requests to vary from NIST SP 800-171 in writing to the Contracting Officer, for consideration by the DoD CIO. The Contractor need not implement any security requirement adjudicated by an authorized representative of the DoD CIO to be nonapplicable or to have an alternative, but equally effective, security measure." Note who decides. Not you, and not your assessor. A written request goes through the contracting officer to the DoD CIO, and an "equally effective" alternative is one that has been adjudicated as such, not one you have described as such.

The CMMC rule adds two defined terms that do part of the same job. 32 CFR 170.4 defines an enduring exception as "a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible," gives as examples "systems required to replicate the configuration of 'fielded' systems, medical devices, test equipment, OT, and IoT," and says "No operational plan of action is required but the circumstance must be documented within a system security plan." A temporary deficiency is "a condition where remediation of a discovered deficiency is feasible, and a known fix is available or is in process," and it "must be documented in an operational plan of action." The rule adds that a temporary deficiency "is not based on an 'in progress' initial implementation of a CMMC security requirement but arises after implementation," and that "There is no standard duration for which a temporary deficiency may be active."

Read those two definitions against the compensating-control idea and the split is clean. An enduring exception is the closest CMMC gets to a constraint you cannot remove, and it lives in the system security plan. A temporary deficiency is a fix in progress, and it lives in a plan of action. Neither is a substitute control, and a POA&M is a deferral with its own eligibility rules and clock, which our CMMC POA&M article sets out. Do not describe a compensating control as a POA&M item, and do not describe a POA&M item as a compensating control; an assessor reads them under different rules.

HIPAA: the "equivalent alternative measure"

The Security Rule never uses the phrase, and the mechanism it does have is narrower than a general compensating control because it applies only to addressable implementation specifications. 45 CFR 164.306(d)(3) requires a covered entity or business associate to "Assess whether each implementation specification is a reasonable and appropriate safeguard in its environment," and then either "Implement the implementation specification if reasonable and appropriate," or, if not, "Document why it would not be reasonable and appropriate to implement the implementation specification" and "Implement an equivalent alternative measure if reasonable and appropriate."

Three consequences. Required specifications have no alternative path at all; the rule says a covered entity "must implement" them. The documentation of why comes before the alternative, not after it, and it is the piece investigators ask for. And "addressable" does not mean optional: the choice is implement, or document and substitute, never skip.

SOC 2: no worksheet, and a different job for the phrase

A SOC 2 examination has no compensating-control form and no acceptance test in the PCI sense, because the Trust Services Criteria describe outcomes rather than prescribed controls. What are the Trust Services Criteria explains that structure, and it is the reason a substitute control in SOC 2 is not an exception to anything: management chooses the controls, and the auditor tests the ones chosen.

Where the phrase does real work in SOC 2 is after a control fails. When an exception is noted, whether another control operated and caught the failure is one of the things the auditor weighs in deciding whether the exception stays a footnote or qualifies the opinion, and naming that control is one of the four parts of a management response that reads well. Can you fail a SOC 2 audit owns that conversation on this site, and we will not restate it here. The short version: in SOC 2 a compensating control is a thing you point to when a control failed, not a thing you file in advance because a control cannot exist.

The same word across five regimes

SOC 2 is deliberately absent from that table: there is no formal trigger and no formal acceptance, and the phrase does its work inside exception responses instead.

Three things a compensating control is not

It is not a POA&M. A plan of action defers a requirement to a date. A compensating control replaces one indefinitely with something that mitigates the same risk. The CMMC rule keeps the two apart by definition, and the POA&M rules govern the first and say nothing about the second.

It is not a remediation plan. A remediation plan fixes a control that failed, with a root cause, an owner and a date, and how to write one auditors accept is a different article for a different moment. A compensating control is what you designed because the stated control could not run, and the PCI text is explicit that it cannot be used to patch a requirement missed in the past.

It is not an "alternative control" in the loose sense. Every regime above requires the substitute to cover the risk the original addressed. A control you already run for another requirement, relabelled, covers nothing new, and the PCI worksheet's row 4, "any additional risk posed by the lack of the original control," exists to make that visible.

One thing it is: reusable evidence. A compensating control that operates continuously produces artifacts on a cadence like any other control, and reusing evidence across frameworks applies to it in the ordinary way. Tag the artifacts to every regime the control serves when you collect them.

The record that survives review

Whatever the regime, the record an assessor accepts has the same six parts, because the PCI worksheet is a good template for a question every regime asks:

• The constraint, stated so a stranger could verify it. A named legacy platform with a vendor end-of-support date is a constraint. "Our engineers prefer" is not.
• The objective of the original requirement, in the regime's own words. If you cannot say what the requirement is for, you cannot show the substitute achieves it.
• The additional risk the substitute leaves open, honestly. A worksheet that says "none" in row 4 reads as unexamined.
• The substitute control, described as a control: what runs, how often, who owns it, what it produces.
• How it was validated, meaning tested by someone, with results, before the assessment.
• How it is maintained, because an unmaintained compensating control is next year's exception.

Write it before the assessor arrives, date it, and revisit it when the constraint changes. Constraints expire: the legacy system gets replaced, the vendor ships the feature, the contract is renegotiated. The most common finding we see on this subject is a compensating control still in place two years after the constraint that justified it went away.

Where Top Floor fits

Most of the compensating-control work we do is not designing substitutes. It is telling a client that the constraint they have written down is not one, before an assessor does, and helping them decide between fixing the requirement and documenting the substitute properly. That conversation belongs in audit and assurance readiness and, for cardholder environments, in PCI DSS readiness, where the worksheet is drafted alongside the control set rather than in the week before the assessment. For defense contractors, CMMC readiness is where enduring exceptions and the system security plan get sorted out, and SOC 2 readiness is where the exception-response version of the question lives.

Against our own interest: if you have one legacy system, one clear constraint and a QSA who has already told you what the worksheet needs, you do not need us for this. Fill in the six rows, test the control, and keep the evidence.

How to decide this week

List every place your control set says "compensating" or "alternative" or "in lieu of." For each one, write down the regime it belongs to and check it against that regime's trigger in the table above, not against a generic definition.

Then ask one question of each: is the constraint still true? If the answer is no, the entry is no longer a compensating control; it is an unmet requirement with a paper trail, and the fix is to implement the original.

Finally, for anything under PCI DSS, confirm that the requirement is being answered under the defined approach. If the same requirement is being met under the customized approach for any system component, the compensating control cannot cover that component, and the Council has said so in one word.

Frequently asked questions

What counts as a legitimate constraint for a compensating control?

A technical or business condition that prevents the requirement as stated from being met and that you can document. The PCI DSS v4.0 SAQ D worksheet restricts compensating controls to "entities that have a legitimate and documented technological or business constraint," and the Council describes the typical case as "a legacy system or process that cannot be updated to meet the requirement." Cost, convenience and a project schedule are not constraints in any regime that recognizes the concept, and an assessor will read a worksheet built on one of them as an unmet requirement.

Can we use a compensating control under the PCI DSS customized approach?

No. The PCI Security Standards Council's answer is that "Compensating controls are not an option with the customized approach." They belong to the defined approach only, and they are for entities that cannot meet the requirement as stated, while the customized approach is for entities that choose to meet it differently by satisfying the Customized Approach Objective. The Council does allow the two to coexist across an environment: compensating controls for some system components and the customized approach for the same requirement on others.

Is a POA&M the same as a compensating control?

No. A plan of action and milestones defers a requirement to a scheduled completion date; a compensating control replaces a requirement you cannot meet with a substitute that mitigates the same risk. The CMMC rule keeps them apart by definition: a temporary deficiency, where "a known fix is available or is in process," goes in an operational plan of action, while an enduring exception, where full compliance "is not feasible," is documented in the system security plan with no plan of action required. Filing a substitute control as a POA&M item, or a deferral as a compensating control, invites an assessor to read it under the wrong rule.

Does HIPAA allow compensating controls?

The Security Rule never uses the phrase, but 45 CFR 164.306(d)(3) provides a narrower equivalent for addressable implementation specifications. The covered entity or business associate must assess whether the specification is reasonable and appropriate in its environment, and if it is not, must "Document why it would not be reasonable and appropriate to implement the implementation specification" and then "Implement an equivalent alternative measure if reasonable and appropriate." Required specifications have no alternative path, and addressable does not mean optional: the choice is implement, or document and substitute.