Ten years ago, third-party risk management was something a bank's examiners asked about and most other companies treated as good practice. That has changed. In the EU, the Digital Operational Resilience Act now sets binding rules for how financial entities manage their technology providers. In the US, the federal banking agencies have issued joint guidance on third-party relationships, and New York's financial regulator has written vendor security into its cybersecurity rule. Privacy law makes every controller answerable for its processors. And outside regulated sectors, the audit frameworks that customers ask for — SOC 2 and ISO/IEC 27001 — both expect a vendor programme an auditor can test.
This post reads those regimes side by side, in plain terms, and turns them into the records a programme must be able to produce. It is written for executives and boards who need to know what is being asked of the organisation, and for the risk and compliance leads who answer for it. It is a summary, not legal advice.
Confirm the wording with your compliance team
Regulations are summarised here in our own words to show how they relate to each other. Which regimes apply to you, and exactly what they require, depends on your sector, your jurisdictions and your regulator's own interpretation. Read the primary texts and confirm with your compliance and legal teams before relying on any summary, including this one.
In short
- The regimes agree more than they differ. Know your vendors, size the effort to the risk, put the right terms in the contract, keep watching, plan the exit and keep records.
- Financial services carry the heaviest load. DORA, the EBA outsourcing guidelines, the US interagency guidance and NYDFS Part 500 all apply detailed expectations.
- Everyone else meets the same ideas through audits and privacy law. SOC 2 CC9.2, ISO/IEC 27001 Annex A 5.19–5.23, GDPR Article 28 and, in the EU, NIS2 Article 21.
- The test is the record. An examiner or auditor asks you to show the inventory, the tiering, the due diligence, the contract, the monitoring and the decisions. A programme that cannot produce them has not done them.
Why this is a board-level question
Every one of these regimes repeats the same principle: an organisation may outsource a service, but not the responsibility for it. The board, or the management body, remains accountable for the risks its vendors create. Some regimes say so directly; DORA, for example, places responsibility for ICT risk management, including third-party arrangements, on the financial entity's management body. The practical consequence is that the board needs a view of third-party risk it can stand behind: which vendors are critical, how they were chosen, what is wrong with them now and what the organisation would do if one failed.
Financial services in the EU: DORA and the EBA guidelines
The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, has applied since 17 January 2025 to a wide range of EU financial entities. Its chapter on ICT third-party risk asks firms to manage that risk as part of their ICT risk framework, to adopt a strategy for it, to assess providers before contracting, to watch for concentration, to include specified provisions in their contracts, to plan exits for arrangements that support critical or important functions, and to keep a register of information covering all contractual arrangements with ICT third-party service providers. That register is reported to supervisors. DORA also creates an oversight framework for ICT providers designated as critical at EU level.
The European Banking Authority's Guidelines on outsourcing arrangements (EBA/GL/2019/02) predate DORA and continue to shape practice for banks and other institutions in their scope. They expect an outsourcing policy, an assessment of whether a function is critical or important, due diligence before contracting, contractual rights of access and audit, ongoing monitoring, documented exit strategies and an outsourcing register. Where DORA and the EBA guidelines overlap for ICT services, check with your compliance team how your supervisor expects the two to fit together.
Financial services in the US: the interagency guidance and NYDFS
The Interagency Guidance on Third-Party Relationships: Risk Management was issued in June 2023 by the Board of Governors of the Federal Reserve System, the FDIC and the OCC (for the OCC, Bulletin 2023-17). It replaced each agency's earlier guidance with one text. It describes the third-party relationship as a lifecycle — planning, due diligence and selection, contract negotiation, ongoing monitoring and termination — supported by governance: oversight and accountability, independent reviews, and documentation and reporting. It is explicitly risk-based: banks are expected to apply more comprehensive and rigorous oversight to relationships that support critical activities.
The New York Department of Financial Services cybersecurity regulation, 23 NYCRR Part 500, applies to entities it licenses. Section 500.11 requires a third-party service provider security policy: written policies and procedures covering how providers are identified and risk-assessed, the minimum cybersecurity practices they must meet, due-diligence processes for evaluating them, and periodic assessment of the risks they present and the adequacy of their practices. It also expects guidelines on matters such as access controls, including multi-factor authentication, encryption, and notice of cybersecurity events affecting the entity's systems or information. Part 500 was amended in November 2023, with requirements phasing in afterwards; confirm the current text and dates with your compliance team.
Privacy, resilience and the audit frameworks
GDPR Article 28 applies to any organisation that uses a processor for personal data of people in the EU. The controller may use only processors that provide sufficient guarantees of appropriate technical and organisational measures. Processing must be governed by a contract — in practice, the data processing agreement (DPA) — that sets out, among other things, that the processor acts only on documented instructions, keeps the data confidential, secures it, engages sub-processors only with the controller's authorisation, assists with data subjects' rights, deletes or returns the data at the end, and makes available the information needed to demonstrate compliance, including audits.
NIS2, Directive (EU) 2022/2555, requires essential and important entities in its scope to take cybersecurity risk-management measures. Article 21 lists supply chain security among them, including the security of relationships with direct suppliers and service providers, and asks entities to take into account suppliers' vulnerabilities and the quality of their products and security practices. As a directive, it applies through each member state's national law, so the exact obligations vary by country.
SOC 2, the AICPA's attestation against its Trust Services Criteria, includes common criterion CC9.2: the entity assesses and manages risks associated with vendors and business partners. ISO/IEC 27001:2022 Annex A has five controls on supplier relationships: 5.19 information security in supplier relationships, 5.20 addressing information security within supplier agreements, 5.21 managing information security in the ICT supply chain, 5.22 monitoring, review and change management of supplier services, and 5.23 information security for use of cloud services. Neither framework is a law; both are what your own customers will ask about, and both are tested by an auditor.
| Regime | Who it reaches | What it emphasises for third parties |
|---|---|---|
| DORA (EU) 2022/2554 | EU financial entities, from 17 January 2025 | ICT third-party strategy, pre-contract assessment, contract provisions, concentration, exit plans, register of information |
| EBA outsourcing guidelines (EBA/GL/2019/02) | Banks and other institutions in EBA scope | Critical or important functions, due diligence, access and audit rights, exit strategies, outsourcing register |
| US interagency guidance, June 2023 (OCC Bulletin 2023-17) | Banks supervised by the Fed, FDIC and OCC | Lifecycle risk management, risk-based rigour for critical activities, governance and documentation |
| NYDFS 23 NYCRR 500.11 | Entities licensed by NYDFS | Written third-party service provider policy, risk assessment, minimum practices, due diligence, periodic assessment |
| GDPR Article 28 | Controllers using processors for EU personal data | Sufficient guarantees, a processing contract with required terms, sub-processor authorisation, deletion or return, audits |
| NIS2 Article 21 | Essential and important entities, via national law | Supply chain security as a required risk-management measure |
| SOC 2 CC9.2 | Organisations seeking a SOC 2 report | Vendor and business-partner risks assessed and managed |
| ISO/IEC 27001:2022 A.5.19–5.23 | Organisations certified to ISO/IEC 27001 | Supplier relationships, agreements, ICT supply chain, monitoring, cloud services |
Where the regimes agree
Read together, the regimes describe one programme in different vocabularies. Strip out the sector-specific detail and six expectations remain. Almost every regime above touches all six, with different weight.
inventory or register"] --> B["Size the effort
criticality and tiering"] B --> C["Diligence before signing
evidence, assessment"] C --> D["The right contract
security, data, audit, exit terms"] D --> E["Keep watching
monitoring and periodic review"] E --> F["Plan the exit
termination and data return"] E -.-> B G["Governance and records
who decided, on what evidence"] -.-> A G -.-> C G -.-> D G -.-> E G -.-> F
Six shared expectations, held together by governance and records.
The records a programme must be able to produce
Examiners and auditors do not assess intentions; they ask for evidence. The practical test of a third-party programme is whether it can produce, quickly and consistently, the records below. The right-hand column shows where each lives in InsightVendors today, and what is planned rather than supported.
| Record | Asked for by (examples) | In InsightVendors |
|---|---|---|
| Inventory of vendors with owner, services, data and systems | DORA register, EBA register, ISO 5.19, NYDFS | Vendor list and Vendor 360 relationship tab. A DORA register-of-information export is planned for 1.3. |
| Criticality or tier, with the reasons | Interagency guidance, DORA, EBA | Tier 1–4 from customer-owned rules; inherent risk with each factor listed |
| Due diligence evidence | All regimes | Documents with extracted fields and page-cited findings; assessments with each answer's source |
| Contract terms against required provisions | DORA, EBA, GDPR Art. 28, ISO 5.20 | Contract agent checks clauses against your playbook and proposes redlines; DPA subprocessors, breach window, location, SCCs, deletion |
| Ongoing monitoring and periodic review | Interagency guidance, NYDFS, ISO 5.22, CC9.2 | Signals with reactions by tier; reassessment cadence by tier; document expiry |
| Fourth parties and concentration | DORA, EBA | Subprocessors and subservice organisations extracted from DPAs and SOC reports; concentration on the insights page |
| Exit and termination | DORA, EBA, interagency guidance, GDPR Art. 28 | Offboarding checklist: access revoked, data returned or deleted, contract terminated. Exit plans for critical vendors are planned for 2.0. |
| Decisions and who made them | All regimes | Lane decisions, conditions as tracked findings, agent runs with what they cited and who approved, the activity trail |
The last row deserves emphasis because agents change it. When an agent reads a SOC report or proposes a contract redline, a regulator will reasonably ask how the organisation controlled that work. In InsightVendors every agent action is recorded as an agent run with its input, output, autonomy level, what it cited, whether it used rules or a model, and who approved it. Messages to vendors wait in an outbox until a person releases them. That record is what lets you say that people made the decisions.
For the CISO
Regulators treat a critical vendor's incident as your operational incident, often with your notification clock. The CISO needs current evidence and a monitored signal for every critical ICT provider.
Ask: for each Tier 1 vendor, is the SOC report in date, are critical findings owned, and what is the exit plan?
For the vendor-risk lead
The vendor-risk lead owns the records. The aim is that any examiner request in the table above can be answered from the system in minutes, not assembled from email.
Ask: can we produce the register, the tiering rationale and the last review for any vendor today?
For the board
The board is accountable and should see a short, regular report: critical vendors, concentration, open critical findings and overdue reviews, with trend.
Ask: would we know if a critical vendor's assurance lapsed, and who would tell us?
What InsightVendors does not claim
Using InsightVendors does not make a programme compliant with any regulation; your policies, decisions and evidence do. In 1.0 the workflow templates are general (Standard SaaS, Critical/regulated, Low-risk fast track, Renewal, Offboarding). Regime-specific templates for the OCC, DORA and NYDFS, board reporting and exit plans for critical vendors are planned for 2.0, and the DORA register export for 1.3. Until then, the records exist but you shape them into each regulator's format yourself.
What to do next
Confirm, with counsel, which of the regimes above reach you, through which entities and jurisdictions.
For each regime, note what it adds to inventory, tiering, diligence, contract, monitoring and exit.
Make sure what a regulator calls critical or important lands in your Tier 1.
Add the provisions DORA, the EBA and GDPR Article 28 require, so the Contract agent checks every agreement against them.
Pick five vendors and ask for the records in the table above. Time how long it takes.
A short, regular view of critical vendors, findings, concentration and overdue reviews.
Every regulator asks the same question in its own words: can you show that you chose, contracted and watched your vendors with care?
Build one programme that meets the shared expectations, keep the records as you go, and confirm each regime's exact wording with your compliance team.