The Payment Card Industry Data Security Standard (PCI DSS) protects payment card data. It applies to every organisation that stores, processes or transmits cardholder data, and to entities that can affect the security of that data. The current version is v4.0.1. This guide is a practical implementation, scoping and assessment reference; it does not reproduce the PCI SSC’s licensed documents.
Scope and the Cardholder Data Environment (CDE)
Scope is the single biggest driver of PCI cost, effort and risk. The CDE is every system that stores, processes or transmits cardholder data (CHD) or sensitive authentication data (SAD), plus any system connected to or that could impact the security of those systems. Getting scope right — and then reducing it — is the first and most important step.
| Data type | Examples | Storage rule |
|---|---|---|
| Cardholder Data (CHD) | Primary Account Number (PAN), cardholder name, expiry, service code | PAN must be rendered unreadable wherever stored (encryption, truncation, tokenisation, hashing) |
| Sensitive Authentication Data (SAD) | Full track data, CAV2/CVC2/CVV2/CID, PINs/PIN blocks | Must NOT be stored after authorisation — even encrypted |
Reducing scope (do this first)
- Network segmentation to isolate the CDE from the rest of the network.
- Tokenisation so systems hold tokens, not real PANs.
- Outsourcing card capture to a compliant provider (hosted payment page, redirect, iframe).
- Point-to-point encryption (P2PE) so merchant systems never see clear card data.
- Eliminating unnecessary storage of CHD entirely.
The 12 requirements
| # | Requirement | Intent |
|---|---|---|
| 1 | Install and maintain network security controls | Firewalls/NSCs restrict traffic to and from the CDE |
| 2 | Apply secure configurations to all system components | Remove vendor defaults; harden systems |
| 3 | Protect stored account data | Render PAN unreadable; never store SAD post-authorisation; manage keys |
| 4 | Protect cardholder data with strong cryptography during transmission | Encrypt CHD over open/public networks |
| 5 | Protect all systems and networks from malicious software | Anti-malware and detection mechanisms |
| 6 | Develop and maintain secure systems and software | Secure development, patching, change control, WAF/script controls |
| 7 | Restrict access to system components and CHD by business need to know | Least privilege and role-based access |
| 8 | Identify users and authenticate access | Unique IDs, strong authentication, MFA |
| 9 | Restrict physical access to cardholder data | Facility, media and device controls |
| 10 | Log and monitor all access to system components and CHD | Audit logs, time sync, daily review, retention |
| 11 | Test security of systems and networks regularly | Vulnerability scans (ASV), penetration testing, wireless, change detection |
| 12 | Support information security with organisational policies and programs | Policy, risk analysis, awareness, incident response, TPSP management |
What changed in v4.0 / v4.0.1
v4.0 introduced significant changes over v3.2.1; v4.0.1 is a limited-scope clarification of v4.0. Many controls were "future-dated" as best practice and are now mandatory.
- Customised Approach — meet a requirement’s objective with alternative controls, supported by a documented Targeted Risk Analysis (TRA).
- Expanded multi-factor authentication, including for all access into the CDE.
- Stronger password/authentication parameters.
- Targeted Risk Analyses to set the frequency of certain recurring controls.
- Payment-page script management and integrity monitoring (anti-e-skimming) and anti-phishing controls.
- Expanded requirements and responsibilities for service providers.
- Automated log review mechanisms.
Validation: how you prove compliance
Merchant levels
| Level | Annual card volume (per brand) | Typical validation |
|---|---|---|
| Level 1 | Over 6 million transactions | Report on Compliance (ROC) by a QSA (or ISA), quarterly ASV scans |
| Level 2 | 1 – 6 million | SAQ (often QSA-assisted) + quarterly ASV scans |
| Level 3 | 20,000 – 1 million (e-commerce) | SAQ + quarterly ASV scans |
| Level 4 | Under 20,000 (e-commerce) / up to 1 million | SAQ + ASV scans as required by the acquirer |
Common SAQ types
| SAQ | Who it applies to |
|---|---|
| SAQ A | E-commerce/MOTO fully outsourced to a compliant provider; no CHD on merchant systems |
| SAQ A-EP | E-commerce that partially manages the payment page (e.g., direct-post) but does not store CHD |
| SAQ B / B-IP | Imprint machines or standalone dial-out / IP-connected terminals; no electronic CHD storage |
| SAQ C / C-VT | Payment application systems connected to the internet / virtual terminals; no CHD storage |
| SAQ P2PE | Merchants using a validated PCI P2PE solution |
| SAQ D | All other merchants and all service providers eligible to self-assess |
Service providers validate as Level 1 (Report on Compliance) or Level 2 (SAQ D for Service Providers) based on volume and the payment brands’ rules. Choosing the correct SAQ is essential — the wrong one wastes effort or leaves gaps.
Implementation roadmap
- Scope: inventory systems, people and processes; map card-data flows end to end (including third parties).
- Reduce scope: segment, tokenise, adopt P2PE or outsource capture.
- Gap assessment against all 12 requirements for the in-scope environment.
- Remediate: firewalls/NSCs, encryption & key management, MFA, logging, secure development, patching.
- Test: internal and ASV external vulnerability scans, penetration testing (network + application), segmentation testing.
- Document: policies, Targeted Risk Analyses, evidence, and responsibility matrices (including TPSPs).
- Validate: complete the correct SAQ or a QSA-led ROC; produce the Attestation of Compliance (AOC).
- Maintain: business-as-usual controls, quarterly scans, and annual re-validation.
Assessment and audit approach
- Define assessment type (SAQ self-assessment vs QSA-led ROC) and scope with a current card-data-flow diagram and network diagram.
- Sample system components across the CDE; interview staff; observe processes; inspect configurations and evidence.
- Validate segmentation with penetration testing where used to reduce scope.
- Confirm ASV scans passed (four consecutive quarters as applicable) and penetration testing remediation.
- Complete testing for every sub-requirement, document findings, remediate, and re-test.
- Produce the ROC/SAQ and Attestation of Compliance (AOC) and submit to the acquirer/brands.
Evidence checklist
- Cardholder data-flow and network diagrams (current).
- Scope and segmentation documentation, with segmentation penetration-test results.
- Firewall/NSC rule sets and review records.
- Encryption and key-management procedures and records.
- MFA and access-control configurations and access reviews.
- Patch and vulnerability-management records; ASV scan reports.
- Penetration-test reports (network and application) and remediation evidence.
- Log configuration, daily review evidence and retention.
- Secure-development and change-management records; payment-page script inventory.
- Policies, Targeted Risk Analyses, awareness-training records and incident-response plan.
- Third-party service provider (TPSP) list, responsibility matrix and their AOCs.
Common gaps that fail assessments
- Unsegmented networks that pull the entire estate into scope.
- Storing SAD after authorisation, or storing PAN in clear text/logs.
- Incomplete MFA on remote and administrative access into the CDE.
- Weak key management and undocumented cryptography.
- Ad-hoc logging that cannot support an investigation, or logs never reviewed.
- No routine internal/external scanning or penetration testing.
- Missing management of third-party service providers and their responsibilities.
- The wrong SAQ type selected for how payments are actually accepted.
PCI DSS mapped to other frameworks
| Framework | Relationship |
|---|---|
| ISO 27001 | ISMS controls overlap heavily; PCI DSS is prescriptive for card data, ISO is a risk-based management system |
| SOC 2 | Security Trust Services Criteria overlap; evidence can be reused |
| NIST CSF / 800-53 | PCI requirements map to Protect/Detect functions and control families |
| RBI / PA-PG | RBI payment-aggregator rules expect a PCI DSS-compliant posture for card data |
How CyberSigma helps
CyberSigma is PCI QSA authorised across the CEMEA region. Our senior assessors scope accurately, help you reduce scope, remediate efficiently and complete the SAQ or QSA-led ROC — from readiness to a signed Attestation of Compliance.
Frequently asked questions
Which SAQ do I need?
It depends on how you accept payments (e.g., fully outsourced hosted page vs handling card data directly). Choosing the correct SAQ is essential — our free PCI DSS scope checker gives an indication.
What changed in PCI DSS v4.0.1?
v4.0 introduced expanded MFA, stronger authentication, targeted risk analyses, payment-page script integrity and more; v4.0.1 is a minor clarification update. Several requirements are now mandatory after being future-dated.
Who needs a QSA?
Level 1 merchants and many service providers require a Qualified Security Assessor–led assessment. CyberSigma is PCI QSA authorised across the CEMEA region.
Official documents
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.