PCI DSS v4.0.1 · Cardholder data scope

§ I · The standard

What PCI DSS actually is, in plain English.

PCI DSS is a contractual standard: not a federal law, not a certification framework. It is published by the PCI Security Standards Council, a body founded in 2006 by the five major card brands (Visa, Mastercard, American Express, Discover, JCB), and enforced through a contractual chain: card brand → acquiring bank → merchant or service provider. The current version is v4.0.1, published June 2024 as a clarifying revision of v4.0; v3.2.1 retired on March 31, 2024. There is no PCI logo for merchants. There is the standard, your acquirer’s reporting requirement, and the brand fines that follow non-compliance.

The standard is structured as twelve requirements grouped into six control objectives: build & maintain a secure network; protect cardholder data; maintain a vulnerability management program; implement strong access control; regularly monitor & test; maintain an information-security policy. Underneath the twelve are roughly 300 sub-requirements, each with a defined approach (prescriptive control text) and, new in v4, a customized approach: you may meet the control objective via an alternative method if you document a targeted risk analysis. The customized approach is powerful and dangerous; QSAs scrutinize it heavily.

What pulls you into PCI scope is one act: storing, processing, or transmitting cardholder data, or being able to affect its security. That definition is broader than people think: iframes, redirects, call-center recordings, support agents reading numbers off the screen, log files that capture failed checkouts. The cardholder data environment (CDE) is the systems, people, and processes that touch CHD plus anything connected to them. Scope is the lever that decides everything else: SAQ vs ROC, control burden, QSA fees, and how often the standard hurts.

Senior practitioner's note

If your CDE is the whole production network, you don’t have a PCI program. You have a PCI tax.

The single most consequential decision in any PCI engagement is made before the first control is written: what is in scope and what is not. Done well, scope reduction shrinks the CDE to a handful of segmented systems, drops the SAQ category two letters, and cuts the QSA assessment fee by 40-70%. Done badly: or not done at all: you spend three years applying enterprise-grade controls to systems that should never have been in scope, and re-spend it every year. Cardholder data is more like a toxic asset than a strategic one. Touch as little as possible. Tokenize, redirect, outsource. Then defend the perimeter you’re left with.

§ II · Scope & level decoder

What level are you, and which SAQ applies?

PCI levels are set by your acquirer, mostly by annual transaction volume. The level decides validation method: SAQ vs ROC. The SAQ category decides which subset of the 12 requirements applies. Both decisions hinge on how you take payments, not just how much.

Interactive · 3 questions

PCI scope check

1. How do you accept card payments?

2. Annual card transactions across all channels?

3. Are you a merchant or a service provider (process / store / transmit on behalf of others)?

Answer above: we’ll tell you the SAQ category, the validation route, and where scope can probably be reduced.

§ III · The standard

The twelve requirements: grouped by what they actually do.

All twelve apply to every entity in scope of a ROC. SAQs cherry-pick a subset based on payment channel. We group them here as we group them in engagements: the five operational families QSAs walk through. Tap each tab for the in-scope sub-requirements and the artifact a QSA will ask for.

RequiredReqs 1–2: Build & maintain a secure network

Network segmentation lives here. This is where scope is won or lost. Done right, segmentation is the load-bearing wall of a small CDE; done wrong, every Wi-Fi access point and dev VLAN is in scope. Defaults must be eliminated; QSAs test them.

Req 1.2

Network security controls (NSCs)

Documented network diagram showing all CHD flows; NSC ruleset reviewed every 6 months; ingress / egress restrictions to / from CDE; deny-by-default.

Req 1.3

CDE isolation

Inbound traffic to CDE limited to necessary ports / protocols / sources. Outbound restricted. Anti-spoofing implemented. Public-facing DMZ separates internet from internal.

Req 1.4

Trusted / untrusted networks

All connections between CDE and untrusted networks (incl. corporate LAN, if not segmented) controlled. Segmentation testing every 6 months for service providers.

Req 2.2

Configuration standards

Hardening standards per system type (CIS / vendor benchmarks). Vendor defaults removed. Single primary function per server (or virtualized equivalent).

Req 2.3

Wireless

Defaults changed (SSID, keys, SNMP). Strong cryptography. Wireless connected to CDE detected and inventoried.

RequiredReqs 3–4: Protect cardholder data

Storage minimization, masking, key management, encryption in transit. SAD (sensitive authentication data: CVV, full track, PIN) cannot be stored after authorization: period. If you find SAD in logs, you have a problem you must surface to your acquirer, not bury.

Req 3.2

SAD storage prohibition

Sensitive authentication data not stored after authorization. Full track, CAV2/CVC2/CVV2/CID, PIN/PIN block all prohibited. Log scrubbing required.

Req 3.3

PAN masking

PAN masked when displayed (max first 6 / last 4); full PAN visible only with documented business need. Service-provider stricter requirements.

Req 3.5

PAN protection at rest

Strong cryptography (AES-256 / equiv); hashing must be keyed (HMAC); truncation; tokenization. Disk-level encryption alone does not satisfy at the application layer.

Req 3.6–3.7

Cryptographic key management

Documented KMS lifecycle: generation, distribution, storage, retirement, escrow. Split knowledge / dual control for clear-text key components. Key changes annually.

Req 4.2

Transmission encryption

Strong cryptography & protocols protecting CHD over open / public networks. TLS 1.2+ minimum. Trusted-key inventory. End-user messaging tech (email, IM) must not transmit unprotected PAN.

RequiredReqs 5–6: Vulnerability management & secure SDLC

Anti-malware, patching cadence, secure software development. v4 introduced custom & bespoke software requirements that real engineering organizations actually have to read. Threat modeling, code review, separation of dev/test/prod: the things mature shops do anyway, now mandated.

Req 5.2–5.3

Anti-malware

Deployed on all systems commonly affected. Mechanism kept current. Periodic scans + active scanning. Logs retained.

Req 6.2

Bespoke / custom software

SDLC w/ security training; threat modeling; secure coding practices; code review of all custom code; deps inventoried with vuln tracking.

Req 6.3

Vulnerability identification

Vuln-rank process. CVE / advisory monitoring. Critical / high vulns patched within one month.

Req 6.4

Public-facing web apps

WAF or app-vuln review at least annually + after material change. v4 future-dated 6.4.3 / 11.6.1: payment-page script integrity (e-skimming).

Req 6.5

Change management

Documented change-control procedures; security impact assessment; rollback; separation of dev/test/prod; PAN never used in non-prod.

RequiredReqs 7–9: Strong access control

Logical access (Req 7), authentication including MFA (Req 8), and physical access (Req 9). v4 made MFA required for ALL access into the CDE: not just admins, not just remote: future-dated to March 31, 2025. The era of unauth’d console boxes inside the CDE is over.

Req 7.2

RBAC + least privilege

Access by job function; explicit approval; default deny; reviewed at least every 6 months. Service-provider stricter cadence.

Req 8.2–8.3

Identification & authentication

Unique IDs. Strong passwords (12+ chars, complexity), 90-day rotation OR dynamic risk-based; password reuse prevented; account lockout 30 min / 10 attempts.

Req 8.4

MFA

MFA required for ALL access into CDE, all admin access, and all remote access: mandatory March 31, 2025. Phishing-resistant MFA strongly preferred.

Req 9.2–9.4

Physical access

Facility entry controls. Visitor identification & logs. Onsite-personnel ID. Media (incl. paper) inventory; secured storage; chain-of-custody for shipped media.

Req 9.5

POI device protection

Skimmer-tampering inspection cadence; up-to-date list of devices; training for staff to detect tampering.

RequiredReqs 10–12: Logging, testing, policy

Audit logs (Req 10), security testing including pen-tests + segmentation tests (Req 11), and the program-level governance & policy framework (Req 12): including the explicit targeted risk analysis v4 introduced for any control following the customized approach.

Req 10.2

Audit logs: what to capture

User activity, privileged-account activity, access to audit-log files, invalid logical-access attempts, identification-mech changes, init / stop / pause of audit-log mech, system-level object creation / deletion.

Req 10.4–10.7

Log review & retention

Daily review (manual or via automation). 12-month retention with 3 months immediately available. Time-sync to authoritative source. Failures of critical security control systems detected and addressed promptly.

Req 11.3

Penetration testing

External & internal pen-tests at least annually + on significant change. Application-layer + network-layer. Exploitable findings remediated and re-tested. Service providers test segmentation every 6 months.

Req 11.6

Payment-page integrity

Future-dated 11.6.1: mandatory March 31, 2025. Detect & alert on unauthorized changes to payment-page HTTP headers and content. Anti-skimming.

Req 12.3

Targeted risk analysis

For every control with a defined frequency or following the customized approach, a documented targeted risk analysis. This is the new “we pick the cadence” clause: QSAs read every word.

Req 12.5–12.10

Program governance

Information-security policy reviewed annually. Roles & responsibilities. Incident response plan tested annually. Service providers: documented executive responsibility for cardholder data protection.

§ IV · Validation route

SAQ vs ROC: self-attestation or independent assessor.

Two roads to a signed Attestation of Compliance. SAQs are self-assessment questionnaires for lower-risk channels and lower volume; a Report on Compliance is a full QSA-led assessment, mandatory for Level 1 merchants and most service providers. Picking the wrong route, or the wrong SAQ category, is one of the most common (and most expensive) errors in PCI.

Self-Assessment Questionnaire (SAQ)

Eight categories (A, A-EP, B, B-IP, C, C-VT, P2PE, D). Each is a subset of the 300+ sub-requirements scoped to a specific payment channel. Signed off by an internal officer; submitted to the acquirer with an AoC. Cheapest route: if you genuinely qualify.

SAQ AE-commerce, fully outsourced (PSP-hosted iframe / redirect)
SAQ A-EPE-commerce, partial outsourcing (your page calls PSP scripts)
SAQ B / B-IPImprint / standalone dial-out terminal
SAQ C / C-VTPayment app on networked POS / virtual terminal
SAQ P2PEP2PE-listed solution from PCI SSC list
SAQ DEverything else: the long one (~330 items)
EligibilityRead each SAQ’s eligibility criteria literally

Required for Level 1 merchants & most service providers

Report on Compliance (ROC)

Full QSA-led assessment against all in-scope sub-requirements. The QSA produces a ROC + an AoC; the AoC goes to the acquirer / brand. ISA-led ROCs are permitted for some entities. Where the stakes are real, this is the answer your acquirer expects to see.

Triggers Level 1Merchants >6M Visa/MC tx; AmEx >2.5M; any compromised entity
Service-provider Level 1>300k card tx / yr or otherwise designated
Performed byQSA (PCI SSC-listed) or qualified ISA
CycleAnnual; ROC on file with acquirer
Segmentation testingEvery 6 months for service providers; annual for merchants
ScopeFull 12 reqs · all in-scope sub-reqs
QSA assessment fee$50–250k typical, scope-driven

§ V · Readiness calendar

From engagement to signed AoC: realistic.

Most first-time PCI engagements run 6–12 months. Half is scope reduction, half is control implementation, the QSA shows up at month 9. We compress where possible; we don’t compress scoping.

Wk 0 – 6

Scope & data flow

CDE inventory. Cardholder data flow diagrams: every channel, every system, every third party. Where can we tokenize, redirect, or kill the flow entirely? Output: revised scope memo.

Wk 4 – 14

Segmentation

Network re-design. Firewalls, VLANs, jump hosts. Independent segmentation testing scheduled. P2PE / tokenization deployment if applicable. Validate the new CDE before locking it down.

Wk 10 – 26

Control implementation

12 requirements end-to-end. MFA into the CDE (8.4). Logging & review (10). Vuln mgmt + patch (6.3). Targeted risk analyses for 12.3-keyed controls. Policy rewrite. Every artifact pre-mapped to a sub-req.

Wk 24 – 36

Pen-test, scans, evidence

Quarterly ASV scans (if SAQ A-EP / D / ROC). Annual internal + external pen-tests (Req 11.3). Segmentation test report. Application pen-test on payment pages. Findings remediated & re-tested before fieldwork.

Wk 32 – 44

QSA fieldwork & AoC

QSA on-site (or virtual). Walk-throughs, evidence requests, sample testing. Draft ROC → final ROC → signed AoC. AoC distributed to acquirer + downstream customers. Day 1 of next year’s cycle.

§ VI · How Nexurion runs it

Senior partner from day one. Scope-led from week one.

Most PCI programs we inherit were built backwards: someone bought a SAQ portal, ran a self-assessment against the wrong category, and discovered at QSA fieldwork two years later that the ROC scope is the entire production network. We start somewhere else. The first six weeks of every engagement are scope work: where does cardholder data actually go? The CDE inventory we produce in week six often shocks executives; it always reduces the question by an order of magnitude.

Once scope is locked, we run controls implementation against the QSA’s eventual evidence list. We work shoulder-to-shoulder with engineering on segmentation, with security on logging and detection, with legal and procurement on the third-party contract chain (PCI flows down differently than HIPAA: written agreements per Req 12.8 are not optional). We rehearse the targeted risk analyses required by 12.3 before the QSA reads them. QSAs read them very carefully. Read our methodology.

The QSA is hired separately. We are scope & readiness; they are independent assessment. We’ve walked clean engagements with most major QSAs and will introduce you to firms calibrated to your stage and brand context. We have not had a client fail a ROC under our care. See engagement outcomes.

Engagement structure

Tokenize first. Encrypt second. Then argue about the controls.

If you can hand the PAN to a P2PE-listed device or a PSP-hosted iframe and never see it yourself, do that: you’ve dropped two SAQ categories and saved six figures of recurring assessment cost. If you must store, tokenize. If you must transmit, terminate TLS at the edge of the smallest possible CDE. Every dollar spent on a control that should have been scope reduction is a dollar you will spend again next year. QSAs & the brands »

§ VII · Where engagements stall

Six places PCI programs go sideways.

After running these for years, the failure modes are remarkably consistent. The technical ones are easier than the organizational ones.

01 / Scope expansion

The CDE that silently grew.

A reporting tool got read access to the payments DB “just for analytics”; an SRE jump-host has a route to the CDE for emergencies; a customer-success rep can pull a PAN to verify a refund. Each pulled a system into scope. CDE inventory once a year, not once a decade.

02 / SAQ misapplication

SAQ A when you’re really A-EP.

A merchant claims SAQ A because the PSP hosts the page: but the merchant’s page loads a JS snippet from the PSP. That puts you in A-EP, not A. The eligibility text is one paragraph. Read every word. Misclaiming an SAQ category is a brand fineable offense.

03 / SAD in logs

CVV in the application log.

Common: framework defaults, debug logging, error traces. SAD storage post-authorization is an absolute prohibition (Req 3.2). Find it pre-fieldwork via log scan; remediate; document destruction; tighten logging filters. The QSA’s last finding you want is “CVV in /var/log”.

04 / Customized approach abuse

“We’ll just customize it.”

v4’s customized approach is a powerful tool for mature programs and a footgun for the rest. Each customized control needs a documented targeted risk analysis: threats, controls, residual risk, monitoring. QSAs scrutinize these heavily. Don’t use it because the defined approach is hard.

05 / 12.8 contract gaps

Third parties without written agreement.

Req 12.8 requires written agreements with every TPSP that touches CHD, plus an inventory plus due diligence plus monitoring of their PCI status. Most programs have AoCs in a folder, not the contract clause that obligates the TPSP to maintain compliance. Rebuild the contract chain.

06 / Payment-page e-skimming

Magecart never left.

v4’s 6.4.3 + 11.6.1 (mandatory March 31, 2025) require script-integrity controls on payment pages. Most e-commerce platforms still load dozens of third-party scripts on checkout pages. The e-skimming threat is real and ongoing; deploy SRI / CSP / RASP before the QSA asks.

§ VIII · The brands & the QSAs

Five brands set the rules. One QSA signs your ROC.

PCI DSS is owned by the PCI Security Standards Council: a consortium founded by Visa, Mastercard, AmEx, Discover, and JCB. The Council writes the standard; the brands set the validation thresholds and the fines. Your acquirer enforces both. When you fall out of compliance, the bill arrives from your acquirer first, who is being charged by the brand: typically $5k–$100k per month until you re-validate, plus per-transaction non-compliance fees, plus liability for fraud losses traced to your CDE.

A Qualified Security Assessor (QSA) is an individual certified by the PCI SSC, working at a QSA-listed company. The QSA Company list is the authoritative directory. QSAs perform ROCs and sign the AoC; ISAs (Internal Security Assessors) can do the same for their employer. Picking the right QSA matters more than most teams realize: firms vary widely in industry depth, in willingness to engage on the customized approach, and in how they handle disagreement during fieldwork.

Our role is the inverse of theirs. We do not sign your AoC; we make sure the program the QSA reviews is one that earns it. We have walked clean ROCs with most major QSA firms and will introduce you to two or three calibrated to your industry, payment channel, and engagement temperament. The QSA you pick on day one is the QSA you should still want on day 365 of your remediation, if it comes to that. Choose with that in mind.

If a breach occurs, a PFI (PCI Forensic Investigator): a separate, more specialized credential: is appointed by the brand within days. They reconstruct the intrusion, the data exfiltrated, and your control posture at the time. Their report drives the brand’s liability assessment and the duration of the post-breach monitoring regime. Brands maintain a PFI list; you do not get to pick.

§ IX · Cross-mapping

PCI against the rest of the stack.

PCI is narrow-by-design: it covers cardholder data, full stop. Most payments-adjacent companies run a broader framework on top for general assurance. Where they overlap; where they don’t.

Framework	Overlap with PCI DSS v4	What you still need to do
SOC 2 Type 2	~55%: CC6 / CC7 cover most of Reqs 7–10 (access, logging, monitoring) for the common-criteria scope.	PCI-specific: scope inventory, segmentation testing, ASV scans, payment-page integrity, the prohibition on storing SAD, the QSA-signed AoC.
ISO 27001 : 2022	~60%: Annex A maps cleanly to Reqs 7, 8, 9, 10, 12. Risk-based approach helps with Req 12.3 targeted risk analyses.	PCI-specific technical reqs: 1 (network controls), 3 (CHD storage), 4 (transmission), 11.3 (pen-test cadence), 11.6 (payment-page integrity).
PA-DSS / PCI SSF	Different scope: PA-DSS covered payment applications (now superseded by Software Security Framework). DSS covers the entity using the app.	If you sell a payment application, you need PCI SSF (SSS + Secure SLC). DSS alone does not suffice.
PCI P2PE	Massive scope-reduction lever: deploying a P2PE-listed solution drops most of Reqs 3–4 and shrinks the CDE dramatically.	Strict deployment per the P2PE Instruction Manual; the listing is the solution’s, not yours.
PCI 3DS Core	For 3DS Server / ACS / DS roles: layered on top of DSS for entities operating 3-D Secure infrastructure.	Separate assessment by a 3DS-qualified QSA. Largely orthogonal to merchant DSS work.
HIPAA	~10%: orthogonal frameworks. Healthcare merchants accepting cards need both, with separate scopes.	HIPAA Security Rule, BAA chain, breach-notification clock: different data class entirely (PHI vs CHD).

§ X · v4.0 → v4.0.1: what changed

v3.2.1 retired March 31, 2024. v4 is the standard now.

PCI DSS v4.0 was published in March 2022; v3.2.1 retired March 31, 2024. v4.0.1 (a clarifications-and-corrections update, no new requirements) was published June 2024. A subset of future-dated v4 requirements became mandatory March 31, 2025: if you have not addressed them, you are out of compliance now, regardless of when your next assessment lands.

Customized approach. v4 introduced a second compliance route alongside the defined approach. For each applicable control, an entity may design its own implementation, supported by a documented targeted risk analysis. Powerful for mature programs; a footgun for everyone else.
Targeted risk analysis (Req 12.3). Required for every control with a defined frequency the entity sets, and for every customized-approach control. Threats, controls, residual risk, monitoring: all written, all dated.
MFA into the CDE (Req 8.4). Mandatory for all access into the CDE, all admin access, all remote access: effective March 31, 2025. Phishing-resistant strongly preferred.
Payment-page integrity (Reqs 6.4.3 + 11.6.1). Detect and alert on unauthorized changes to payment-page HTTP headers and content. Anti-skimming. Mandatory March 31, 2025.
Service-provider expectations. Stricter cadences across the board: quarterly access reviews, six-month segmentation testing, formal executive responsibility for cardholder data protection (12.4).
Cryptographic inventory (Req 12.3.3). A documented inventory of cryptographic cipher suites and protocols in use, reviewed annually and on material change.

Read our deeper take in Field Notes Vol. IV: “v4’s customized approach: when it’s a tool, when it’s a trap.”

§ XI · Pairs with

PCI is rarely the only framework.

A short list of what we typically scope alongside it: in order of how often the question comes up.

Most-asked pair

SOC 2 Type 2

For the broader assurance story your enterprise buyers ask about. Material evidence overlap with PCI Reqs 7–10.

→

For international

ISO 27001 : 2022

When the customer is non-U.S. or the program is global. Three-year cert cycle; risk-based approach pairs well with v4’s 12.3.

→

If AI in product

ISO 42001

AI management system: pairs with PCI when ML touches transaction data or fraud decisioning. Governance »

→

If healthcare

HIPAA

Healthcare merchants accepting cards: both apply, with separate scopes. CHD is not PHI; PHI is not CHD.

→

§ XII · FAQ

Frequently asked.

Are we PCI certified after a clean ROC? +

No, but it’s the closest PCI gets. You are PCI-validated for the assessment period: usually one year. The artifact is a signed Attestation of Compliance from the QSA, distributed to your acquirer and to downstream customers. There is no PCI logo, no certificate suitable for marketing. Marketing should say “PCI DSS v4 validated, AoC available under NDA”: never “PCI certified.”

What does a PCI engagement cost? +

Two costs to separate. Nexurion readiness: $60–180k for first-time programs depending on CDE complexity, payment-channel count, and starting posture: senior-led, scope-reduction-first, evidence pre-built. QSA assessment: $50–250k separately, paid to the assessor firm, scope-driven. We do not collect QSA fees, and we do not refer to a QSA we have a financial relationship with. See pricing structure »

Can we just do an SAQ A and skip the QSA? +

If you genuinely qualify, yes: and SAQ A’s eligibility is narrower than most teams remember. SAQ A is for e-commerce merchants who have fully outsourced all cardholder data functions to PCI DSS-validated third-party service providers, and who do not electronically store, process, or transmit any cardholder data on their own systems. The moment your page loads a JS snippet from your PSP, you are SAQ A-EP, not SAQ A. Read the eligibility paragraph literally. We do this read for clients in the scoping memo.

What triggers Level 1 classification? +

Three paths. Volume: >6M Visa/MC card transactions per year (AmEx threshold is 2.5M). Compromise: any merchant suffering a breach, regardless of volume, can be re-classified upward by their acquirer. Brand designation: any merchant the brand designates Level 1: typically because of risk, channel, or visibility. Service-provider Level 1 is >300k card transactions per year, or otherwise designated. Level 1 means a ROC, not an SAQ.

If we use Stripe (or similar), are we still in scope? +

Yes: you are still a merchant and PCI still applies. What changes is which SAQ. A pure Stripe Checkout / Stripe Elements iframe deployment, with no card data ever touching your servers, can put you on SAQ A. A Stripe.js deployment that loads from your domain may be SAQ A-EP. A merchant using Stripe Terminal or storing tokens still has DSS obligations around the systems handling those flows. The PSP’s AoC is a piece of your evidence, not a substitute for your own validation.

Does SOC 2 satisfy PCI? +

No. They overlap meaningfully on access control, logging, change management: but SOC 2 has no concept of an SAQ category, no QSA, no payment-channel scope, no segmentation-testing cadence, no payment-page-integrity requirement, no SAD prohibition. A clean SOC 2 report is good supporting evidence in a PCI engagement; it is not an AoC.

Does the customized approach save us work? +

Sometimes. For a mature program with strong telemetry and a defensible risk function, yes: the customized approach lets you replace a defined-approach control that doesn’t fit your architecture with one that does. For everyone else, no: the targeted risk analysis is more work than just implementing the defined approach. We see teams reach for it because the defined approach feels onerous, and then watch them spend three times the effort defending the customization to the QSA. Use it because you have a better way, not because the standard is hard.

What about e-skimming: is that really us? +

If you run a payment page (anything other than a full PSP redirect), yes. The Magecart-style attack family is responsible for a substantial share of card-data theft over the past five years and continues to mature. v4 Reqs 6.4.3 + 11.6.1 (mandatory March 31, 2025) require script-integrity controls on payment pages: SRI, CSP, RASP, or equivalent. If your checkout loads dozens of third-party tags, you are exposed and out of compliance with v4. We rebuild this regularly.

§ XIII · From the Brief

Field notes on PCI DSS.

Pieces from The Field Notes directly relevant to the standard.

Coming · Vol. IV

v4’s customized approach: when it’s a tool, when it’s a trap.

A QSA-side read on which entities should adopt the customized approach for which controls: and which should run the defined approach and never look back.

Coming · Vol. V

Scope reduction is the only PCI strategy that compounds.

Six client patterns where one architectural decision: tokenization, P2PE, hosted iframe: halved the assessment cost for the next decade.

Coming · Vol. VI

The day the e-skimmer landed.

A reconstructed Magecart incident in a mid-market retailer: how the script got in, what it took, what the brand did, what compliance with v4 6.4.3 + 11.6.1 would have prevented.

PCI DSS v4.0.1: scope is the whole game.