Skip to content ↓ | Skip to navigation ↓

Compliance is a concern for every organization that handles customers’ data. Unfortunately, it’s not always easy for companies to meet the security requirements of frameworks like PCI DSS. Each organization faces technological and/or business constraints; factors which shape its security decisions and sometimes rule out the implementation of certain measures.

In the event an organization can’t satisfy the requirement for a protective measure, it must adopt another mechanism that offers a similar level of security as the original standard. That’s where compensating controls come in.

What Is (and Isn’t) a Compensating Control?

First introduced in PCI DSS 1.0, compensating controls are alternate measures that organizations can use to fulfill a compliance standard. Those controls must satisfy four criteria:

  1. Meet the intent and rigor of the original stated requirement;
  2. Provide a similar level of defense as the original stated requirement;
  3. Be “above and beyond” other PCI DSS requirements (not simply in compliance with other PCI DSS requirements); and
  4. Be commensurate with the additional risk imposed by not adhering to the original stated requirement.

Some organizations think of compensating controls as shortcuts by which they can achieve compliance with little effort and money spent. But that’s not the case. Dr. Anton Chuvakin and Branden Williams, co-authors of PCI Compliance, note alternate compliance measures are, in fact, quite difficult to implement:

“Compensating controls are challenging. They often require a risk-based approach that can vary greatly from one Qualified Security Assessor (QSA) to another. There is no guarantee a compensating control that works today will work one year from now, and the evolution of the standard itself could render a previous control invalid.”

Companies with an interest in compensating controls need to understand that Qualified Security Assessors (QSAs) will ask for documentation of their business constraints during a security assessment. The documented constraints must be legitimate. In other words, an organization can’t cite a qualified professional going on vacation as a constraint.

Companies must also submit documentation demonstrating that they performed a risk analysis of the gap between the original measure and a proposed alternate measure. Performing such an analysis takes time and costs money – sometimes even more than what it would take to address the original issue or vulnerability. Only then can organizations move onto the next step: designing a compensating control.

Designing a Compensating Control

Organizations have a lot of flexibility in creating alternate controls. After all, compensating controls can apply to nearly every PCI DSS requirement aside from permissible storage of sensitive authentication data after authorization. Let’s look at some examples.

Example #1: Segregation of Duties

To prevent instances of fraud and error, some organizations are required to create an internal control that requires two or more staff complete separate parts of a task. Take an organization’s financial department, for example. One employee might assume several accounting duties, while another employee might be responsible for just writing the checks.

But as noted by Tech Target, it’s not always possible for every organization to implement that control. That’s especially true for companies with small staffs. In those instances, an organization might maintain and review logs and audit trails instead.

Example #2: Encryption

Some companies may lack the resources necessary to encrypt all electronic data. They might, therefore, turn to compensating controls to provide an equivalent level of security. Those include database security applications, e-mail encryption and other tools.

Companies might decide, for instance, to switch their mid-tier UNIX operating systems from Discretionary Access Control (DAC) to Mandatory Access Control (MAC). Doing so could help render the data unreadable under PCI Requirement 3.4. But true to any compensating control, there’s a cost.

Dr. Chuvakin and Williams explain:

“Security professionals inside companies love the idea of converting to MAC as it allows us to have more granular control over the systems and their data. Practical ones know that converting an existing system requires so much effort that the costs outweigh the benefits.”

Example #3: Log Storage

A retailer with 500 stores needs to log all individual accesses to cardholder data. They currently store their data in a large database. To meet the requirement, the company is considering purchasing lots of drive space to store its logs.

Log management is important to breach detection and response, so the retailer shouldn’t overlook that step. To figure out which cards are accessed through the data contained in the logs, the company doesn’t necessarily need to invest in more storage space. It could instead log the actual query performed against the database during a batch process that runs daily.


Even after an organization comes up with a compensating control, they might not yet be in the clear. In the case of merchants, a QSA can initially approve the control, but the Acquiring Bank has the final say. That means a company can waste a lot of time and resource designing a control that their acquirer might block anyway.

With that said, compensating controls are useful when it comes to compliance. But they’re impermanent fixes that organizations should replace with the original control as soon as possible. Companies should never use them as shortcuts to achieving compliance.