Archive for September 2nd, 2010


Writing A Compensating Control

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.


Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

September 2010