PCI DSS v4.0.1 · Audit-ready · Scoping · SAQ · RoC readiness

PCI DSS v4.0.1 — built to pass, built to hold

We scope the CDE, build the controls across the 12 requirements, produce evidence your QSA will actually sign off, and walk with you into the assessment. No template packs, no last-minute cosmetics — a compliance programme that survives the audit and the year that follows it.

Get a scoping review How we work Compliance & GRC pillar

Standard

PCI DSS v4.0.1 (Jun 2024) · future-dated items enforceable since 31-Mar-2025

Who it fits

Merchants L1-L4 · PSPs · acquirers · processors · fintech

Outcome

Defensible SAQ or a RoC signed by a QSA

A PCI programme that holds up in the audit — and on a Tuesday.

PCI DSS — the Payment Card Industry Data Security Standard — is the PCI Security Standards Council's framework for every organisation that stores, processes or transmits cardholder data or sensitive authentication data. The current version is v4.0.1 (June 2024), and every v4.0 requirement has been enforceable since 31 March 2025. No more future dates to hide behind.

The cost of PCI is not really the number of controls — it is the size of the scope. So that is where we start. Cardholder data flows, segmentation, tokenization, iframe redirects, data minimization. When the Cardholder Data Environment is bounded properly, the 12 requirements land on a much smaller estate, and the programme becomes affordable to run year on year.

We are an implementation and readiness partner, not a QSA — and we think that distinction matters. We build, document, evidence and accompany, but the Report on Compliance is signed by a QSA accredited by the PCI SSC. If you have not engaged a QSA yet, we will help you shortlist one and stand the relationship up cleanly.

Plainly put:

Around 80% of the cost and risk of a PCI DSS programme is set in the first few weeks, when scope is drawn. What you get wrong there, you pay for every year after.

Scope is the lever, not the checklist

Most PCI programs are expensive because the Cardholder Data Environment was never properly bounded. We start with network flows, segmentation and tokenization so the 12 requirements land on a fraction of the estate.

Controls mapped to your stack, not a template

Every requirement in PCI DSS v4.0.1 is tied to a control owner, a technical implementation and a recurring piece of evidence on your platform — AWS, Azure, GCP, hybrid or on-prem. No PowerPoint shields, no 'see appendix' cop-outs.

Evidence the QSA can actually use

Logs, tickets, configuration baselines, change records and test results gathered as you run — not rebuilt the week before assessment. What a QSA wants to see, already in the shape they want to see it.

Customized Approach — only when it earns its keep

v4.0 opened the door to a Customized Approach. It is powerful but documentation-heavy. We use it where the default control genuinely does not fit your architecture, and we produce the Appendix E worksheets that survive a QSA review.

Who this fits

Does PCI DSS apply to you?

If PAN, CVV or sensitive authentication data touches any part of your stack, PCI DSS applies. These are the profiles where our programme most often lands.

Merchants, Level 1 to Level 4

From global retailers running millions of card-present and card-not-present transactions to mid-market brands consolidating SAQ A, SAQ B-IP, SAQ C or SAQ D.

Acquirers, PSPs, gateways, processors

Service providers that store, process or transmit cardholder data or sensitive authentication data and need an annual Report on Compliance signed by a QSA.

Fintech, neobanks and issuers

Card issuing, wallets, BaaS platforms and embedded payments that touch PAN at any point in the flow — including tokenized flows with narrow residual scope.

SaaS and e-commerce with embedded checkout

Platforms that never handle the PAN directly but host scripts or iframes on payment pages — the exact surface hit by v4.0 requirements 6.4.3 and 11.6.1.

How we work

From scope to signed RoC

Battle-tested across processor, retail and fintech engagements. Every phase leaves reusable artefacts for the next annual cycle.

Scope and reduce

Data flows, segmentation, tokenization, out-sourcing, iframe patterns. Every system we can pull out of the CDE is a system we do not have to audit, operate or pay for next year.

Gap assessment

Structured review across the 12 requirements, 6 control goals and every time-bound v4.0 item. Output: prioritized findings, severity, effort estimate, remediation owner.

Design the target

Control-level target state on your real stack: which tool, which setting, which owner, which recurring evidence. Where the default control does not fit, we design and document the Customized Approach.

Implement and harden

We execute or steer delivery: segmentation, key management, logging, vulnerability management, identity and MFA, hardened baselines, change control and secure SDLC.

Test what the standard demands

Quarterly ASV scanning via an approved vendor, internal and external penetration tests (req. 11.4), segmentation tests, code review and change-driven retesting.

Dry-run and stand beside you for the audit

Mock assessment against the applicable SAQ or against a QSA-style walkthrough. We close observations and stay in the room for the formal review through to RoC or AoC.

What you walk away with

Artefacts you can defend, not a PDF

We work in parallel with your team, your QSA (if you already have one) and your real platform. Everything is versioned and reusable for subsequent cycles.

CDE diagram and scope rationale

Asset inventory, cardholder data flow diagrams, trust zones, segmentation map and a documented rationale for every system placed in or pulled out of scope.

Gap assessment against PCI DSS v4.0.1

Control-by-control review with severity, prioritized findings, estimated effort, quick wins and longer structural work kept separate so the plan is financeable.

A remediation plan you can actually run

Phased roadmap with owners, dependencies and audit-window alignment. Not a wishlist — a plan that survives sprint planning and a budget conversation.

Policies, procedures, runbooks

A documentation set sized to your organization, written to be used rather than filed: operational procedures, response runbooks and repeatable evidence templates.

Structured evidence across all 12 reqs

Evidence stored with control ID, owner, date and pointer to the underlying record. Ready for a SAQ package or a QSA walkthrough.

Customized Approach Worksheets

Where relevant: control objective, risk analysis, alternate design, testing procedures and maintenance expectations — written in the Appendix E format QSAs will not push back on.

Case snapshots · anonymized

How PCI DSS lands in the real world

We do not publish names or metrics — we respect our confidentiality commitments. We do share profile, context and outcome.

Pan-European payment processor

Context

PSP with an annual RoC commitment. Cloud-native microservices, rapid growth and a CDE that had grown by accretion rather than design. QSA already engaged; 9 months to next assessment.

What we did

Rebuilt the CDE map from data flow outwards, carved PAN processing into a segmented zone, moved storage onto tokenization and wrote the Customized Approach Worksheets for the controls that genuinely did not fit as defined.

Outcome

In-scope system count cut materially, evidence ready on time, RoC signed in-window with no high-risk findings.

Omnichannel retailer — e-commerce plus physical stores

Context

Split compliance posture: SAQ A for a redirected e-commerce flow and SAQ D for the physical and back-office estate. v4.0's 6.4.3 and 11.6.1 script-integrity controls were uncovered as the mandatory date approached.

What we did

Inventoried and signed payment-page scripts, stood up HTTP header monitoring, closed PoS logging gaps and reissued the SAQ with evidence a QSA or acquirer can actually follow.

Outcome

Defensible self-assessment posture, managed web-skimming risk and an annual review cadence embedded into the GRC programme.

Embedded-payments fintech on AWS

Context

Series-B fintech whose acquirer required PCI DSS attestation. No prior formal audit, small engineering team, AWS-native platform.

What we did

Designed the scope from zero on AWS primitives (account segregation, KMS, centralized logging, secrets management), built a lean documentation set and stood alongside them through the first RoC with a selected external QSA.

Outcome

First RoC achieved with no high-risk findings; compliance built into the platform's normal delivery cycle rather than bolted on annually.

About the standard

What you actually need to know about v4.0.1

Straight from the standard and the PCI Security Standards Council. Source and date cited so you can verify.

i PCI DSS v4.0.1 is the version in force, published by the PCI Security Standards Council on 11 June 2024. It clarifies v4.0 and introduces no new requirements (pcisecuritystandards.org).
i The v4.0 'future-dated requirements' became enforceable on 31 March 2025. Every previously time-bound control is now fair game in assessment.
i Merchant level and applicable SAQ are determined by transaction volume and acceptance model; the definitive level is assigned by the card brand and the acquirer.
i The Report on Compliance is only signed by a Qualified Security Assessor (QSA) accredited by the PCI SSC. Hard2bit is an implementation and readiness partner — not a QSA.
i The external quarterly scan under requirement 11.3.2 has to be performed by an Approved Scanning Vendor (ASV) approved by the PCI SSC.

Common mistakes

What a serious PCI programme is NOT

Six patterns behind most of the non-conformities we see in assessment. We avoid them by design.

× Dropping a boilerplate policy pack with no mapping to your assets, systems or data flows.
× Buying controls before scoping the CDE — the fastest way to multiply cost and still fail.
× Conflating SAQ with RoC. Different vehicles, different profiles, different bar.
× Marking requirements 'N/A' with no written justification in the SAQ.
× Leaving ASV scans, penetration tests and segmentation testing for the last month before assessment.
× Adopting the Customized Approach without the Appendix E documentation — objective, risk analysis, design, testing, maintenance.

FAQ

PCI DSS, in plain English

Is Hard2bit a QSA? Will you sign the Report on Compliance?

No — and we would not trust anyone who blurs that line. The Report on Compliance can only be issued by a Qualified Security Assessor accredited by the PCI Security Standards Council. Hard2bit is the implementation and readiness partner: we scope, build, evidence and walk you into the audit room. If you have not engaged a QSA yet, we will help you shortlist one and set the relationship up cleanly.

Which version of the standard do you work to?

PCI DSS v4.0.1, published by the PCI Security Standards Council on 11 June 2024. It is a clarification revision over v4.0 and introduces no new requirements. The v4.0 'future-dated requirements' became mandatory on 31 March 2025, so every previously time-bound control is now assessable at face value.

What is the real difference between an SAQ and a RoC?

The SAQ (Self-Assessment Questionnaire) is a self-attestation signed by merchants and some service providers at lower transaction profiles. The RoC (Report on Compliance) is a formal assessment performed by a QSA, typical for Level 1 merchants and most service providers. The right SAQ depends on acceptance model and volume; we pin that down in week one and we do not let it drift.

How do you bring the CDE down and why does it matter so much?

Every asset inside the Cardholder Data Environment inherits dozens of PCI controls forever. We combine network segmentation, tokenization, data minimization, redirect-to-PSP patterns and hardened perimeters. Done well, fewer systems are audited, risk falls and the recurring cost curve bends downward — without breaking the business.

When does the Customized Approach actually make sense?

It is not a shortcut. The Customized Approach meets a control objective with a design different from the Defined Approach — valuable when your architecture genuinely cannot support the default (think ephemeral infrastructure, programmatic access, platform-level controls). It demands full Appendix E documentation: objective, risk analysis, design, testing, maintenance. We use it where it pays for itself; otherwise, the Defined Approach is faster.

How long does a PCI DSS program take?

It depends on starting position, CDE size and team maturity. A first certification at a small fintech on a modern cloud stack tends to stabilise in a matter of months; a large processor with a sprawling CDE and structural remediation needs can run 12+ months. The initial diagnosis sets a realistic calendar — we do not quote a timeline before we know the scope.

How does PCI DSS sit alongside ISO 27001, ENS, NIS2 or DORA?

PCI DSS is specific to card data; the others are broader security or operational-resilience frameworks. Control overlap is real (access management, logging, vulnerability management, incident response), and a well-designed programme reuses evidence across frameworks. For clients with ISO 27001 and PCI DSS, we map ISO Annex A against the PCI requirements and avoid duplicated effort.

Can you also operate the controls once they are built?

Yes — and most clients take us up on that. Managed SOC/MDR covers requirement 10 and the detection side of 11. Vulnerability management covers 6.x and 11.x. The IR retainer is the clean answer to 12.10. Compliance stays alive in operations, not in a binder.

Related services

The controls that keep PCI alive in operations

PCI touches almost every layer. These are the services we usually combine with it so compliance holds up between audits, not just during them.

ISO 27001 ENS NIS2 DORA Managed SOC / MDR Vulnerability management Web / API pentesting Incident response 24/7 IR retainer Virtual CISO (vCISO) Digital forensics (DFIR) Cybersecurity audit Financial sector

PCI DSS on the horizon? Start with the scope.

Two-week scoping review: CDE map, v4.0.1 gap snapshot and a prioritized remediation plan — before anyone asks for a budget.

Book a scoping review Compliance & GRC pillar