PCI DSS

Introduction

The Payment Card Industry Data Security Standard (PCI DSS) is the globally recognised baseline for protecting cardholder data (CHD) and sensitive authentication data (SAD) throughout their lifecycle of storage, processing and transmission. Maintained by the PCI Security Standards Council (PCI SSC) - a body founded by American Express, Discover, JCB International, Mastercard and Visa Inc. - the standard applies to any merchant, service provider or other entity that stores, processes or transmits account data, regardless of size, industry or geography. This deep-dive is written for security leaders, compliance managers, internal auditors and technical teams preparing for a formal PCI DSS assessment against the current version of the standard, PCI DSS v4.0.1 (the maintenance release that superseded v4.0 and retired v3.2.1 on 31 March 2024).

Unlike a legal regulation, PCI DSS is a contractual obligation enforced by the individual payment card brands and by acquiring banks. Non-compliance can result in monthly fines, increased transaction fees, mandatory forensic investigation after a breach, and in severe cases the withdrawal of the ability to accept card payments. The standard is prescriptive and technical, but v4.0 introduced a more outcome-focused philosophy through the Customised Approach, alongside the traditional Defined Approach. This guide walks through every requirement family, the assessment evidence auditors expect, scoping discipline, and a phased implementation roadmap.

What is PCI DSS

PCI DSS is a set of security requirements designed to ensure that all companies that accept, process, store or transmit credit card information maintain a secure environment. The scope of protection centres on two data categories. Cardholder Data (CHD) comprises the Primary Account Number (PAN), cardholder name, expiration date and service code. Sensitive Authentication Data (SAD) comprises the full track data (magnetic-stripe data or its equivalent on a chip), the card verification code/value (CAV2/CVC2/CVV2/CID) and PINs/PIN blocks. The cardinal rule is that SAD must never be stored after authorisation, even in encrypted form, while CHD may be stored only when there is a legitimate business need and only under strong protection such as strong cryptography with associated key-management processes.

The standard is organised into 12 principal requirements grouped under six control objectives, expanded into several hundred detailed sub-requirements and testing procedures. PCI DSS v4.0 added roughly 60 new requirements. Many were designated 'best practice' until 31 March 2025, after which they became mandatory - meaning any assessment with a report date on or after 1 April 2025 must treat those future-dated requirements as in force. Key v4.0 themes include: continued flexibility through the Customised Approach; increased emphasis on continuous security rather than point-in-time compliance; expanded multi-factor authentication (MFA); stronger anti-phishing and e-commerce skimming controls (notably the new script and header-integrity requirements 6.4.3 and 11.6.1); and clearer definitions of roles and responsibilities via 'Roles and Responsibilities' sub-requirements attached to each of the 12 requirements.

Validation instruments

• Report on Compliance (ROC): a full assessment performed by a Qualified Security Assessor (QSA) or an Internal Security Assessor (ISA); mandatory for Level 1 merchants and most large service providers.
• Self-Assessment Questionnaire (SAQ): a self-validation tool for eligible smaller merchants; variants include SAQ A, A-EP, B, B-IP, C, C-VT, P2PE, D-Merchant and D-Service Provider, each scoped to a specific payment channel and technology.
• Attestation of Compliance (AOC): the signed declaration of compliance status, submitted to the acquirer or payment brand alongside the ROC or SAQ.
• Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) where applicable under Requirement 11.3.2.

Who must comply

PCI DSS applies to all entities involved in payment card processing - merchants, processors, acquirers, issuers and service providers - as well as any other entity that stores, processes or transmits cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment (CDE). The rigour of validation is determined by transaction volume, which places each entity into a merchant or service-provider level defined by the individual card brands (levels below reflect Visa/Mastercard conventions; thresholds can differ by brand and by forensic history).

• Payment gateways, processors and payment facilitators (PayFacs) that touch account data.
• SaaS and cloud providers whose services could affect the security of a client CDE (for example hosting, managed firewalls, tokenisation or fraud-scoring platforms).
• Call centres, BPOs and back-office operations that capture PANs over the telephone or via correspondence.
• E-commerce businesses using redirect, iframe or direct-post integrations - each carries a different SAQ eligibility and script-integrity obligation.
• Any organisation that has outsourced payment handling but retains responsibility for vendor oversight and for the portions of PCI DSS it still influences.

Structure of PCI DSS

PCI DSS is structured as six control objectives (goals) that decompose into 12 core requirements. Each core requirement contains sub-requirements, defined testing procedures, guidance and - in v4.0 - customised-approach objectives and applicability notes. The table below maps the goals to their requirements.

Two additional structural constructs are essential. Appendix A extends the standard for specific scenarios: A1 (multi-tenant service providers), A2 (SSL/early TLS for POS POI terminals) and A3 (the Designated Entities Supplemental Validation, DESV, applied to entities directed by a payment brand or acquirer). The Customised Approach allows an entity to meet the stated Customised Approach Objective of a requirement using controls of its own design, provided it documents a targeted risk analysis and the QSA validates that the objective is met.

Master assessment checklist

This is the core of the guide. Each of the 12 requirements is enumerated below with the principal sub-requirement themes, what an assessor must verify, and the typical evidence expected. Use these tables as the backbone of a readiness or gap assessment; every control area is covered so that nothing is skipped. Evidence should always be current, dated, and traceable to a named owner.

Requirement 1 - Install and Maintain Network Security Controls

Requirement 2 - Apply Secure Configurations to All System Components

Requirement 3 - Protect Stored Account Data

Requirement 4 - Protect CHD with Strong Cryptography During Transmission

Requirement 5 - Protect All Systems and Networks from Malicious Software

Requirement 6 - Develop and Maintain Secure Systems and Software

Requirement 7 - Restrict Access by Business Need to Know

Requirement 8 - Identify Users and Authenticate Access

Requirement 9 - Restrict Physical Access to Cardholder Data

Requirement 10 - Log and Monitor All Access

Requirement 11 - Test Security of Systems and Networks Regularly

Requirement 12 - Support Information Security with Organisational Policies and Programmes

Scoping

Scoping is the single most consequential activity in a PCI DSS programme: it defines which systems, people and processes fall under the standard and therefore the size, cost and risk of the assessment. The Cardholder Data Environment (CDE) comprises the people, processes and technologies that store, process or transmit CHD or SAD. PCI DSS scope, however, is broader than the CDE - it also includes any 'connected-to' or 'security-impacting' systems that can affect the security of the CDE, even if they never touch account data themselves (for example, an authentication server, a jump host, a patch-distribution server, or a hypervisor hosting CDE workloads).

• CDE systems: any system that stores, processes or transmits CHD/SAD, and any system on the same network segment.
• Connected-to / security-impacting systems: systems that can connect to or influence the security of the CDE (e.g. NTP, DNS, AD, SIEM, admin workstations, backup servers).
• Out-of-scope systems: only truly isolated systems with adequate network segmentation and no ability to affect CDE security - and the isolation must be validated by penetration testing.
• Segmentation is not mandatory but is strongly recommended to reduce scope; if used, its effectiveness must be tested at least annually (every six months for service providers).
• Scope reduction techniques: tokenisation, point-to-point encryption (P2PE), outsourcing to compliant providers, and iframe/redirect e-commerce integrations that keep PAN off the merchant's servers.

Implementation approach

A successful PCI DSS programme is delivered in phases. The following five-phase roadmap moves an organisation from an undefined state to sustained, audit-ready compliance. Each phase lists indicative activities and the deliverables that de-risk the eventual formal assessment.

Phase 1 - Discovery and scoping

• Activities: identify all payment channels; perform cardholder-data discovery scans; map data flows; build asset inventory; determine merchant/service-provider level and applicable SAQ or ROC.
• Deliverables: current data-flow diagrams, network diagrams, CDE and in-scope inventory, validation-type determination, project charter.

Phase 2 - Gap assessment

• Activities: assess current state against all 12 requirements; identify control gaps; risk-rank findings; validate segmentation assumptions; review third-party AOCs.
• Deliverables: gap-analysis report, prioritised remediation plan with owners and timelines, provisional Customised/Defined approach decisions.

Phase 3 - Remediation

• Activities: implement or tune NSCs, encryption, MFA, logging and monitoring; harden systems; deploy anti-malware and FIM; write/update policies and procedures; establish training and TPSP management.
• Deliverables: hardening standards, key-management procedures, updated policies, deployed technical controls, remediation-closure evidence.

Phase 4 - Validation and testing

• Activities: run internal and ASV scans until passing; conduct penetration testing and segmentation testing; complete evidence collection; perform an internal readiness (pre-assessment) review.
• Deliverables: passing scan reports, pen-test report with remediation, complete evidence library, readiness sign-off.

Phase 5 - Formal assessment and sustainment

• Activities: engage QSA for ROC or complete SAQ; sign AOC; submit to acquirer/brand; establish business-as-usual (BAU) monitoring and continuous-compliance cadence.
• Deliverables: ROC/SAQ, signed AOC, BAU calendar (daily log review, quarterly scans, six-monthly reviews, annual pen-test and scope confirmation).

Maturity and capability model

PCI DSS itself is pass/fail at the point of assessment, but organisations benefit from tracking their compliance maturity to move from reactive, point-in-time validation to sustained security-as-BAU. The following model gauges programme capability.

Assessment and audit approach

1. Confirm validation type and level (SAQ vs ROC) with the acquirer or payment brand, and select the correct SAQ variant if self-assessing.
2. Define and document scope: finalise data-flow and network diagrams, asset inventory, and segmentation boundaries.
3. Select the assessment approach per requirement: Defined Approach (meet requirements as written) or Customised Approach (meet the objective via designed controls with a targeted risk analysis).
4. Conduct interviews, observations, configuration reviews and sampling across in-scope system components and personnel.
5. Test each sub-requirement against its defined testing procedure and record the result as In Place, Not Applicable, Not Tested or Not in Place.
6. For any Customised Approach items, review the entity's controls matrix, targeted risk analysis and testing evidence to confirm the objective is met.
7. Validate compensating controls (Defined Approach only) against the compensating-controls worksheet where a requirement cannot be met as stated.
8. Aggregate findings into the ROC (or complete the SAQ), remediate any Not-in-Place items, and re-test until all applicable requirements are In Place.
9. Complete and sign the Attestation of Compliance (AOC); attach passing ASV scans and pen-test evidence.
10. Submit the AOC and supporting artefacts to the acquirer/brand, and initiate the BAU cadence for the next cycle.

Evidence request list

Assessors request evidence across several categories. Prepare a structured, indexed evidence library keyed to each requirement to accelerate the assessment.

• Governance and policy: information-security policy, acceptable-use policy, targeted risk analyses, roles-and-responsibilities matrix, annual scope-confirmation record.
• Architecture: current network diagrams, data-flow diagrams, CDE and asset inventories, segmentation design.
• Network and configuration: firewall/NSC rulesets and six-monthly reviews, hardening/build standards, sampled configurations, wireless configuration.
• Data protection: data-retention and disposal policy, discovery-scan results, encryption and tokenisation architecture, key-management procedures and custodian forms.
• Access and authentication: RBAC matrix, user inventory, six-monthly access reviews, MFA configuration and coverage, joiner-mover-leaver records.
• Physical security: badge/visitor logs, media-handling and destruction records, POI device inventory and inspection logs.
• Logging and monitoring: logging configuration, SIEM alerting rules, daily-review records, retention evidence, FIM and IDS/IPS configuration.
• Testing: internal and ASV scan reports, penetration-test and segmentation-test reports, remediation and retest evidence.
• Vulnerability and change management: patch reports and SLAs, SDLC and secure-coding standards, code-review and SAST/DAST reports, change tickets.
• Third parties and incident response: TPSP inventory and contracts, provider AOCs, responsibility matrix, incident-response plan and annual test records.
• Awareness: security-awareness training content and completion records, phishing-simulation results.

Roles and responsibilities

KPIs to track

• Percentage of in-scope systems compliant with hardening/build standards.
• Percentage of critical/high patches applied within the one-month SLA (Req 6.3.3).
• Number of open ASV scan failures and mean time to remediate to a passing scan.
• MFA coverage across CDE, remote and administrative access (target 100%).
• Percentage of accounts reviewed on the six-monthly access-review cycle.
• Number of overdue firewall/NSC ruleset reviews (target zero).
• Daily log-review completion rate and mean time to detect/respond to critical alerts.
• Security-awareness training completion rate (target 100% within cycle).
• Number of TPSPs with current AOCs on file versus total TPSP inventory.
• Time to remediate high/critical penetration-test findings.
• Number of dormant accounts not disabled within 90 days (target zero).
• Percentage of payment pages with active script-integrity monitoring (Req 6.4.3 / 11.6.1).

Readiness checklist

• Validation type and merchant/service-provider level confirmed with the acquirer.
• Current data-flow and network diagrams produced and validated within the last 12 months.
• Cardholder-data discovery scan completed with no unexpected PAN/SAD storage.
• CDE and in-scope asset inventory complete and reconciled.
• Segmentation implemented and tested (annually, or six-monthly for service providers).
• NSC rulesets documented and reviewed within the last six months.
• System hardening standards defined and applied to all component types.
• SAD confirmed not stored post-authorisation; stored PAN rendered unreadable.
• Key-management procedures documented with custodian acknowledgements.
• Strong cryptography enforced on all transmission over open, public networks.
• Anti-malware, FIM and anti-phishing controls deployed and current.
• Secure SDLC, WAF and payment-page script controls operating.
• Least-privilege access model and six-monthly access reviews evidenced.
• MFA enforced for CDE, remote and all administrative access.
• Physical access, media handling and POI inspection controls in place.
• Centralised logging, daily review, time sync and 12-month retention operating.
• Quarterly internal and ASV scans passing; annual pen-test and segmentation test complete.
• Security-awareness training delivered within the cycle to all personnel.
• TPSP inventory, contracts, AOCs and responsibility matrix maintained.
• Incident-response plan documented and tested within the last 12 months.
• Annual scope confirmation recorded and signed.
• Evidence library indexed by requirement and ready for the assessor.

Common gaps

• Under-scoping: failing to include connected-to and security-impacting systems, or relying on untested segmentation.
• Inadvertent SAD storage: full track data, CVV or PIN blocks retained in application logs, debug files or database columns.
• Stale firewall/NSC rulesets with permissive 'any-any' rules and no six-monthly review evidence.
• Incomplete MFA: administrative or remote access covered but access into the CDE from within the corporate network overlooked.
• Patch-SLA breaches for critical and high vulnerabilities beyond the one-month window.
• Weak or undocumented cryptographic key management - no split knowledge, dual control or rotation records.
• Logging gaps: logs not centralised, not reviewed daily, retained under 12 months, or missing required event fields.
• E-commerce script and header-integrity controls (6.4.3, 11.6.1) not implemented, leaving pages exposed to skimming.
• Third-party risk blind spots: missing AOCs, absent responsibility matrices, and no ongoing TPSP monitoring.
• Dormant and shared accounts not disabled or justified; leaver access left active.
• Point-in-time compliance mindset - controls degrade after the assessment because BAU cadence is not embedded.
• Untested incident-response plan and no defined breach-notification path.

PCI DSS mapped to other frameworks

PCI DSS controls overlap substantially with broader security frameworks, allowing organisations to reuse evidence and align programmes. The mapping below is indicative and should be validated against the official crosswalks.

Frequently asked questions

Need help with PCI DSS?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.