PCI DSS Compensating Controls Explained (With Worked Examples)

Compensating controls are alternative safeguards used when a required control cannot be implemented as written, chosen to reduce the same risk to a similar level. In PCI DSS, a compensating control is allowed only when a legitimate, documented technical or business constraint stops you meeting a requirement. It must meet the intent and rigour of the original requirement, give a similar level of defence, go above and beyond other PCI DSS requirements, and be proportionate to the extra risk. You document it on the Compensating Controls Worksheet in Appendix C of the standard, and it is re-validated at every assessment.

Compensating controls are widely misunderstood. They are not a way to avoid work, and an assessor will reject one that does not meet the criteria. This guide explains how they work under PCI DSS v4.0.1.

Key takeaways

• A compensating control is an alternative to a defined requirement when a genuine constraint prevents you meeting it.
• Every compensating control must pass four criteria set in Appendix B of PCI DSS.
• Controls you are already required to have do not count; the alternative must go above and beyond.
• Each one is documented on a worksheet and re-validated at every assessment.
• The customised approach introduced in v4.0 is a different mechanism with different rules.

What is a PCI DSS compensating control?

PCI DSS v4.0.1 offers two ways to meet a requirement. The defined approach means implementing the requirement as written and having it tested with the standard’s testing procedures. The customised approach means meeting the requirement’s stated objective with a control you design.

Compensating controls belong to the defined approach. You use one when you cannot meet a defined requirement as stated because of a documented constraint, and you have put other controls in place that reduce the risk to a similar level. Appendix B of the standard sets the rules and Appendix C contains the worksheet. Both are in PCI DSS v4.0.1, available from the PCI SSC document library.

When is a compensating control allowed?

Only when the constraint is real. An assessor will test that first.

Cost may influence how quickly you remove a constraint, but it is not a constraint in itself.

What are the four compensating control criteria?

Appendix B sets four criteria. Fail any one and the compensating control is not valid.

What does “above and beyond” mean?

You cannot count a control you are already required to implement. If a requirement already obliges you to do something for that system, doing it does not compensate for something else.

Existing requirements can still help when you apply them to something they would not otherwise cover, or apply them more strictly than required. For example, reviewing logs for a specific legacy system in near real time, rather than at the frequency the standard sets, goes beyond the baseline.

Compensating control examples in practice

Example 1: an unsupported operating system

A retailer runs a payment application on an operating system that no longer receives security updates. The vendor’s replacement will not be ready for a year, so the retailer cannot meet the requirement to install critical security patches within one month of release (6.3.3).

A credible compensating control might combine:

• Moving the system into its own tightly restricted network segment that allows only the connections the application needs.
• Application allow-listing, so only approved executables can run.
• File integrity monitoring on critical system and application files.
• Real-time alerting on any unexpected logon, process or network connection, reviewed promptly.
• Authenticated scanning of the system more often than quarterly, through vulnerability scanning services, with results reviewed each time.
• A documented, funded plan and date to migrate to the supported replacement.

None of these alone would be enough. Together they address the specific risk that unpatched vulnerabilities could be exploited. The assessor will test each element, so the retailer also needs evidence that they work, such as PCI DSS penetration testing of the new segment.

More compensating controls examples

The same pattern, a genuine constraint answered by several layered controls, applies to other requirements. These are typical starting points, not ready-made answers: each still has to pass the four criteria for your environment.

Compensating controls outside PCI DSS

The idea is not unique to card payments. The NIST glossary defines a compensating security control as one used in place of a recommended baseline control that gives equivalent or comparable protection. In financial controls, the classic example is a finance team too small to separate who raises and who approves payments, which compensates with an independent review of every payment run by a manager outside the team.

Not every scheme works this way. ISO 27001 has no separate compensating control process: you choose controls through risk treatment and justify them in your Statement of Applicability. Cyber Essentials is pass or fail against fixed requirements, so unsupported software, for example, must be removed or moved into a segregated sub-set outside the certified scope.

How do you complete the Compensating Controls Worksheet?

The worksheet in Appendix C has six sections. Write it for someone who has never seen your environment.

Be specific about systems, configurations and evidence. Vague statements such as “enhanced monitoring is in place” will not survive review. In a Self-Assessment Questionnaire, you mark the requirement “In Place with CCW” and attach the worksheet. Our guide to common SAQ mistakes shows how these are often misused, and our free PCI compliance check gives a quick view of the gaps you may need to close first.

What is the difference between a compensating control and the customised approach?

They are easy to confuse, but they work differently.

Some requirements cannot be met with the customised approach at all. If you are simply stuck with a legacy system, a compensating control is usually the right tool.

Why are compensating controls rejected?

• The constraint is really about cost or convenience.
• The proposed controls are already required by other PCI DSS requirements.
• The controls do not address the specific risk created by the gap.
• There is no evidence the controls operated effectively over the assessment period.
• The worksheet is generic and could describe any environment.

How long can a compensating control stay in place?

As long as the constraint exists and the control keeps passing validation, but treat it as a debt to be repaid. It is re-evaluated at every assessment. Between assessments, monitor it like any other control, record and fix failures, and check whether the constraint still exists. Once the constraint is gone, the compensating control is no longer valid and you must meet the original requirement. A PCI DSS gap analysis is a good time to review them all.

Getting it right first time

The best time to discuss a compensating control is before you build it, not during the assessment. Sovereign Secure is a PCI SSC-approved Qualified Security Assessor company and a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026 to 2028. A PCI DSS consultant from our team can help design and document the control, and we test it as part of your PCI compliance audit.