PCI DSS – the Payment Card Industry Data Security Standard – is the security baseline every organisation that stores, processes, or transmits cardholder data must meet. It isn't legislation; it's contract law with global reach, flowing from the card brands through acquiring banks to every merchant and service provider that touches a card number. That makes it unusually non-negotiable: non-compliance means fines passed down by your acquirer, and after a breach, the difference between "compliant at the time" and not is measured in forensic investigations, liability shifts, and sometimes the ability to accept cards at all. The only active version is v4.0.1, and since 31 March 2025 the full v4 requirement set – including the ones everyone deferred – is mandatory in every assessment.
Scope is the whole gameLink to this section
PCI DSS applies to your cardholder data environment (CDE) – the systems that touch account data plus everything connected to them or able to affect their security. Left unmanaged, that definition swallows your whole network, and with it your assessment cost. The professional move is to make scope small: segment ruthlessly, tokenise so card numbers never enter your systems, and push storage and processing to validated providers via redirect or hosted-field integrations. Scope reduction is the highest-ROI security work in the payments world – we routinely take assessments from "the entire company" down to a walled garden – and v4 sharpened the expectation by requiring documented scope confirmation every twelve months.
How validation worksLink to this section
What you must prove depends on your transaction volume and integration model:
- Self-Assessment Questionnaire (SAQ). Most merchants validate via an SAQ, and choosing the right one matters enormously: SAQ A (fully outsourced, ~30 requirements) and SAQ D (everything, 200+) are different projects entirely. Your integration architecture decides which you're entitled to claim.
- Report on Compliance (ROC). Level 1 merchants (over six million transactions a year) and most service providers need a full onsite assessment by a Qualified Security Assessor (QSA), producing a ROC and Attestation of Compliance.
- Quarterly ASV scans of external-facing systems and annual penetration testing apply across most validation paths.
If you're a SaaS or service provider in the payment flow, expect customers to ask for your AOC during procurement – it functions like a SOC 2 report for the payments world.
What v4 changed in spiritLink to this section
Beyond new controls (MFA everywhere into the CDE, payment-page script integrity, tougher password rules), v4 made two philosophical shifts. First, compliance is meant to be continuous – assigned owners, scheduled activities, and evidence accumulating year-round, replacing the annual scramble. Second, the customised approach lets mature organisations meet a requirement's objective with a different control design, provided they can document and defend it – flexibility that's earned with governance, not claimed for free. Both shifts reward exactly one thing: an operating security programme with records to show for it.
The people requirement nobody budgets forLink to this section
Requirement 12.6 mandates a formal security awareness programme – for everyone with CDE access, at hire and at least annually, with acknowledgement records, and content covering phishing and social engineering (the vector behind most card-data breaches). QSAs sample this evidence every assessment. It's a line item most organisations solve badly with a generic video and a spreadsheet; it's also precisely what our platform was built for – engaging, practitioner-built courses, automatic assignment, and tamper-evident completion records exported on demand.
How PCI DSS relates to other frameworksLink to this section
PCI DSS is deep but narrow – world-class prescription for one data type. Its controls slot neatly inside a broader ISO 27001 ISMS or NIST CSF programme, and its hardening, MFA, patching, and logging demands overlap heavily with the Essential Eight – so uplift done well pays into all of them at once.
How we helpLink to this section
We've secured cardholder environments from single-SAQ startups to multi-entity ROC assessments, and our approach is consistent – shrink first, then comply:
- Scoping and reduction. CDE mapping, segmentation design, and tokenisation/outsourcing strategy that cuts both risk and assessment burden – often down an entire SAQ tier.
- Gap assessment against v4.0.1. A requirement-by-requirement readiness review with a prioritised remediation plan in engineering language, not auditor-speak.
- Control implementation. Hardening, MFA, logging pipelines, vulnerability management, and the documentation set – built alongside your team.
- The 12.6 programme, solved. Security awareness training with phishing and social-engineering content, delivered and tracked on our platform with verifiable, tamper-evident records.
- Assessment support. SAQ selection and completion, ASV scan management, QSA liaison, and evidence packs that make fieldwork short.
The table below walks through all twelve requirements and how we help with each.
The twelve PCI DSS requirements
Build and maintain a secure network and systems
| Req | Requirement | How we help |
|---|---|---|
| Req 1 | Install and maintain network security controls | We design and document the segmentation that walls off your cardholder data environment – the single decision that most reduces both risk and assessment cost – with rulesets reviewed and evidenced on schedule. |
| Req 2 | Apply secure configurations to all system components | We build hardened configuration baselines for every in-scope component, kill vendor defaults, and enforce the standard through automation rather than memos. |
Protect account data
| Req | Requirement | How we help |
|---|---|---|
| Req 3 | Protect stored account data | Our first question is always "why are you storing this at all?" – we minimise retention, then encrypt, tokenise, and key-manage what genuinely must remain, with SAD never stored post-authorisation. |
| Req 4 | Protect cardholder data with strong cryptography during transmission | We inventory every transmission path for account data – including the forgotten ones like email, chat, and call recordings – and enforce strong cryptography across them. |
Maintain a vulnerability management programme
| Req | Requirement | How we help |
|---|---|---|
| Req 5 | Protect all systems and networks from malicious software | We deploy and tune anti-malware and phishing defences across in-scope systems, paired with the user awareness that stops what filters miss. |
| Req 6 | Develop and maintain secure systems and software | We stand up patching with PCI's clock in mind (critical patches within a month), secure development training for engineers, and the payment-page change and integrity controls v4 added for e-commerce. |
Implement strong access control measures
| Req | Requirement | How we help |
|---|---|---|
| Req 7 | Restrict access by business need to know | We implement least-privilege, role-based access to cardholder data with documented approval and periodic access reviews that generate their own evidence. |
| Req 8 | Identify users and authenticate access | We enforce unique IDs, strong authentication, and the MFA v4 requires for all access into the CDE – wired into your identity provider, not bolted on. |
| Req 9 | Restrict physical access to cardholder data | We cover the physical dimension – facility controls, media handling and destruction, and the point-of-interaction device inspections skimmers depend on you skipping. |
Regularly monitor and test networks
| Req | Requirement | How we help |
|---|---|---|
| Req 10 | Log and monitor all access to system components and cardholder data | We centralise and protect audit logs, set the daily review process (automated, not aspirational), and configure alerting so anomalies surface while they're still small. |
| Req 11 | Test security of systems and networks regularly | We coordinate quarterly ASV scans, internal scanning, and annual penetration testing – including the segmentation testing that proves your scope boundary actually holds. |
Maintain an information security policy
| Req | Requirement | How we help |
|---|---|---|
| Req 12 | Support information security with organisational policies and programmes | This is where we live – the policy set, risk assessments, vendor management, incident response plan, and the mandated security awareness programme (12.6), delivered on our platform with tamper-evident completion records your QSA can sample in seconds. |