Third-Party Cyber Risk: Managing the Vendors Who Hold Data You Are Accountable For
Third-party cyber risk is the data and access you have handed to vendors, and the accountability you have not. What Indian regulators and the DPDP Act expect of you when a supplier is breached, how to tier vendors, what a useful assessment looks like, and the contract clauses that matter most.
Governance, Risk and Compliance
In October 2026 a large Indian bank told the stock exchanges that records containing customer information had surfaced on a dark web forum, that it had learnt of this from its threat intelligence provider and government agencies rather than from its own systems, and that a detailed investigation was still needed to confirm the data's authenticity and source. Whatever that investigation finds, the disclosure carried the bank's name, the regulator's attention went to the bank, and the customers were the bank's. That is third-party risk in one paragraph: the data is yours, the systems often are not, and the accountability never moves. Here is what Indian regulators and the DPDP Act now expect of you for the vendors who hold your data, how to run a programme that regulators accept and vendors can actually answer, and what to do when one of them is breached.
In short. Start with an inventory of every vendor that holds your data or has access to your systems, and tier them by what they could do to you. Assess the critical tier with evidence, not questionnaires alone. Put the clauses regulators require into contracts: security obligations, incident notification fast enough to meet your own six-hour clock, audit rights, sub-contracting approval, data location and return on exit. Monitor the critical few continuously. And write the playbook for a vendor breach before it happens, because when it does, the reporting duties and the penalties are yours.
Why this has become a board topic
Verizon's 2025 Data Breach Investigations Report found that "the percentages of breaches where a third party was involved doubled, going from 15% to 30%"; its 2026 report puts third-party involvement at close to half of all breaches. The cases behind those numbers are well documented and all involved organisations that had done nothing wrong themselves, except trust.
| Case | What happened | The third-party lesson |
|---|---|---|
| MOVEit Transfer, 2023 | A zero-day in a file transfer product used by thousands of organisations and their vendors; Emsisoft counted 2,773 affected organisations and more than 95 million individuals by mid-2024 | Many victims had never heard of the product; their vendor, or their vendor's vendor, used it |
| Snowflake customers, 2024 | Mandiant found attackers used stolen credentials for customer accounts that "did not require multi-factor authentication and in many cases, the credentials had not been rotated for as long as four years", with about 165 organisations potentially exposed and no breach of the platform itself | The provider was secure; the customers' configuration of it was not. Shared responsibility applies to SaaS too |
| Change Healthcare, 2024 | A ransomware attack on a US healthcare payments intermediary; its parent later put the number of affected people at about 190 million | A single vendor can be a point of failure for an entire sector |
| Okta support system, 2023 | A stolen credential, saved in an employee's personal account, gave access to the identity provider's support case system and files customers had uploaded to it | Even your security vendors are third parties, and support tickets are data |
| CDK Global, 2024 | Ransomware at a dealer management software provider took roughly 15,000 car dealerships offline for weeks; one estimate put direct dealer losses above $1 billion | Concentration risk: when everyone uses the same vendor, everyone goes down together |
What Indian regulators require
India's financial regulators have moved from general outsourcing guidance to specific, auditable requirements, and all of them put the accountability on the regulated entity.
RBI
- Outsourcing directions, 2025. The Reserve Bank of India (Commercial Banks – Managing Risks in Outsourcing) Directions, 2025, issued on 28 November 2025 with immediate effect, replaced the earlier outsourcing instruments including the 2023 Master Direction on outsourcing of IT services; parallel directions were issued for NBFCs. Existing IT outsourcing agreements had to comply "at the time of renewal or by April 10, 2026, whichever is earlier." The contract requirements include: the service provider reports cyber incidents "without undue delay, so that an incident is reported by the bank to the RBI within six hours of detection by the service provider"; data stored only in India; the provider liable for its sub-contractors; the bank's right to audit the provider and its sub-contractors; concentration risk assessed; and an exit strategy.
- Cybersecurity directions, 2026. The 31 July 2026 directions for banks add, for IT and cyber arrangements outside the outsourcing rules, a vendor risk assessment covering concentration risk, conflicts of interest and single points of failure, the principle that the bank remains "accountable for ensuring appropriate management and assurance", a right to audit, source code escrow for critical applications, and written vendor confirmation that an application is "free of known vulnerabilities, malware, and any covert channels in the code". The NBFC directions carry equivalent clauses for the middle layer and above. Our guide to the NBFC directions covers them. Neither direction requires a software bill of materials or sets a fixed vendor-to-bank reporting clock; the six-hour obligation sits on the bank.
SEBI
The CSCRF's supply chain standard requires that "suppliers and third-party service providers ... shall be identified, prioritized, and assessed using a cyber-supply chain risk assessment process", that contracts include measures to meet the entity's cybersecurity programme, that "concentration risk on outsourced agencies shall be assessed", and that third parties "be mandated to follow similar standards of information security". It goes further than RBI on software: "SBOM shall be obtained for all new software procurements of core and critical activities and kept updated with every upgrade or change", and regulated entities were to obtain SBOMs for existing critical systems within six months of the framework's issue. The responsibility, the framework says, "lies primarily with REs". See our SEBI CSCRF guide and our explainer on software bills of materials.
IRDAI
The Information and Cyber Security Guidelines, version 2.0 of April 2026, require vendor classification, the right to audit "as part of contract with vendors", due diligence that verifies sub-contracting arrangements, periodic reassessment, access revocation and data return on termination, and a rule that service providers "cannot further outsource activities unless they obtain prior written permission" from the insurer. Cloud services may be taken "only from the Ministry of Electronics and Information Technology (MeitY) empaneled CSPs". A vendor certified to ISO 27001 may be accepted in place of periodic audits, but only where the certificate's scope and statement of applicability cover the service provided. Incidents go to CERT-In within six hours with a copy to IRDAI.
CERT-In
The April 2022 directions apply to your vendors as well as to you. Service providers, intermediaries, data centres and body corporates must report incidents within six hours of noticing them; everyone must keep logs for a rolling 180 days within India; and data centres, cloud providers, virtual server providers and VPN providers must keep validated subscriber records for five years. A vendor that cannot show you how it meets these is a vendor that will struggle to help you meet your own obligations.
What the DPDP Act changes
The Digital Personal Data Protection Act, 2023 draws the line sharply. A data fiduciary may engage a data processor "only under a valid contract", and the fiduciary must protect personal data "including in respect of any processing undertaken by it or on its behalf by a Data Processor". The breach notification duty in section 8(6) sits with the fiduciary, and so do the penalties: up to ₹250 crore for failing to take reasonable security safeguards and up to ₹200 crore for failing to notify a breach. The Rules, whose main provisions commence in May 2027, require the contract with a processor to include "appropriate provision ... for taking reasonable security safeguards" and set the notification clocks: affected individuals "without delay", the Data Protection Board without delay and then a detailed report "within seventy-two hours of becoming aware of the breach". There is no clause in the Rules obliging a processor to tell you; that has to be in your contract. Our 180-day DPDP readiness plan puts the processor work into the timeline.
The international frameworks
If you hold ISO/IEC 27001:2022 certification or work to NIST, the same expectations appear in a different vocabulary. Annex A controls 5.19 to 5.23 cover information security in supplier relationships, requirements agreed with each supplier, the ICT supply chain, monitoring and review of supplier services, and the use of cloud services. NIST CSF 2.0 puts supply chain risk management in the Govern function: requirements "integrated into contracts and other types of agreements with suppliers", due diligence before relationships, suppliers included in incident planning and response, and provisions "after the conclusion of a partnership or service agreement". NIST SP 800-161 Revision 1 is the detailed practice guide. The ISO 27001 implementation guide covers where supplier controls fit in the management system.
A programme that works
1. Inventory
Every vendor with your data or access to your systems, including the ones procurement does not know about: SaaS tools bought on a card, integrations set up by a developer, the agency that runs your social media. Finance records, single sign-on logs and cloud marketplace bills find most of them.
2. Tier
By what the vendor could do to you: the sensitivity and volume of data it holds, the access it has, how hard it would be to replace, and whether it is a regulatory "material" outsourcing. Three tiers is enough. The critical tier is usually ten to thirty vendors, and that is where the effort goes.
3. Assess with evidence
Questionnaires are a starting point, not an assessment. For the critical tier, read the SOC 2 Type II report and its exceptions, check that an ISO 27001 certificate's scope and statement of applicability actually cover your service, review the vendor's own penetration test summary, and where the exposure justifies it, test the integration yourself.
4. Contract
The clauses below, agreed before the data moves, not at renewal.
5. Monitor
Continuous for the critical tier: external attack surface, breach disclosures, certificate expiry, changes of ownership or sub-contractor, and the vendor's own incident reports. Annual reassessment for the rest.
6. Exit
For every critical vendor, a written answer to what happens if it fails, is breached or is acquired: data return and deletion, an alternative, and how long the switch takes.
The contract clauses that matter
| Clause | What it should say | Who requires it |
|---|---|---|
| Security obligations | Specific controls, not "industry standard"; standards the vendor must follow; encryption, access control and logging requirements | DPDP Rule 6, SEBI, IRDAI, ISO 5.20 |
| Incident notification | A clock measured in hours from the vendor's detection, with what must be included, so you can meet your own six-hour and 72-hour duties | RBI, IRDAI, CERT-In (indirectly), DPDP |
| Audit and inspection | Your right to audit the vendor and its sub-contractors, and the regulator's right to inspect | RBI, IRDAI, SEBI |
| Sub-contracting | No further outsourcing of your work without your prior written approval; the vendor liable for its sub-contractors | RBI, IRDAI |
| Data location and residency | Where data is stored and processed, and any restriction to India | RBI outsourcing, digital lending, DPDP cross-border rules |
| Software assurance | An SBOM for critical software, kept current; confirmation that delivered code is free of known vulnerabilities; escrow for critical applications | SEBI, RBI 2026 |
| Testing and evidence | Annual independent assurance reports shared with you; your right to test the integration | All, as evidence |
| Continuity | Tested recovery arrangements and recovery objectives aligned to yours | RBI, IRDAI, ISO 5.30 |
| Exit | Data return in a usable format, certified deletion, transition assistance, and what happens on insolvency or acquisition | RBI, IRDAI, NIST GV.SC-10 |
Reading assurance documents properly
Vendors will send you certificates and reports. Each proves something specific, and none of them proves that your data is safe.
- SOC 2 Type II. An auditor's opinion on controls at the service organisation over a period, against the criteria the vendor chose to include. Read the scope, the period, the exceptions and the complementary user entity controls, which are the things you are expected to do.
- ISO 27001 certificate. Evidence of a management system conforming to the standard within the certified scope. Check the scope statement and ask for the statement of applicability; IRDAI's own guidance conditions reliance on the service being inside it.
- CSA STAR. Level 1 is a self-assessment against the cloud controls matrix; Level 2 is a third-party audit built on ISO 27001 or SOC 2.
- Shared Assessments SIG. A standardised questionnaire, in full and lite forms. Useful for consistency, but it is still the vendor marking its own homework.
- Penetration test summaries. Ask for the date, the scope, the tester's independence and the closure status, not just the executive summary.
When a vendor is breached
The first hours are the same as any incident, with one difference: you may not have the facts, and the reporting clocks run anyway.
Hour 0 — Establish what you know
What data and access the vendor has, from your inventory; what the vendor has told you; what the contract says they must tell you and by when.
Hours 1–6 — Contain and report
Suspend the vendor's access and rotate shared credentials. Report to CERT-In within six hours of noticing, and to RBI, SEBI or IRDAI on their clocks, with what you know and a statement that the investigation continues. Do not wait for the vendor's final report.
Days 1–3 — Investigate and notify
Get the vendor's evidence, check your own logs for the same indicators, and determine whose data is affected. Once the DPDP Rules apply, notify affected individuals without delay and file the detailed report to the Board within 72 hours of becoming aware.
Afterwards — Decide
Whether to keep the vendor, what the contract should have said, and what the inventory missed. The incident response retainer that handles your own incidents should cover vendor incidents too.
Common mistakes
- Assessing everyone equally. Two hundred questionnaires a year and no evidence for the ten vendors that matter.
- Trusting the certificate's existence rather than its scope. An ISO certificate for the vendor's head office does not cover the data centre that holds your data.
- No clock in the contract. "Promptly" is not six hours.
- Ignoring fourth parties. Your vendor's cloud provider, payroll processor and support contractor are in your supply chain whether or not you have a contract with them.
- Treating SaaS as the vendor's problem. The Snowflake cases were customer configuration: no MFA, stale credentials, no network restrictions. Our guide to SaaS security posture management covers your side of that line.
- Stopping at onboarding. Vendors change owners, sub-contractors and security teams. The assessment from three years ago describes a different company.
A third-party risk management programme does not have to be large to be effective; it has to be focused on the vendors that can hurt you and backed by contracts that say what regulators expect. For the software supply chain specifically, see digital supply chain security.
Frequently Asked Questions
Click any question to expand the answer.
QWhat is third-party cyber risk?
The risk that a vendor, supplier, partner or service provider that holds your data or has access to your systems is breached, fails or misuses that access, with the consequences landing on you. Regulators and the DPDP Act place accountability for that data on the organisation that collected it, whoever processes it.
QWho is responsible when a vendor is breached?
You are, for your customers and your regulators. The DPDP Act requires a data fiduciary to protect personal data including processing done on its behalf by a processor, and the breach notification duty and penalties sit with the fiduciary. RBI, SEBI and IRDAI all state that accountability for outsourced activities remains with the regulated entity.
QWhat does RBI require for third-party and outsourcing risk?
The 2025 outsourcing directions for banks and NBFCs require board-approved policies, due diligence, contracts with audit rights, sub-contractor approval, data stored in India, an exit strategy, concentration risk assessment, and incident reporting by the provider fast enough for the bank to report to RBI within six hours of the provider's detection. The 2026 cybersecurity directions add vendor risk assessment, source code escrow and vendor confirmation that applications are free of known vulnerabilities.
QDoes SEBI require an SBOM from vendors?
Yes. The CSCRF requires regulated entities to obtain a software bill of materials for all new software procurements for core and critical activities, kept updated with every change, and required SBOMs for existing critical systems within six months of the framework's issue.
QWhat does the DPDP Act say about data processors?
A data fiduciary may engage a processor only under a valid contract, must protect personal data including processing done on its behalf, and must notify the Data Protection Board and affected individuals of a breach. The Rules, whose main provisions commence in May 2027, require the processor contract to include provisions for reasonable security safeguards and set a 72-hour clock for the detailed report to the Board. The Rules do not oblige the processor to notify you, so the contract must.
QHow should vendors be tiered?
By what they could do to you: the sensitivity and volume of data they hold, the access they have to your systems, how hard they are to replace, and whether the arrangement is a material outsourcing in regulatory terms. Three tiers are usually enough, with the critical tier, typically ten to thirty vendors, getting evidence-based assessment and continuous monitoring.
QAre security questionnaires enough?
No. They are a starting point. For critical vendors, read the SOC 2 Type II report and its exceptions, confirm that an ISO 27001 certificate's scope and statement of applicability cover your service, review penetration test summaries, and where the exposure justifies it, test the integration yourself.
QWhat should a vendor contract include for cybersecurity?
Specific security obligations, an incident notification clock measured in hours from the vendor's detection, audit and regulator inspection rights, no sub-contracting without approval, data location rules, software assurance such as SBOMs and vulnerability-free confirmation, assurance reports, tested continuity arrangements, and exit terms covering data return and deletion.
QWhat is fourth-party risk?
The risk from your vendors' own vendors: their cloud provider, payroll processor, support contractor or software supplier. You usually have no contract with them, which is why regulators require you to approve sub-contracting and hold your vendor liable for it.
QWhat should we do when a vendor is breached?
Establish what data and access the vendor has, suspend its access and rotate shared credentials, report to CERT-In within six hours of noticing and to your sector regulator on its clock with what you know, obtain the vendor's evidence, check your own logs, and once the DPDP Rules apply, notify affected individuals without delay and the Board within 72 hours.
QDoes an ISO 27001 certificate mean a vendor is secure?
It means the vendor operates a management system conforming to the standard within the certified scope. Check that the scope and statement of applicability cover the service you buy; IRDAI's 2026 guidelines allow reliance on a certificate only on that condition.
QHow often should vendors be reassessed?
Critical vendors continuously, through monitoring of their attack surface, disclosures, certificates and ownership, with a formal reassessment at least annually. Lower tiers annually or at renewal. Any vendor should be reassessed after a breach, an acquisition or a change in the services it provides.
Related reading
For the software side of the supply chain, see why software bills of materials matter. For the data protection obligations behind processor contracts, what a real DPDP assessment covers. For the reporting clocks a vendor breach triggers, CERT-In six-hour incident reporting and incident response retainers.
Sources
- Reserve Bank of India, Commercial Banks – Managing Risks in Outsourcing Directions, 2025.
- Reserve Bank of India, NBFC – Managing Risks in Outsourcing Directions, 2025.
- Reserve Bank of India, Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026.
- Securities and Exchange Board of India, Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI regulated entities.
- IRDAI, Information and Cyber Security Guidelines for Regulated Entities, Version 2.0 (April 2026).
- Ministry of Law and Justice, Digital Personal Data Protection Act, 2023.
- Ministry of Electronics and Information Technology, Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E)).
- CERT-In, Directions under section 70B(6) of the IT Act, 2000 (28 April 2022).
- NIST, SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations.
- NIST, Cybersecurity Framework 2.0.
- Verizon, Data Breach Investigations Report.
- Emsisoft, Unpacking the MOVEit breach: statistics and analysis.
- Google Cloud / Mandiant, UNC5537 targets Snowflake customer instances for data theft and extortion.
- Okta, October 2023 security incident: recommended actions.
- Cloud Security Alliance, STAR programme levels.
Adayptus Consulting
Governance, Risk and Compliance, Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India, building third-party risk programmes that regulators accept and vendors can actually answer.
