A bank outsources its card processing to a vendor. The vendor, in turn, uses a cloud hosting provider and a subcontracted support team. A configuration error at the hosting layer exposes customer data. Who is accountable? The regulator's answer is clear: the regulated entity. Responsibility can be shared operationally, but it cannot be outsourced away.

This principle underpins how Indian financial regulators approach third-party risk. As banks, NBFCs, payment companies and fintechs rely increasingly on vendors, cloud platforms and technology partners, the quality of third-party oversight has become a central supervisory theme.

The regulatory backdrop

The RBI has issued directions that touch third-party risk from several angles, including its Master Direction on Outsourcing of Information Technology Services (2023) and the broader IT governance framework. Together with sector guidance on outsourcing of financial services and cyber security frameworks, they establish expectations that regulated entities should:

  • Retain ultimate responsibility for outsourced activities.
  • Perform due diligence before engaging service providers.
  • Ensure contracts include appropriate security, audit, access and exit provisions.
  • Monitor providers on an ongoing basis.
  • Manage concentration risk and dependencies.
  • Maintain business continuity and exit plans.
  • Ensure regulator access to relevant information and, where applicable, to service providers.

Requirements vary by entity type and by criticality of the outsourced service. Check the current text applicable to you.

Why third-party risk is hard

Visibility. You may not know every subcontractor in the chain, or where data actually resides.

Scale. Large institutions may have hundreds or thousands of vendors, making uniform deep assessments impossible.

Dependency. Some vendors are deeply embedded. Switching costs are high, which weakens negotiating leverage.

Limited control. You cannot patch a vendor's systems or enforce their staff behaviour directly.

Changing risk. A vendor that was secure at onboarding may degrade over time through acquisitions, staff turnover or technology change.

Building a risk-based programme

1. Inventory all third parties. Create a complete register covering service providers, cloud services, software suppliers and fourth parties where visible. Capture what data they handle, which systems they connect to and which business services depend on them.

2. Tier by criticality. Classify vendors by impact if they fail or are breached: critical, high, medium, low. Criteria include access to sensitive or customer data, support for critical business services, regulatory relevance, substitutability and connectivity to your network.

3. Apply proportionate due diligence. Critical vendors warrant deep assessment: security questionnaires, evidence review, certifications such as ISO 27001 or SOC 2 reports, penetration test summaries, financial stability checks, business continuity capabilities, regulatory standing and, where justified, on-site audits. Lower tiers can use lighter checks.

4. Strengthen contracts. Include clauses for security requirements, incident notification timelines, audit and inspection rights for you and the regulator, data location and confidentiality, subcontractor controls, business continuity, termination assistance and data return or deletion.

5. Monitor continuously. Track performance and security posture: service levels, incident reports, certification renewals, security ratings or external signals, audit results and changes in ownership or subcontractors. Reassess critical vendors at least annually, and after significant events.

6. Plan for failure. Develop exit strategies and contingency plans for critical services, including alternative providers, data portability and tested recovery arrangements.

7. Integrate with incident response. Define how vendor incidents are detected, reported and escalated, and how your own regulatory reporting duties are met within required timelines.

8. Govern at senior level. Report vendor risk to risk committees and the board, particularly for critical outsourcing arrangements and concentration risks.

Cloud and concentration considerations

Heavy reliance on a small number of cloud or technology providers creates concentration risk that regulators watch. Assess whether multiple critical services depend on one provider, region or technology. Consider architecture and contractual choices that reduce single points of failure, and test resilience.

Data protection overlay

Under the Digital Personal Data Protection Act, a data fiduciary remains responsible for personal data processed on its behalf by processors, and must ensure reasonable security safeguards. Vendor contracts should therefore address data protection obligations, breach notification and deletion.

Common failures

  • Due diligence performed once at onboarding and never repeated.
  • Contracts lacking audit rights or incident notification clauses.
  • Fourth-party risk ignored.
  • Relying solely on a vendor's questionnaire answers without verifying evidence.
  • No tested exit plan for critical services.
  • Vendor inventory incomplete, particularly for SaaS tools adopted by business teams without IT involvement.

Metrics worth tracking

  • Percentage of vendors tiered and assessed on schedule.
  • Number of critical vendors with overdue reassessments.
  • Open high-risk vendor findings and age.
  • Incidents involving third parties.
  • Contracts missing required clauses.
  • Concentration indicators.

A quick test

Pick your most critical vendor and ask: Do we know what data they hold and where? When did we last review their security evidence? What does the contract say about breach notification and audit rights? How long could we operate if they failed tomorrow? If the answers are unclear, you have identified your priority.

Strengthen your vendor oversight

F9 Infotech designs third-party risk programmes, performs vendor assessments and helps align contracts and monitoring with RBI and other regulatory expectations. Assess vendor risk with F9 Infotech. Contact us.

This article offers general guidance and is not regulatory advice. Confirm applicable requirements for your entity.