PCI DSS

Compensating Control Requirements for PCI

Since the very beginning of the PCI DSS, there has been the ability to put in place a compensating control for any requirement. Compensating controls are a type of internal control where the entity uses an alternative method to achieve the same result. They are used where there is a technical or business constraint that prevents meeting the stated objective and are a means to mitigate the risk of the original requirement.  It can be a very complex topic, so I’ll break this discussion down into the guidelines to use, the process one would follow, the aspects of the documentation and lessons learned along the way.

Guidelines

The compensating control process is found in two appendices of the PCI DSS, Appendix B and Appendix C. Appendix C is the compensating control worksheet (more on that later) and Appendix B is the introduction and guidelines for filing a compensating control. We in the QSA community call them ‘CCW,’ which means “Compensating Control Worksheet”, and technically is Appendix C, but both appendices should be consulted if you find yourself in a position to need one. An important note: a CCW is applied to entities that self-assess using the Self-Assessment Questionnaire, and to entities that are required to have an external QSA assess their compliance.

Appendix B should be reviewed before you get started, its valuable guidance. The key bullet points are:[1]

1. The compensating control must meet the intent and rigor of the original PCI DSS requirement.
2. Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against.
3. Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.)
4. Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.

Let’s break these down. The first one, “The compensating control must meet the intent and rigor of the original PCI DSS requirement,” means it has to be able to stand on its own as a viable control to meet your PCI DSS requirements.  For example, if systems are not loaded with critical patches throughout a change moratorium during the holiday season, and you have controls in place to enhance logging, enhance access controls, immediate file change notifications and intrusion protection. Those controls are to address the additional risk of not patching systems in a timely manner. They must be running, configured and in place at the time you stopped normal patch management processes. Also, evidence of the implementation of the compensating control must be documented at that time.  You can’t “back date” evidence to meet your PCI compliance later when you’re in the annual assessment.

The second procedural statement, “Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against,” can’t be overstated. Whatever it is you put in place in lieu of the original control can’t lower your overall risk and leave you exposed to attack.  Information security is all about defense in depth. If you lower your defensive posture by putting in place a control that does not cover the risk, the control you put in becomes a risk in itself.

Third, “Be ‘above and beyond’ other PCI DSS requirements…” Simply being compliant with other PCI DSS requirements is not a compensating control.  The writers of the PCI DSS have a specific goal in mind and each requirement is written to address the intent of that goal. Your compensating control must address the risk that the original requirement is designed to cover. What does “above and beyond” mean? It means you can’t rely on your existing controls to cover where you’re imploring alternative means to meet compliance.  You must put additional controls in place to ‘overcompensate’ for the lack of the original control.

The last procedural statement, “Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement,” means the compensating control has to be of equal effectiveness as the original control.

The Process

So how do you get a compensating control done? I would say it’s fairly straightforward, just fill out the form found in Appendix C, but that is an oversimplification. The CCW is embedded in the Report on Compliance, RoC, in Appendix C.  The RoC template has an example which can be found at the bottom of Appendix C to help guide you.  The author of the CCW writes in the column, “Explanation” to address the “Information Required.”

Each control that needs a compensating control must have a unique compensating control worksheet. That applies even if you have the same compensating control cover multiple PCI DSS requirements.

I make writing the CCW a collaborative effort between myself and the client. Some QSAs write the CCW themselves, but I prefer to have the client partner with their input. The CCW has a validation step that requires the QSA/ISA to review/test the alternative controls to make sure they are operating properly. The QSA/ISA documents in the RoC their response on the review/test steps taken to validate the alternative control.

The Form

Which leads me to the form itself.[2] As mentioned, there are six “Information Required” areas to the form:

1. Constraints – the technical or business reason for not being able to meet the original requirement as stated in the PCI DSS
2. Objective – what was the original control goal? Define the objective met by the compensating control
3. Identified Risk – identify addition risk found as a result of the lack of the original control
4. Definition of Compensating Controls – this is where the compensating control is written down in detail, how it addresses the original control, and how it covers any additional risk
5. Validation of Compensating Controls – this is usually reviewed by the QSA/ISA; captured here is how was the control is tested and validated
6. Maintenance – what are the process/controls to maintain the compensating control.

Lessons Learned

As a QSA, I see CCW’s all the time. I’ve had assessments where no compensating controls are added, and I’ve had assessments where several requirements are covered by compensating controls. It’s part of my role as assessor to review and observe the results of testing procedures for compensating controls. Ultimately, it’s the QSA who has the responsibility to accept/reject the compensating control.

I’m going to add a few thoughts on what I’ve seen conducting assessments:.

Constraints tend to be the most interesting responses. The constraint really needs to be a concrete technical or business reason for not meeting the original requirement. As a QSA, I’ve read some to the effect, “We got behind and forgot to re-scan after fixing the vulnerabilities,” while others are more pointed, like “It will cost us $2M in order to comply with the original requirement, and we don’t have the budgetary expense at this time.” I’m showing these to you as there’s a fine line here between a valid reason, like the latter, and the former looking like they are simply non-compliant. Make sure you’re not trying to retroactively implement a compensating control when, in fact, the control is non-compliant.

Objective – For the objective, you need to look at both the PCI DSS requirement and the Guidance column. There’s an intent and a goal behind each requirement, and the guidance column in the DSS is there to explain that intent and the goal. By stating what is the intent of the original requirement and the objective of the compensating control, a comparison can be immediately made to judge the merits of the compensating control.

Identified Risk – I’ve found that the guidance column in the PCI DSS is helpful to understand risks induced by the missing controls. Through an understanding of the risks involved, the next section can be framed as to the mitigation of those risks. Only through a deep understanding of the risks can adequate controls be applied where the original control is not in place.

Definition of Compensating Controls – This section should be written assuming the reader has never touched information security. The reason behind that is a sufficient level of detail needs to be there to fully explain the compensating control. For example, if extra logging is one of your compensating controls, go into detail of how that logging is going to take place, how it is going to be monitored and what actions will be taken in the event of an incident. This is not the time to say, “Trust me, I know it’s OK and protected.” There are many people who read the compensating controls downstream of the QSA/ISA. Providing sufficient detail in the CCW heads off rejection of the form and potential rework.

Validation of Compensating Controls – Validation steps are explicit steps taken to validate the controls are working as intended.  It also provides the assurance the compensating control addresses the risk incurred by not using the original controls dictated by the PCI DSS requirement. As a QSA, I want to see the compensating control works as intended and was put in place at the appropriate time. Compensating controls are required to be put in place immediately on a gap in controls, not after the fact. I’m wanting to see that the compensating control was put in place at the appropriate point in the past, and I’ll ask for evidence to the effect. Using the logging example above, I want to capture evidence that the logging control was put in place months ago (older log entries) when the original control was no longer workable, and is in place and working as designed today (running log processes and current log entries). That evidence is put into the assessment work papers for long term archive.

Maintenance – This is where what is maintaining the compensating control is captured. What are the steps being taken to make sure the compensating control doesn’t disappear? Using the logging example, if system builds need changes to the operating system to enhance the logging, how is that happening? Is there a standardized build process that makes sure the enhanced logging is configured? Does the team involved in the logging know of the compensating controls and are change records being monitored by the PCI coordinator looking for changes that may remove the controls? Does your logging system verify connectivity to the target to make sure logging is enabled? These are examples of the questions to ask when thinking about the maintenance. As a QSA, I’m looking for enhanced oversight of the systems and processes that surround the compensating control, and a raised awareness of the compensating control with support teams.

This blog just touches the surface of CCWs. As I stated at the top, compensating controls can be extremely complex in nature and result in a great deal of work to implement. As a closing comment, I want to share there is a school of thought that compensating controls have a short lifetime. The timeline being something like put a CCW in this year, budget for the fix next year, and implement the desired PCI DSS control the third year. While I’ve worked for companies that held that thought, it is not universally applied, mostly because of budgetary constraints. Compensating controls can be used year after year just as long as they are still required and still viable.

[1] These can be found in the PCI DSS v3.2.1 found at https://www.pcisecuritystandards.org/document_library

[2] Paraphrased from the PCI DSS v3.2.1 found at https://www.pcisecuritystandards.org/document_library