There are circumstances where companies could face some technical or business impediments preventing them from implementing the requirements as explicitly stated in the standard. Does this mean that these companies could never achieve and maintain compliance?

There is a common misconception that organizations must meet the requirements as they are written. This is not the case. The important thing is that the inherent security objectives behind each requirement are met. The PCIco and the Payment Brands provide some flexibility by allowing companies to pull a rabbit out of their hat. This rabbit is named "compensating controls": a very popular topic these days as more and more organizations look at it as a way to achieve compliance. But is this really the case?

A compensating control is a work-around for a security requirement. In other words: it’s another way to reach the objective sustained by a specific security requirement without satisfying the requirement itself. Understanding this requirement and its objective is therefore of the utmost importance in choosing and evaluating a compensating control. 

The reader could refer to “Navigating the PCI DSS” to get an understanding of the objective behind each requirement.

With the exception of requirement 3.2 – Do not store sensitive authentication data after authorization - any security objectives supported by the PCI DSS requirements can be met with compensating controls. 

There is, however, a caveat to the above statement. Companies must prove that the roadblock to implementing the requirement is temporary and due to "legitimate" technical or business constraints. The term “temporary” is important as the situation must be reviewed on an annual basis.

What does “legitimate” mean to the Council? It isn’t very explicit on this. Definitely the cost of implementation isn’t a legitimate constraint for them, but an application running on an old non-supported operating system (sustained by a migration roadmap) or the Christmas sale load delaying implementation are two examples of “acceptable” legitimate constraints provided by the Council at the 2011 PCI community meeting.

To potentially be considered valid, a compensating control must fulfill the same intent and objective of the requirement it’s supposed to replace, with the same or higher level of defense, and without introducing any other risks (border effects) or with any additional risks both minimized and documented.

So the root of the issue is whether or not the risk has been sufficiently addressed: the risk of not implementing the requirement, and the risk inherent to the selection of the compensating control.

Every compensating control must be supported by a risk analysis and must be documented as follows:

<!--[if !supportLists]-->1.     <!--[endif]-->What is the original objective that one tries to cover?

<!--[if !supportLists]-->2.     <!--[endif]-->What are the legitimate constraints preventing meeting the original requirement?

<!--[if !supportLists]-->3.     <!--[endif]-->What is the compensating control?

<!--[if !supportLists]-->4.     <!--[endif]-->What are the identified risks posed by the lack of original control or introduced by the implementation of the compensating control?

According to the standard, QSAs are the ones responsible for validating the compensating controls, at least for Level 1 merchants and service providers. There are no other validators than the acquirers themselves for all other merchant levels.

However, the majority of the QSAs are NOT in favor of compensating controls and would dissuade their customers from using them. According to them, compensating controls could reveal themselves to be much more costly and difficult to implement that the requirements they replace. The fact that QSAs must sign off the compensating controls is probably another reason for this reluctance. 

Additionally, there is no unification for the validation of the legitimate constraints and compensating controls among QSAs. A compensating control could be seen validated by one QSA while being rejected by another.

A central database of “historically accepted compensating controls and legitimate business or technical constraints” could be of some added value for the community.

My interviews with the Council, the Brands and the QSAs on that matter leads me to conclude that due to the stringent constraints imposed by the PCIco on the selection and use of compensating controls, combined with the QSAs reluctance to approve the use of compensating controls, and also the lack of unification, compensating controls should be considered more as a mirage than a magic trick.

<!--[if !supportLists]-->1.     <!--[endif]-->What is your experience in this field?

<!--[if !supportLists]-->2.     <!--[endif]-->Have you already made use of compensating controls?

<!--[if !supportLists]-->3.     <!--[endif]-->If yes was it easy to get validated?

<!--[if !supportLists]-->4.     <!--[endif]-->Would you be in favor of a publicly available database of compensating controls?

Navigating the PCI DSS

PCI Compliance dashboard