PCI DSS and payment data security. 8 chapters and a final quiz.

Chapter 1. Origins of PCI DSS and the data it protects.

PCI DSS (Payment Card Industry Data Security Standard) is the global security standard for payment card data. It is not a law but a contractual obligation. The card networks (Visa, Mastercard, Amex, Discover, JCB) impose it, through acquiring banks and PSPs, on every entity that stores, processes, or transmits card data, from a bakery’s kiosk to the largest e-commerce players. The standard is published and maintained by the PCI Security Standards Council (PCI SSC), founded in 2006 by the five networks to unify their separate security programs.

Two data categories: CHD and SAD

The standard distinguishes two categories. The first is cardholder data (CHD), which may be stored under strict conditions. Storing sensitive authentication data (SAD) after authorization is prohibited under all circumstances, even if encrypted.

PCI DSS works alongside legal frameworks but does not replace them. A PAN leak is almost always also a personal data breach under the GDPR. The competent supervisory authority, the CNIL in France, must then be notified within 72 hours. Critical European operators must also comply with NIS2. PCI compliance does not exempt you from any legal obligation, and non-compliance found at the time of a compromise always makes the bill bigger.

Chapter 2. Scope: the CDE, connected systems, and segmentation.

The CDE (cardholder data environment) comprises the people, processes, and technologies that store, process, or transmit CHD or SAD. PCI DSS scope does not stop at the CDE. It also includes systems connected to the CDE and systems that can affect its security, even if they never see a PAN. Overlooking them remains the most common scoping error, and the costliest one in an audit.

• In the CDE: payment servers, databases storing PANs, card terminals and POI devices, POS software, contact center call recorders, network traffic carrying CHD.
• Same network segment: any component that shares an unfiltered segment with the CDE is de facto in scope, even if it never touches card data.
• Connected systems: directory services (Active Directory), DNS, NTP, patch servers, centralized antivirus, monitoring, backups. They “talk” to the CDE.
• Security-impacting systems: administrative jump hosts, hypervisors hosting CDE virtual machines, orchestrators, CI/CD pipelines that deploy payment code, secrets management tools.
• Third parties: hosting providers, managed service providers, PSPs. Their compliance must be monitored under contract (12.8), and their share of responsibility documented in a responsibility matrix.

Version 4.0.x settles a point of principle: scoping is no longer an implicit best practice but a tested requirement. The entity must prove every year that it has confirmed its scope, and the assessor must verify it. An understated scope discovered during an audit can invalidate an entire compliance cycle.

Chapter 3. The 12 requirements of v4.0.x.

The 12 requirements fall under six goals: build and maintain a secure network (1–2), protect account data (3–4), manage vulnerabilities (5–6), control access (7–9), monitor and test (10–11), and govern security (12). Behind these 12 headings sit roughly 250 to 300 testable controls, many of which v4.0.x has tightened. The table below walks through them from a practitioner’s perspective.

Defined approach or customized approach

Version 4.0 offers two ways to meet a requirement. The defined approach implements the control as written and tests it against the standard’s testing procedures. The customized approach lets the entity design a different control that meets the stated security objective. The entity documents the control and performs a targeted risk analysis, and the assessor then designs its own testing procedures. It is a powerful tool for mature organizations, but it demands a lot of evidence.

• Theme 1, authentication: MFA everywhere into the CDE, resistant to replay and bypass (8.4.2, 8.5.1), and passwords of 12 characters or more.
• Theme 2, e-skimming: together, 6.4.3 and 11.6.1 go straight after payment page compromises (covered in a dedicated chapter below).
• Theme 3, continuous compliance: TRAs to justify frequencies, detection of control failures, documented reviews. The “annual snapshot” gives way to an ongoing process (BAU, business as usual).

Chapter 4. Merchant levels and validation: SAQ, ROC, AOC.

Everyone must be compliant, but not everyone proves it the same way. The networks sort merchants into four levels by annual transaction volume. The level determines how compliance is validated: either an on-site audit resulting in a ROC (Report on Compliance) signed by a QSA (Qualified Security Assessor) or an internal ISA, or a self-assessment using an SAQ (Self-Assessment Questionnaire). Either way, an AOC (Attestation of Compliance) goes to the acquirer.

Service providers (PSPs, hosting providers, processors, token vault operators) follow a two-level scale. Above 300,000 transactions processed, an annual ROC is mandatory. Providers can then be listed on the Visa and Mastercard registries of compliant service providers, which is as much a selling point as an obligation.

Choosing your SAQ: match it to how you accept payments

In practice, your acquirer (or PSP) has the final word on which SAQ applies and how often you must provide evidence. If you are torn between two SAQs, document your eligibility reasoning: it is the first document requested after an incident.

Chapter 5. Reducing scope: tokenization, iframes, redirects, P2PE.

The best security control is not holding the data at all. Modern PCI compliance strategy moves card data to specialists (PSPs, P2PE providers, token vaults), turning an SAQ D project with 250+ controls into an SAQ A of about 30 questions. Four levers dominate.

Tokenization comes in two types. Vault tokens are issued by your PSP. They are ideal for one-click payments and subscriptions, but they lock you in to that PSP. Network tokens (Visa VTS, Mastercard MDES) are issued by the card networks. They follow the card (updating automatically when it is reissued), are portable across acquirers, and improve authorization rates. Either way, a token outside the CDE is not card data, and that shift is the whole point.

P2PE: validated point-to-point encryption

A PCI-validated P2PE solution encrypts data the moment it is captured in an approved terminal (the SRED function of PTS devices), under strict key management. Key management usually relies on DUKPT, with a unique key derived for each transaction. Decryption happens only in an HSM within the provider’s secure environment, so the merchant cannot technically access cleartext data, and its POS systems, network, and back office drop out of scope. One caveat: a home-grown E2EE solution that is not listed by the PCI SSC does not qualify for SAQ P2PE, and any scope reduction is then at the acquirer’s discretion.

Chapter 6. 6.4.3 and 11.6.1: countering Magecart web skimming.

Magecart refers to a loose constellation of criminal groups specializing in digital skimming. They inject a few lines of JavaScript into a payment page to copy card data as the customer types it, then exfiltrate it to a third-party server. The attack is invisible to the merchant (the transaction completes normally) and to the customer (the page looks untouched). The attack vectors are well known: compromise of the site itself and, above all, the third-party script supply chain, where a tag manager, chatbot, review widget, or analytics script is modified at the source.

Requirement 6.4.3: governing scripts

• A complete inventory of all scripts loaded and executed in the consumer’s browser on payment pages, including third-party scripts and the dependencies they load in turn.
• Written justification for why each script is needed: any script without a documented purpose must go.
• Authorization: a mechanism (process plus technology) ensures that only approved scripts can be added.
• Integrity: a method ensures that each script has not been tampered with (SRI, CSP, or a dedicated monitoring solution).

Requirement 11.6.1: detecting tampering

A change- and tamper-detection mechanism must alert on any unauthorized modification to security-impacting HTTP headers (notably the CSP). It also covers the contents of payment page scripts as received by the consumer’s browser. The key word is “received”: what must be monitored is what the client actually renders, not just the files on the server. It must run at least weekly, or at the frequency defined by a targeted risk analysis (TRA).

<!-- HTTP header: restrictive CSP on the payment page -->
Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://js.psp-example.com;
  frame-src https://checkout.psp-example.com;
  connect-src 'self' https://api.psp-example.com;
  report-uri https://csp-report.merchant-example.com/collect

<!-- Integrity check (SRI) for a versioned third-party script -->
<script
  src="https://js.psp-example.com/v3/checkout.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6R9GqQ8KvuXy9rx7HNQlGYl1kPzQho1wxJwY8wC7q"
  crossorigin="anonymous"></script>

In practice, merchants layer several defenses. The CSP runs in blocking mode, with violation reporting (report-uri). SRI covers versioned scripts but does not work for PSPs’ self-updating scripts, which is why dedicated domains allowlisted in the CSP matter. Payment page monitoring tools replay a purchase journey through synthetic crawling and compare the scripts received, backed by real-time DOM monitoring. Even with a PSP iframe (SAQ A), the parent page can be hijacked to overlay a fake form: vigilance can never be fully delegated.

Chapter 7. Proving resilience: ASV scans and penetration testing.

Requirement 11 mandates an ongoing testing cycle on two complementary fronts: vulnerability scans (automated, broad, frequent) and penetration tests (manual, deep, scenario-based). Confusing the two is a classic cause of non-compliance.

An ASV (Approved Scanning Vendor) is a provider approved by the PCI SSC, and only an ASV can produce acceptable external scans. Discipline matters as much as technology: four passing scans a year, dated, with rescans until blocking findings are eliminated. A missed quarter cannot be made up after the fact.

Penetration testing (11.4)

• Frequency: at least annually and after any significant infrastructure or application change or upgrade.
• Scope: external and internal, network layer and application layer (with OWASP as the reference), covering the entire CDE and its critical entry points.
• Documented methodology: an industry-recognized approach, a qualified tester who is independent of the team operating the systems tested, and written rules of engagement.
• Segmentation: controls isolating the CDE are tested at least once a year (merchants) and every six months (service providers), per 11.4.5/11.4.6.
• Remediation: exploitable vulnerabilities found are fixed and then retested.

Chapter 8. Incidents, notification, and the real cost of non-compliance.

Requirement 12.10 calls for an operational incident response plan with defined roles and contacts, 24/7 availability, scenario-specific procedures, testing of the plan at least once a year, and staff training. Version 4 adds dedicated procedures for when a PAN is found where it should not be, such as in rogue exports, logs, or tickets (12.10.7). When an incident hits, improvising costs millions.

The cost of non-compliance