PCI Compliance Every Day

The title of this post sounds daunting, does it not? However, achieving PCI compliance every day is not as daunting as you might think.

With the release of PCI Data Security Standard (DSS) v3.2, the PCI Security Standards Council (SSC) introduced the concept of business as usual (BAU). BAU is meant to embed those relevant PCI DSS requirements into the business operations of organizations.

The PCI DSS v3.2 provides the following as examples of processes that should be part of an organization’s BAU:

• Monitoring of security controls
• Ensuring security control failures are identified, rectified and a root cause analysis (RCA) is performed
• Change management
• Changes to organizational structure (i.e. merger/acquisition)
• Periodic reviews and communication regarding PCI DSS compliance
• Review of hardware and software technologies to confirm they continue to be supported by the vendor and can meet the entity’s security requirements, including PCI DSS

The hope of the BAU process is that if the organization integrates the relevant PCI DSS requirements into the business processes, compliance will be more consistent and therefore more effective at securing cardholder data. That, in turn, will address the data breaches that are the result of compliance failures. Or so the thought process goes.

Which brings us to who will enforce this BAU approach? For most organizations, BAU is not required by the PCI DSS, but we would suspect that could change if data breaches continue to be the result of failed operational practices. That said, if your organization is one of those lucky enough to be required to go through the Designated Entities Supplemental Validation (DESV), you will need to provide a lot of evidence that following BAU will generate.

The biggest value that BAU brings to the table is you are always monitoring your PCI compliance and creating evidence for your next PCI assessment. But even better, when you run into compliance gaps, you know about them before your QSA comes onsite for your annual assessment. There is nothing worse than going through your annual assessment and the QSA finding a particular control has not been operating for a period of time, which you didn’t know about. With BAU, those surprises are not likely to occur because you should know quickly when a requirement is no longer being met.

So, you and your organization believe you could benefit from BAU. The next question we get is, “How do we implement BAU?”

The first thing an organization needs to do is to define some terms that the PCI DSS does not define. Those two terms are ‘significant change’ and ‘periodic.’ Rather than waste your time here on this subject, I will refer you to a post on the PCI Guru Blog that provides such guidance on this subject.

The next step is to determine who is responsible for BAU. While on the surface this appears to be a compliance issue, ultimately it is a governance issue. So, ultimately, a C-Level executive should be responsible for BAU. That person can delegate responsibilities for the actual performance and collection of evidence responsibilities within the organization.

Once those decisions are made, you will need to get down to the actual implementation of BAU. In future posts, we will discuss requirements in the PCI DSS that you can embed into your organization’s operating processes and how you can accomplish that effort. Some of those requirements can be easily implemented while others will require some effort. But at the end of the day, that effort will not only improve your PCI compliance but will likely improve the overall security of your organization.