A practical PCI DSS risk assessment example for Indian merchants: score payment risks, assign controls, document evidence and meet PCI DSS v4.0.1.
One forgotten checkout script can expose card data without breaking the payment flow, leaving an Indian merchant with an incident, an acquirer investigation and a damaged payment relationship. This PCI DSS risk assessment example shows how to turn that exposure into named risks, tested controls and evidence an assessor can actually verify.
The example is designed for an Indian e-commerce or D2C business using a payment aggregator, hosted page or embedded form. It does not replace the correct Self-Assessment Questionnaire (SAQ), Report on Compliance (ROC), or advice from your acquirer or Qualified Security Assessor (QSA).
Why Does an Indian Merchant Need a PCI DSS Risk Assessment?
Payment Card Industry Data Security Standard, or PCI DSS, is the card industry's security standard for entities that store, process or transmit payment account data, or could affect its security. The current standard is PCI DSS v4.0.1. It is not an Indian statute, but your acquiring bank, payment aggregator or card brand can make compliance a contractual condition of accepting cards.
Indian regulation adds another layer. The Reserve Bank of India's 24 June 2022 circular on restriction on storage of actual card data required entities in the card-payment chain, other than card issuers and card networks, to purge card-on-file data after 30 September 2022. A merchant therefore cannot treat PCI DSS compliance as permission to keep actual card credentials. PCI DSS and RBI requirements must both be checked; meeting one does not cancel the other.
The PCI Security Standards Council, or PCI SSC, uses “targeted risk analysis” for two specific purposes:
- Activity frequency: PCI DSS Requirement 12.3.1 applies where a requirement permits an entity to decide how often an activity will occur. The analysis must identify protected assets, threats, likelihood and impact factors, justify the chosen frequency, and be reviewed at least every 12 months.
- Customized controls: Requirement 12.3.2 applies when an entity uses the Customized Approach instead of a defined PCI DSS control. The entity must show that its control meets the security objective and provides equivalent protection.
These are not excuses to skip controls. PCI SSC's targeted risk analysis guidance says the analysis supports a defined frequency or a customized approach. It does not let management decide that an inconvenient requirement is unnecessary.
Requirement 12.3.1 and other future-dated v4.x requirements became effective on 31 March 2025.
Start by Mapping the Card-Payment Flow and PCI Scope
A risk register built before scoping is mostly fiction. Draw the transaction from the customer's browser to authorization and settlement. Include every component that stores, processes or transmits account data, every system that can connect to those components, and every person or service provider that can affect their security.
For a typical Indian D2C merchant, map the storefront and checkout; browser scripts; the aggregator's redirect, hosted fields or iframe; APIs and webhooks; administrator and developer access; logs and support tools; hosting providers; refunds and token workflows; and every payment service provider.
Do not assume “we use a gateway” means “nothing is in scope.” PCI SSC explains that SAQ A eligibility depends on all payment-page elements originating directly from a PCI DSS validated provider and on meeting every other SAQ A criterion. Its SAQ A guidance for e-commerce scripts also requires eligible merchants using an embedded payment page to confirm that their site is not susceptible to script attacks, either through suitable protections or confirmation from the provider.
Ask the acquirer or payment aggregator which validation document it accepts. A redirect, iframe, direct-post form, virtual terminal and merchant-hosted payment page have different exposure. Choosing the shortest SAQ because it looks convenient is not risk management.
Record four scoping facts before scoring anything:
Scope field | Example entry
Payment channel | Web checkout using provider-hosted fields in an iframe
Account data handled | Merchant does not intentionally store PAN or sensitive authentication data
Systems that can affect security | Storefront, tag manager, admin panel, deployment pipeline and DNS
Validation route | Confirm with payment aggregator; current assumption is SAQ A subject to all eligibility criteria
PAN means primary account number, the long card number. Sensitive authentication data includes full track data, card verification codes and PIN data. Never put real card data into the risk register, screenshots or test evidence.
Copy This PCI DSS Risk Assessment Example
Use one row for one risk scenario. “Cyberattack” is too vague. “An unauthorized tag-manager user inserts a checkout script that copies PAN before submission” is testable.
This worked example assumes a medium-sized Indian D2C merchant with an iframe supplied by a PCI DSS validated payment aggregator. Scores use likelihood from 1 to 5 and impact from 1 to 5. Inherent risk is measured before current controls; residual risk is measured after controls.
ID | Asset and threat scenario | Inherent risk | Key controls and evidence | Residual risk | Owner and review
PAY-01 | Checkout page: unauthorized JavaScript skims card data or changes the payment frame | 5 × 5 = 25 | Script inventory; approval for each script; restricted tag-manager access; Content Security Policy; integrity controls where suitable; change or tamper alerts; weekly evidence review | 2 × 5 = 10 | Engineering lead; monthly and after checkout changes
PAY-02 | Admin account: stolen credentials let an attacker change checkout or redirect settings | 4 × 5 = 20 | Unique IDs; phishing-resistant multi-factor authentication where supported; least privilege; quarterly access review; immediate leaver removal; authentication logs | 2 × 5 = 10 | Security owner; quarterly and on role change
PAY-03 | Provider failure: payment aggregator's PCI status expires or its responsibility is misunderstood | 3 × 5 = 15 | Current Attestation of Compliance; written responsibility matrix; contract security clauses; incident contacts; annual service-provider review | 2 × 4 = 8 | Finance and security; annually and before renewal
PAY-04 | Support process: staff copy a PAN or card-verification code into tickets, chat or recordings | 4 × 5 = 20 | Written prohibition; redaction; restricted recordings; staff training; ticket search; deletion workflow; monthly sample review | 2 × 5 = 10 | Support head; monthly
PAY-05 | Stored data: legacy database, logs or backups retain actual card-on-file data contrary to RBI direction | 3 × 5 = 15 | Data discovery; log masking; approved token use; retention schedule; purge evidence; backup checks; quarterly scans for PAN patterns | 1 × 5 = 5 | Data protection owner; quarterly
PAY-06 | Vulnerability: critical checkout dependency remains unpatched and is exploited | 4 × 5 = 20 | Software inventory; vulnerability feeds; risk ranking; critical patch within one month under PCI DSS Requirement 6.3.3; deployment evidence; exception approval | 2 × 5 = 10 | Engineering lead; continuous intake, monthly reporting
PAY-07 | Incident delay: the team detects suspicious checkout changes but does not contact the aggregator or acquirer promptly | 3 × 5 = 15 | Tested incident plan; current call tree; evidence-preservation steps; provider notification clauses; tabletop exercise | 2 × 4 = 8 | Incident lead; every six months
The numbers are not universal. If your own checkout captures PAN before sending it to a processor, PAY-01 has a wider scope and the controls above are incomplete. If a call centre accepts card details, include telephony, recordings, workstations, physical access and staff processes.
For every row, attach evidence. A policy saying “access is reviewed” does not prove that April's review happened. Use dated approvals, exported access lists, alert tickets, provider attestations, training records, scan reports and closed remediation tickets.
How Should You Score and Approve Each Risk?
Use a scoring method simple enough that teams apply it consistently. Rate likelihood from 1, rare with strong controls and no known exposure, to 5, almost certain because a known exposure or absent control exists. Rate impact from 1, negligible interruption and no account-data exposure, to 5, broad compromise, payment suspension or severe business damage.
Multiply the scores. Treat 15 to 25 as high, 8 to 12 as medium and 1 to 6 as low. These bands are management priorities, not PCI SSC grades.
Risk acceptance needs a named approver, reason, expiry date and conditions. High residual risks should have a remediation plan, budget, owner and due date.
Do not reduce impact merely because a control exists. Multi-factor authentication may reduce takeover likelihood, but not the harm if takeover succeeds.
Build a Valid Requirement 12.3.1 Targeted Risk Analysis
The general register above helps management prioritize work. A Requirement 12.3.1 targeted risk analysis has a narrower job: justify the frequency of a PCI DSS activity where the standard explicitly allows a risk-based frequency.
Use this copyable structure:
Required field | Example for payment-page tamper detection
PCI DSS requirement | 11.6.1, change and tamper detection for payment pages
Asset protected | Checkout page, HTTP headers, iframe integration and customer account data
Threat | Unauthorized script, changed header or modified payment redirect
Likelihood factors | Public page; weekly deployments; four third-party scripts; restricted deploy access; prior incidents: none
Impact factors | Silent theft can continue while checkout still works; possible account-data compromise and acquirer action
Selected frequency | Automated evaluation daily; alert triage each business day; documented review weekly
Justification | Frequent code and script changes make a longer interval unreasonable; automation keeps daily monitoring proportionate
Owner and evidence | Security lead; alert logs, triage tickets and weekly signed review
Approval and next review | CTO approval; review within 12 months or after a major checkout, provider or threat change
PCI DSS Requirement 11.6.1 sets at least weekly performance as the defined baseline, or a periodic frequency supported by the targeted risk analysis. The analysis should explain why your chosen frequency minimizes the chance of the threat being realized. “Management decided monthly” is not analysis.
Requirement 12.3.1 itself requires the targeted analysis to be reviewed at least once every 12 months and updated when needed. Use earlier trigger reviews after a payment-page redesign, new provider, material incident, acquisition, hosting migration, new script manager or major change in transaction volume.
For merchants eligible for the January 2025 SAQ A, PCI SSC removed Requirements 6.4.3, 11.6.1 and their supporting 12.3.1 item from that questionnaire, but it did not remove the underlying payment-page security concern from PCI DSS. The Council added an eligibility statement requiring the merchant to confirm its site is not susceptible to script attacks. Document the method and provider confirmation instead of interpreting the shorter SAQ as permission to ignore checkout integrity.
What Evidence Should Be Ready for an Assessor or Acquirer?
Create an evidence index with a clear owner and retention period. Keep current payment-flow and network diagrams; the scope and SAQ or ROC decision; completed validation documents and scans; targeted analyses; the script inventory; access reviews; patch tickets; provider agreements and compliance evidence; incident exercises; and proof that actual card data is not retained.
An Attestation of Compliance records an SAQ or ROC result; it does not transfer all responsibility. Document merchant, provider and shared controls.
Do not collect evidence only in the week before validation. Set recurring tasks for access review, provider review, script review, vulnerability treatment and targeted-risk-analysis renewal. If an employee leaves or a payment provider changes mid-year, an annual calendar alone will miss the event.
A 30-Day Action Plan for Indian E-Commerce Teams
Days 1–5: confirm the payment design. Draw the flow, list providers and identify whether the site redirects, embeds an iframe, uses hosted fields or captures card data. Get the correct SAQ and submission route in writing.
Days 6–10: remove forbidden data. Search databases, logs, tickets, analytics, recordings and backups. Quarantine findings, preserve necessary incident evidence, purge safely and confirm that recurring payments use permitted tokens.
Days 11–15: build the register. Replace the example assumptions with your systems, score risk, name one owner per control and date every high-risk remediation.
Days 16–20: test checkout integrity. Inventory scripts, remove unnecessary tags, restrict deployment access and test change detection. Obtain the provider's implementation instructions and SAQ A confirmation where relevant.
Days 21–25: check people and providers. Review privileged access, leavers, shared accounts, contracts, provider evidence and incident contacts. Train support staff never to copy card-verification codes.
Days 26–30: approve and schedule. Approve risk treatment, complete validation, index evidence and schedule the annual Requirement 12.3.1 review plus event-based reviews.
Frequently Asked Questions
Is PCI DSS legally mandatory in India?
PCI DSS is an industry standard, not an Act of Parliament. However, acquiring banks, payment aggregators and card brands can require it contractually. RBI's payment-aggregator framework also expects merchant infrastructure connecting to aggregators to meet PCI DSS controls, so ignoring it can put card acceptance at risk.
Does using Razorpay, Cashfree or another payment aggregator remove PCI scope?
No. Outsourcing can reduce scope, but the exact integration and every SAQ eligibility condition matter. Confirm the applicable SAQ with the provider or acquirer and document shared responsibilities.
Can an Indian merchant store card numbers if they are encrypted?
Do not assume so. RBI's card-on-file direction required merchants and other entities in the payment chain, except card issuers and card networks, to purge actual card data after 30 September 2022. Use the approved tokenization route and confirm edge cases with your payment provider.
How often must a PCI DSS targeted risk analysis be reviewed?
Requirement 12.3.1 requires review at least once every 12 months and an update when needed. Major changes to checkout, providers, scope, technology or threats should trigger an earlier review.
Is a general cybersecurity risk register enough for PCI DSS 12.3.1?
Usually not by itself. A valid targeted risk analysis must identify the exact PCI DSS requirement, assets, threats, likelihood and impact factors, selected activity frequency, justification, review and update process.
Who should approve PCI DSS risk acceptance?
The approver should have authority over the business impact and remediation budget. Security or engineering can analyze the risk, but high payment, contractual or customer risk normally needs accountable senior management approval.
Turn This PCI DSS Risk Assessment Example Into a Live Control
A spreadsheet is useful only while its owners, evidence and legal assumptions stay current. Use this PCI DSS risk assessment example to establish the first register, then link every row to the correct PCI DSS v4.0.1 requirement, RBI direction, provider contract, control owner and review trigger.
Payment security is only one part of an Indian business's compliance exposure. Check your broader compliance posture free at complianceradar.in and build one timeline for the obligations that apply to your business.