The Standard Nobody Reads Until an Audit
The Payment Card Industry Data Security Standard exists because, in the early 2000s, every major card brand had its own proprietary security programme and merchants were drowning in overlapping requirements. Visa, Mastercard, Amex, Discover, and JCB joined forces in 2004 to publish a single unified framework. The result was PCI DSS - today in its fourth major revision, v4.0, published in March 2022 with full enforcement of its so-called “future-dated” requirements kicking in on the 31st of March 2025.
If your organisation stores, processes, or transmits cardholder data, or if it operates infrastructure that could affect the security of that data, you are in scope. That scope is often far wider than compliance teams initially expect.
The Twelve Requirements at a Glance
PCI DSS organises its controls into six broad goals, each containing two requirements, for a total of twelve. The table below is a quick orientation - the sections that follow unpack the ones that cause the most pain in practice.
| Req. | Domain | Core Concern |
|---|---|---|
| 1 | Network Security | Install and maintain network security controls |
| 2 | Secure Configuration | Apply secure configurations to all system components |
| 3 | Account Data Protection | Protect stored account data |
| 4 | Cryptography in Transit | Protect cardholder data with strong cryptography over open networks |
| 5 | Malware Protection | Protect all systems against malware |
| 6 | Secure Development | Develop and maintain secure systems and software |
| 7 | Access Control | Restrict access to system components by business need-to-know |
| 8 | Authentication | Identify users and authenticate access to system components |
| 9 | Physical Security | Restrict physical access to cardholder data |
| 10 | Logging and Monitoring | Log and monitor all access to system components and cardholder data |
| 11 | Security Testing | Test security of systems and networks regularly |
| 12 | Policy and Governance | Support information security with organisational policies and programmes |
Requirement 3: The Encryption Problem Most Teams Get Wrong
Requirement 3 is where organisations consistently stumble. The goal is to ensure that Primary Account Numbers (PANs) - the sixteen-digit card number - are unreadable anywhere they are stored. PCI DSS mandates strong one-way hashing (SHA-256 or better), truncation, tokenisation, or strong encryption with proper key management.
The key management piece is where it breaks down. It is not sufficient to encrypt PANs with AES-256 if the encryption key lives in a flat file on the same server, is never rotated, or is accessible to the application process with database read access. PCI DSS v4.0 tightened the requirements here: cryptographic key custodians must formally acknowledge their responsibilities, key-encrypting keys must be at least as strong as the data-encrypting keys, and key storage must be separated from the data they protect.
A Hardware Security Module (HSM) is the practical answer for organisations above a certain scale. For smaller environments, a dedicated secrets manager with strict IAM policies and audit logging is the minimum acceptable baseline.
# Checking that PANs are not present in log files - a common gap
# Never log raw card data; this grep is a sanity check during assessments
grep -rE '[3-6][0-9]{3}[\s\-]?[0-9]{4}[\s\-]?[0-9]{4}[\s\-]?[0-9]{4}' /var/log/app/
Requirement 6: Secure Development and the Web Application Firewall Mandate
Requirement 6 addresses the software development lifecycle. Every bespoke or custom-developed application that is in scope for PCI must be built against a recognised set of secure coding guidelines - OWASP is the standard reference - and must undergo both internal code review and external penetration testing before deployment.
For public-facing web applications, PCI DSS gives organisations a choice: deploy a technical control that actively detects and prevents web-based attacks (a WAF), or perform a web application vulnerability assessment at least every twelve months and after significant changes. In practice, the WAF route is almost always preferred because the assessment cadence required for the alternative is operationally expensive.
The v4.0 revision strengthened Requirement 6.4.3 considerably. It now requires organisations to manage all scripts loaded on payment pages - including third-party scripts - by maintaining an inventory, ensuring each has a documented business justification, and implementing controls to ensure script integrity. This directly targets Magecart-style supply chain skimming attacks, which have compromised thousands of payment pages by injecting malicious JavaScript through compromised third-party analytics or chat widgets.
<!-- Subresource Integrity: a concrete control for third-party scripts on payment pages -->
<script
src="https://cdn.example.com/analytics.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous">
</script>
Requirement 11: Penetration Testing Is Not Vulnerability Scanning
This distinction matters enormously in an audit context. A vulnerability scan identifies known weaknesses by comparing system configurations and software versions against a database of CVEs. A penetration test involves a skilled person attempting to exploit those weaknesses - and others - to demonstrate actual, exploitable impact.
PCI DSS requires both. External vulnerability scans must be performed quarterly by an Approved Scanning Vendor (ASV). Internal scans must be run quarterly as well. Penetration tests must be conducted at least annually and after any significant infrastructure or application change.
Requirement 11.4.2 introduced a new control in v4.0: organisations must have a documented methodology for their penetration tests, covering both network-layer and application-layer testing. The methodology must be consistent with industry standards such as PTES, OWASP Testing Guide, or NIST SP 800-115. Assessors will ask to see the scoping document, the test plan, and the remediation evidence - not just the report.
The 2025 Future-Dated Controls
When v4.0 was published, the PCI Security Standards Council designated a set of requirements as “future-dated,” giving organisations until March 2025 to implement them. These are now fully enforced. The most operationally significant ones include multi-factor authentication for all access into the cardholder data environment (not just administrative access), the third-party script management controls under 6.4.3, and phishing-resistant MFA for all personnel with remote access.
Organisations that treated these as optional during the v4.0 transition period are now out of compliance. Qualified Security Assessors are expected to test these controls as part of any Report on Compliance issued after the deadline.
Where Organisations Actually Fail
Based on the findings published annually by Verizon in its PCI DSS Compliance Report, most failures cluster around the same areas year after year. Logging and monitoring (Requirement 10) is consistently the weakest domain: organisations install SIEM tooling but fail to define alert thresholds, review logs daily, or retain logs for the required twelve months with at least three months immediately available. Requirement 12 - policy and governance - also shows persistent gaps, particularly around formal risk assessment processes and third-party service provider management.
The practical lesson is that technical controls alone do not produce compliance. PCI DSS is as much a governance and process standard as it is a technical one. An organisation can have excellent encryption and a well-tuned WAF, and still fail an assessment because it cannot produce evidence of quarterly log reviews or signed acknowledgements from its service providers.
A Note on Scope Reduction
The single most effective strategy in a PCI DSS programme is reducing scope. Every system, process, and person that touches cardholder data is in scope. Tokenisation is the primary technical mechanism for reducing scope in modern architectures: replace the PAN everywhere it is used in business processes with a non-sensitive token, and only the tokenisation vault and the systems that interact with it remain in scope.
For e-commerce environments, redirecting payment collection to a fully hosted payment page operated by a compliant service provider eliminates most of the application-layer scope entirely. The trade-off is reduced control over the payment user experience - a business decision as much as a technical one.
Takeaways
PCI DSS v4.0 is more prescriptive than its predecessors in several key areas, particularly around cryptographic key management, third-party script integrity, and the evidence requirements for penetration testing. Organisations that approach it as a checkbox exercise tend to repeat the same findings every assessment cycle. Those that integrate its requirements into their engineering and governance processes find that the compliance overhead diminishes significantly over time, because the controls become part of normal operations rather than an annual scramble before the QSA arrives.