Skip to content

Framework

PCI DSS, the payment card security standard

Reviewed 6 October 2026

PCI DSS

PCI DSS is the Payment Card Industry Data Security Standard, maintained by the PCI Security Standards Council. It applies to every organisation that stores, processes or transmits cardholder data. Version 4.x is the only active version, and its 51 future-dated requirements became mandatory in every assessment from 31 March 2025.

Definition

What is PCI DSS?

PCI DSS is a contractual obligation rather than a law. It reaches organisations through their acquiring bank and card scheme agreements, which is why enforcement looks like fines passed down by an acquirer or the loss of card processing, rather than regulatory action.

Version 4.x introduced a customised approach alongside the traditional defined approach. The defined approach follows the stated requirement literally. The customised approach lets an organisation meet the stated objective by a different means, with its own targeted risk analysis and a heavier evidential burden. It is genuinely useful for mature organisations and adds work for everyone else.

The single most important decision in any PCI programme is scope. Every system that stores, processes or transmits cardholder data is in scope, and so is every system connected to those. Scope reduction - tokenisation, redirect or iframe payment pages, network segmentation - does more to reduce cost and risk than any other action available.

Who PCI DSS applies to

  • Any organisation storing, processing or transmitting cardholder data, at any transaction volume.
  • E-commerce businesses, where the March 2025 requirements on payment page script management changed obligations materially.
  • Service providers handling card data on behalf of merchants, who face a stricter assessment regime.
  • Organisations taking card payments by phone, where call recording is a recurring and frequently unnoticed scope problem.
  • SaaS platforms that touch payment flows even without storing card numbers.

The path

How long does PCI DSS actually take?

Realistic elapsed durations for an organisation starting without a dedicated compliance function. Elapsed time, not effort - the two are routinely confused when this gets scoped.

  1. 013-6 weeks

    Scope definition and reduction

    Map every card data flow, including the ones nobody documented - phone payments, email attachments, paper. Then reduce scope before assessing it. Moving to a hosted payment page or tokenisation can shift a merchant from SAQ D to SAQ A and remove most of the programme.

  2. 021-2 weeks

    Determine the validation route

    Merchant level and payment channel determine whether validation is by self-assessment questionnaire or by a Qualified Security Assessor producing a Report on Compliance. Choosing the wrong SAQ is common and invalidates the result, so this is worth confirming with the acquirer in writing.

  3. 032-5 months

    Remediate against v4.x

    Close the gaps, including the 51 requirements that became mandatory in March 2025. For e-commerce, requirements 6.4.3 and 11.6.1 on payment page script inventory and change detection are the ones most often still outstanding.

  4. 044-8 weeks, then continuous

    Validate and maintain

    Complete the SAQ and attestation, or the QSA assessment, alongside quarterly ASV scans and any required penetration testing. Validation is annual, but the controls are continuous, and quarterly scans are where lapses become visible.

Cost and internal effort figures are being confirmed with the practice before publication: cost and effort figures · Q15

Failure points

Where PCI DSS programmes usually go wrong

Not the theory. The specific things that cause a delayed audit, a major non-conformity, or a certificate that does not survive its first surveillance visit.

Scope larger than anyone realised

Call recordings capturing card numbers read aloud, cards emailed by customers, a legacy database with historical transactions, a support tool that logs full request bodies. Each pulls systems into scope. Scope is discovered by following the data, not by asking which systems are the payment systems.

The wrong SAQ

SAQ A applies only where card functions are fully outsourced to a validated third party. An iframe or a redirect may qualify; a page collecting card details in your own form and posting them onward does not, even if you never store them. Completing SAQ A when SAQ A-EP applies means the attestation is invalid.

E-commerce script requirements ignored

Requirements 6.4.3 and 11.6.1 require an inventory of every script on the payment page, justification and authorisation for each, and a mechanism to detect unauthorised change to the page. These became mandatory in March 2025 and remain the most commonly outstanding v4.x items.

Quarterly scans not actually quarterly

Four passing ASV scans across the year, at roughly quarterly intervals, are required. Organisations run one before their assessment and skip the rest. A failed scan must be remediated and rescanned until it passes, which takes time nobody has allocated.

Segmentation asserted rather than tested

Network segmentation reduces scope only if it works. Where it is relied on, its effectiveness must be tested at least annually, and every six months for service providers. Asserting segmentation without testing means the whole environment is in scope.

Treating validation as the objective

PCI DSS requires controls to operate continuously, not to be true on assessment day. Breaches at compliant organisations are overwhelmingly organisations that were compliant at their last assessment and had drifted since. The attestation is a snapshot; the obligation is not.

Dates that apply

The deadlines attached to PCI DSS

  • In force · 18 months agoThe 51 future-dated requirements are mandatory in every assessment

Verified 6 October 2026Full regulatory horizon ->

How we run it

PCI DSS, delivered in sprints

  • 01Card data flows mapped by following the data, including phone, email and paper channels that never appear on a network diagram.
  • 02Scope reduction pursued first, because moving down an SAQ level removes more cost and risk than any control you could implement.
  • 03The correct SAQ confirmed against the actual payment integration, and agreed with the acquirer before work starts.
  • 04The v4.x future-dated requirements addressed explicitly, particularly the e-commerce script controls that are widely still open.
  • 05Quarterly ASV scanning and segmentation testing set up as a running cycle with an owner, not a pre-assessment scramble.
  • 06QSA liaison where a Report on Compliance is required, including evidence preparation and scope negotiation.

Choosing between them

PCI DSS or ISO 27001?

PCI DSS is prescriptive and narrow: a defined list of technical and process requirements applied to a defined cardholder data environment, imposed contractually by the card schemes. ISO 27001 is risk-based and broad: the organisation selects controls proportionate to risks it has assessed, across whatever scope it defines. PCI DSS tells you what to do; ISO 27001 asks you to justify what you have chosen to do. An ISO 27001 ISMS provides useful governance underneath a PCI programme - risk assessment, supplier management, incident response - but it satisfies none of the specific PCI requirements, and PCI compliance says nothing about security outside the cardholder data environment.

ISO 27001

FAQ

PCI DSS: questions people actually ask

What changed in PCI DSS v4.x on 31 March 2025?

The 51 future-dated requirements introduced in v4.0 stopped being best practice and became mandatory in every assessment. They include multi-factor authentication for all access into the cardholder data environment, expanded password requirements, targeted risk analyses for several controls, and for e-commerce the payment page script inventory and change detection requirements under 6.4.3 and 11.6.1. PCI DSS v4.0.1 was a limited clarifying revision and did not change that date.

Which SAQ applies to our business?

It depends on how card data reaches you. SAQ A covers merchants who have fully outsourced all card functions to a validated third party, typically through a redirect or a properly implemented iframe. SAQ A-EP covers e-commerce merchants whose site affects the payment transaction but does not receive card data directly. SAQ D covers everyone else, and service providers. Choosing incorrectly invalidates the attestation, so confirm it with your acquirer in writing.

Is PCI DSS a legal requirement?

No. PCI DSS is a contractual requirement flowing from the card schemes through acquiring banks to merchants and service providers. Consequences for non-compliance are contractual - fines passed down by the acquirer, increased transaction fees, or withdrawal of card processing. A breach involving cardholder data will usually also engage data protection law separately.

Do we still need PCI DSS if we use Stripe or a similar provider?

Yes, but the obligation is much smaller. Using a payment provider that handles card data through a redirect or a hosted field set typically puts a merchant in SAQ A or SAQ A-EP rather than SAQ D, which removes most of the requirements. It does not remove the obligation entirely, and since March 2025 e-commerce merchants using embedded payment fields have specific obligations around scripts on the payment page.

How long does PCI DSS compliance take?

For a merchant who can validate by SAQ A after scope reduction, four to eight weeks is realistic. For SAQ D or a QSA-assessed Report on Compliance from a standing start, six to nine months is more typical, with scope reduction work usually paying for itself several times over. Quarterly ASV scanning and annual validation continue indefinitely afterwards.

Related

ISO 27001ISO 42001SOC 2NIST AI RMFNIST 800-53Cyber EssentialsGDPR

Start

Three ways in, depending on how close the deadline is.

Or just email a human: hello@cloudgap.ai

We reply within24 hours