PCI DSS Compliance Services for Enterprises in India
Achieve and maintain PCI DSS v4.0.1 compliance with end-to-end payment security assessments, QSA-ready evidence generation, and a clear read on the future-dated requirements that became mandatory in March 2025 — delivered by a CERT-In empanelled firm trusted by leading BFSI and fintech enterprises.
Trusted by India's leading enterprises
Before anything else
Scope is the whole economics of PCI DSS
Every other decision on this page is downstream of one question: which systems store, process or transmit account data, and which merely touch something that does. These are the four positions organisations actually occupy.
| State | What it means | What follows |
|---|---|---|
| Fully outsourced, correctly | Payment pages are redirected or fully hosted by the provider, and account data never reaches your systems in any form. | The smallest scope available and the cheapest validation. The condition is that it is actually true: an integration that posts card data through your page before forwarding it is not this, however it was sold. |
| Segmented, and the segmentation is tested | The cardholder data environment is isolated by controls that are verified to work, so the systems outside it are out of scope by evidence, not by diagram. | The best position for anyone who genuinely handles account data. Segmentation testing is what converts an architectural intention into a defensible scope reduction, and it pays for itself in audit effort. |
| Segmented on the diagram only | The network diagram shows a separated environment; the firewall rules, jump hosts, shared directory services and management tooling connect it to everything else. | The most expensive discovery available, because it is usually made during assessment when the scope has already been priced. Connected-to systems are in scope, and the assessor decides that, not the diagram. |
| Undefined | Nobody can currently say where account data flows, which is common where payments were added product by product over several years. | Data-flow discovery before anything else. Starting remediation before the flows are known is how organisations pay to harden systems that should have been taken out of scope instead. |
- Scope is defensible
- Unknown, and therefore unbudgeted
- Costs the most to discover late
The paperwork
What you end up holding, and who is allowed to produce it
PCI DSS validation produces a small number of specific artefacts. Knowing which one applies to you decides who you need to engage and when.
| Artefact | What it is | Who produces it |
|---|---|---|
| Report on Compliance | The full assessment document, produced where the acquirer or card brand requires an on-site assessment. It records how each requirement was tested and what the evidence was. | A Qualified Security Assessor, or an Internal Security Assessor where permitted |
| Self-Assessment Questionnaire | A self-validation route, with several versions matched to how payments are accepted. Choosing the wrong one is common and is usually discovered by the acquirer. | You, normally with support |
| Attestation of Compliance | The signed summary artefact that accompanies either route. This is the document your acquirer and your enterprise customers actually ask to see. | Signed by you, and by the assessor where one was engaged |
| ASV scan reports | External vulnerability scans of internet-facing systems in scope, run on a quarterly cadence and to a passing result. | An Approved Scanning Vendor |
| Penetration test reports | Internal and external testing of the cardholder data environment under Requirement 11.4, including validation that segmentation holds where scope reduction depends on it. | Security Brigade, CERT-In empanelled since 2008 |
| Security Brigade is not a Qualified Security Assessor. We produce the testing evidence, close the findings and package the artefacts so your QSA assessment is short. We say so plainly, because a firm that blurs this is telling you something about how it handles the rest of the detail. | ||
Report on Compliance
- What it is
- The full assessment document, produced where the acquirer or card brand requires an on-site assessment. It records how each requirement was tested and what the evidence was.
- Who produces it
- A Qualified Security Assessor, or an Internal Security Assessor where permitted
Self-Assessment Questionnaire
- What it is
- A self-validation route, with several versions matched to how payments are accepted. Choosing the wrong one is common and is usually discovered by the acquirer.
- Who produces it
- You, normally with support
Attestation of Compliance
- What it is
- The signed summary artefact that accompanies either route. This is the document your acquirer and your enterprise customers actually ask to see.
- Who produces it
- Signed by you, and by the assessor where one was engaged
ASV scan reports
- What it is
- External vulnerability scans of internet-facing systems in scope, run on a quarterly cadence and to a passing result.
- Who produces it
- An Approved Scanning Vendor
Penetration test reports
- What it is
- Internal and external testing of the cardholder data environment under Requirement 11.4, including validation that segmentation holds where scope reduction depends on it.
- Who produces it
- Security Brigade, CERT-In empanelled since 2008
Security Brigade is not a Qualified Security Assessor. We produce the testing evidence, close the findings and package the artefacts so your QSA assessment is short. We say so plainly, because a firm that blurs this is telling you something about how it handles the rest of the detail.
What v4 actually changed
The customised approach, and why it raises the bar instead of lowering it
PCI DSS v4.0.1 is the current version, a limited revision of v4.0 issued in June 2024, and the transition is finished: v3.2.1 was retired on 31 March 2024, and the future-dated requirements that v4 introduced with a grace period became mandatory on 31 March 2025. So there is no longer a phase-in to plan around; there is only the standard. The structural change worth understanding is that v4 offers two routes to meeting a requirement. The defined approach is the familiar one: implement the control as written, and be tested against it. The customised approach lets an organisation meet the stated security objective by a different means, which sounds like flexibility and is better understood as a documentation obligation. Taking it means producing a targeted risk analysis, designing and documenting the alternative control, defining how its effectiveness will be tested, and satisfying an assessor that the objective is genuinely met. It is a good fit for mature organisations with an unusual architecture and a poor fit for anyone reaching for it to avoid remediation, because the evidentiary burden is higher than simply implementing the control. The same logic runs through the rest of v4: more requirements now turn on a targeted risk analysis that says why your chosen frequency or method is appropriate, which means the standard increasingly tests whether you can justify your decisions, not only whether you made them.
Where we do the work
The testing and the evidence, so the assessment is short
Data-flow discovery and scope reduction
Establish where account data actually flows, then reduce what has to be assessed. Scope reduction is the only lever that lowers both the assessment cost and the ongoing control burden at the same time.
Segmentation validation
Testing that the isolation your scope depends on actually holds. Where scope reduction is claimed on segmentation, this is the evidence that makes the claim defensible instead of asserted.
Penetration testing of the cardholder data environment
Internal and external testing of the systems in scope, covering payment flows, the applications and APIs that carry them, and the infrastructure beneath.
Application and API testing of payment flows
Manual testing of the checkout, refund, stored-credential and reconciliation paths, where logic flaws live that a scanner will not reach.
Evidence packaging for your QSA
Findings, retest results and closure evidence assembled into QSA-ready packages through Lemon, with remediation tracked to verified closure and not to a ticket being marked done.
Reading across to your Indian obligations
For BFSI and fintech, the same testing evidence answers RBI expectations on the payments estate. Running the two programmes together is materially cheaper than running them cold.
Methodology
How a compliance engagement runs
Every engagement follows this process through Lemon, our proprietary audit management platform.
Security Brigade follows a rigorous compliance audit methodology that covers all 12 PCI DSS requirement families. Every phase is orchestrated through our proprietary Lemon platform, which ensures consistent execution, centralised artefact management, and daily progress visibility. Our approach is specifically designed to produce QSA-ready evidence that satisfies both PCI Council requirements and Indian regulatory mandates from RBI and CERT-In simultaneously.
Scoping and CDE Mapping
We identify and document your complete Cardholder Data Environment including all systems, network segments, personnel, and third-party connections that store, process, or transmit cardholder data. Payment flows are mapped end-to-end.
Gap Analysis Against PCI DSS v4.0.1
Systematic assessment of your current security posture against all PCI DSS v4.0.1 requirements. Each control is evaluated for implementation status with detailed gap documentation and risk prioritisation for remediation planning.
Remediation Roadmap and Support
We deliver a prioritised remediation roadmap with technology-specific guidance for every identified gap. Our team conducts walkthrough sessions with your technical teams and provides ongoing advisory support throughout the remediation process.
Penetration Testing per Req 11.4
Full internal and external penetration testing of the CDE as required by PCI DSS Requirement 11.4. Testing covers network segmentation validation, web application testing of payment flows, and API security assessment with QSA-ready evidence and proof-of-concepts.
Payment Ecosystem Monitoring via ShadowMap
ShadowMap, our EASM platform, provides continuous monitoring of your payment processor ecosystem and third-party service providers as required by Requirement 12.8. This includes dark web monitoring, credential leak detection, and supply chain risk visibility.
Evidence Packaging and QSA Support
We compile all assessment artefacts, test results, remediation evidence, and compliance documentation into QSA-ready packages. Our team supports you through the QSA assessment with clarifications, additional evidence, and technical guidance as needed.
"We ship 50 deploys a week. Traditional pentesting firms take three weeks to deliver a report that's already stale. Security Brigade's B-52 engine generates structured test plans and validates coverage in days, not weeks. Their AI doesn't replace testers — it makes sure nothing gets missed. We've caught business logic flaws in our payment orchestration that SAST and DAST both labelled 'low priority.'"
Continuous Compliance with ShadowMap
The audit gives you a snapshot. ShadowMap gives you the always-on view.
An annual audit proves your posture at a single point in time. Between audits, attack surfaces drift, credentials leak, sub-domains get added, vendors get breached. ShadowMap watches the boundary continuously so the next audit isn't a surprise.
CART · Continuous Automated Red-Teaming
Automated vulnerability detection and validation on your live attack surface — exploit context delivered, not just scanner noise.
Annual audits prove a moment. CART proves resilience continuously.
Explore on ShadowMapThreat Intelligence
1,000+ threat actor profiles, CVE tracking against your stack, IOC monitoring, and geographic threat analysis.
Know which threats are coming for you specifically.
Explore on ShadowMapThe platform underneath
The instrument sets the cadence. B-52 is what runs at it.
Requirement 11 is the testing requirement, and it is separable from the audit built around it. B-52 addresses that requirement specifically, including what a scan record does and does not satisfy on its own.
FAQ
PCI DSS v4.0.1, answered for the person scoping it
The questions that decide cost and timing. Talk to our team about your payment architecture.
Contact usIs Security Brigade a QSA?
Which version applies to us?
How much can we reduce scope?
What is the customised approach, and should we use it?
How often do we need penetration testing?
Start Your PCI DSS v4.
0.1 Compliance Journey Today
Talk to our compliance experts about your payment security requirements and get a tailored roadmap to certification
Typically responds within 1 business day · No commitment required
Our reading of the circulars