Organisations that process, transmit and/or store cardholder data or SAD (sensitive authentication data), or can affect their security, must comply with the PCI DSS (Payment Card Industry Data Security Standard).
This is an international information security standard designed to:
Enhance account data (cardholder data and SAD) security; and
Facilitate the adoption of consistent data security measures globally.
Currently, the Standard is at v4.0.1. You can learn more about the changes introduced by PCI DSS version 4 here.
Merchants and service providers must also annually validate their PCI DSS compliance, via either:
SAQ (self-assessment questionnaire) submission; or
An audit conducted by a qualified third party – a QSA (Qualified Security Assessor).
To determine which you must do, contact:
Your acquiring financial institutions (for merchants); or
The individual payment brands (for service providers).
The more transactions you process, the more likely you need to be audited by a qualified external auditor – a QSA.
If you’ve recently experienced a breach and were subject to a PCI forensic investigation, you’re also more likely to need to bring in a QSA.
How to prepare for PCI audit success
Select and engage with your QSA
1. Obtain top management support
Contrary to common belief, PCI DSS compliance isn’t just a matter for the IT department.
Many different teams are likely to have at least some PCI DSS-related responsibilities, including finance, sales and marketing. Besides, having documented procedures and processes is of little use if not everyone follows them.
So, make sure you obtain visible support from top management. This will help enforce processes and secure adequate resources.
2. Select and engage with your QSA
All qualified auditors (QSAs) must meet the same set of requirements to be (re)certified by the PCI SSC (Payment Card Industry Security Standards Council).
But QSAs vary in how they determine the PCI DSS requirements and evaluate the appropriateness of security measures. (Not to mention differences in experience, aptitude and thoroughness.)
The right QSA can help identify and address security risks, while meeting your organisation’s specific needs and budget. Remember: your QSA isn’t just there to audit you, but also to offer insight and support on achieving and maintaining compliance.
However, they can only do that if you regularly engage with your QSA – not just when the annual audit comes round.
Furthermore, to get the most out of your partnership, your QSA needs an in-depth understanding of the specific challenges your organisation is likely to face.
We therefore strongly recommend you choose a QSA with experience in both your sector and, more importantly, your technology landscape.
3. Document your scope
Your scope document provides the foundation of your PCI DSS compliance project.
In fact, PCI DSS v4.0.1 explicitly requires – in sub-requirement 12.5.2 – organisations to document and confirm their PCI DSS scope at least every 12 months and after significant changes to the in-scope environment.
Your scope document should include:
Network diagrams;
Data flow diagrams, covering all payment stages;
An inventory of the system components in scope;
An inventory of the people, processes and technologies in scope; and
All locations where you store, process or transmit account data, including:Locations outside the currently defined CDE (cardholder data environment);Transmissions between systems and networks;Applications that process cardholder data; and
File backups.
The resulting document should accurately identify your scope borders, which you must be able to justify, and describe the controls that form those boundaries (i.e. segmentation controls).
The document should also cover all in-scope people, processes, technologies and system components.
Finally, the scope should also include components that affect the security of the in-scope environment, even if not directly in scope themselves – the server that hosts your directory service, for example.
Keep your scope document on hand when talking to QSA candidates. It’ll help both parties determine whether they’re a good match, like whether the QSA has experience with the technologies you rely on.
Further reading: This blog explains how you can reduce your PCI DSS scope to reduce your compliance burden.
4. Conduct a gap analysis
Before you can implement missing technological controls and documentation, first establish to what extent you’re meeting the PCI DSS requirements. An effective way to do this is by conducting a gap analysis.
A gap analysis compares your current measures against the PCI requirements and identifies any shortcomings. This exercise is particularly beneficial for organisations new to the PCI DSS.
Where you identify gaps, document:
Necessary remediation actions;
Responsibilities for them; and
Due dates to complete them.
Where a requirement isn’t applicable, document the justifications. And if you’re relying on a compensating control, document its details.
In both scenarios, the QSA must validate your justifications/controls, and document them in the RoC (Report on Compliance). So, if you have those details on hand, you’ll have a far smoother audit.
You may also want to take advantage of the ‘customised approach’ option that version 4 introduced. However, it requires you follow a strict process, so we recommend consulting your QSA about this – any disputes could prolong the audit or even lead to audit failure.
Finding this blog useful? To get notified of future
blogs and other free resources, subscribe to our free
weekly newsletter: the Security Spotlight.
5. Remediate any gaps
Once you’ve identified your compliance gaps, address them!
Implement any missing documentation and technological controls your gap analysis found, or you’re putting the security of cardholder data at risk.
As you do this, bear in mind that rapidly putting together written documentation on how you truly do things is merely difficult, whereas a missing technology control is likely deemed a control failure, which can in turn lead to audit failure.
This is because compliance with the PCI DSS’s technology requirements is binary – you either have or haven’t met them.
For example:
If a technology control must generate a log you must keep for at least a year, and you’re not undergoing your first audit, not having those logs can be deemed a control failure.
If an entity hasn’t conducted 4 quarterly vulnerability scans (that passed) in the past 12 months because it didn’t schedule the scans properly, the scans are incomplete, or the identified vulnerabilities haven’t been addressed from one quarter to the next, then the organisation hasn’t met the requirement (sub-requirement 11.3).
Should you find yourself in such a situation, you’ll likely need to discuss the remediation options with your QSA and implement (additional) compensating controls – a clearly far less attractive option than making sure you’re prepared for the audit so you can sail through the process.
6. Review periodic activities
Once all documentation and technical measures are in place, you need to review – and, if necessary, implement – all periodic activities. These activities should also become part of business as usual, so you’ll maintain PCI compliance.
Let’s go through a few examples.
Daily log reviews
To quickly find out about a possible security breach, you need to continually monitor and record everything that happens to your systems and networks by generating access and traffic logs.
Review these logs daily to identify anomalies that could signify a breach. Where identified, follow up on them.
Risk assessments
Risk assessments are vital to any security project, whether related to the PCI DSS or not.
The Standard requires a number of specific risk assessments, mostly to identify how frequently to carry out a given action – performing anti-tamper checks on card reader devices, for example.
Organisations rarely include these assessments within their general corporate risk assessment, so likely need to issue specific actions to complete them.
Quarterly internal and external vulnerability scans
Conducting regular vulnerability scans helps identify vulnerabilities and misconfigurations of public-facing websites, applications and infrastructures. You can then fix them before a threat actor can exploit them.
The PCI DSS requires you to run at least quarterly scans:
Internal scans, conducted by qualified staff; and
External scans, conducted by an ASV (Approved Scanning Vendor).
Annual internal and external penetration testing
Conducting regular penetration tests helps you identify and fix vulnerabilities in your systems, networks and controls before an attacker can exploit them.
Unlike a vulnerability scan, which only identifies known vulnerabilities, a penetration tester might use any information gleaned over the course of testing to penetrate an environment.
This can include information that appears harmless to an automated scan. The tester could also combine multiple low-level vulnerabilities to mimic a more damaging attack.
In either scenario, penetration testers will usually attempt to exploit the identified vulnerabilities as a proof of concept, but without causing damage to your networks or systems.
The PCI DSS requires all types of testing – internal, external and testing of segmentation controls – to be conducted by an independent and qualified tester.
7. Conduct a mock audit
As a final preparation for the formal audit, conduct a mock audit.
Whether you do this internally or bring in an external party, it’ll both:
Help staff know what to expect (particularly if this is their first audit); and
Provide one last opportunity to identify and remediate nonconformities.
Remember: even if those nonconformities might not lead to audit failure, because you can fix them within the remediation period, they will slow down the audit, making it a much more arduous process for everyone.
Prevent such experiences by ensuring you’re prepared and maintaining PCI DSS compliance as part of business-as-usual activities.
What to learn more about how PCI DSS audits work?
Our free green paper, PCI DSS Audits – Preparing for success, explains the audit process in detail.
It also discusses the most common audit challenge, and how to overcome it.
We first published a version of this blog in January 2018.
The post 7 Steps to Prepare for PCI DSS Audit Success appeared first on IT Governance UK Blog.
