PCI DSS (Payment Card Industry Data Security Standard) is a global set of technical and operational requirements, maintained by the PCI Security Standards Council, for any organization that stores, processes, or transmits payment card data. In India, PCI DSS applies directly to online and offline merchants accepting card payments, and it applies with extra regulatory weight to payment aggregators and payment gateways, which the Reserve Bank of India requires to meet card-network data security standards under its Payment Aggregator and Payment Gateway (PA-PG) framework. This guide covers who must comply, what the 12 requirements actually demand, which Self-Assessment Questionnaire (SAQ) applies to your business, and a practical roadmap to get compliant without stalling your engineering roadmap.
Card data breaches are expensive, and regulators on both the card-network side (PCI SSC) and the banking side (RBI) have converged on the same expectation: if you touch a card number, you own the responsibility for protecting it, regardless of company size.
Who Needs to Comply in India
PCI DSS is not an Indian government law, but it functions like one for any business in the card payment chain, because Visa, Mastercard, RuPay, and other card networks contractually require it through your acquiring bank or payment aggregator agreement. Three groups in India are directly in scope.
Merchants. Any business — online or offline — that accepts card payments and stores, processes, or transmits cardholder data (the card number, expiry date, cardholder name, or service code) is contractually obligated to be PCI DSS compliant, even a small D2C brand using a hosted checkout page.
Payment aggregators and payment gateways. RBI's Master Direction on Payment Aggregators and Payment Gateways requires PAs to be authorized entities that meet baseline data security standards, and in practice, card network rules require these entities to be validated against the full PCI DSS standard given the volume and sensitivity of card data flowing through their systems. An unauthorized or non-compliant aggregator faces both card-network penalties and RBI regulatory action.
Service providers. Hosting providers, payment processors, and any third party that stores or transmits cardholder data on behalf of a merchant or aggregator are also in scope, typically validated against the more demanding service-provider SAQ tiers.
The Compliance Journey — From Scoping to Attestation
Most Indian businesses treat PCI DSS as a single audit event. It is more accurate to treat it as a recurring process with a defined starting point: knowing exactly where cardholder data lives.
Scoping is the step Indian merchants skip most often, and it's the one that determines everything downstream. If your cardholder data environment (CDE) is poorly defined, you either over-scope (assessing systems that never touch card data, wasting effort) or under-scope (missing a system that does touch card data, leaving a real gap). A tightly segmented network — where the systems handling card data are isolated from the rest of your infrastructure — shrinks both your PCI scope and your actual attack surface at the same time.
The 12 PCI DSS Requirements, Grouped by Control Objective
PCI DSS v4.0.1, the current version maintained by the PCI Security Standards Council, organizes its 12 core requirements under six broader control objectives. Reading the requirements in this grouped form makes the standard far easier to reason about than reading all 12 as a flat list.
| Control Objective | Requirements | What It Covers |
|---|---|---|
| Build and Maintain a Secure Network and Systems | Req 1–2 | Firewall configuration, no vendor-default passwords or security parameters |
| Protect Cardholder Data | Req 3–4 | Encrypt stored card data, encrypt data in transit across open public networks |
| Maintain a Vulnerability Management Program | Req 5–6 | Anti-malware controls, secure software development and patch management |
| Implement Strong Access Control Measures | Req 7–9 | Need-to-know access, unique IDs and authentication, physical access restrictions |
| Regularly Monitor and Test Networks | Req 10–11 | Logging and tracking all access, regular vulnerability scans and penetration testing |
| Maintain an Information Security Policy | Req 12 | A formal, maintained security policy covering all personnel |
Two requirement areas deserve extra attention for Indian businesses. Requirement 6, on secure software development, is where most e-commerce breaches actually happen — attackers exploit an unpatched CMS plugin or a flaw in custom checkout code rather than breaking encryption. Requirement 11, on regular testing, is where periodic vulnerability scanning and penetration testing stop being a paperwork exercise and start catching real, exploitable issues before an attacker does.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanSAQ Levels — Which One Applies to Your Business
Not every merchant undergoes a full on-site PCI DSS audit by a Qualified Security Assessor (QSA). The PCI Security Standards Council defines nine Self-Assessment Questionnaire (SAQ) types, matched to how a merchant actually accepts and handles card data, and RBI-regulated payment aggregators additionally set their own merchant transaction-volume thresholds for which validation path applies.
| SAQ Type | Who It's For |
|---|---|
| SAQ A | Card-not-present merchants who fully outsource payment processing to a PCI DSS validated third party |
| SAQ A-EP | E-commerce merchants whose website affects the payment transaction, even if card data never touches their servers |
| SAQ B / B-IP | Merchants using standalone, PCI-approved payment terminals with no electronic cardholder data storage |
| SAQ C-VT | Merchants using a virtual payment terminal, manually keying in card data on an isolated computer |
| SAQ C | Merchants with a payment application connected to the internet, but no electronic cardholder data storage |
| SAQ P2PE | Merchants using a validated point-to-point encryption solution end-to-end |
| SAQ D (Merchant) | All merchants not eligible for a simpler SAQ — the most comprehensive merchant questionnaire |
| SAQ D (Service Provider) | Service providers and payment aggregators not eligible for a simpler SAQ |
A Practical Compliance Roadmap for Indian Businesses
PCI DSS compliance is achievable in phases, and most of the cost is engineering effort rather than external spend, especially if you start from a reduced-scope architecture.
- Reduce your scope first. Route card data through a PCI DSS validated payment gateway using a redirect or hosted iframe rather than handling raw card numbers on your own servers. This alone moves most merchants from a heavy SAQ D obligation to a lighter SAQ A or A-EP.
- Inventory the cardholder data environment. Document every system, network segment, and third party that stores, processes, or transmits card data — including logs, backups, and support tooling that might inadvertently capture card numbers.
- Run a gap assessment against the 12 requirements. Map your current firewall rules, encryption practices, access controls, and logging against each requirement and record every gap explicitly rather than assuming coverage.
- Remediate the highest-risk gaps first. Unpatched internet-facing systems, default credentials, and unencrypted card data in transit or at rest are the gaps attackers exploit fastest — fix these before addressing documentation-only gaps.
- Test before you attest. Run vulnerability scans and, where required, a full penetration test of the cardholder data environment. This is also the point at which working with a CERT-In empanelled partner for the assessment strengthens your evidence trail for both PCI DSS and RBI expectations.
- Complete the correct SAQ or QSA assessment and submit the Attestation of Compliance (AOC) to your acquiring bank or payment aggregator, who will typically require it before renewing your merchant agreement.
- Treat compliance as continuous, not annual. Quarterly ASV scans, ongoing patch management, and log monitoring are required between formal assessments, not just in the weeks before renewal.
Where VAPT Fits Into PCI DSS
Requirement 11 is where PCI DSS and penetration testing intersect directly, and it's also where most Indian businesses under-invest relative to what the standard actually expects. A quarterly ASV scan checks for known vulnerabilities on internet-facing systems; it does not test whether those vulnerabilities are chainable into an actual compromise of the cardholder data environment, which is what a proper penetration test evaluates. Bachao.AI, built by Dhisattva AI Pvt Ltd, runs automated VAPT scans that surface exactly the class of exposed services, misconfigurations, and application-layer flaws that PCI DSS Requirement 11 assessments are designed to catch, giving merchants and payment aggregators continuous visibility between formal assessment cycles. If you want a current picture of your externally-facing attack surface before your next PCI DSS review, a free VAPT scan is a fast starting point, and teams also working through India's data protection obligations can review DPDP compliance requirements alongside PCI DSS. More practical compliance breakdowns like this one are available on the blog.