Third-party risk management for Indian regulated entities: an integrated regulatory perspective

Practitioner reference for CISOs, vendor management leads, and risk officers in Indian regulated entities · 2026-05-24 · Reflects RBI, SEBI, IRDAI, DPDPA, and CERT-In requirements through Q1 2026

Why TPRM in India is a different beast

If you are running third-party risk management at an Indian bank, NBFC, insurer, broker-dealer, or any other regulated entity, you are not running one TPRM programme. You are running five.

You have the RBI's requirements (outsourcing guidelines, IT outsourcing directions, the SAR ecosystem, the new co-lending oversight). You have SEBI's framework for market intermediaries. You have IRDAI's requirements for insurance entities. You have DPDPA's processor obligations across all of them. You have CERT-In's requirements for any vendor that touches your incident response. And underneath all of it, you have the operational reality that your vendors are themselves outsourced, your subcontractors have subcontractors, and the actual data flows look nothing like your contracts say they should.

This guide is for the people running that programme. It is not a reading of each regulation in isolation — that's what the underlying regulator websites are for. It is an integrated practitioner perspective on what the obligations actually require, how they overlap (and where they don't), and what an actually-working TPRM programme looks like in 2026.

I am writing this from experience advising Indian banks, NBFCs, fintechs, insurers, and brokers on their TPRM programmes from 2019 onwards — including through the RBI tightening of 2023-2024 and the DPDPA notification of 2025. The Indian TPRM landscape changed substantively in the last 24 months and most existing programmes are still adapting.

The regulatory map at a glance

The Indian regulators and their TPRM-relevant instruments:

The complexity is not in any individual regulator's framework. It is in how they interact. A bank using a cloud-hosted CRM via an SaaS vendor that subcontracts AI processing to a third party is governed by every regulator on this list, with each one having different requirements about contracts, audits, incidents, data localisation, and termination.

What's specifically Indian about Indian TPRM

Several things distinguish Indian TPRM obligations from international (ISO 27036, NIST 800-161, EBA EU outsourcing) frameworks:

The "outsourcing of core activity" prohibition. Under RBI rules, certain functions cannot be outsourced — what counts as core varies by entity type. For banks, it includes credit risk management, treasury operations, and certain compliance functions. For NBFCs the line is different. For insurers, IRDAI defines core functions narrowly. The implication is that "we'll just outsource it" is not a universal answer to capability gaps; some things must stay in-house regardless of cost or capability.

Data localisation requirements. RBI's 2018 payment data directive requires payment data to be stored in India. SEBI has expanded localisation expectations for sensitive market data. IRDAI requires policyholder data to be processable in India. DPDPA may add cross-border restrictions per Section 16 once specific destinations are notified. The result: many international cloud vendors require special India-only deployment configurations, and TPRM must verify these.

The CERT-In 6-hour incident notification. Any vendor that processes incidents must be capable of supporting your CERT-In notification within 6 hours. Most international vendors operate to a 24-72 hour SLA. The TPRM programme must specifically flag this gap and require contractual commitments.

Sectoral overlay on top of DPDPA. Where DPDPA's general processor obligations conflict or overlap with sectoral data protection (e.g., banking confidentiality under the Banking Regulation Act, insurance confidentiality under the Insurance Act), the sectoral requirements typically prevail or layer on top. This is unlike the EU model where GDPR is universal and sectoral law adds. The result is more complexity in vendor agreements.

The RBI Cyber Security Framework's tiered approach. Banks are differentiated by size and complexity, and TPRM expectations scale accordingly. Large private banks face a different bar than small co-operative banks. This is being mirrored in SEBI's CSCRF (5-tier model) and increasingly in IRDAI's approach. The good news: small entities have proportional obligations. The bad news: scale up across the tier threshold and you have a substantially larger TPRM programme to build.

The five-question vendor classification

The first move in any TPRM programme is classification. Not all vendors are equal. The classification model I use across Indian engagements has five questions, in order:

Q1: Does the vendor access regulated data? - Personal data (DPDPA) - Sensitive personal data (DPDPA Section 9) - Financial data (RBI / SEBI / IRDAI) - Critical information infrastructure data (NCIIPC)

Q2: Does the vendor perform a regulated function? - Credit decisioning - Payment processing - KYC/AML processing - Insurance underwriting or claims - Order matching, settlement

Q3: What is the vendor's access mode? - Read-only access to data - Read-write access - System administration access - Direct service delivery (e.g., outsourced operations)

Q4: What is the dependency level? - Replaceable (multiple alternatives, switch within weeks) - Hard to replace (specialised, switch within quarters) - Effectively irreplaceable (custom integration, switch within years if at all)

Q5: What is the failure impact? - Operational disruption only - Regulatory non-compliance triggered by vendor failure - Material harm to customers or third parties - Existential business impact

The five answers produce a classification. I use a four-tier model:

• Tier 1 (Critical): Yes/Yes to Q1+Q2, high on Q3-Q5. Vendors providing core regulated services with sensitive data access and high dependency. Subject to maximum TPRM rigour — annual audits, deep due diligence, board-level visibility, regulatory notification of arrangement.
• Tier 2 (Material): Yes to Q1 or Q2, medium on Q3-Q5. Vendors handling regulated data or performing supporting functions. Annual review with focused due diligence.
• Tier 3 (Important): Limited regulated data access OR replaceable function. Biennial review with proportional due diligence.
• Tier 4 (Routine): No regulated data, no regulated function. Lighter review.

The thresholds matter. Tier 1 vendors trigger specific RBI / IRDAI / SEBI requirements that don't apply to Tier 2 vendors. Misclassifying a vendor down a tier creates audit findings; misclassifying up a tier creates unnecessary cost.

What the contracts must include — by regulator

A vendor contract for a Tier 1 vendor in an Indian regulated entity must address all of the following. Different regulators emphasise different clauses, and they aggregate:

The list looks long because it is. A correctly-drafted Tier 1 vendor contract for an Indian bank runs 60-120 pages. The cost of legal review is real and must be budgeted (typically ₹2-8 lakh per Tier 1 contract for full negotiation; lower for templated lower-tier vendors).

The CERT-In 6-hour reality. This is the clause vendors push back hardest on. The honest position: most international vendors cannot commit to 6 hours. The compromise that has emerged in practice is a tiered notification — the vendor commits to a specific shorter SLA for "indicators that may relate to a CERT-In reportable incident at the customer" (typically 1-4 hours), with full incident details on the longer 24-72 hour timeline. This gives the customer enough lead time to support CERT-In notification within 6 hours.

Sub-processor management. RBI and SEBI both expect material sub-processors to be disclosed and approved. The pragmatic implementation is a sub-processor list maintained by the vendor, refreshed quarterly, with named entities and roles. Material changes (new sub-processor, country change, function change) trigger customer notice and right of objection. Anything less than this fails audit scrutiny.

The audit cycle

For Tier 1 vendors, expect:

• Onboarding due diligence — security questionnaire, evidence of certifications (ISO 27001, SOC 2 Type II, others as applicable), site visit if local, virtual review if remote, contract negotiation
• Annual audit — typically combines a vendor-provided SOC 2 Type II report plus a focused on-site or virtual audit on areas the SOC 2 doesn't cover
• Quarterly check-ins — incident review, change notifications, KPI tracking, sub-processor changes
• Continuous monitoring — automated checks for vulnerabilities, security ratings (BitSight, SecurityScorecard), threat intelligence

The audit doesn't need to be invasive every time. The structured cycle is:

The goal is to cycle through all material controls over 3-4 years while keeping each individual audit proportional.

What to look for in a vendor SOC 2 Type II report

A vendor will hand you their SOC 2 report and assume you'll read the executive summary. You should read more:

1. Auditor identity and reputation. SOC 2 issued by a tier-1 firm (Big 4, established mid-tier) carries more weight than SOC 2 issued by a smaller boutique. Both can be valid; some boutiques are excellent. Note the auditor.
2. Scope statement. Make sure the systems/services in scope are the ones you actually use. Vendors sometimes scope SOC 2 narrowly to specific products.
3. Period covered. Type II requires 6-12 months of testing. Reports covering less than 6 months are not full Type II.
4. Exceptions / deviations table. Every SOC 2 has some exceptions. Look at frequency, severity, and management response. A clean report with zero exceptions is suspicious; a report with major exceptions and inadequate response is a warning sign.
5. Sub-service organisations — does the vendor "carve out" sub-services (cloud providers, etc.) from their report? Find the carve-out section and verify those sub-services have their own SOC 2 reports.
6. Complementary user entity controls (CUECs) — the vendor expects YOU to perform certain controls for the SOC 2 to apply. List of these is usually in section 4. You need to operate those controls; the auditor will check.

A vendor that can't produce a current SOC 2 Type II should produce equivalent evidence (ISO 27001 + supplementary audit reports, or detailed SIG/CAIQ responses). Absence of any third-party assurance for a Tier 1 vendor is a finding.

DPDPA's specific impact on TPRM

DPDPA changed the TPRM landscape in 2025. Before DPDPA, processor obligations were primarily handled through commercial contracts. Post-DPDPA, certain obligations are now statutory:

• Processor must process only on instructions of fiduciary — Section 8(3)
• Processor must implement reasonable security safeguards — Section 8(5)
• Processor must notify fiduciary of personal data breach without undue delay — Section 8(6) read with Section 8(5)
• Processor must delete personal data upon contract termination unless retention required by law — Section 8(7)
• Processor liable for own violations including penalties — Section 33

This last one is significant. Pre-DPDPA, your contract would shift breach liability to the processor through indemnification. Post-DPDPA, the processor can be directly penalised by the Data Protection Board, separately from any fiduciary liability. This changes vendor due diligence — you're not just protecting yourself; the regulator can act on your vendor independently.

The Significant Data Fiduciary (SDF) designation effect. If you're an SDF (any entity processing large volumes of personal data, with specific thresholds to be notified by the government), additional obligations apply: DPO appointment, periodic DPIA, periodic data protection audit. The audit obligation covers your processors as well — the SDF's audit must verify that processors are compliant. This means audit rights in vendor contracts need to be enforceable in practice, not just on paper.

The Consent Manager ecosystem. DPDPA introduces a Consent Manager construct — independent entities that maintain consent records on behalf of Data Principals. By November 2026, certain types of processing must go through Consent Managers. If your vendor is involved in personal data collection workflows, your TPRM must verify they support the Consent Manager integration architecture.

What I see going wrong in Indian TPRM programmes

After enough engagements, patterns emerge. The most common issues:

Tier 1 vendor inventory incomplete. Asked to list Tier 1 vendors, the team produces 25. Independent reconstruction from finance and operations adds 7-12 more. The pattern is consistent — "shadow" vendors signed by business units, "incidental" vendors that processing turns out to be material, "legacy" vendors that nobody currently owns. The fix is bi-annual reconciliation against finance spend AND access management data; no business unit signs vendors without TPRM clearance for above a threshold (₹5 lakh annual is a reasonable cut-off).

Contracts signed without TPRM review. Procurement signs based on commercial terms. Security clauses are inherited from a generic template. Five years in, the contract doesn't reflect actual data flows. The fix: every contract above the threshold gets TPRM review before signature. Procurement and TPRM coordinate to make this fast — usually one week SLA — but the review must happen.

Sub-processor maps are vendor-generated and unverified. The vendor lists their sub-processors. The customer accepts the list as fact. The customer never verifies that the listed sub-processors are the only ones. Periodic spot-checks (random sampling of incident reports, vulnerability scans, access logs to see what IPs and domains appear) catch discrepancies. Without this, the sub-processor inventory is fiction.

Audit findings don't close. Year 1 audit found 12 findings on Vendor X. Year 2 finds 14, of which 8 are repeats. Year 3 finds 18, of which 11 are repeats. The audit cycle is documenting failure rather than driving improvement. The fix is that audit findings have to flow into vendor performance reviews and contract renewal decisions, with clear thresholds for escalation. The CISO/CRO should have visibility into "vendors with N+ open findings" as a standing metric.

Concentration risk not measured. The TPRM programme tracks individual vendors. It doesn't track that 30% of critical workloads run on one cloud, that two-thirds of payment processing runs through one acquirer, that the IT outsourcing supplier provides services to four of your top-tier vendors. Concentration risk is a board-level conversation, often missed because TPRM is organised vendor-by-vendor rather than cross-vendor.

Termination assistance untested. The contract requires termination assistance — data return, transition support. In practice, when termination happens (vendor goes bankrupt, services don't meet SLA, regulatory action), the actual transition is improvised and chaotic. The exit is the riskiest moment of the vendor relationship. TPRM should require documented termination procedures and, for Tier 1 vendors, periodic exit testing (yes, this is genuinely done by a small number of organisations and works well).

What I would build into a TPRM programme if starting from scratch in 2026

A blank-slate Indian TPRM programme today:

Foundation (Month 1-3): - Vendor classification model with documented thresholds - Master vendor inventory reconciled against finance and access management - Risk scoring methodology - Contract template library (Tier 1 / Tier 2 / Tier 3 / Tier 4) - Standard security questionnaire (start with SIG Lite or CAIQ, customise to Indian regulatory specifics)

Process (Month 4-6): - Onboarding workflow with TPRM gate - Annual review cycle and assignment - Incident notification protocol - Sub-processor change management - Termination assistance procedure

Tooling (Month 7-9): - GRC platform with vendor module (consider ProcessUnity, ServiceNow VRM, Archer; budget ₹15-50 lakh annually) - Continuous monitoring service (BitSight, SecurityScorecard; budget ₹5-15 lakh annually for mid-sized programme) - Contract management system if not already in place - Reporting dashboards for executive and regulatory visibility

Governance (Month 10-12): - TPRM steering committee - Board-level reporting - Specific regulatory submissions for Tier 1 vendors as required - First annual programme review with external assurance

This is roughly an 18-month build for a meaningfully complete programme. Cost: ₹40-80 lakh of internal investment plus ₹15-40 lakh of external advisory. Smaller organisations can do this for less by skipping the tooling and using spreadsheets — workable up to 50-60 vendors, painful above that.

A final note on the regulatory direction

The trajectory in Indian regulation is clear: more TPRM rigour, more direct regulator scrutiny of vendors, faster incident notification, stricter sub-processor management, more attention to concentration risk and operational resilience. The DORA-style framing (Digital Operational Resilience Act in the EU) is starting to influence Indian thinking, particularly at RBI.

If your TPRM programme is currently barely keeping up with 2024 expectations, the gap to 2027 expectations will be substantial. The investment now is significantly cheaper than the catch-up later. Specifically:

• Sub-processor transparency — expect explicit regulatory requirements within 18-24 months
• Concentration risk reporting — expect quantitative thresholds and reporting requirements within 24-36 months
• Exit readiness testing — expect to demonstrate this in audits within 36 months
• AI vendor specific assessment — expect distinct AI vendor TPRM track within 12-18 months
• Cross-border data flow restrictions tied to vendor location — expect DPDPA Section 16 notifications within 12 months

Building for these now is cheaper than retrofitting later.

This guide draws on practitioner experience advising Indian banks, NBFCs, insurers, fintechs, and IT services firms on TPRM programmes from 2019 through Q1 2026. Specific regulatory obligations vary by entity type, scale, and license; verify against current regulatory text. This is not legal advice.

ControlForge maps TPRM controls across RBI, SEBI, IRDAI, DPDPA, CERT-In, ISO 27001, and SOC 2 frameworks. The Vendor Classification tool generates a tier assignment based on the five-question model. The Cross-Border Flow Analysis tool maps vendor data flows against DPDPA Section 16 and sectoral overlays. Available at controlforge.com.