PCI DSS Compliance Deepdive

1. Overview

What PCI DSS Is

The Payment Card Industry Data Security Standard (PCI DSS) is a global information security standard maintained by the PCI Security Standards Council (PCI SSC). It applies to any organization that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD), or that can impact the security of the cardholder data environment (CDE). The current version is PCI DSS v4.0.1, published in June 2024 as a clarifying revision to v4.0. Compliance with v3.2.1 ended on 31 March 2024; the future-dated v4.0 requirements became mandatory on 31 March 2025.

Who It Applies To

Merchants, service providers, payment processors, acquirers, issuers, gateways, and any vendor that touches cardholder data on behalf of a merchant. Applicability is independent of company size — a small e-commerce site that accepts cards is in scope, as is a global processor handling billions of transactions.

Outcome

• Self-Assessment Questionnaire (SAQ) — for merchants and service providers below volume thresholds. Nine SAQ types (A, A-EP, B, B-IP, C, C-VT, D-Merchant, D-Service Provider, P2PE) match common card-acceptance channels.
• Report on Compliance (ROC) — produced by a Qualified Security Assessor (QSA) or an Internal Security Assessor (ISA) for Level 1 merchants and Level 1 / Level 2 service providers. The ROC is the full assessment document; an Attestation of Compliance (AOC) summarizes the result for relying parties.

PCI DSS is not a government regulation — it is a contractual obligation imposed by the card brands (Visa, Mastercard, American Express, Discover, JCB) via acquiring banks. Non-compliance is enforced through fines, increased transaction fees, and ultimately suspension of card-acceptance privileges.

High-Level Goals

• Protect cardholder data wherever it is stored, processed, or transmitted
• Reduce the scope of the cardholder data environment through segmentation and tokenization
• Maintain a vulnerability management program and continuous monitoring
• Demonstrate operating effectiveness of controls on an annual cadence

Security Consultants delivers PCI DSS readiness, scope reduction strategy, and ongoing program management through the PCI DSS compliance service. The QSA-issued ROC and the Approved Scanning Vendor (ASV) external scans are performed by third parties — we coordinate and prepare clients for both.

2. Scope & Applicability

What Is In Scope

• Any system component that stores, processes, or transmits CHD or SAD
• Any system component that is connected to or can impact the security of the CDE (so-called "connected-to" or "security-impacting" systems)
• Network devices, servers, applications, virtualization platforms, and cloud workloads within the CDE
• People with logical or physical access to the CDE
• Service providers that process, store, or transmit CHD on behalf of the entity (third-party risk management is a v4.0 focus area)

What Can Be Out of Scope

• Systems that have no connectivity to the CDE and cannot impact its security
• Properly segmented network zones (validated by penetration testing under Requirement 11.4.5 for service providers, 11.4.6 for merchants)
• Outsourced functions where a service provider has provided their own AOC covering the relevant requirements

Segmentation

Segmentation is the primary tool for scope reduction. PCI DSS does not require segmentation, but unsegmented networks place every connected system in scope. Segmentation must be verified by penetration testing at least every 12 months for service providers and at least every 24 months for merchants, plus after any significant change.

Cardholder Data vs Sensitive Authentication Data

• CHD: Primary Account Number (PAN), cardholder name, expiration date, service code. Can be stored if properly protected.
• SAD: full track data, CAV2/CVC2/CVV2/CID, PIN/PIN block. Must not be stored after authorization, even encrypted.

Reporting Levels

• Merchant Level 1: more than 6 million transactions per brand per year — annual ROC by QSA, quarterly ASV scans.
• Merchant Levels 2 / 3 / 4: SAQ matched to acceptance channel, quarterly ASV scans where applicable.
• Service Provider Level 1: more than 300,000 transactions per brand per year — annual ROC by QSA.
• Service Provider Level 2: fewer than 300,000 — SAQ D for Service Providers.

Customized Approach

PCI DSS v4.0 introduced the customized approach alongside the traditional defined approach. Defined approach uses the specified testing procedures verbatim. Customized approach allows an entity to design alternative controls to meet a stated Customized Approach Objective, validated by a QSA using a Controls Matrix and a Targeted Risk Analysis. Customized approach is unavailable to SAQ filers and adds assessment effort, but it gives mature entities flexibility to use modern architectures (for example, ephemeral compute or service mesh telemetry) that may not align cleanly to the original requirement wording.

3. Core Principles

PCI DSS organizes 12 high-level requirements into six control objectives. v4.0.1 contains around 300 base requirements, expanding to over 500 sub-requirements when applicability notes and testing procedures are counted.

Build and Maintain a Secure Network and Systems — Requirements 1 and 2 cover network security controls (firewalls, NSCs) and secure configuration of system components.

Protect Account Data — Requirements 3 and 4 cover stored account data protection (strong cryptography, key management, retention limits) and transmission security (TLS, end-to-end encryption).

Maintain a Vulnerability Management Program — Requirements 5 and 6 cover anti-malware and secure software development, including the new v4.0 emphasis on threat modeling and authenticated vulnerability scanning.

Implement Strong Access Control Measures — Requirements 7, 8, and 9 cover role-based access, identity and authentication (MFA on all access into the CDE under v4.0), and physical access.

Regularly Monitor and Test Networks — Requirements 10 and 11 cover logging, monitoring, vulnerability scans, segmentation testing, and penetration testing.

Maintain an Information Security Policy — Requirement 12 covers governance, risk assessment, third-party risk, incident response, and the Targeted Risk Analysis program new in v4.0.

4. Control Breakdown

Requirement 1 — Network Security Controls

Purpose: Restrict inbound and outbound traffic to that which is necessary for the CDE.
Minimum Expectations: Documented network security control rulesets reviewed at least every six months; default-deny posture; documented data-flow diagrams covering all CHD flows.
Evidence: Firewall and security-group configurations, ruleset review records, network diagrams, data-flow diagrams.
Common Gaps: Stale firewall rules, missing data-flow diagrams, lateral CDE access from corporate networks.

Requirement 2 — Secure Configurations

Purpose: Eliminate vendor defaults and harden system components.
Minimum Expectations: Configuration standards aligned with an industry source (CIS, vendor benchmarks); inventory of system components; documented exceptions.
Evidence: Hardening checklists, configuration management tooling exports, asset inventory.

Requirement 3 — Protect Stored Account Data

Purpose: Minimize stored PAN and protect what must be stored.
Minimum Expectations: Documented data retention and disposal policy; PAN rendered unreadable (truncation, tokenization, strong cryptography); SAD never stored post-authorization; documented key management lifecycle (3.6, 3.7).
Evidence: Data discovery scans, key inventory, KMS configurations, retention schedule attestations.
Common Gaps: PAN found in support tickets, application logs, or backups outside the CDE — a frequent finding that expands scope unexpectedly.

Requirement 4 — Protect Cardholder Data in Transit

Purpose: Prevent interception across open public networks.
Minimum Expectations: TLS 1.2 or higher with strong cipher suites; documented certificate inventory; protection of PAN sent via end-user messaging technologies.
Evidence: TLS configuration scans, certificate inventories, messaging policy.

Requirement 5 — Anti-Malware and Phishing Defenses

Purpose: Detect and prevent malicious software.
Minimum Expectations: Anti-malware solution on systems "commonly affected by malicious software" (v4.0 wording is risk-based, not blanket); periodic evaluation; v4.0 adds explicit anti-phishing controls (5.4.1).
Evidence: Coverage reports, alert handling tickets, email gateway configurations.

Requirement 6 — Develop and Maintain Secure Systems and Software

Purpose: Protect against software vulnerabilities throughout the SDLC.
Minimum Expectations: Documented secure SDLC; v4.0 adds payment-page integrity controls (6.4.3) and a documented inventory of bespoke and custom software with a process to identify vulnerabilities (6.3.2); manage public-facing web-app vulnerabilities (6.4.1, 6.4.2).
Evidence: SDLC procedures, code review records, SAST/DAST outputs, payment-page Content Security Policy.
Common Gaps: Payment-page skimming controls (Magecart-class) underdeveloped — a v4.0 emphasis. See our penetration testing service for authenticated web application testing.

Requirement 7 — Restrict Access by Business Need to Know

Purpose: Enforce least privilege.
Minimum Expectations: Role-based access control; documented access matrix; reviewed at least every six months (v4.0 requirement 7.2.4).
Evidence: Access review attestations, role definitions, ticket-based provisioning.

Requirement 8 — Identify Users and Authenticate Access

Purpose: Unique identification and strong authentication.
Minimum Expectations: Unique IDs; MFA for all access into the CDE (8.4.2, future-dated to 31 March 2025); 12-character password minimum if passwords are used as the only factor (8.3.6); periodic re-authentication for system or application accounts (8.6).
Evidence: IdP configuration, MFA enrolment reports, password policy.

Requirement 9 — Restrict Physical Access

Purpose: Limit physical access to CDE and media.
Minimum Expectations: Visitor logs, badge controls, media handling and destruction, POI device inventory and tamper inspections (9.5).
Evidence: Facility logs, media disposal records, POI inspection logs.

Requirement 10 — Log and Monitor All Access

Purpose: Detective control through comprehensive audit logging.
Minimum Expectations: Log content per 10.2; log retention at least 12 months with three months immediately available; daily review automated where possible (10.4.1.1, v4.0); time synchronization across components.
Evidence: SIEM rule inventory, log retention configurations, daily review tickets.

Requirement 11 — Test Security Regularly

Purpose: Validate that controls work.
Minimum Expectations: Quarterly internal and external vulnerability scans; external scans by an ASV; annual penetration test (internal and external) with segmentation testing per scope; v4.0 adds authenticated internal scans (11.3.1.2) and payment-page change detection (11.6.1).
Evidence: ASV scan reports, pentest reports, segmentation test results, payment-page integrity logs.

Requirement 12 — Maintain an Information Security Policy

Purpose: Governance, risk, and third-party management.
Minimum Expectations: Annually-reviewed information security policy; documented roles and responsibilities; annual risk assessment; Targeted Risk Analyses for any flexibility used under v4.0 (12.3.1, 12.3.2); third-party service provider monitoring (12.8, 12.9); incident response plan tested annually.
Evidence: Policies, risk assessments, vendor inventory and AOCs, IR plan and tabletop records.
Mapping: Substantial overlap with ISO 27001 ISMS, particularly Clauses 6.1, 7.5, and 8.1. See our risk assessment service for the targeted risk analyses required by v4.0.

5. Minimum Requirements (Non-Negotiable)

Mandatory Documents

• Scope definition and CDE diagram
• Network diagram showing all in-scope components
• Data flow diagrams covering every CHD flow
• Information security policy and supporting policies
• Configuration and hardening standards per system type
• Risk assessment and Targeted Risk Analyses (v4.0)
• Incident response plan
• Vendor inventory with AOCs and responsibility matrix
• Inventory of bespoke and custom software (6.3.2)
• Cryptographic key inventory and key management procedures

Mandatory Processes

• Quarterly external ASV scans (passing)
• Quarterly internal vulnerability scans (authenticated under v4.0)
• Annual internal and external penetration testing with segmentation validation
• Six-monthly firewall ruleset review and user access review
• Annual risk assessment and IR tabletop
• Continuous monitoring and daily log review
• Annual security awareness training plus targeted training for developers and incident responders

Technical Controls (Baseline)

• MFA on all access into the CDE
• Strong cryptography for PAN at rest and in transit
• Hardened, monitored network boundaries
• Comprehensive logging and SIEM correlation
• Endpoint protection on relevant system components
• Web application protections including payment-page integrity monitoring

Recurrence

• Quarterly: ASV scans, internal scans
• Six-monthly: firewall rule reviews, access reviews
• Annual: penetration test, ROC or SAQ, risk assessment, IR tabletop, policy review
• Continuous: monitoring, vulnerability remediation

6. Technical Implementation Guidance

Scope Reduction

• Tokenize PAN at the earliest point of capture and remove cleartext PAN from downstream systems
• Use a payment gateway iframe or hosted payment page to keep your application outside the CDE where possible (SAQ A model)
• Segment the CDE with hardware or cloud network controls validated by independent penetration testing

Cardholder Data Discovery

• Run authenticated data-discovery scans across file shares, databases, mailboxes, ticketing systems, and developer environments
• Document remediation for any PAN found outside the CDE and re-scan after remediation
• Repeat at least annually

Cryptography

• Use NIST-approved algorithms (AES-256, RSA-3072, ECDSA P-256)
• Manage keys with a documented lifecycle: generation, distribution, storage, rotation, retirement, destruction
• Use a managed KMS (AWS KMS, Azure Key Vault, GCP KMS) or HSM where feasible
• Implement key custodian acknowledgement (3.7.3)

Access Control

• Enforce MFA at the identity provider for all CDE access including administrators
• Avoid shared accounts; where unavoidable, document justification and monitor
• Disable service accounts that don't need interactive login and rotate credentials per documented schedule

Monitoring

• Centralize logs from CDE network devices, servers, applications, IDPS, and identity providers
• Configure alerts on critical events: privilege escalation, log tampering, anti-malware disablement, payment-page modification
• Time-sync all components to a validated NTP source

Vulnerability and Patch Management

• Rank vulnerabilities by severity and remediate critical and high within 30 days (6.3.3 risk-based)
• Track service-provider patches and pre-staged remediation for unsupported components
• Use authenticated scanning for internal targets

7. Policy & Procedure Requirements

Typical PCI DSS document set:

• Information Security Policy
• Acceptable Use Policy
• Access Control Policy
• Cryptography and Key Management Policy
• Configuration and Hardening Standards
• Network Security Standard
• Logging, Monitoring, and Alerting Standard
• Vulnerability and Patch Management Procedure
• Secure Software Development Standard
• Data Retention and Disposal Policy
• Third-Party Risk Management Policy
• Incident Response Plan
• Targeted Risk Analysis register (v4.0)
• Business Continuity and Disaster Recovery Plan
• Annual Risk Assessment Procedure

Each must define scope, ownership, review frequency, and link to the underlying technical control. For dual-standard programs combining PCI DSS with ISO 27001 or SOC 2, most policies serve both standards with minor scope additions.

8. Audit Evidence & Verification

QSAs assess each requirement using the testing procedures in the standard. For each control, they expect to see policy, supporting procedure, configuration evidence, and evidence of operating effectiveness over the assessment period.

Typical Evidence Categories

• Documentation: policies, procedures, network and data-flow diagrams, scope statement, risk assessment, Targeted Risk Analyses
• Configuration: firewall rules, hardening exports, IAM exports, KMS configurations, SIEM rule sets
• Observations: walk-throughs of administrative actions, payment-page demonstrations, segmentation tests
• Records: ASV scan reports, penetration test reports, change tickets, incident records, daily log review tickets, training completion
• Interviews: with administrators, developers, incident responders, vendor managers

Sampling

QSAs sample system components, users, and time periods. Sample sizes scale with population; for large populations a typical sample is 25 plus a coverage justification across system types and geographies.

Common Remediation Items

• PAN discovery findings outside the CDE
• Incomplete data flow diagrams
• Stale firewall rules without business justification
• Missing Targeted Risk Analyses for any flexibility used
• Payment-page integrity controls not yet implemented
• Insufficient evidence of daily log review
• Service provider AOCs missing or stale

Independent pre-assessment review through our internal audit service or readiness review catches these before the QSA arrives.

9. Implementation Timeline Considerations

Typical Duration

• First-time ROC (mature controls): 4–6 months from kickoff to ROC issuance
• First-time ROC (substantial remediation): 9–18 months including scope reduction, tokenization rollout, and v4.0 future-dated control implementation
• SAQ A or A-EP: 4–8 weeks if architecture aligns to a hosted payment page
• Annual recertification: 6–10 weeks of QSA fieldwork plus continuous evidence collection

Milestones

• Scope and PAN discovery
• Gap assessment against v4.0.1
• Scope reduction design (tokenization, segmentation)
• Control remediation
• Evidence collection and policy completion
• ASV scan readiness
• Penetration test and segmentation test
• QSA fieldwork and ROC drafting
• AOC issuance and acquiring bank submission

Dependencies

• Cooperation from payment gateway and tokenization vendor
• Network and cloud platform team capacity for segmentation work
• Development team capacity for payment-page integrity and bespoke software inventory
• vCISO or program lead to coordinate evidence collection (see vCISO service)

10. Ongoing Security BAU Requirements

• Quarterly ASV scans submitted via the acquirer portal
• Quarterly internal authenticated scans with remediation tracking
• Daily log review and SIEM alert handling
• Six-monthly firewall ruleset and access reviews
• Continuous payment-page integrity monitoring
• Annual penetration test and segmentation validation
• Annual risk assessment, Targeted Risk Analysis refresh, and policy review
• Annual IR tabletop and BCP test
• Vendor AOC tracking and renewal monitoring
• Cardholder data discovery at least annually and after material change

11. Maturity Levels

Minimum Compliance

• Defined approach used throughout
• SAQ filed where eligible; ROC where required
• Manual evidence collection and quarterly remediation cycles
• Baseline tooling for scans, logging, and MFA

Intermediate

• Tokenization rolled out; PAN largely removed from internal systems
• Centralized SIEM with correlation rules tuned for CDE events
• Continuous configuration validation (Terraform + policy as code)
• Documented Targeted Risk Analyses supporting flexibility

Advanced

• Customized approach used for selected requirements with QSA-validated Controls Matrices
• Continuous compliance posture, evidence collected automatically
• End-to-end encryption (P2PE) where applicable
• Integrated PCI DSS, SOC 2, and ISO 27001 evidence collection with shared control library

12. FAQs

Is PCI DSS mandatory?

PCI DSS is not a government regulation, but compliance is required by the card brands through the acquiring bank. Non-compliance carries fines, increased transaction fees, and ultimately suspension of card acceptance. Several US states have also incorporated PCI DSS by reference in data protection statutes.

What version applies right now?

PCI DSS v4.0.1, published in June 2024 as a clarifying revision to v4.0. v3.2.1 was retired on 31 March 2024 and v4.0 future-dated requirements became mandatory on 31 March 2025. Any assessment performed today must be against v4.0.1.

Who issues my Report on Compliance?

A QSA (Qualified Security Assessor) firm listed on the PCI SSC website, or an Internal Security Assessor (ISA) for entities with an in-house ISA program. Security Consultants is not a QSA firm — we prepare clients for the QSA assessment, manage scope and remediation, and represent the program through fieldwork.

Do we need quarterly ASV scans?

If you have any externally-facing system component in the CDE, yes. ASV scans are performed by an Approved Scanning Vendor listed on the PCI SSC website. Internal scans must also be quarterly and, under v4.0, authenticated where feasible.

What is the difference between SAQ and ROC?

SAQ is a self-assessment questionnaire eligible at lower transaction volumes and for specific acceptance channels (nine SAQ types). ROC is a formal report produced by a QSA or ISA against the full set of requirements, required for Level 1 merchants and Level 1 / Level 2 service providers.

What is the customized approach in v4.0?

An alternative to the defined approach. For applicable requirements, the entity designs its own controls to meet a stated Customized Approach Objective, documents a Targeted Risk Analysis, and produces a Controls Matrix that the QSA validates. Customized approach is unavailable to SAQ filers and increases QSA effort.

How do we reduce scope?

The two most effective levers are tokenization (replace PAN with a non-sensitive token outside the CDE) and segmentation (isolate the CDE so unrelated systems cannot reach it). A hosted payment page or iframe-based capture can take a merchant site out of scope for most cardholder data requirements (SAQ A model).

What does PCI DSS cost?

Costs split into QSA fees, ASV fees, penetration testing, and consulting. For a first-time mid-market ROC, expect total program costs in the range of $80,000–$250,000 across the first year depending on remediation scope. Annual recertification typically runs 50–70 percent of year one once controls are operating.

Can we use the same controls for ISO 27001 and PCI DSS?

Yes — substantial overlap exists, particularly across Requirements 1, 2, 6, 7, 8, 10, 11, and 12. A shared ISMS supports both standards with PCI-specific extensions for tokenization, payment-page integrity, ASV scans, and the customized approach documentation.

What happens if we have a breach involving cardholder data?

Notify your acquirer immediately, engage a PCI Forensic Investigator (PFI) from the PCI SSC list, preserve evidence, and follow your incident response plan. Card brands may impose fines and require an enhanced ROC for several years following the incident.

How does PCI DSS relate to PCI PIN, P2PE, and 3DS?

These are separate PCI SSC standards for specific scenarios — PIN entry devices, point-to-point encryption solutions, and 3-D Secure access control servers. They share infrastructure and principles with PCI DSS but are assessed separately. Achieving P2PE often dramatically reduces the merchant's PCI DSS scope.

13. Summary

PCI DSS v4.0.1 is the governing standard for any organization that touches cardholder data. Compliance is a multi-year program built on disciplined scope management, strong cryptography, continuous monitoring, and annual independent validation by a QSA or through an SAQ filing. The v4.0 changes — MFA into the CDE, payment-page integrity, authenticated internal scanning, Targeted Risk Analyses, and the customized approach — raise the bar for control sophistication while opening more flexibility for mature programs.

To scope an engagement, book a call from the PCI DSS compliance service page, or talk to us about combining PCI DSS with ISO 27001, SOC 2, or a complete vCISO program for ongoing program management. For penetration testing aligned with PCI DSS requirements 11.4.x, see our penetration testing service.