Society of Payment Security Professionals - Payment Security Blog

Verify that Compensating Controls work

If you build a new deck in your backyard, would you test it out before inviting your friends and family over for a bar-b-que?  Well it turns out that many merchants are documenting compensating controls but not actually testing them to make sure they work.  How could this be?  I’m asking myself the same question.

There is a simple approach to understanding compensating controls that starts with asking the question, “When would I use a compensating control?”  The answer to that is any time that you have a legitimate business or technical reason.  For example, you may have some specialized technology that meets the intent of the requirement but not in the prescribed manner of the Security Audit Procedures (SAP).

Then you should document your findings, so you can show them to people if they ever ask, “what in the world were you thinking?”  This documentation should include those items listed in the Compensating Controls Worksheet.

1. Constraint - the business or technical constraint precluding compliance with the original requirement
2. Objective - the intent of the original control
3. Identified Risk - the risk posed by the lack of the original control
4. Compensating Controls - the controls in place that mitigate the risk to meet the intent that could not be achieved via the constraint

But you cannot stop here!  You actually need to test these compensating controls to make sure they hold up.  It’s not sufficient to say that a company uses RACF security on their Mainframe as a compensating controls for something else if you do not evaluate the security of the RACF configuration.  For each compensating control you must actually TEST it to make sure it is sufficient to mitigate the risk to cardholder data.

As Ronald Regan always said, “Trust, but verify!” (“doveryai, no proveryai”)