What Is a Compensating Control and How Do You Document One?

A compensating control is a safeguard an organization uses in place of a recommended control in a standard baseline, while still giving similar protection to the system. It can be managerial, operational or technical. It is a documented substitute for a control you cannot apply as written, not a way to skip the requirement.

Where does the term come from?

The NIST glossary defines a compensating security control as a safeguard or countermeasure employed in lieu of a recommended control in a baseline, which provides equivalent or comparable protection for an information system. It cites NIST SP 800-30 Rev. 1 and SP 800-39, both drawing on CNSSI 4009, and NIST SP 800-137 gives a related definition tied to SP 800-53 controls.

NIST SP 800-53B defines low, moderate and high control baselines, plus guidance on tailoring and overlays. Tailoring is the formal route to adjust a baseline: control PL-11 asks organizations to tailor the selected baseline by applying specified tailoring actions. Compensating controls sit inside that process. The idea is that the baseline is a starting point, and you may choose another control when you can show it covers the same risk.

Other frameworks use the term in their own way, with their own approval steps. Read the rules of the framework your auditor applies.

When is one appropriate?

A real constraint should exist: a legacy system that cannot support multi-factor authentication, a medical or industrial device that cannot be patched, a vendor that does not offer a required setting. Cost or inconvenience alone is a weak reason, and auditors tend to treat it as one.

The substitute must address the same risk. Replacing "encrypt data at rest" with "we have a lock on the server room" does not cover the same threat. Replacing it with strong network isolation, tight access control and monitoring of reads may cover part of it, and should be described honestly as partial.

A constructed example

A hospital laboratory uses an old analysis machine that cannot be patched. The requirement is timely patching of known vulnerabilities. The team documents a compensating package:

• the device is on an isolated network segment with a deny by default rule, with only one allowed connection to the results server;
• removable media is disabled and the ports are physically blocked;
• all traffic to and from the device is logged and reviewed weekly;
• the vendor's end of support date triggers a replacement plan.

The record names the risk each measure addresses, shows how the residual risk is lower than the unpatched baseline, and gives an expiry date for review. That record is what an auditor wants to see.

What goes into the documentation?

• The requirement you cannot meet, with its identifier.
• The constraint that prevents it, with evidence.
• The compensating measures, and the specific risk each one handles.
• How you will verify they work, such as a test or log review, and how often.
• The residual risk, and who accepted it.
• An owner and a review date.

How to check or apply this

1. Confirm the constraint is real and written down.
2. Name the threat the original control was meant to reduce.
3. Design measures that address that threat, preferably more than one layer.
4. Describe what remains uncovered and get a named person to accept that risk.
5. Test the measures and keep the evidence.
6. Set a review date, usually tied to when the constraint might end, such as a replacement or upgrade.
7. Track all compensating controls in one register and revisit it every audit cycle.
8. Remove the entry once the original control is implemented.

Quick check

Sources

• NIST CSRC glossary: Compensating security control
• NIST SP 800-53B, Control Baselines for Information Systems and Organizations
• NIST SP 800-53 Rev. 5 control catalog, OSCAL JSON from NIST (PL-11)

Last reviewed: 18 October 2026.