Toolkit · Compliance · about 5 minutes
PCI DSS Readiness Check
Scope determines both cost and effort, and it is what organisations get wrong most expensively. This starts there, then covers the version 4.0 additions people miss, including multi-factor authentication for all access into the cardholder environment and payment page script management.
24 questions. Nothing is sent anywhere as you answer, the scoring runs in your browser, and we only receive anything if you ask for the written version at the end.
Scope and validation route
What is in scope decides everything else, including the price.
Have you confirmed you do not store sensitive authentication data after authorisation?
The card verification value, full magnetic stripe or chip data, and PIN data must never be stored after authorisation. This fails validation on its own.
Is there a documented cardholder data flow showing everywhere card data is received, processed, transmitted and stored?
Do you know your merchant or service provider level, and therefore whether you need a self-assessment questionnaire or a full report on compliance?
Have you confirmed which self-assessment questionnaire applies, based on how you actually accept payments?
The simplest questionnaire requires fully outsourced payment pages. A single embedded field or redirect detail can move you to a much larger one.
Where segmentation is used to reduce scope, has its effectiveness been validated by testing rather than assumed from a diagram?
Access control
Who can reach card data, and how that is proved.
Is multi-factor authentication in place for all access into the cardholder data environment?
Version 4.0 extended this from remote access only to all access, including from inside the network.
Have vendor-supplied defaults been changed everywhere, including passwords, SNMP community strings and wireless keys?
Is access granted on a least-privilege basis and reviewed at least every six months?
Does every user have a unique identifier, with no shared or generic accounts?
Is physical access to systems holding card data restricted and logged?
Protecting stored and transmitted data
Encryption, key management and what happens on the wire.
Is stored card data rendered unreadable, by truncation, tokenisation or strong cryptography?
Are cryptographic keys managed with documented procedures covering generation, storage, rotation and retirement?
Is card data encrypted in transit across open or public networks using current protocols?
Is there a documented retention policy, with card data actually deleted when no longer needed?
Maintaining secure systems
Patching, testing and the version 4.0 additions people miss.
Are critical patches applied within one month of release?
Are internal and external vulnerability scans run quarterly, with external scans by an approved scanning vendor?
Is penetration testing performed at least annually and after significant change, covering segmentation controls?
Do you manage and inventory the scripts running on payment pages, and detect unauthorised changes to them?
A version 4.0 requirement aimed at digital skimming, and one of the most commonly missed.
Are anti-malware controls deployed and kept current on systems commonly affected?
Monitoring and programme
Logging, response, and the governance around it.
Are logs of access to card data and system components collected, protected from alteration and retained for a year?
Are logs reviewed, with a defined process for acting on anomalies rather than collecting them only?
Is there an incident response plan covering a suspected card data compromise, and has it been tested?
Have you completed targeted risk analyses where version 4.0 requires them to justify frequencies?
Are third-party service providers that could affect card data security tracked, with their compliance status monitored?