PCI DSS Compliance &
Cardholder Data Security

Full-cycle advisory for merchants, payment processors and service providers handling card payment data. We take you from CDE scoping and gap assessment through SAQ completion or QSA-assisted ROC to your Attestation of Compliance — and keep you compliant quarterly thereafter.

PCI DSS v4.0 SAQ A · A-EP · B · B-IP · C · C-VT · D ROC · AOC · ASV Scans March 2025 Mandatory Reqs

What Is PCI DSS and Who Must Comply?

Visa
Mastercard
Amex
Discover
JCB

The Payment Card Industry Data Security Standard (PCI DSS) is a global security framework governed by the PCI Security Standards Council, mandated by all five major card brands above. It applies to every entity that stores, processes or transmits Primary Account Numbers (PANs) — including merchants, payment service providers, acquirers and SaaS platforms with embedded payments.

PCI DSS v4.0 replaced v3.2.1 in March 2024, with six previously "best practice" requirements becoming mandatory from March 2025. The standard now covers 259 sub-requirements across 12 top-level requirements.

Not just for large companies

PCI DSS applies to every business that accepts card payments — a single POS terminal, a Shopify store, a payment link or a payment API integration all bring you into scope. There is no size exemption.

  • Scope is determined by cardholder data flows — not company size or revenue
  • Even "outsourced" payment pages do not remove your PCI DSS responsibility
  • Service providers handling card data on behalf of merchants have their own obligations
  • RBI and card brand operating regulations in India reference PCI DSS compliance
  • Non-compliance discovered post-breach can void your cyber insurance policy

The Cost of Getting It Wrong

$5K–$100K
Monthly Fines
Card brand monthly fines per card brand for non-compliance, escalating over time
$50–$90
Per Compromised Card
Card replacement costs charged back to the acquirer and passed to the merchant after a breach
5 Years
Enhanced Audits
Post-breach mandatory forensic investigation plus annual QSA audits for up to 5 years

Indian context: RBI's Payment Aggregator and Payment Gateway guidelines (2020, updated 2022) explicitly require PCI DSS compliance for all entities handling card data. NPCI also references PCI DSS for card network participants. Non-compliance risks PA/PG licence revocation.

Which Level Are You?

Level 1
> 6M transactions/yr
Annual on-site QSA ROC + quarterly ASV scan + annual penetration test
Level 2
1M – 6M transactions/yr
Annual SAQ D + quarterly ASV scan + annual penetration test
Level 3
20K – 1M (e-commerce)
Annual SAQ + quarterly ASV scan
Level 4
< 20K e-com / <1M all others
Annual SAQ (recommended) + quarterly ASV scan

Understanding Your Cardholder Data Environment (CDE)

PCI DSS compliance starts with correctly defining your CDE — the systems, people and processes that store, process or transmit cardholder data. Getting the scope wrong is the single biggest cause of failed audits.

👤
Cardholder
Customer initiates payment
PAN + CVV + Expiry ──────→
🌐
Payment Page / App
Req 6.4.3 — Script control
Encrypted (TLS 1.2+) ──────→
Payment Gateway / PSP
Tokenisation / processing
Authorisation ──────→
🏦
Acquiring Bank
Card network routing
Auth Response ──────→
Merchant Systems
Token only — no PAN
In-scope CDE — full PCI DSS controls apply
Out-of-scope — PAN never touches these systems
Connected-to-CDE — risk assessed, segmentation required

Scope reduction strategy: The most effective way to reduce PCI DSS burden is network segmentation and tokenisation. If your systems receive only payment tokens (never raw PANs), they are out of scope. We help you design your architecture to legitimately minimise scope — reducing effort, cost and audit risk significantly.

All 12 Requirements — Detailed Overview

PCI DSS v4.0 organises 259 sub-requirements across 12 top-level requirements grouped under 6 control goals. We assess, implement and evidence all of them.

Goal 1 Build and Maintain a Secure Network and Systems
REQ 1
Install and Maintain Network Security Controls

Firewalls / NSCs between untrusted networks and CDE. Documented NSC rulesets. Bi-annual ruleset review. Inbound and outbound traffic restricted to what is necessary for cardholder data environment. All other traffic explicitly denied.

REQ 2
Apply Secure Configurations to All System Components

No vendor-supplied default passwords. Documented configuration standards for all in-scope systems. Disable all unnecessary services, ports and protocols. System component inventory maintained. Wireless environments secured and inventoried.

Goal 2 Protect Account Data
REQ 3
Protect Stored Account Data

Data retention and disposal policy. PAN storage minimised — never store SAD (CVV2/CVC2, PIN blocks, full magnetic stripe) post-authorisation. Stored PAN rendered unreadable using AES-256 or strong one-way hash. Truncation or tokenisation. Cryptographic key management procedures. v4.0 NEW Disk-level encryption no longer sufficient alone.

REQ 4
Protect Cardholder Data with Strong Cryptography During Transmission

TLS 1.2 minimum (TLS 1.3 recommended) for all PAN transmission over open/public networks. SSL and early TLS prohibited. Certificate management. Wireless networks use WPA3 or WPA2 with AES. v4.0 NEW Inventory of all trusted keys and certificates required.

Goal 3 Maintain a Vulnerability Management Programme
REQ 5
Protect All Systems Against Malware

Anti-malware deployed on all systems susceptible to malicious software. Updated anti-malware mechanisms. Periodic evaluations for systems not commonly affected by malware. Anti-phishing mechanisms. v4.0 NEW Anti-phishing technology required for email protection.

REQ 6
Develop and Maintain Secure Systems and Software

Security in SDLC. Vulnerability management and patch process (critical patches within 1 month). Web application protection (WAF or code review). Bespoke software development standards. v4.0 MANDATORY Req 6.4.3: Payment page script inventory and integrity control. Req 6.3.3: All software components protected from known vulnerabilities.

Goal 4 Implement Strong Access Control Measures
REQ 7
Restrict Access to System Components and Cardholder Data by Business Need-to-Know

Access control system with default deny-all. All access documented with business justification. Role-based access control (RBAC). Quarterly review of user access rights. Access for third-party/contractors controlled and monitored.

REQ 8
Identify Users and Authenticate Access to System Components

Unique user IDs. Password complexity (min 12 characters in v4.0). Account lockout after 10 failures. Session timeout after 15 minutes. v4.0 MANDATORY MFA required for ALL CDE access (not just remote). Service accounts documented and reviewed. Passwords hashed with strong one-way function.

REQ 9
Restrict Physical Access to Cardholder Data

Physical access controls to CDE facilities. Visitor access procedures and logs. Media controls for devices containing cardholder data. Point-of-interaction (POI) device protection — inventory, periodic inspection for tampering, training staff to detect skimming devices.

Goal 5 Regularly Monitor and Test Networks
REQ 10
Log and Monitor All Access to System Components and Cardholder Data

Audit logs for all CDE access. Log content requirements (user ID, event type, date/time, success/failure, origination, affected component). Log protection from modification. Daily log review. Log retention minimum 12 months (3 months immediately available). v4.0 MANDATORY Automated mechanisms for log review and anomaly detection (Req 10.7.3).

REQ 11
Test Security of Systems and Networks Regularly

Wireless access point scanning (quarterly). ASV external vulnerability scanning (quarterly, certified ASV vendor). Internal vulnerability scanning (quarterly). Penetration testing annually and after significant changes — internal and external, plus segmentation test. File integrity monitoring (FIM). v4.0 MANDATORY Req 11.6.1: Automated change and tamper-detection mechanism for payment pages, evaluated weekly.

Goal 6 Maintain an Information Security Policy
REQ 12
Support Information Security with Organisational Policies and Programmes

Comprehensive information security policy reviewed annually. Acceptable use policy. Risk assessment process (Req 12.3). Targeted risk analysis for flexible controls (Req 12.3.2). Operational security procedures. Cryptographic algorithm inventory (Req 12.3.3). Third-party / service provider management programme (Req 12.8). Incident response plan with defined roles, tested annually (Req 12.10). Security awareness programme for all personnel — at hire and annually (Req 12.6).

6 New Requirements You Must Action Now

These requirements were "best practice" in PCI DSS v4.0 but became mandatory from 31 March 2025. If you were compliant under v3.2.1 and haven't addressed these, you are now out of compliance.

Req 6.4.3

Payment Page Script Inventory & Integrity

Every script loaded on your payment page must be documented in an authorised inventory with a business justification. Each script must have a method to confirm it has not been tampered with (e.g. subresource integrity hash). No unauthorised scripts permitted.

E-commerce merchants using hosted payment pages or iframes
Req 11.6.1

Payment Page Change & Tamper Detection

A mechanism must be deployed to detect unauthorised modifications to payment page HTTP headers and script contents. Evaluation must occur at minimum once every 7 days — catching Magecart / web-skimming attacks in near real-time.

All merchants with e-commerce payment pages
Req 8.4.2

MFA for All CDE Access

Multi-factor authentication is now mandatory for all interactive user access to the CDE — not just remote access. Any user logging into a server, database or system within the CDE must use MFA regardless of whether access is from inside or outside the network.

All entities — affects all admin and privileged accounts
Req 10.7.2 & 10.7.3

Automated Failure Detection for Critical Controls

Failures of critical security controls (NSC, IDS/IPS, FIM, anti-malware, audit logs, access controls, segmentation controls) must be detected promptly and responded to. Manual periodic checks are no longer sufficient — automated alerting is required.

Service providers (10.7.2) and all entities (10.7.3)
Req 12.3.2

Targeted Risk Analysis for Customised Controls

Where an entity uses the "customised approach" (flexible control design instead of prescriptive controls), a documented targeted risk analysis must demonstrate that each customised control achieves the stated security objective at least as effectively as the standard requirement.

Entities using the customised approach for any requirement
Req 12.3.3

Cryptographic Algorithm Inventory

A documented inventory of all cryptographic cipher suites, protocols and algorithms in use must be maintained and reviewed at least annually against current industry guidance and emerging threats. Plans for migrating away from weak algorithms must be documented.

All entities — especially those using legacy TLS or SHA-1

Which SAQ Type Applies to You?

Choosing the wrong SAQ is a common mistake that either leaves you under-compliant or forces unnecessary work. The correct SAQ depends entirely on how card payments flow through your environment.

SAQ A
~22 requirements
Simplest SAQ. No electronic storage, processing or transmission of cardholder data on your systems.
Applicable to

Card-not-present merchants (e-commerce, mail/phone order) who have fully outsourced all payment functions to PCI DSS validated third parties. Your website only redirects customers to the payment processor.

SAQ A-EP
~191 requirements
For e-commerce where your website is involved in the payment flow even if processing is outsourced.
Applicable to

E-commerce merchants whose website does not directly receive cardholder data but uses a payment page that could be modified to intercept data (e.g. iframes that load third-party scripts on your domain).

SAQ B-IP
~83 requirements
For merchants using IP-connected PTS-approved payment terminals that are isolated from other systems.
Applicable to

Face-to-face merchants using standalone, IP-connected POS terminals (EFTPOS machines) certified to PTS. No electronic storage of cardholder data. Terminal communicates directly to processor.

SAQ D
~250+ requirements
Most comprehensive SAQ — all requirements apply. Required for most merchants with in-house systems.
Applicable to

All merchants not qualifying for SAQ A–C-VT, and all service providers eligible for SAQ assessment. If you store PANs, run your own payment application, or have complex card data environments — this is your SAQ.

SAQ C, SAQ C-VT and SAQ P2PE are also available for specific environments. We identify the correct SAQ for your setup during the scoping engagement.

Our 6-Phase Path to Validated Compliance

Phase 1 — Scoping & Discovery

Define Your CDE Boundary

Map all cardholder data flows: where PANs enter, how they move, where they are stored, how they are transmitted and who touches them. Identify all in-scope system components. Assess network segmentation effectiveness. Determine applicable Merchant Level and SAQ type. Produce a formal CDE scoping document with network diagram.

Phase 2 — Gap Assessment

Measure Against All 259 Sub-Requirements

Structured assessment of your current controls against every PCI DSS v4.0 sub-requirement. Each gap rated by effort, risk and priority. Explicit attention to the six new March 2025 mandatory requirements. Output: gap assessment report with prioritised remediation plan and effort estimates for each control deficiency.

Phase 3 — Remediation

Implement Required Controls

Hands-on support implementing: network segmentation and firewall rules, TLS 1.2/1.3 enforcement, MFA deployment for CDE access, access control and IAM procedures, log management and SIEM configuration, anti-malware and patch management, payment page script inventory (Req 6.4.3), tamper detection mechanism (Req 11.6.1), and PCI-required policy suite (Req 12).

Phase 4 — SAQ or ROC Preparation

Build Your Compliance Evidence Package

For SAQ merchants: complete the correct SAQ with documented evidence for every "Yes" response. For Level 1 merchants or those requiring ROC: prepare the full Report on Compliance evidence pack — system descriptions, control documentation, test results and management attestations. QSA liaison and audit coordination.

Phase 5 — ASV Scans & Penetration Testing

Mandatory Technical Testing

Coordinate quarterly external vulnerability scans with an Approved Scanning Vendor (ASV). Scope and commission annual penetration tests (internal network, external perimeter, web application). Segmentation testing to validate CDE isolation. Remediate and re-scan all high/critical findings. Produce passing scan reports for your Acquiring Bank.

Phase 6 — AOC & Ongoing Compliance

Attestation, Submission and Maintenance

Finalise and sign the Attestation of Compliance (AOC). Submit completed SAQ/ROC and AOC to your acquirer and card brands as required. Establish quarterly scan schedule and annual audit calendar. Optional: retainer for continuous compliance monitoring, quarterly internal assessments, staff re-training and regulatory update tracking.

Your Complete PCI DSS Deliverable Set

Every engagement produces audit-ready documents and evidence artefacts that you retain permanently — not just a compliance certificate that expires.

CDE Scoping DocumentNetwork diagram, data flow maps, in/out-of-scope system inventory
PCI DSS v4.0 Gap ReportAll 259 sub-requirements assessed, gaps prioritised by risk and effort
Remediation RoadmapSequenced action plan with owner, timeline and effort for each gap
PCI Policy SuiteAll Req 12 policies — ISP, AUP, IR plan, vendor management, risk assessment
SAQ CompletionCorrect SAQ type completed with documented evidence for every control
ROC PreparationFull evidence pack for Level 1 ROC or where ROC is contractually required
ASV Scan CoordinationQuarterly external scan setup, tracking and finding remediation guidance
Penetration Test ScopeDefined scope document for internal, external and segmentation pen test
Script Inventory (Req 6.4.3)Payment page script register with integrity method and business justification
Attestation of Compliance (AOC)Completed AOC for acquirer/card brand submission
Security Awareness TrainingStaff training satisfying Req 12.6 with attendance records and certificates
Cryptographic InventoryReq 12.3.3 compliant cipher suite and protocol register with migration plan

Industries & Entity Types

  • E-commerce merchants — online retailers, D2C brands, subscription platforms accepting card payments
  • Payment aggregators & gateways — entities processing card data on behalf of merchants (RBI PA/PG licensees)
  • Fintech & lending platforms — payment-enabled apps, BNPL providers, neo-banks with card issuance or acceptance
  • Retail & hospitality — physical POS merchants, hotel chains, restaurant groups with card terminals
  • SaaS with embedded payments — platforms that integrate Stripe, Razorpay, PayU or similar and may be in scope as service providers
  • Healthcare billing — hospitals and clinics accepting card payments at reception or online
  • Travel & ticketing — OTAs, airlines, ticketing portals processing high card transaction volumes
  • Service providers — hosting providers, managed service companies, cloud platforms that store or process card data for clients

PCI DSS + ISO 27001 together: If you're also pursuing ISO 27001, combining both programmes under one engagement reduces effort by 30–40%. Shared policies, shared risk assessment, shared internal audit — one programme, two certifications. Explore ISO 27001 →

Start Your PCI DSS Programme →

Ready to Achieve PCI DSS v4.0 Compliance?

Whether you're a Level 4 merchant completing your first SAQ, a fintech navigating RBI's PA/PG guidelines, or a Level 1 processor preparing for a full QSA ROC — we bring the expertise to get you there efficiently and confidently.