This is a very popular topic these days as more and more organizations have to rely on compensating controls to comply with the PCI DSS. With the exception of requirement 3.2 – do not retain track data, any of the other PCI DSS requirements can be met with a compensating control.
First, let us get familiar with what is required for a compensating control. For v1.2 of the PCI DSS, there are seven elements to the compensating control.
- Identification of the PCI DSS requirement that the compensating control is addressing.
- Identifying the business constraint(s) as to why the organization cannot meet the PCI DSS requirement.
- Defining the objective(s) of the original PCI DSS requirement and the objective(s) that this compensating control addresses.
- Identification of any additional risk presented by having the organization rely on the compensating control.
- Identification and definition of the compensating controls.
- Procedures followed to validate the compensating controls.
- Procedures followed to maintain the compensating controls.
The first rule is that a compensating control should only address one PCI DSS requirement. However, in practice, I write some compensating controls addressing a single group of PCI requirements such as with 8.4 where you have an (a) and (b) component. For requirements like 8.5 where you really have separate requirements, I write those as separate compensating controls. It is up to your QSA to determine whether or not multiple requirements can be covered by a single compensating control.
Identifying the business constraint should be the easiest part of a compensating control. However, I have seen too many constraints that indicate the only reason there is a compensating control is because of a lack of the business’ ability to implement the requirement. That just does not cut it. You really need to document valid business reasons as to why a compensating control is needed. The fact that your organization does not have the backbone to implement PCI DSS requirements is not a valid reason.
However, the biggest areas where things go awry is with sections 4, 5 and 6 of the compensating control form. Section 4 is where the organization documents the controls that compensate for the fact that the original requirement not being implemented. Section 5 is where the organization documents the processes for validating that the controls in section 4 are operating effectively. And section 6 is where the organization documents its processes that maintain the controls documented in section 4.
The rule that people seem to miss is that if you document a control in section 4, then you need corresponding discussions in sections 5 and 6 to provide the processes that validate and maintain that control. I have seen too many instances where a lot of great controls are documented in section 4 and then in sections 5 and 6 those same controls are never discussed.
To avoid this situation, I tell my clients to list out all of your compensating controls in section 4. Then in the same order as in section 4, go through in sections 5 and 6 and document what was done to validate and maintain the controls.
As an example, if section 4 says, “Hardening standards for Linux go beyond the vendor standard and all services are removed other than those services absolutely needed for the Linux server to function as a Web server.” Then in section 5, I would expect to see, “Validated that the client’s Linux hardening standard goes beyond the vendor’s by comparing the two standards. Compared the hardening standard to the configuration of a sample of x of y Linux servers and confirmed that the standard was in fact implemented.” In section 6, I would want to see, “Client’s Linux system engineers evaluate each security patch for its applicability to their environment and whether it enables unnecessary services. Patches are implemented in a test environment and evaluated with port and vulnerability scanners to ensure that the patch does not enable services that are not necessary.”
Hopefully this clarifies for all of you how to write a proper compensating control.
PCI Guru 
We currently use company owned desktops to enter credit card data into the 3rd party website for processing. The data is obtained via call center rep. These functions are limited to desktop and not allowed for laptop or work from home users – controlled using IP address. These desktops are behind corporate firewall. Per PCI control 1.4 – Our QSA asked us to install personal firewall and IPS on this desktops to manage scope so other connected systems such as share drive, email, etc.. would be out of scope and also IPS would not allow any malware from being installed. One of the issue I have with this control is that the control talks about laptop / mobile devices and NOT desktops. So why do we need to install the personal firewall and IPS on the desktops?
Any guidance you can provide on this?
I can only assume that it was done for the critical file monitoring capability (requirement 11.5), not for malware prevention (requirements 1.4 and 5.1.1). However, not all host-based IPSs do good jobs of ensuring critical files are not tampered with, particularly those related to applications outside of Microsoft Office or similar. So, I can only assume that whatever IPS solution being used does do a reasonable job of monitoring files that are not expected to change except for when maintenance/updates are performed. In your environment, the risk is that a keyboard logger gets installed that is able to gain access to cardholder data as it is keyed. That is why critical file monitoring is necessary so new software cannot be installed without being not allowed or an administrator being alerted.
Can you please give me some more examples of compensating controls.
While I would like to, the consultant in me says that doing that would be giving away my livelihood. 🙂
That is an honest response.. 🙂
Reading your post I thought of a problem which I have never completely resolved. In other words the question is: Can a compensating control be used indefinitely trough the years (I mean in different ROC of the same customer) or is it necessary to bring the customer to reach the full compliance of that requirement? If the answer is affirmative, how long can a compensating control be used? I mean, I know, generally speaking, that every year the requirement have to be re-validated and also that the standard evolve in the span of its life-cycle, but in your opinion, do compensating controls have a life time that can not be exceeded?
There is no limitation to how long a compensating control can be relied upon. However, a QSA is required to assess the functioning of any compensating controls as part of an organization’s annual PCI assessment.
I do have some clients that have escalation procedures for their compensating controls. For example, for the first two years the department manager is required to justify the use of the compensating control(s). At the third and fourth year, the department manager’s boss is required to justify and sign off on the compensating control(s). At the fifth year, the next person up in the chain has to justify and approve the compensating control. This process continues until the CEO is required to justify and approve the compensating control. The idea is to give an incentive for people to fix the situation rather than just perpetuating it.
One day we’ll all look back on this and laugh.
One can only hope it will only get better.
But based on the card brands’ and banks’ approach to this, you have to wonder.
Compensating controls are good in theory, but we have seen them backfire in practice. A compensating control is a way that someone can try to validate their PCI compliance without meeting the letter of the standard. The “alternative” control is supposed to meet the security of the standard.
If there is a breach, the compensating control is then re-evaluated and in every case we have seen it is determined that even though a QSA signed off on the compensating control, it was deemed insufficient after a breach.
Therefore, most of our customers see compensating controls as a way to meet their compliance obligations, but they all assume that they will be penalized for using them if there is an issue.
Unfortunately, there are a number of instances where a compensating control is the only way to comply. I have a client that maintains a transaction database that carries only 150 days worth of transactions. The bare minimum that their business can afford to maintain. However, in order to change encryption keys for this database takes just shy of a year to change because the database must be decrypted and the re-encrypted with the new key. As a result, it’s just not possible to change encryption keys and therefore, they have a compensating control.
One thing that you neglected is that compensating controls must go above and beyond the requirement that it is compensating.
Just like all other controls, it takes diligence to maintain them and keep them operating. even the best of companies have issues in keeping up their diligence on their controls. Even with good internal and external audit programs, errors happen. Where compensating controls run into problems is when you are mostly relying on compensating controls for all of yoru controls. Then you have no overlap to save you when controls go out of compliance.
@PCI Guru,
You and your client will be happy to learn that the latest PCI council training (as of February anyway) suggests that changing the key encrypting key(typically the password protecting a keystore in a DB environment) is sufficient to meet this requirement.
I could not believe it when I heard the first time and had to go back and review again(online training). I completely disagree with this approach as it does nothing end the use of a compromised key which I believe was the original intent of this control.
Yes, we are aware of the changing the encryption of the key encrypting key as a valid way of meeting the requirement. However, the client already had the compensating control in place from a number of years back, and continues to use it since it is already in place. That said, when you are relying on encrypting the key encrypting key (KEK), you need to have controls surrounding that encryption process so that the KEK cannot be readily compromised. That is where most organizations get it wrong.
@Bradley,
In cases where you have seen compensating controls fail, were they designed to address the threat in the first place? If the controls were properly maintained should they have prevented the compromise? I have seen instances where QSA’s throw everything including the kitchen sink into compensating controls which really do not address the threat the original control was trying to address. In fact, in many cases they are just a rehash of other controls which are already required.
When compensating controls fail they fail because the controls involved were not monitored and/or managed to keep them working as specified. It’s very rare that they are not designed right because we review them to ensure that they are designed to meet and go beyond the original requirement. However, as the QSA, we are not responsible for ensuring that they are executed correctly day-in and day-out and that is where things usually go wrong. In your example of QSAs tossing everything into a compensating control, that usually is a good indication of a QSA that does not understand what a compensating control is and how to write one.