PCI DSS v4.0.1 Compliance Readiness
The global standard for protecting payment card data. We get you validation-ready for PCI DSS v4.0.1 — defining and tightening your cardholder data environment, closing the gaps, and proving the controls with the Requirement 11 penetration testing we run ourselves — then coordinating cleanly with your QSA and ASV so the assessment confirms what we have already tested.
Scope and segmentation to validation. CERT-In Empaneled. We are not your QSA or ASV — we make sure you pass theirs.
The standard that keeps payment data safe
The Payment Card Industry Data Security Standard — PCI DSS — is the global baseline of technical and operational requirements for protecting payment account data.
It is maintained by the PCI Security Standards Council and enforced through the card brands and your acquiring bank. It applies to every organization that stores, processes or transmits cardholder data, and to the service providers that can affect the security of those transactions. The standard is built around one disciplined idea: know exactly where cardholder data lives and flows, shrink that footprint as far as you can, and prove that the controls protecting it actually hold.
The current version is PCI DSS v4.0.1, published by the PCI SSC in June 2024. It is a limited revision — an errata to v4.0 that corrects wording and clarifies intent, with no requirements added or removed, so the framework remains 12 requirements grouped under 6 control objectives. What changed the stakes is timing: v4.0 introduced a set of future-dated requirements that were advisory until they became mandatory on 31 March 2025. That date has passed. Every PCI DSS assessment now runs against the full v4.0.1 requirement set — including the new expectations around targeted risk analysis, authenticated internal scanning, and the expanded penetration-testing and segmentation-testing rules. Whether you are validating for the first time or maintaining an existing posture, the target is the same one, in full.
"PCI compliance isn't a form you fill in. It's a claim about your cardholder data environment — so we shrink that environment, segment it, and test it, until the claim is simply true."
Who has to comply — and how they validate
If you touch cardholder data, PCI DSS applies. How you validate that compliance depends on how you take payments and how much volume you do — the card brands define merchant levels and the matching validation path, set through your acquirer. We scope every engagement to the level and path that actually bind you.
| Criterion | How they validate | Validation path |
|---|---|---|
| Level 1 merchants | The highest transaction volumes. Validation is typically an annual, QSA-led on-site assessment producing a Report on Compliance, with quarterly ASV scans. | RoC (QSA) · ASV scan · AOC |
| Levels 2–4 merchants | Lower volumes, validated by the appropriate Self-Assessment Questionnaire and an Attestation of Compliance, with quarterly ASV scans where external-facing. Exact requirements are set by your acquirer. | SAQ · ASV scan · AOC |
| E-commerce & omnichannel | Online and mixed channels where the website can affect transaction security — often the difference between a short SAQ and a much larger one. Scope and segmentation decide which. | SAQ A / A-EP / D · Scope-driven |
| Service providers | Payment gateways, aggregators, processors, SaaS and hosting providers in the payment flow. Validated by SAQ D (Service Provider) or a QSA-led RoC, with stricter, more frequent obligations. | SAQ D / RoC · 6-monthly segmentation |
| Anyone storing, processing or transmitting CHD | If cardholder data enters your environment, you are in scope — and the single biggest lever on cost and effort is how much of your estate that data is allowed to reach. | In scope · Reduce scope first |
Your merchant level and validation path are confirmed by your acquirer and the card brands — not by us. What we do is make sure that whichever path you are on, you walk into it ready.
Twelve requirements, six objectives
PCI DSS v4.0.1 organizes 12 core requirements under 6 control objectives. The objectives are the why; the requirements are the what.
Everything in an assessment — every test procedure, every piece of evidence, every SAQ question — ladders up to one of these twelve. The map below is the standard's actual spine.
Build and Maintain a Secure Network and Systems — The network controls and secure configurations that keep the cardholder data environment defensible from the perimeter inward (Requirements 1–2).
Protect Account Data — How stored account data is protected and how it is encrypted in transit across open, public networks (Requirements 3–4).
Maintain a Vulnerability Management Program — Protecting systems from malicious software and developing and maintaining secure systems and software (Requirements 5–6).
Implement Strong Access Control Measures — Restricting access by business need-to-know, authenticating every user, and controlling physical access to the data (Requirements 7–9).
Regularly Monitor and Test Networks — Logging and monitoring all access, and regularly testing the security of systems and networks — vulnerability scans and penetration testing (Requirements 10–11).
Maintain an Information Security Policy — Supporting information security with organizational policies and programs across all personnel (Requirement 12).
v4.0.1 added or sharpened the controls inside these requirements — targeted risk analysis, authenticated internal scanning, expanded penetration and segmentation testing — but the twelve-and-six structure is unchanged. Get the structure right and the detail has somewhere to live.
Two ways to implement, two ways to validate
PCI DSS v4.0.1 gives you a choice in how you meet each requirement, and your level sets how you prove it. Both choices change the work — so we settle them at the start.
Defined Approach
The traditional route. You meet each requirement exactly as written and are tested against the standard's stated procedures. It is the right default for most environments and what every SAQ uses — customized implementations are not supported in a self-assessment.
Customized Approach
For risk-mature organizations, v4.0.1 allows you to meet a requirement's objective with a control of your own design — but only with a documented targeted risk analysis and a controls matrix proving at least equivalent protection. It offers flexibility at the cost of more evidence, and it is assessed by a QSA, never self-assessed. We help you decide where, if anywhere, it is worth it.
Self-Assessment Questionnaire (SAQ)
A self-validation route for eligible merchants and service providers, in several types matched to how you take payments — A, A-EP, B, B-IP, C, C-VT, P2PE and D. The right SAQ can be the difference between a few dozen controls and the full standard, which is exactly why scope and segmentation matter so much. We guide you to the correct SAQ and to a defensible answer for every line.
Report on Compliance (RoC)
The full, formal assessment — performed by a Qualified Security Assessor (QSA), typically for Level 1 merchants and many service providers. The QSA, not us, signs the RoC. We get you ready for it, sit alongside you through it, and make sure the QSA finds an environment that has already been tested.
Whichever approach and path apply, both routes finish with an Attestation of Compliance (AOC) — and the external scans behind them are run by a PCI SSC Approved Scanning Vendor (ASV). We coordinate both; we issue neither.
How a PCI DSS engagement runs
A disciplined path from defining scope to signed attestation — built so the validation at the end confirms work that is already done and already proven.
FIG. 02 — PCI compliance path · 01–05 Intect-led · the external ASV scan is the Approved Scanning Vendor's · 06 RoC signed by a QSA · 07 AOC submitted to the acquirer
Steps 01–05 are ours to do and prove. The RoC sign-off is the QSA's and the external ASV scan is the Approved Scanning Vendor's — we coordinate both so the handoffs are clean and the evidence is already in place. PCI compliance is also a yearly cycle: scans, penetration tests and validation recur, and we support the whole rhythm.
What an engagement includes
We scope to where you are — first-time validation, a v4.0.1 uplift, or sustaining an existing posture — and cover the work end to end.
Cardholder data discovery
where CHD is stored, processed and transmitted
Cardholder data environment (CDE) definition and data-flow mapping
Network segmentation design and review to reduce PCI scope
SAQ eligibility analysis
identifying the correct SAQ type for your environment
Gap assessment against all 12 requirements of PCI DSS v4.0.1
Customized vs defined approach guidance
including targeted risk analysis where relevant
Prioritized remediation roadmap mapped to requirement and risk
Hands-on support closing gaps
across configuration, access control, logging, secure development and policy
Policy and procedure support aligned to Requirement 12
Remediation re-check as fixes land
Internal vulnerability scanning
Internal and external penetration testing per Requirement 11.4
Segmentation testing to prove the CDE is genuinely isolated
(Req 11.4.5; six-monthly for service providers, Req 11.4.6)
Application- and network-layer testing to an industry-accepted methodology, with retest after remediation
SAQ completion guidance, line by line, with evidence
Evidence collection and an audit-ready artifact pack for a QSA-led RoC
QSA liaison through the Report on Compliance and ASV-scan coordination for the external quarterly scans
AOC preparation support
Requirement 11 is where we live
Most PCI readiness work hands the testing to someone else. For us, the testing is the work — and PCI explicitly allows us to do it.
A paper-ready environment isn't a proven one
A conventional readiness project reviews configurations, writes policies and assembles evidence — then waits for an external test to find out whether the cardholder data environment actually holds. That is a late, expensive moment to discover that a segmentation control leaks, or that an exposed service reaches into the CDE. The gap between "configured" and "proven" is exactly where payment breaches happen.
We run the Requirement 11 testing ourselves
Intect is CERT-In Empaneled with an offensive-security heritage, and Requirement 11's internal and external penetration testing and segmentation testing do not require a QSA or an ASV — only a qualified tester with organizational independence. That is precisely us. We probe the CDE perimeter and critical systems at the application and network layers, prove whether your segmentation truly isolates the cardholder data environment, and correct what we find — so by the time a QSA assesses your RoC or you submit your SAQ, the controls have already been attacked and have already held. The external quarterly ASV scan stays with a PCI SSC Approved Scanning Vendor; we coordinate it. The hard part — proving the environment is defensible — is ours.
The QSA confirms your compliance. The ASV runs the perimeter scan. We make sure the cardholder data environment behind both has been tested by people who break into them for a living.
REQ 11 · PENTEST-BACKED EVIDENCEWhat you receive
Every engagement produces the artifacts your team needs to operate a PCI-compliant environment — and the evidence a QSA or your acquirer expects to review.
PCI scope & CDE definition
A documented cardholder data environment with data-flow diagrams, so everyone agrees what is in scope before assessment begins.
Segmentation review report
An assessment of how effectively your segmentation isolates the CDE, with recommendations to shrink scope further.
Gap assessment report
Your current state mapped against all 12 requirements of PCI DSS v4.0.1, with a prioritized remediation roadmap.
SAQ guidance pack
The correct SAQ type identified and a defensible, evidence-backed answer for every applicable line.
Penetration testing & segmentation testing report (the offensive edge)
Requirement 11 internal and external penetration testing and segmentation testing, with reproducible proof-of-concept, demonstrated impact and remediation guidance — then retest.
Remediation roadmap & support
Specific, prioritized fixes with clear ownership, and hands-on support to close them.
Audit-ready evidence pack
Organized artifacts mapped to each requirement, ready for SAQ submission or a QSA-led RoC.
QSA & ASV coordination
Liaison through the Report on Compliance and coordination of the external ASV scans, so the handoffs are clean and nothing stalls.
Why teams choose Intect for PCI DSS
CERT-In Empaneled — A real, recognized cybersecurity credential — so the technical validation behind your PCI posture carries weight where it counts.
We run Req 11 ourselves — Requirement 11's penetration testing and segmentation testing don't need a QSA or ASV — they need attackers. That is our origin, not an add-on.
Scope-and-segmentation rigor — We treat scope reduction as the first and most valuable move in PCI, shrinking what has to be assessed before we assess it.
Clean QSA & ASV coordination — We are not your QSA or ASV, and we are clear about it — we get you ready, then coordinate both so validation is a confirmation, not a scramble.
Frequently asked questions
Is Intect a QSA or an ASV?
No — and we are deliberately clear about that. A Qualified Security Assessor (QSA) performs and signs the Report on Compliance; an Approved Scanning Vendor (ASV) runs the external quarterly scans. Both are specific PCI SSC designations. Intect provides PCI readiness — scope and segmentation review, gap assessment, SAQ guidance, remediation, and the Requirement 11 penetration and segmentation testing — and then coordinates your QSA and ASV. We make you ready to pass their assessments; we do not stand in for them.
Then who signs our RoC and runs our ASV scan?
The QSA signs the Report on Compliance and its Attestation of Compliance. A PCI SSC Approved Scanning Vendor runs the external vulnerability scans. We prepare the evidence, support you through the RoC, and coordinate the ASV scans — but the formal sign-off and the official external scan stay with the designated parties, which is exactly what keeps your validation credible.
If you're not a QSA, how can you do the penetration testing?
Because PCI DSS says so. Requirement 11's internal vulnerability scans, internal and external penetration tests and segmentation testing only require a qualified tester with organizational independence — they explicitly do not require a QSA or ASV. That work is offensive security, which is exactly what Intect does. The one external test reserved for an ASV is the quarterly external vulnerability scan; we coordinate that, but we run the penetration testing and segmentation testing ourselves.
Which SAQ do we need — or do we need a full RoC?
It depends on how you take payments and your transaction volume, which your acquirer and the card brands ultimately confirm. Most merchants validate with the appropriate Self-Assessment Questionnaire — A, A-EP, B, B-IP, C, C-VT, P2PE or D — while the highest-volume merchants and many service providers need a QSA-led Report on Compliance. Choosing the right SAQ, and reducing scope so you qualify for a smaller one, is one of the first things we do.
What changed in PCI DSS v4.0.1, and do we need to act?
v4.0.1 is a limited revision of v4.0, published in June 2024 — it corrects wording and clarifies intent, with no requirements added or removed, so it is still 12 requirements under 6 objectives. The bigger change is that v4.0's future-dated requirements became mandatory on 31 March 2025. That date has passed, so every assessment now runs against the full v4.0.1 set, including the expanded testing and risk-analysis expectations. If you validated under an older posture, you need to uplift.
What's the difference between scope reduction and just doing the controls?
Everything. In PCI, every system that the cardholder data environment can reach falls into scope and must meet the standard. Effective segmentation isolates the CDE so far fewer systems are in scope — which means less to remediate, a smaller SAQ, a shorter assessment and lower ongoing cost. We treat scope reduction as the highest-leverage work in the whole engagement, and we prove the segmentation holds by testing it.
How long does PCI compliance take?
It depends on your current state, your scope and how much segmentation work is needed — which is exactly what the scoping and gap assessment establish first. We give you a realistic, evidence-based timeline up front rather than a generic promise, and we sequence the work so the penetration testing, ASV scan and validation line up without stalls.
The testing behind your PCI posture
PCI's testing requirements are offensive-security work — and several of them map directly to services we already run.
Get PCI-ready — and prove it.
Tell us how you take payments and where you are in your PCI cycle, and we'll scope a readiness engagement that fits — define your CDE, reduce your scope, run the Requirement 11 testing, and coordinate your QSA and ASV.