PCI DSS compensating controls and the customised approach: when each applies and how QSAs test them

Three routes to one requirement

Most organisations meet almost every PCI DSS requirement the plain way: implement the control as written and show the evidence. That is the defined approach, and for most controls it remains the quickest route.

Sometimes the plain way is blocked. A payment application may be too old to support a control, or a vendor may no longer patch a platform. Version 4 offers two ways forward, and they are easily confused. A compensating control is a substitute used within the defined approach because a constraint stops you meeting the requirement as stated. The customised approach is a different method of validation altogether, chosen deliberately by an organisation that wants to meet a requirement's objective in its own way.

Both sit inside a scope you have already agreed. If you are still deciding what belongs in the cardholder data environment, start with our guide to scoping and segmentation; removing a legacy system from scope is often cheaper than compensating for it.

Compensating controls: the conditions they must satisfy

The PCI Security Standards Council describes compensating controls as available where an entity cannot meet a requirement as stated because of a legitimate and documented technical or business constraint, and has reduced the associated risk through other controls. The Council has also said plainly that a compensating control cannot be used retrospectively to cover a requirement that was missed in the past.

The standard's appendix on compensating controls sets out the tests an alternative must pass. In substance:

• Intent and rigour. The alternative must meet the purpose of the original requirement and give a comparable level of protection.
• Above and beyond. It must go further than other PCI DSS requirements. A control you are already obliged to run elsewhere in the standard cannot be counted as compensation for a different one.
• Commensurate with the risk. It must address the additional risk created by not meeting the requirement, in proportion to that risk.
• Maintained. It must keep working for as long as it is relied upon, and it is evaluated again at each annual assessment.

Each compensating control is recorded on a compensating controls worksheet. The worksheet walks through the constraint, the objective of the original requirement, the risk the gap creates, the alternative controls, how they were validated and how they are maintained. For a Report on Compliance the worksheet sits with the report; self-assessment questionnaires carry their own version for the merchant to complete.

The customised approach: what the Council asks for

The customised approach was introduced with version 4. Instead of implementing the requirement as written, the organisation designs a control that meets the customised approach objective stated for that requirement, and proves it. The Council notes that it suits entities with robust security processes and strong risk management.

For each requirement met this way, the organisation must produce two things before the assessment begins. The first is a targeted risk analysis for that control. The second is a controls matrix that describes the control, how it meets the objective, how it is tested internally and who owns it. Requirement 12.3.2 and Appendices D and E of the standard are where the Council gathers these elements.

The assessor derives testing procedures specific to your control rather than using the published ones, so assessment effort rises. The route is available only in a Report on Compliance, so a merchant who would otherwise use a self-assessment questionnaire needs the agreement of its acquirer and a full assessment. And compensating controls cannot be used within the customised approach; the two do not combine for the same requirement.

Defined, compensating or customised: side by side

Worked example: a legacy system that cannot meet a requirement

A contact centre runs a billing application that is more than a decade old. It stores full card numbers for recurring payments and cannot render them unreadable in its database, so one part of Requirement 3 cannot be met as stated. The vendor has stopped developing the product, and a replacement platform is scheduled but will not be live before the next assessment.

Is the constraint legitimate?

Yes, if it is documented: the vendor's written confirmation that encryption is not supported, the approved replacement plan, and the business reason the application is still needed.

What counts as compensation?

The team places the database on its own isolated segment, reachable only from two hardened application servers. Database access is restricted to a small approved group through a separate privileged-access route, every query against the card table is logged and alerts on bulk reads, and file integrity monitoring watches the database files. Routine access reviews do not count, because Requirement 7 already demands them; the extra segmentation, the query-level alerting and the dedicated access route are what go above and beyond.

What goes on the worksheet?

The constraint and its evidence, the objective of the original requirement (stored card numbers must be useless to anyone who obtains them), the added risk, the alternative controls, how the team tested them and who maintains them until the replacement goes live. The QSA then tests each alternative independently. Once the new platform is live, the compensating control is retired.

The customised approach would be possible only with a targeted risk analysis, a controls matrix and a Report on Compliance; for a temporary legacy constraint, a well-built compensating control is usually more proportionate.

Where these routes go wrong

• Calling a missed deadline a constraint. A control that was simply not implemented in time does not qualify, and the QSA will ask for the evidence behind the claimed constraint.
• Counting controls that are already required. Segmentation, logging or access reviews that another requirement demands anyway do not compensate for anything.
• Treating the worksheet as permanent. A compensating control carried for years with no plan to remove the constraint weakens the case at every assessment.
• Choosing the customised approach to avoid work. It adds analysis, documentation and assessor effort; it rewards maturity, not haste.
• Deciding without the assessor. Raise either route with your QSA early; our guide to internal assessment and the ISA covers how to test these controls yourself first.

PCI DSS compensating controls: questions buyers ask