The 12 PCI DSS requirements: a practical SaaS walkthrough

PCI DSS v4.0.1 contains 12 requirements grouped into 6 goals, covering network security, account data protection, vulnerability management, access control, monitoring and organisational policy — and auditors test at numbered sub-requirement level, so each sub-requirement is a distinct evidence unit. This walkthrough covers all 12 with the sub-requirements SaaS teams most often fail, the real deadlines (several widely repeated ones are wrong), and the evidence an assessor will ask for. If enterprise customers raise PCI DSS in security questionnaires alongside your ISO 27001 and UK GDPR posture, start here.

How many requirements does PCI DSS contain?

PCI DSS contains 12 requirements, grouped into 6 goals. Each requirement breaks into numbered sub-requirements — 8.3.6 is a sub-requirement of Requirement 8, not a separate requirement — and each sub-requirement carries its own testing procedures, which is where most evidence requests land. Treat every sub-requirement as a distinct audit unit rather than a bullet point under its parent.

The six goals: build and maintain a secure network and systems (Requirements 1 and 2), protect account data (3 and 4), maintain a vulnerability management programme (5 and 6), implement strong access control (7 to 9), regularly monitor and test networks (10 and 11), and maintain an information security policy (12). If you already run ISO 27001, several goals land on controls your ISMS holds — which is the premise behind cross-framework platforms like ours.

What are the 12 PCI DSS requirements at a glance?

In one pass, grouped by goal as the standard groups them:

1. Build and maintain a secure network and systems — Requirement 1 installs and maintains network security controls (the v4 generalisation of firewalls) and Requirement 2 applies secure configurations to all system components
2. Protect account data — Requirement 3 protects stored account data with encryption, truncation and masking, and Requirement 4 protects cardholder data with strong cryptography during transmission
3. Maintain a vulnerability management programme — Requirement 5 protects all systems and networks from malicious software, and Requirement 6 develops and maintains secure systems and software
4. Implement strong access control — Requirement 7 restricts access by business need to know, Requirement 8 identifies users and authenticates access, and Requirement 9 restricts physical access to cardholder data
5. Regularly monitor and test networks — Requirement 10 logs and monitors all access, and Requirement 11 tests security regularly (vulnerability scans and penetration tests live here)
6. Maintain an information security policy — Requirement 12 supports information security with organisational policies and programmes

For a SaaS team the cross-framework overlap is real: Requirements 7, 8, 10 and 11 land heavily on ISO 27001 Annex A controls, so one evidence base can serve both audits. The per-requirement readiness view is what our platform tracks as you collect.

What changed in the PCI DSS v4 password requirements?

Requirement 8.3.6 raised the minimum password length from 7 to 12 characters (8 only where a system cannot support 12), containing both letters and numbers — mandatory since 31 March 2025. The 90-day forced rotation did not disappear, though, and this is the detail most summaries get wrong: under 8.3.9, where passwords are the only authentication factor for an account, you must still either rotate every 90 days or dynamically analyse the account’s security posture. Deploy MFA and the calendar rotation requirement falls away.

If your ISMS still documents 90-day rotation everywhere for ISO 27001 alignment, reconcile the two deliberately rather than by accident. NIST SP 800-63B — the guidance this shift leans on — treats frequent forced resets as a driver of weaker passwords. Write that rationale into your access-control policy once, cross-map it to both frameworks, and both audits read the same evidence.

MFA scope under 8.4

8.4.1 requires MFA for all non-console administrative access; 8.4.2 extends it to all access into the cardholder data environment; 8.4.3 covers remote access originating from outside the network, which pulls in third parties and support staff. 8.5 governs how the MFA system itself must be configured — not bypassable, at least two factor types, no replay.

Evidence an assessor expects for Requirement 8

Hold your password policy text, a configuration export showing the 12-character minimum actually enforced, MFA enrolment reports per user, and a documented exception process for service accounts. A policy PDF without the matching configuration export is the classic Requirement 8 failure.

How long do you have to patch a vulnerability under PCI DSS?

One month, for the serious ones: Requirement 6.3.3 requires patches that remediate critical or high-severity vulnerabilities to be installed within one month of the patch’s release. Lower-ranked patches get a timeframe you define and document in your risk analysis — three months is a common choice. Note the clock runs from patch release, not from when you noticed it, so a backlog of unreviewed scanner findings is already burning your window.

You may see a "15 days from detection" rule quoted for PCI DSS. No such deadline exists in the standard — we checked the v4.0.1 text before publishing this, because the claim appears in several AI-generated summaries. The real pairing is 6.3.1, which requires you to identify vulnerabilities from industry sources and risk-rank them with a documented method, and 6.3.3’s one-month window for the critical and high tier.

Internal scans close the loop (11.3.1)

Requirement 11.3.1 requires internal vulnerability scans at least once every three months, with high-risk and critical findings resolved and verified by rescan. This is where a patch-cycle gap gets caught: if you patch monthly, a critical finding early in the cycle can still be in window — but you need the dated detection, the dated fix and the passing rescan to prove it.

Evidence an assessor expects for Requirement 6

Expect to show the risk-ranking methodology, per-finding timestamps from detection to resolution, and the linkage between your patch records and the 11.3.1 rescan results. This is where a shared evidence base pays off: the same patch and scan evidence feeds ISO 27001 Annex A 8.8 and PCI DSS at once, with drift alerts when a control stops producing it.

What are the ASV scan requirements, and how often must you scan?

Requirement 11.3.2 requires external vulnerability scans by an Approved Scanning Vendor at least once every three months — four passing scans a year — plus an out-of-cycle scan after any significant change. An ASV is a company validated by the PCI Security Standards Council to run these scans; you cannot self-scan or substitute a generic pentest provider, and the approved list is published by the PCI SSC.

A scan passes only when nothing scoring CVSS 4.0 or higher remains unresolved or undocumented as a false positive. Plan remediation time between scan and rescan inside each quarter, because a quarter without a passing scan is a gap you cannot backfill later — an assessor matches scan dates to the calendar, and so will an enterprise customer reading your attestation.

Evidence an assessor expects for external scans

Keep all four passing ASV reports per year plus the remediation evidence and rescans that got you there. Assessors also check that the scanned ranges cover everything currently exposed, so an alert on newly public IP addresses matters as much as the reports themselves.

What are the penetration testing requirements in v4.0.1?

Internal and external penetration tests each run at least once every 12 months and after any significant change — internal testing under 11.4.2, external under 11.4.3, following a documented methodology defined in 11.4.1. What counts as a significant change is yours to define and document (new system components, topology changes, authentication-flow changes), so a major release can trigger a test between annual cycles. Exploitable vulnerabilities the test finds must be corrected and the correction verified under 11.4.4.

Segmentation testing — stricter for service providers

If you rely on segmentation to shrink your CDE scope, 11.4.5 requires you to test that the segmentation actually isolates the CDE at least every 12 months and after changes. Here is the catch for SaaS teams: if you store, process or transmit cardholder data on behalf of customers, you are a service provider, and 11.4.6 tightens segmentation testing to at least every six months. Claiming segmentation in a scoping questionnaire with no test result invites the assessor to put everything back in scope.

Evidence an assessor expects for Requirement 11 pentests

The pentest report with scope, methodology, dates and tester details; remediation records showing findings tracked to closure; your documented significant-change criteria; and the segmentation test result if you use one for scoping. The tester must be organisationally independent of the team that manages the systems — for most small SaaS teams that means an external provider, though it does not have to be a QSA.

Does PCI DSS have a disaster recovery requirement?

No — there is no standalone disaster recovery requirement in PCI DSS. The continuity expectations are distributed: Requirement 10.7.2 requires failures of critical security control systems — network security controls, IDS and IPS, audit logging, segmentation controls among them — to be detected, alerted and addressed promptly, and Requirement 12.10 requires an incident response plan that is reviewed and tested at least annually. Multi-tenant service providers pick up additional isolation and support obligations in Appendix A1.

In practice an assessor probing continuity wants three things: a documented incident response plan that covers availability scenarios, evidence that alerts actually fire when backup or logging systems fail, and records of plan testing.

Mapping the continuity expectations to ISO 27001

If you run ISO 27001:2022 alongside PCI DSS, one control set covers both: Annex A 5.29 (information security during disruption) and 5.30 (ICT readiness for business continuity) carry the planning and testing evidence, while A 8.14 (redundancy) supports the availability story. Collect backup-failure alerts, continuity test records and incident-plan reviews once and cross-map them. The honest gap in automating this: cloud infrastructure evidence collects well through connectors, but physical records like a data-centre failover exercise still need manual upload.

How do PCI DSS levels change what you must evidence?

Your level determines the validation instrument, not the 12 requirements themselves. The highest tier — around 6 million annual transactions for merchants, 300,000 for service providers, with exact thresholds set per card brand — needs a Report on Compliance from a Qualified Security Assessor; lower levels can usually self-assess with a Self-Assessment Questionnaire. Either way the controls are the same standard.

If you handle cardholder data on behalf of customers you are a service provider, which is the usual shape for a SaaS scale-up — and most land on SAQ D for Service Providers, which covers all 12 requirements. So your evidence base is the same as a top-tier provider’s; only the attestation route differs. Enterprise customers will typically ask for your Attestation of Compliance, not a certificate — PCI DSS does not issue certificates at all.

How do you run PCI DSS alongside ISO 27001 and GDPR?

Most of the 12 requirements map onto ISO 27001:2022 Annex A: access control (Requirements 7 and 8 against A 5.15 to 5.18 and 8.2 to 8.5), vulnerability management (6 and 11 against A 8.8), logging and monitoring (10 against A 8.15 and 8.16). UK GDPR Article 32 picks up encryption, resilience and regular testing, so Requirements 3, 4 and 11 do double duty. What does not overlap: ASV scan cadence, cardholder data scoping and the segmentation testing clock have no Annex A equivalent, so expect roughly two-thirds shared evidence with the PCI-specific items handled separately.

Where automation genuinely helps: MFA status, endpoint posture, cloud configuration and logging evidence collect continuously and feed every framework they map to. Where it falls short: penetration test reports, assessor interviews and scoping decisions need a human owner, and no dashboard substitutes for them. Raize Orion runs ISO 27001, PCI DSS and GDPR from one cross-mapped evidence base — and the honest limit is the same one we state everywhere: the tool surfaces drift and gaps, but your assessor judges the controls, not the dashboard.

FAQ

Do all 12 requirements apply if I never touch cardholder data?

If your systems never store, process or transmit account data and cannot affect its security, PCI DSS likely does not apply to you at all. If cardholder data flows through your environment even indirectly, scoping and segmentation decisions determine which requirements land on you — and claiming reduced scope without documented justification and segmentation testing invites an assessor to put everything back in scope.

How long do I have to fix a critical vulnerability?

Install the patch within one month of its release for critical and high-severity vulnerabilities (6.3.3), and within your own documented timeframe for the rest. Internal scans every three months (11.3.1) must then show the finding resolved by rescan. The often-quoted "15 days from detection" deadline is not in the standard.

Can I run my own penetration test?

Only if the tester is organisationally independent of the team that manages the target systems, which for most small SaaS teams means an external provider in practice. ASV scans are a separate matter and always require a PCI SSC-approved vendor. Whichever route you take, the report must show scope, methodology, dates and tester details, with findings tracked to closure.

Is PCI DSS a legal requirement in the UK?

No — PCI DSS is contractual, enforced through the card brands and your acquirer, not UK legislation. The consequences of non-compliance are commercial: fines passed down by your acquirer, higher processing fees, or losing card acceptance. UK GDPR is the legal layer, and Article 32 overlaps with the encryption and testing requirements — which is why one evidence base can serve both.