Many PCI DSS requirements by themselves already have a defined frequency, and the maintenance of their compliance is not usually a major challenge, such as quarterly vulnerability scans (requirement 11.2), annual penetration tests (requirement 11.3) or bi-annual firewall rule revisions (requirement 1.1.7). Other PCI DSS requirements, however, do not have such detailed periodic reviews but are directly related to specific events. These requirements end up acting as triggers based on various requirements and generate a cascading effect. These trigger requirements are often overlooked or even forgotten about when maintaining compliance.

We can cite as an example, an operating system upgrade which could impact as many as 20 requirements when, if not properly implemented or adhered to, could result in non-compliance.

Not familiar with PCI DSS 3.2? Check out our blog on all the latest changes. 

But then how does one maintain compliance with PCI DSS while managing day-to-day operations? The answer may be ensuring compliance to one of the more complex and comprehensive PCI DSS requirements, Req. 12.

Requirement 12.2, in summary, requires that a company maintain a documented risk assessment process and that the risk assessment should be completed at least annually. A well-conducted risk assessment should identify all critical assets as well as the threats and vulnerabilities which could negatively impact the operation of the assets. As PCI DSS and the control requirements held within the standard are mandatory, CIPHER recommends the use of PCI DSS controls to mitigate risk. When assessing risk, with an industry standard such as ISO27001/27005, the correlation between the ISO27001 Annex A control requirements and those held to the PCI DSS standard quickly become apparent.

In the end, the company should maintain an up to date risk registery which identifies the vulnerabilities and impact to the organisation and its compliance objectives. By identifying the trigger events which could impact the PCI DSS compliance checklist and presenting these as the example matrix included below, provides a holistic view of compliance objectives which need to be met for each of the organisational triggers:

PCI DSS Impacts and Requirements Matrix

The next tip: look at the company’s established processes and take full advantage of its existing tools. Technology teams increasingly rely on automated systems and processes to help manage processes, such as change and configuration management as well as incident response. CIPHER recommends that organisations use these tools to explore opportunities for automating document updates, data flow diagrams ensuring that tools are used to their maximum capability.

With these recommendations, maintaining a PCI DSS compliance checklist may become less painful, while maturing day-to-day operations in preparation for a formal PCI DSS assessment.

Eduardo Justo de Oliveira is PCI QSA of CIPHER’s GRC team.

Clive Boonzaaier is the Technical Director for CIPHER UK.