CyphrQ
Menu

Third-Party Risk Management: Tiering, Contracts, Monitoring and Exit

Third-party risk management in practice: tier vendors, run due diligence, write audit, breach-notice and exit clauses, monitor, and offboard cleanly.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

10 min read

What is third-party risk management? Third-party risk management (TPRM), also called vendor risk management, is how you decide which suppliers can touch your data, systems or customers, check them before you sign, write the right promises into the contract, watch them while they work for you, and leave cleanly. Done well, it puts most effort on the few suppliers that could really hurt you, not on a questionnaire for everyone.

Outsourcing your IT doesn't outsource responsibility for your data. Regulators in the US, the EU and India have written rules for managing suppliers, and recent breaches show why.

Why does third-party risk management matter? Two recent cases

MOVEit, 2023. The US cybersecurity agency CISA reported that, beginning on 27 May 2023, the CL0P ransomware gang exploited CVE-2023-34362, a SQL injection flaw in Progress Software's MOVEit Transfer file-sharing product. Internet-facing MOVEit servers were infected with a web shell named LEMURLOOT, which was used to steal data from the underlying databases (CISA AA23-158A). The same advisory estimates the group, also known as TA505, has compromised more than 3,000 US-based and 8,000 global organisations over its history. For the organisations hit, the entry point was a supplier's product, not their own code.

Snowflake customer accounts, 2024. Google's Mandiant reported in June 2024 that a threat actor it tracks as UNC5537 used Snowflake customer credentials stolen by infostealer malware on non-Snowflake systems, and that Mandiant and Snowflake had notified about 165 potentially exposed organisations (Mandiant, 10 June 2024). Mandiant found no evidence of a breach of Snowflake's enterprise environment. The three factors it named were all on the customer side: no multi-factor authentication (MFA), credentials that had not been rotated, in some cases for years, and no network allow lists.

Put the two together and you get the two halves of third-party risk. Sometimes the supplier's product fails. Sometimes the supplier is fine and your own setup of the supplier fails. A programme has to cover both. How infostealers harvest those credentials is covered in infostealers and session token theft.

What do regulators expect from third-party risk management?

Region Rule What it says, in short
US Final interagency guidance on third-party risk management (Federal Reserve, FDIC, OCC), 6 June 2023 One life cycle for all bank third parties: "planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination" (Federal Reserve). It replaced each agency's earlier guidance, including OCC Bulletins 2013-29 and 2020-10 (OCC Bulletin 2023-17)
EU DORA for ICT suppliers; EBA Guidelines on third-party risk management for non-ICT services DORA's register of information covers every ICT contract (see our DORA guide). The EBA announced its final non-ICT guidelines in a press release dated 18 September 2026, focused on arrangements supporting critical or important functions; once applicable they will repeal the 2019 outsourcing guidelines (EBA)
India RBI Master Direction on Outsourcing of Information Technology Services, RBI/2023-24/102, 10 April 2023, effective 1 October 2023 Due diligence, required contract clauses, concentration risk, and an exit strategy for outsourced IT (RBI)
Any sector NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices (May 2022, updated 1 November 2024) A multilevel approach to identifying, assessing and mitigating cyber risk "throughout the supply chain at all levels" of an organisation (NIST CSRC)

As of 26 October 2026, the EBA's page left the application date and compliance deadline for the new guidelines blank, so confirm them before planning a migration.

How do you tier vendors in a third-party risk programme?

Tiering decides how much work each supplier gets. Score each one on four questions:

  1. Criticality. If this supplier stopped tomorrow, would a critical service stop? The RBI calls an arrangement material if, when "disrupted or compromised", it could "significantly impact" the business.
  2. Data. Does it hold or see personal, payment or confidential data? How much?
  3. Access. Does it have accounts, API keys or network connections into your systems?
  4. Substitutability. How long would it take to replace?
Tier Typical profile Assurance before signing Review cycle
1, critical Supports a critical function, holds sensitive data or has privileged access, hard to replace Full due diligence, independent assurance report, contract clauses below, tested exit plan At least yearly, plus continuous signals
2, important Holds some sensitive data or has limited access Questionnaire plus evidence, key contract clauses Every one to two years
3, low No sensitive data, no access, easy to replace Basic checks and standard terms At renewal

Expect the tier 1 list to be short. If it runs to dozens of suppliers, the criteria are too loose. Those few deserve most of your time.

What evidence should you ask a vendor for in due diligence?

A questionnaire tells you what the supplier says. Evidence tells you what someone checked. For tier 1 and tier 2:

  • An independent assurance report covering the service you buy. Our guide to SOC 1, SOC 2 and SOC 3 reports explains what to read beyond the cover page.
  • Cloud-specific assurance for cloud services. The CSA Cloud Controls Matrix and STAR registry is one public source.
  • Financial and legal checks. The RBI lists "qualitative, quantitative, financial, operational, legal and reputational factors" for due diligence (Para 13(3)).
  • Their own suppliers. Who are the subcontractors that touch your data, and where are they?
  • Their incident history. Ask what incidents affected customers in the last three years and what changed afterwards.

Which clauses should a third-party contract include?

The contract is where risk management becomes enforceable. India's RBI Direction is a useful template because it lists clauses explicitly (Para 16):

  • Audit rights, including the "right to conduct audit of the service provider (including its sub-contractors)".
  • Regulator access, "recognising the authority of regulators to perform inspection" of the provider and its subcontractors.
  • Subcontractor approval: "prior approval/ consent" before the provider uses subcontractors.
  • Confidentiality, through a non-disclosure agreement on information the provider retains.
  • Termination and orderly transfer: rights to terminate, "including the ability to orderly transfer" the arrangement.
  • Data location, where local rules require it.

Add a breach notice clause with a clock. Under the RBI Direction, the provider must report cyber incidents to the regulated entity "without undue delay" (Para 17(8)), and the entity in turn has its own short deadline to the RBI. Your supplier's notice clock has to be shorter than your own regulator's. For how short those regulator windows are in each country, see breach notification deadlines worldwide.

How do you monitor suppliers, manage concentration risk and exit cleanly?

Monitoring. Between reviews, watch for signals: a new critical vulnerability in a product you use, a supplier breach in the news, a lapsed certificate, a change of ownership. MOVEit is the case for this: the useful question on 7 June 2023 was "do we or any supplier run MOVEit Transfer?", and you could only answer it quickly with an inventory.

Concentration risk. If many of your critical services depend on one supplier, one failure hits them all. The RBI asks firms to assess "concentration risk posed by multiple outsourcings to the same service provider" (Para 17(10)). The Change Healthcare ransomware case shows what one provider's outage can do to a whole sector.

Exit and offboarding. The RBI requires a "clear exit strategy" for outsourced IT that keeps the business running during and after exit (Para 22(1)). When a contract ends:

  1. Disable every account, API key, certificate and network route the supplier used.
  2. Get your data back in a usable format, then get written confirmation of deletion.
  3. Remove the supplier from integrations, single sign-on and email allow lists.
  4. Close the record in your register with the date and the evidence.

Going deeper: for security and IT teams

This section is for security architects, GRC leads and IT auditors who run the programme day to day.

Treat the register as a data model. One record per supplier relationship, linked to the business services it supports, the data classes it handles, the identities it holds in your estate and its subcontractors. DORA's register of information already asks EU financial entities for most of this; the DORA guide covers the format. Organisations outside DORA can reuse the structure.

Inventory supplier identities, not just suppliers. Snowflake showed that your configuration of a supplier is part of your attack surface. For each SaaS supplier, record: whether single sign-on is enforced, whether local passwords still work, whether MFA is required for every human and service login, whether network policies restrict access to trusted locations, and when credentials were last rotated. Mandiant's guidance was "credential monitoring, the universal enforcement of MFA and secure authentication, limiting traffic to trusted locations for crown jewels, and alerting on abnormal access attempts" (Mandiant).

Map products to suppliers for vulnerability response. Keep software bills of materials or at least a product-and-version list per supplier, so a new CVE can be matched in hours. CISA's MOVEit mitigations start with that inventory: "Take inventory of assets and data", then prioritise patching known exploited vulnerabilities on internet-facing systems (CISA AA23-158A). For supplier-hosted products, the contract should give you the right to ask, and a deadline for the answer.

Use NIST SP 800-161 Rev. 1 for structure. It integrates cybersecurity supply chain risk management (C-SCRM) into enterprise risk management through a multilevel approach, with guidance on C-SCRM strategy, implementation plans, policies, plans and risk assessments for products and services (NIST). NIST's page also carries a note, dated 2 December 2025, about a fillable version of its SCRM Assessment Scoping Questionnaire (Table 26), a reasonable starting point for your own tier 1 questions.

Detection and evidence.

  • Alert on supplier accounts logging in from new countries, new autonomous systems or outside contracted support hours.
  • Alert on bulk data export by supplier or integration accounts.
  • Review OAuth app grants and API tokens issued to suppliers each quarter, and remove unused ones.
  • For audit, keep: the tiering decision and its date, due diligence evidence, the signed clauses, monitoring results, incident notices received, and offboarding confirmation.

Questions for tier 1 suppliers:

  • Which of your subcontractors process our data, and where?
  • How fast will you notify us of an incident affecting our data, and through which channel?
  • Can we, and our regulator, audit you and your subcontractors?
  • Which of your products in our estate are internet-facing, and how fast do you patch known exploited vulnerabilities?
  • What does exit look like: data format, timeline and deletion evidence?

Key takeaways

  • Third-party risk has two halves: the supplier's own failures (MOVEit) and failures in how you configure the supplier (Snowflake customer accounts).
  • US banking agencies set one life cycle in June 2023: planning, due diligence, contract negotiation, ongoing monitoring and termination.
  • India's RBI Direction lists the contract clauses to copy: audit rights, regulator access, subcontractor approval, termination with orderly transfer, and data location.
  • The EBA announced non-ICT third-party guidelines on 18 September 2026 that will replace its 2019 outsourcing guidelines once applicable.
  • Spend your effort on tier 1 suppliers, and keep their identities in your estate on the same register.

A third-party risk management checklist

  1. List every supplier and tier it on criticality, data, access and substitutability.
  2. For tier 1, collect independent assurance and check subcontractors.
  3. Put audit, regulator access, subcontractor, breach notice and exit clauses in every tier 1 contract.
  4. Record each supplier's accounts, keys and network access in your estate, with MFA and rotation status.
  5. Keep a product-and-version list per supplier so a new CVE can be matched fast.
  6. Measure concentration: which critical services depend on the same supplier?
  7. Test one tier 1 exit plan a year, and offboard with evidence.

Sources