NPCI UPI / TPAP Security Audit

Introduction to the NPCI UPI / TPAP Security Audit

The Unified Payments Interface (UPI) has become the settlement backbone of India's retail digital payments, processing tens of billions of transactions each month. Every consumer-facing app that lets a user pay, collect or manage money over UPI does so as a Third Party Application Provider (TPAP) riding on the systems of a sponsor bank that acts as the Payment Service Provider (PSP). Because a TPAP handles authentication factors, virtual payment addresses (VPAs), mandate creation, and the mobile application in which UPI credentials are entered, it sits squarely inside the security perimeter that the National Payments Corporation of India (NPCI) governs. The NPCI UPI / TPAP Security Audit is the structured, evidence-based assessment through which a TPAP demonstrates to its sponsor bank, to NPCI and, ultimately, to the Reserve Bank of India (RBI) that it operates the app, its APIs and its supporting infrastructure in line with the UPI Procedural Guidelines, the NPCI circulars on TPAP security, and the RBI's baseline cyber-security expectations for the payments ecosystem.

This guide is written for security, compliance, engineering and product leaders at TPAPs, PSP banks and the payment-technology providers that build UPI stacks. It explains what the audit covers, who is in scope, how the control areas are structured, and — most importantly — provides an auditor-grade master checklist enumerating every domain a competent assessor will test, together with the evidence they will expect to see. Throughout, we distinguish clearly between what the sponsor PSP bank is accountable for and what the TPAP must own, because the shared-responsibility boundary is one of the most misunderstood aspects of UPI security governance.

What is the NPCI TPAP Audit

The NPCI TPAP Audit is a periodic security and compliance assessment of a Third Party Application Provider's UPI-facing environment. It is not a single monolithic certification like PCI DSS; rather it is a composite obligation stitched together from several NPCI and RBI instruments. In practice an assessor evaluates the TPAP against: the UPI Procedural Guidelines and their annexures; NPCI's circulars addressing TPAP onboarding, security requirements and the sharing of risk-and-compliance responsibilities between PSP and TPAP; the technical UPI API and Common Library (CL / UPI SDK) integration requirements; the applicable RBI directions such as the Master Direction on Digital Payment Security Controls and the outsourcing / IT governance directions; and, where card data or wallet balances are also handled, PCI DSS.

The audit takes the form of an independent review — typically by a CERT-In empanelled auditor — that produces a report used by the sponsor PSP bank to certify the TPAP to NPCI. NPCI mandates that this security assessment be carried out at least annually and after any material change to the application or its infrastructure. The output is normally a security audit report plus a compliance certificate, supported by a remediation tracker for any open findings. Unlike a self-attestation, the TPAP audit is expected to be conducted by an empanelled third party and countersigned in the assurance chain that runs TPAP to PSP bank to NPCI.

The audit's purpose is threefold: to protect the confidentiality and integrity of UPI credentials and payment instructions on the device and in transit; to ensure the TPAP cannot introduce fraud, data leakage or systemic risk into the shared UPI network; and to confirm that the TPAP has the governance, incident-response and resilience capabilities expected of a critical financial-infrastructure participant.

Who must comply

The obligation to undergo and evidence a TPAP security audit falls on any entity that provides a consumer or merchant application interface to UPI without itself being the account-holding or PSP bank. The table below summarises the principal categories and their obligations.

• Any app whose end-users create or manage a UPI VPA, link a bank account, set up an autopay mandate, or authorise a UPI PIN entry.
• Any entity that receives or processes the UPI transaction flows, callbacks or reconciliation data from the PSP switch.
• Multi-bank TPAPs sponsored by several PSP banks — each PSP relationship expects assurance, though a single consolidated audit report is typically produced.
• New TPAPs at onboarding (pre-go-live audit) and existing TPAPs on the recurring annual cadence and after major changes.

Structure of the NPCI TPAP Audit

There is no single official numbered control catalogue published for public consumption the way PCI DSS publishes twelve requirements; instead the audit scope is assembled from the security expectations spread across the UPI Procedural Guidelines, NPCI TPAP circulars, the UPI API/CL integration requirements and RBI's digital-payment security controls. For assessment purposes competent auditors organise these into a coherent set of control domains. The domain structure below is the working taxonomy CyberSigma uses to plan and execute a TPAP audit; it maps completely onto the underlying NPCI and RBI requirements while giving assessors a clean, testable structure.

Master assessment checklist

This is the core of the audit. For each domain below we set out what a competent assessor verifies and the evidence a TPAP is expected to produce. Treat every row as a discrete test step; do not treat any domain as optional. Where a control is owned by the PSP bank rather than the TPAP, the TPAP must still evidence that the split responsibility is documented and that its own portion is met.

D1 — Governance, risk and compliance

D2 — Application security (mobile app)

D3 — UPI credential and PIN handling

D4 — Device binding, SMS and registration

D5 — API and integration security

D6 — Cryptography and key management

D7 — Network, infrastructure and cloud security

D8 — Identity and access management

D9 — Data protection and privacy

D10 — Fraud risk management and transaction monitoring

D11 — Logging, monitoring and SOC

D12 — Vulnerability and patch management

D13 — Incident response and reporting

D14 — Business continuity and resilience

D15 — Outsourcing and third-party risk

D16 — Change and configuration management

D17 — Customer protection and grievance redressal

Scoping the assessment

Scoping is decisive for a defensible TPAP audit. Because UPI is a shared-responsibility ecosystem, the assessor must first draw the boundary between what the TPAP builds and operates and what the sponsor PSP provides. Everything that touches UPI credentials, transaction initiation, VPA/mandate management, device binding, or the data flows to and from the PSP switch is in scope. Corporate systems are in scope where they can affect the payment environment (for example, shared identity providers, CI/CD pipelines that deploy the app, and SOC/SIEM tooling).

• In scope: the consumer/merchant mobile app and its release pipeline; backend services handling UPI flows, VPA and mandates; the CL/UPI SDK integration; APIs to the PSP and NPCI; hosting infrastructure (on-prem or cloud) for UPI workloads; supporting security tooling (SIEM, WAF, HSM/KMS, PAM); and third parties operating any of the above.
• Conditionally in scope: analytics, notification, KYC and support systems, to the extent they process UPI-related PII or can influence the payment environment.
• Out of scope (but responsibility-mapped): the PSP switch, the NPCI central infrastructure, and the account-holding banks' core systems — these belong to the PSP/bank/NPCI and must be evidenced in the responsibility matrix rather than tested by the TPAP audit.
• Scope must be re-evaluated at every material change: new payment features (e.g., UPI Autopay, UPI Lite, credit-on-UPI), new hosting regions, new TSPs, or a change of sponsor PSP.

Implementation approach

A TPAP that is preparing for its first audit — or remediating findings from a prior one — benefits from a phased programme. The four phases below move from discovery to sustained assurance.

Phase 1 — Discovery and gap assessment

• Activities: confirm sponsor PSP relationship and shared-responsibility matrix; inventory all UPI-facing components, data flows and third parties; map current controls to the 17 domains; run an initial gap assessment and lightweight app/API scan.
• Deliverables: scope statement and asset/data-flow inventory; PSP-TPAP responsibility matrix; gap-assessment report with prioritised findings; risk register seeded.

Phase 2 — Remediation and control build-out

• Activities: implement missing controls (root detection, cert pinning, PIN-via-CL confirmation, device binding, HSM/KMS, SIEM onboarding, RBAC/PAM, fraud rules); harden infrastructure to baseline; formalise policies (IR, BCP, change, outsourcing, privacy).
• Deliverables: remediation tracker updated to closure; control implementation evidence pack; approved policy set; hardening and configuration baselines.

Phase 3 — Independent audit and testing

• Activities: engage a CERT-In empanelled auditor; perform VA/PT of app, API and infrastructure; execute the master checklist domain-by-domain; validate credential-handling and device-binding through dynamic testing; collect and review evidence.
• Deliverables: VA/PT reports; security audit report with findings and ratings; compliance certificate draft; management responses to findings.

Phase 4 — Certification, submission and continuous assurance

• Activities: close residual findings and obtain retest sign-off; finalise the audit report and certificate; submit to the sponsor PSP for onward assurance to NPCI; establish continuous monitoring and the annual/change-triggered re-audit cadence.
• Deliverables: signed audit report and compliance certificate; PSP submission acknowledgement; continuous-assurance calendar and metrics dashboard.

Maturity and scoring model

NPCI's audit outcome is fundamentally pass/remediate against mandatory requirements, but a maturity model helps a TPAP track its trajectory and prioritise investment beyond the minimum bar. CyberSigma applies the five-level capability model below to each of the 17 domains.

Assessment and audit approach

The independent assessment follows a repeatable sequence so that findings are defensible and reproducible.

1. Engagement and scoping: agree the boundary, obtain the PSP-TPAP responsibility matrix, and issue the scope and evidence request.
2. Documentation review: assess policies, architecture, data-flow diagrams, prior audit reports and the risk register against the 17 domains.
3. Control walkthroughs: interview owners for each domain and trace how mandated controls are designed and operated.
4. Technical testing: perform VA/PT on the app, APIs and infrastructure, including MITM/pinning, root/tamper, PIN-handling, replay and business-logic tests.
5. Configuration and log validation: sample-check hardening baselines, IAM, crypto/key management, SIEM coverage and retention.
6. Evidence sampling: collect and validate artefacts for each checklist row, testing operating effectiveness over a period, not just design.
7. Findings and rating: classify findings by severity, map to the responsible party (TPAP or PSP), and record management responses.
8. Remediation and retest: verify closure of high-severity findings and obtain retest evidence.
9. Reporting: issue the security audit report and compliance certificate with an executive summary and remediation tracker.
10. Submission and follow-up: support submission to the sponsor PSP/NPCI and set the re-audit cadence and continuous-monitoring plan.

Evidence request list

The following categorised list is the evidence a TPAP should assemble before the audit begins; having it ready materially shortens fieldwork.

• Governance: board-approved security policy, PSP-TPAP responsibility matrix, sponsor agreement, NPCI onboarding confirmation, org chart, CISO appointment, risk register, compliance calendar.
• Application: SDLC and threat-modelling records, app hardening/RASP config, obfuscation and pinning configuration, CL/UPI SDK version manifest, prior app VA/PT reports.
• Credential and device: PIN-handling data-flow and design, device-binding design, SMS-validation logs, registration/set-PIN flow walkthroughs.
• APIs and crypto: API specification conformance, TLS scan reports, message-signing evidence, crypto standard, HSM/KMS inventory, key-management and rotation logs, certificate register.
• Infrastructure and cloud: network diagrams, firewall rulebase, hardening baselines and scan reports, WAF/DDoS config, cloud responsibility matrix and CSPM reports, data-residency evidence.
• IAM: RBAC matrix, MFA config, PAM policy and session logs, JML records, access-review sign-offs.
• Data and privacy: data classification and inventory, retention schedule, DPDP consent and grievance-officer records, masking/tokenisation evidence.
• Fraud and monitoring: fraud-rule catalogue, alert samples, mule/limit configuration, CPFIR/fraud-reporting records, SIEM architecture and log-source inventory, SOC use-cases.
• Resilience: BCP/DR plans, DR-drill reports, capacity and availability/SLA reports.
• Third party: vendor due-diligence records, contracts with right-to-audit clauses, sub-processor register, vendor assurance reports (SOC 2 etc.).
• Change and incident: change policy and sample tickets, environment inventory, IR plan and playbooks, prior incident/breach notifications and acknowledgements, PIR/RCA reports.
• Customer protection: grievance SOP and published TAT, dispute/ODR handling evidence, complaint MIS, nodal/grievance-officer disclosures.

Roles and responsibilities

KPIs to track

• Percentage of mandatory controls implemented across the 17 domains (target 100% before certification).
• Number and ageing of open audit/VA/PT findings by severity, and mean time to remediate.
• VA/PT cadence adherence: annual and post-major-change tests completed on schedule.
• Patch compliance rate and mean time to patch critical vulnerabilities.
• Fraud detection rate, false-positive rate, and fraud-reporting timeliness to NPCI/RBI.
• UPI service availability / uptime against target and successful DR-drill completion.
• Percentage of privileged access under PAM and access-review completion rate.
• SIEM log-source coverage and mean time to detect / respond to security alerts.
• Grievance turnaround-time compliance and dispute-resolution rate.
• Third-party assurance coverage: percentage of material providers with current assurance reports.

Readiness checklist

• Sponsor PSP relationship confirmed and PSP-TPAP responsibility matrix documented
• Board-approved UPI/information-security policy in place and current
• Complete scope statement, asset inventory and data-flow diagrams prepared
• UPI PIN captured only via the PSP Common Library; app never sees or stores the PIN
• Root/jailbreak detection, anti-tamper, obfuscation and certificate pinning implemented
• Device hard-binding and SMS validation operational with new-user limits
• TLS 1.2+, message signing, replay protection and rate limiting on all APIs
• HSM/KMS-backed key management with documented lifecycle and certificate monitoring
• Network segmentation, hardening baselines, WAF/DDoS and cloud posture management in place
• RBAC, MFA for admins, PAM and periodic access reviews operating
• Data localisation, DPDP consent/grievance and masking controls implemented
• Real-time fraud monitoring, velocity limits and NPCI/RBI fraud reporting configured
• Centralised SIEM, 24x7 monitoring, log retention and NTP sync established
• Annual VA/PT completed with findings tracked to closure and retested
• IR plan, CERT-In/NPCI/RBI reporting SOP and tabletop drills in place
• BCP/DR with tested RTO/RPO and DR-drill evidence
• Outsourcing due diligence, right-to-audit clauses and sub-processor register complete
• Grievance mechanism, published TAT and ODR/dispute integration live
• Independent CERT-In empanelled auditor engaged and evidence pack assembled

Common gaps

• Treating the PSP as owning all security and failing to document or evidence the TPAP's own share of responsibilities.
• Custom PIN-entry fields or logging that inadvertently touch UPI credentials instead of relying solely on the Common Library.
• Missing or bypassable root/jailbreak detection, anti-tamper and certificate pinning, exposed by MITM tests.
• Weak or absent device hard-binding and SMS validation, enabling account takeover across devices.
• Collect-request and QR-code flows without adequate anti-social-engineering controls and consent screens.
• Inadequate transaction-monitoring rules and slow or missing fraud reporting to NPCI/RBI (e.g., CPFIR).
• Sensitive data stored outside India or logs/non-production environments containing unmasked PII, breaching localisation and DPDP norms.
• Key material handled outside an HSM/KMS, with no documented rotation or certificate-expiry monitoring.
• VA/PT performed but findings left open, or testing not repeated after major releases and feature launches.
• Third-party/TSP arrangements without right-to-audit clauses, sub-processor visibility or current assurance reports.
• Incident-response and BCP/DR plans that exist on paper but are never drilled, so reporting timelines are missed under pressure.
• Running deprecated CL/UPI SDK versions or app builds no longer compatible with NPCI requirements.

NPCI TPAP Audit mapped to other frameworks

TPAPs rarely operate under NPCI requirements alone. Mapping the TPAP control domains to adjacent frameworks lets an organisation reuse evidence and run a single integrated assurance programme.

How CyberSigma helps

Frequently asked questions

Need help with NPCI TPAP Audit?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.