Payment security
PCI DSS Compliance
PCI DSS applies to anyone who stores, processes or transmits payment card data, or can affect the security of the systems that do. Most of the cost of meeting it is decided by one thing: how small you can honestly make the environment it applies to. We start there, then build what the assessment will test.
- Standard
- PCI DSS v4.0.1
- Published
- June 2024
- Future-dated reqs
- 51, live 31 Mar 2025
- ASV external scan
- Every 3 months
What PCI DSS is, and who decides what you must do
The Payment Card Industry Data Security Standard is maintained by the PCI Security Standards Council, a body founded by the card brands. It sets a baseline of technical and operational requirements for any entity that stores, processes or transmits cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment. That includes merchants, processors, acquirers, issuers and service providers.
The requirements are organised into twelve principal areas: network security controls and secure configuration; protecting stored account data and data in transit; protection against malware and secure development; restricting access, authenticating users and controlling physical access; logging, monitoring and regular security testing; and the policies and programmes that hold it together. The current version is v4.0.1, a limited revision published in June 2024 that added and removed no requirements. Version 4.0 was retired on 31 December 2024.
One point surprises most first-time readers. The Council writes the standard but does not decide who must validate compliance or how. That is set by the card brands and by acquirers — the compliance-enforcing entities — which is why your merchant level, and whether you may self-assess, comes from your acquirer and the brands rather than from the standard itself.
What it will ask of you
The standard is long, but an assessment turns on a handful of artefacts. Each one below is something an assessor or your acquirer will ask for by name.
A scope you have confirmed
A documented account of every system that stores, processes or transmits account data, and every system connected to them or able to affect their security. Version 4 makes confirming this scope at least once a year a requirement in its own right.
Passing external scans, every quarter
Evidence of passing external vulnerability scans performed by a PCI SSC Approved Scanning Vendor at least once every three months. A missed quarter is a gap in the record that cannot be backfilled.
The future-dated requirements, in operation
The requirements that were best practice until 31 March 2025 are now mandatory — among them payment page script controls for e-commerce, protection against phishing, 12-character passwords, multi-factor authentication for all non-console access into the cardholder data environment, automated log review, and targeted risk analyses that justify how often you perform certain activities.
The right validation document
Either a Self-Assessment Questionnaire matched to how you accept cards, or a Report on Compliance from an assessor — each with its Attestation of Compliance. Which one you need is set by your acquirer and the card brands, not chosen by you.
Why organisations pursue it
- Card brands hold acquirers responsible for their merchants’ and service providers’ compliance, so your acquirer will ask you to validate it.
- An Attestation of Compliance answers the payment security question in merchant and partner due diligence without a bespoke questionnaire.
- In India, the RBI’s 2025 Payment Aggregator Directions require aggregators to ensure their merchants’ infrastructure complies with PCI-DSS where applicable — so an aggregator’s onboarding team may ask you for it.
- Reducing the cardholder data environment shrinks risk and assessment cost together, which is rarely true of a security control.
- Much of the control work — access, logging, change, vulnerability management — overlaps with ISO/IEC 27001 and SOC 2.
Not sure this is the standard you need?
Tell us what triggered the question — a customer, an auditor, a contract clause — and we will say which of these applies, including when the answer is none of them.
Where we come in, and where we stop
We are not a Qualified Security Assessor company and not an Approved Scanning Vendor. QSA companies are independent security organisations qualified by the PCI Security Standards Council to validate compliance; ASVs are qualified by the Council to run the external scans. We prepare you; they validate and scan. Penetration testing is the exception: Requirement 11.4 asks for a qualified tester with organisational independence, and says in terms that the tester is not required to be a QSA or ASV. So we can perform your internal, external and segmentation tests — provided we did not build what we are testing.
Ours
- Scoping the cardholder data environment, and the segmentation that keeps it small
- Gap assessment against PCI DSS v4.0.1, including the future-dated requirements
- Remediation planning and implementation alongside your engineers
- Policies, procedures, targeted risk analyses and the evidence an assessor samples
- Preparing a Self-Assessment Questionnaire, where your acquirer permits one
- Readiness review before the assessment, and working the assessor’s request list from your side
- Internal, external and segmentation penetration testing under Requirement 11.4, which the standard does not reserve to a QSA or ASV
Not ours
- Assessing and signing a Report on Compliance and its Attestation of Compliance — a QSA, or your own Internal Security Assessor where the card brand permits it
- Quarterly external vulnerability scans — a PCI SSC Approved Scanning Vendor
- Deciding your merchant level and validation route — your acquirer and the card brands
How we get you there
The assessment is performed by a QSA, or by an Internal Security Assessor where the brand allows; external scans are run by an ASV. We prepare you for both and perform neither.
- 01Validation routeWe confirm with you what your acquirer requires — Self-Assessment Questionnaire or Report on Compliance, and which questionnaire — because that decides the shape of everything after it.
- 02Scoping and data flowsWhere account data enters, travels, rests and leaves; which systems are connected to or can affect it; and what segmentation would take systems out of scope. The cheapest control is the one you no longer need.
- 03Gap assessmentRequirement by requirement against v4.0.1, with the future-dated requirements treated as the live obligations they now are. You get a gap register with an owner and an effort estimate per line.
- 04RemediationControls implemented with your teams, plus the policies, targeted risk analyses and procedures the standard asks for — written to be operated, not filed.
- 05Evidence and scanning cadenceLogging, access reviews, change records and the quarterly ASV scan rhythm set up so the evidence exists when an assessor samples it, rather than being assembled afterwards.
- 06Readiness and assessment supportA readiness review against the assessor’s likely testing, then support through the SAQ or the QSA assessment, closing what it raises.
What you get from us
- A scope statement and data flow diagrams for the cardholder data environment
- Segmentation recommendations with the scope reduction each one buys
- A gap register against PCI DSS v4.0.1 with owners and effort
- Policies, procedures and targeted risk analyses ready for assessment
- A prepared Self-Assessment Questionnaire, where that is your route
- An evidence pack organised the way an assessor will request it
Common questions
Can SecuriFii certify us as PCI compliant?
No. We are not a QSA company or an ASV. A Report on Compliance is assessed by a QSA, or by an Internal Security Assessor where the card brand allows it, and external scans are run by an ASV. We do the preparation that makes those steps go well, and we will tell you what to look for in choosing either.
Do we need a Report on Compliance or a Self-Assessment Questionnaire?
Your acquirer and the card brands decide, usually by your transaction volume and history. The PCI Security Standards Council does not set validation requirements itself. Ask your acquirer before anything else, because the answer changes the scope of the engagement.
What changed on 31 March 2025?
By the Council’s count, 51 of the 64 new requirements introduced in v4.0 were best practice until that date and are now mandatory in every assessment. They include the e-commerce payment page requirements 6.4.3 and 11.6.1, anti-phishing mechanisms (5.4.1), 12-character passwords (8.3.6), MFA for all non-console access into the cardholder data environment (8.4.2) and automated log review (10.4.1.1). Version 4.0.1 did not move the date.
Does our PCI DSS penetration test have to be done by a QSA?
No. Requirements 11.4.2 and 11.4.3 require internal and external penetration testing by a qualified internal resource or a qualified external third party, with organisational independence of the tester, and state that the tester is not required to be a QSA or ASV. Your QSA then reviews the methodology and results as part of the assessment.
We use a hosted payment page. Are we out of scope?
Usually not entirely. Outsourcing the payment page can make you eligible for the shortest questionnaire, SAQ A, but that questionnaire now requires you to confirm your site is not susceptible to script attacks affecting your e-commerce systems, and to show quarterly ASV scans. Smaller is not the same as zero.
Our payment aggregator has asked about PCI DSS. Why?
The RBI’s Payment Aggregator Directions of September 2025 require aggregators to ensure their merchants’ infrastructure complies with security standards such as PCI-DSS where applicable, and to review PCI-DSS status during onboarding. The request is the aggregator meeting its own obligation.
Ready to scope it?
Send the date you are working to and roughly how large the organisation is. You will get a reply from a practitioner with an honest read on whether the date is reachable.
Related services
Network Penetration Testing
Test your network the way an outsider would, then the way someone already inside would — and prove that the boundaries you rely on to keep systems apart actually hold.
System Audit Report (SAR) for Data Localisation and Payment Compliance
Show that your payment data is stored only in India — across your systems and your vendors’ — before a CERT-In empanelled auditor tests it and signs the System Audit Report.
ISO/IEC 27001 — Information Security Management
Build an information security management system that survives Stage 2 — and the three years of surveillance that follow.
Related insights
Payment security
PCI DSS v4.0.1: what changed, what became mandatory in March 2025, and SAQ or ROC
Fifty-one requirements stopped being best practice on 31 March 2025, and whether you self-assess was never yours to decide.
Regulation · India
RBI payment data localisation: what the 2018 circular requires, and who signs the SAR
What the Reserve Bank’s 2018 storage direction requires, what the System Audit Report covers, and why only a CERT-In empanelled auditor can sign it.
