Third-party risk management: program, vendor risk assessment and questionnaire

Answer first. Third-party risk management is the program that identifies every outside party an organization depends on, rates each by criticality and data access, assesses the risky ones before contract and on a cycle, writes the controls into the contract, monitors performance and exits cleanly. Regulators set the lifecycle; the Shared Assessments SIG is the industry questionnaire for the assessment step.

What third-party risk management is, and what it covers

The US banking agencies give the widest definition of the subject. Their Interagency Guidance on Third-Party Relationships: Risk Management (Board, FDIC and OCC, June 2023) addresses "any business arrangement" between a banking organization and another entity, by contract or otherwise, and says a relationship may exist without a contract or payment. Its examples include outsourced services, independent consultants, referral arrangements, merchant payment processing, affiliates and subsidiaries, and joint ventures. The point of the breadth is the sentence that follows: use of third parties "does not diminish its responsibility" to operate safely and in compliance, to the same extent as if it did the work itself.

The European Banking Authority draws the same line in its 2026 guidelines. A third-party arrangement is an arrangement of any form between a financial entity and a third-party service provider to support one or more functions on a recurrent or ongoing basis; outsourcing is the subset where the provider performs a function the entity would otherwise perform itself. Third-party risk is the risk that arises from using those services, including services delivered by the provider's subcontractors.

NIST SP 800-161 Rev. 1 names the reason the discipline is hard: identifying cybersecurity risk in the supply chain is "complicated by the information asymmetry" between acquirers and suppliers, because acquirers often cannot see how a product was built or a service is delivered. A third-party risk program is the set of records and activities that reduce that asymmetry to a level the organization can accept.

The program is not procurement, which selects and buys, and not vendor management, which runs the relationship for value; Third-Party Risk vs Vendor Management vs Procurement sets out the boundaries. For a short definition, see What is third-party risk management?.

Who requires it: the five sources that set the standard

Five documents define what a defensible program looks like. They agree on far more than they differ.

Who requires it: the five sources that set the standard

Source	Publisher, date, status	Who it binds	What it contributes to the program
Interagency Guidance on Third-Party Relationships: Risk Management	Board, FDIC, OCC; final 6 June 2023, Federal Register 9 June 2023; supervisory guidance, not law	All banking organizations the three agencies supervise	The five-stage lifecycle (planning, due diligence and selection, contract negotiation, ongoing monitoring, termination), the "critical activities" concept, governance and documentation expectations
Regulation (EU) 2022/2554 (DORA), Chapter V	European Parliament and Council; applies from 17 January 2025; binding regulation	Financial entities in the EU, for ICT services	Register of information (Article 28(3)), pre-contract assessment including concentration risk (28(4), 29), mandatory contract clauses (30), exit strategies (28(8)), oversight of critical ICT third-party providers (31 onward)
EBA Guidelines on outsourcing arrangements, EBA/GL/2019/02	European Banking Authority; 25 February 2019; applied from 30 September 2019	Credit institutions, investment firms and payment institutions	Critical or important function test (paragraph 29), register contents (54 and 55), due diligence (69 to 73), contract minimums (75), sub-outsourcing (76 to 78), audit rights (87 to 93), exit strategies (106 to 108)
EBA Guidelines on the sound management of third-party risk related to non-ICT services, EBA/GL/2026/09	European Banking Authority; final report 18 September 2026; awaiting translation; two-year transitional period; will repeal EBA/GL/2019/02	Financial entities under CRD, IFD, PSD2 and MiCAR	Extends the 2019 approach from outsourcing to all third-party arrangements, aligned with DORA; register to be consistent with, or combined with, the DORA register
NIST SP 800-161 Rev. 1 (Update 1)	NIST; May 2022, updated 1 November 2024; voluntary except for US federal agencies	US federal agencies; used by industry	Cybersecurity supply chain risk management (C-SCRM) across three levels (enterprise, mission and business process, operational); the frame, assess, respond, monitor cycle; criticality analysis; control catalog
ISO/IEC 27036 series	ISO/IEC; Part 1:2021, Part 2:2022, Part 3:2023, Part 4:2016	Any organization; Part 2 carries requirements	Information security in supplier relationships: agreement processes (acquisition and supply), project-enabling processes, technical management processes; hardware, software and services supply chain (Part 3); cloud (Part 4)
Shared Assessments SIG	Shared Assessments; annual editions; licensed	Industry instrument, not a regulation	The standardized questionnaire used for the assessment step: SIG Lite for lower-risk vendors, SIG Core for the full assessment, scoping presets in the 2026 workbook

The UK PRA's SS2/21 and APRA's CPS 230 follow the same lifecycle with a "material" cut-off; this guide does not work through them. Framework pages: EU DORA, NIST SP 800-161 Rev. 1, Shared Assessments SIG.

The lifecycle, stage by stage

The Interagency Guidance describes third-party risk management as "a continuous life cycle" with five stages. DORA, the EBA guidelines and ISO/IEC 27036-2 use different words for the same sequence. The table lines them up and names the record each stage should leave behind.

The lifecycle, stage by stage

Stage	What you do	Record it produces	Interagency Guidance	DORA Chapter V	EBA/GL/2019/02
1. Planning and intake	Decide whether to use a third party, what it will do, what data and systems it touches, and how you will oversee it	Intake record; preliminary tier	"Planning"	Strategy on ICT third-party risk, 28(2); pre-contract assessment, 28(4)	Pre-outsourcing analysis, Section 12
2. Due diligence and selection	Assess the candidate's ability to perform, comply and stay resilient, at a depth set by the tier	Completed questionnaire, evidence, inherent and residual rating, findings	"Due Diligence and Third-Party Selection", factors a to n	Due diligence, 28(4)(d); information security standards, 28(5)	Due diligence, 12.3, paragraphs 69 to 73
3. Contract negotiation	Write the controls, rights and exit terms into the agreement	Executed contract with clause checklist; obligations register	"Contract Negotiation", factors a to q	Key contractual provisions, Article 30	Contractual phase, paragraph 75; sub-outsourcing, 76 to 78
4. Ongoing monitoring	Review performance, control evidence, incidents, financial condition and subcontractor changes on a cadence set by tier	Monitoring log; issues; reassessment	"Ongoing Monitoring"	Audit and inspection, 28(6); reporting obligations, 30(3)(b)	Monitoring, Section 14; audit rights, 13.3
5. Termination and exit	Transition, bring in-house or discontinue; recover data; remove access; close issues	Exit plan; offboarding checklist; closed record	"Termination"	Termination rights, 28(7); exit strategies, 28(8); transition period, 30(3)(f)	Termination rights, 13.4; exit strategies, Section 15
Across all stages: governance	Board oversight, independent review, inventory and reporting	Register or inventory; board pack; audit results	"Governance": oversight and accountability, independent reviews, documentation and reporting	Register of information, 28(3); annual report to authorities	Register, Section 11; internal audit, paragraphs 50 to 51

ISO/IEC 27036-2:2022 covers the same ground as agreement processes (acquisition and supply), organizational project-enabling processes and technical management processes. NIST SP 800-161 Rev. 1 sits across the whole table: it integrates supply chain risk into the NIST SP 800-39 cycle of frame, assess, respond and monitor, and asks for the work to happen at all three levels, enterprise (strategy, policy, implementation plan), mission and business process (tailored plans) and operational (system-level C-SCRM plans and controls).

Planning and intake

Planning is the stage most programs skip, and it is where the tier is set and the oversight cost decided. The Interagency Guidance lists the factors: the strategic purpose of the arrangement and its fit with risk appetite; the benefits and risks; the nature of the arrangement, including "volume of activity, use of subcontractor(s), technology needed, interaction with customers, and use of foreign-based third parties"; costs; customer impact, including access to customer information; information and physical security implications; how the organization will select, assess and oversee the third party, and whether it has the staff and systems to do so; and contingency plans if the activity must move to another provider or in-house. Where critical activities are involved, plans may go to the board for approval.

The EBA asks for the same analysis: an assessment of the effect on operational risk (paragraph 64), scenario analysis for high-severity events where appropriate (65), and a weighing of benefits against new risks, including concentration risk, aggregated risk across the organization and, for significant institutions, step-in risk (66). DORA Article 28(4) requires, before contracting, an assessment of whether the service supports a critical or important function, whether supervisory conditions are met, and "all relevant risks", including ICT concentration risk under Article 29.

In practice this is an intake form with structured fields, not a free-text business case. The fields that drive the tier are the function supported, the data classification, the systems and access involved, the customer interaction, the geography, the use of subcontractors and the substitutability of the provider. Everything downstream reads from them.

Vendor tiering: criticality by data access

Every regime in the previous table says the depth of oversight must match the risk. The Interagency Guidance says not all relationships require the same level of oversight, and that the organization "tailors risk management practices" commensurate with its size and the nature of the relationship. It leaves the method to the organization: some assign a criticality or risk level to each relationship, others identify critical activities and the third parties that support them. What it insists on is "a sound methodology" to decide which relationships receive more oversight.

The criticality half of the method has published definitions to borrow.

• Critical activities (US). Activities that could cause the organization "significant risk if the third party fails to meet expectations", have "significant customer impacts", or have "a significant impact on a banking organization's financial condition or operations". The guidance notes that an activity critical for one organization may not be critical for another.
• Critical or important function (EU). DORA Article 3(22) defines it as a function whose disruption "would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities", or whose interruption would materially impair compliance with authorization conditions or other obligations. EBA/GL/2019/02 paragraph 29 uses the same test and adds two automatic cases: outsourced operational tasks of internal control functions, and outsourcing to an extent that would itself need authorization. Paragraph 31 lists factors to weigh, including whether the arrangement is directly connected to authorized activities, the potential impact of failure, the impact on personal data and the substitutability of the provider.
• Criticality analysis (NIST). NIST SP 800-161 Rev. 1 lists among its foundational practices "a process for identifying and measuring the criticality of the enterprise's suppliers, products, and services", and points to NIST IR 8179 for the method.

The data-access half comes from your own data classification. The matrix below combines the two into four tiers. The bands are an example; the sources require a documented methodology, not this one.

Vendor tiering: criticality by data access

Criticality of the function ↓ / Highest data classification the vendor can access →	Public or none	Internal	Confidential (customer, employee, commercial)	Restricted (regulated personal data, payment data, credentials, source code)
Critical or important function (failure materially impairs the service, customers or compliance; not easily substitutable)	Tier 2	Tier 1	Tier 1	Tier 1
Supports a critical function but is substitutable	Tier 3	Tier 2	Tier 1	Tier 1
Standard business function	Tier 4	Tier 3	Tier 2	Tier 1
Low-impact, short-term or one-off	Tier 4	Tier 4	Tier 3	Tier 2

What each tier gets:

Vendor tiering: criticality by data access

Tier	Assessment before contract	Evidence	Reassessment	Approval
Tier 1	Full questionnaire (SIG Core scope), independent assurance review, financial review, subcontractor mapping, exit plan	SOC 2 Type II or ISO/IEC 27001 certificate, penetration test summary, business continuity test results, insurance certificates	Annual, plus continuous monitoring and event triggers	Board or delegated committee; second-line sign-off
Tier 2	Full questionnaire (SIG Core scope)	Certification or audit report; policy set	Annual or on material change	Risk function and business owner
Tier 3	Short questionnaire (SIG Lite scope)	Self-attestation plus any available certification	Every two years or at renewal	Business owner
Tier 4	Attestation of policy compliance; contract terms only	None beyond contract	At renewal	Procurement

Two rules keep the matrix honest. First, criticality and risk are different axes. A vendor can be critical and well controlled, or trivial and badly controlled; the tier sets the depth of assessment, and the assessment sets the residual risk. Critical Vendor Management works through the distinction and the criteria. Second, the tier is a field on the vendor record with a date and an approver, not a label in a spreadsheet column. EBA/GL/2019/02 paragraph 54(i) asks for "the date of the most recent assessment of the criticality or importance" in the register itself.

Due diligence and the vendor risk assessment

Due diligence answers one question: can this third party perform the activity as expected, follow your policies, comply with the law and do so safely. The Interagency Guidance says prior experience with a vendor is "not an adequate proxy" for it, that scope should be commensurate with risk, and that where information cannot be obtained the organization should document the limitation and consider extra controls, extra monitoring or a different vendor.

The guidance lists fourteen factors, and they make a good structure for the assessment file: strategies and goals; legal and regulatory compliance, including ownership and sanctions screening; financial condition; business experience; qualifications and background checks of key personnel; risk management, including audit and SOC reports; information security; management of information systems; operational resilience, including "dependency on a single provider for multiple activities"; incident reporting; physical security; reliance on subcontractors; insurance; and contractual arrangements with other parties.

The EBA's list overlaps almost entirely. For critical or important functions the provider must have "the business reputation, appropriate and sufficient abilities, the expertise, the capacity, the resources", the organizational structure and any required authorization to perform the function reliably for the life of the contract (paragraph 70); its business model, financial situation, group structure and supervisory status are further factors (71); and where personal or confidential data is involved, the institution must be satisfied that technical and organizational measures protect it (72).

The assessment itself runs in three steps.

Step 1, inherent risk. Rate the arrangement before any vendor control is considered, using the tier inputs: function criticality, data classification, access, geography, subcontracting and substitutability. This score sets the questionnaire scope and does not change when the vendor answers well.

Step 2, control assessment. Send the questionnaire at the depth the tier requires, collect evidence for every "yes" that matters, and review independent assurance. EBA/GL/2019/02 paragraphs 91 to 93 allow reliance on certifications and audit reports only if the institution is satisfied with the audit plan, the scope covers the systems and key controls it cares about, and it assesses the content on an ongoing basis; for critical functions it "should not rely solely on these reports over time". The Interagency Guidance says the same about SOC reports.

Step 3, residual risk and findings. Each gap becomes a finding with a severity, a vendor-side owner, a due date and a link to the contract clause or control it affects. The residual rating is the inherent rating adjusted for the controls you have evidence for, not the ones the vendor says it has. The decision is accept, accept with conditions written into the contract, or decline. For the scoring mechanics, use the same 5×5 method as the enterprise register so vendor risks roll up; see What is a risk register?.

What is vendor due diligence? defines the term; Vendor Risk Review Checklist for Critical Vendors gives a 40-item review for Tier 1.

The questionnaire: the SIG domains and what to ask

The Standardized Information Gathering questionnaire, published by Shared Assessments, is the instrument most large buyers and most vendors already know. It exists in two scopes, SIG Lite for lower-risk relationships and SIG Core for a full assessment, and the 2026 workbook adds scoping presets so an assessor can size the question set to the tier. Its questions map to a set of reference documents that includes ISO/IEC 27001 and 27002, NIST SP 800-53, the NIST Cybersecurity Framework, PCI DSS, the GDPR and, from the 2026 edition, ISO/IEC 42001 for AI management. The workbook is licensed; the domain names below are as Shared Assessments licensees list them for the current edition and should be confirmed against your licensed copy.

The value of the SIG is not its questions, which any team could write, but reuse: a vendor that maintains a completed SIG responds in days rather than weeks, and an assessor compares vendors on one structure. Where a vendor offers a SOC 2 report or ISO/IEC 27001 certificate instead, accept it for the domains it covers and ask the SIG questions only for the domains it does not.

The table gives the 21 SIG domains, what each establishes, the evidence to request and which tiers it applies to. The template CSV has three to four questions per domain in this structure.

The questionnaire: the SIG domains and what to ask

SIG domain	What it establishes	Evidence to request	Tiers
Enterprise Risk Management	The vendor has a risk program with executive ownership and a register	Risk policy; register extract; committee terms of reference	1, 2
Information Assurance	Security program governance, policy set, independent assessment	Security policy; SOC 2 Type II or ISO/IEC 27001 certificate and statement of applicability	1, 2, 3
Human Resources Security	Screening, training, disciplinary process, leaver handling	Background-check policy; training completion rates; joiner and leaver procedure	1, 2, 3
Asset and Information Management	Inventory, classification, handling, media disposal	Classification scheme; asset inventory process; disposal certificates	1, 2
Physical and Environmental Security	Facilities, data center access, environmental controls	Data center certification or SOC report; visitor and badge procedures	1, 2
IT Operations Management	Change, capacity, backup, logging, malware protection	Change procedure; backup and restore test results	1, 2
Access Control	Identity lifecycle, least privilege, MFA, privileged access, reviews	Access policy; last access review; MFA coverage	1, 2, 3
Application Management	Secure development lifecycle, code review, testing, vulnerability handling	SDLC policy; penetration test summary; remediation SLAs	1, 2
Cybersecurity Incident Management	Detection, response, notification timelines, post-incident review	Incident response plan; notification commitment; last exercise report	1, 2, 3
Operational Resilience	Business continuity, disaster recovery, RTO and RPO, testing	BCP and DR plans; last test results; RTO and RPO per service	1, 2, 3
Compliance Management	Regulatory obligations, internal audit, findings tracking	Compliance policy; audit findings status; regulatory correspondence	1, 2
Endpoint Security	Device management, encryption, patching, remote work	Endpoint policy; encryption and patch compliance figures	1, 2
Network Security	Segmentation, firewalls, remote access, monitoring	Network diagram at an appropriate level; monitoring coverage	1, 2
Privacy Management	Lawful basis, data subject rights, transfers, retention, DPO	Privacy notice; records of processing; transfer mechanism; DPA	1, 2, 3 (where personal data)
Threat Management	Vulnerability management, threat intelligence, patch cadence	Scan cadence and results summary; patch SLAs	1, 2
Server Security	Hardening, configuration baselines, logging	Hardening standard; configuration compliance figures	1, 2
Cloud Services	Shared-responsibility model, tenant isolation, key management, regions	Cloud provider assurance report; architecture summary; data location	1, 2, 3 (where cloud-delivered)
Supply Chain Risk Management	How the vendor assesses its own suppliers and components	Supplier risk policy; software bill of materials where relevant	1, 2
Nth-Party Management	Subcontractors used to deliver your service, their location and oversight	Subcontractor list with locations and functions; flow-down terms	1, 2
Artificial Intelligence	Use of AI in the service, data used for training, human oversight, model governance	AI use disclosure; ISO/IEC 42001 status if claimed; data-use terms	1, 2 (where AI is used)
Environmental, Social and Governance	Conduct, modern slavery, environmental reporting where required	Code of conduct; modern slavery statement; relevant disclosures	1 (where policy requires)

For AI vendors specifically, AI Vendor Risk Management sets out the extra questions. Where the vendor processes personal data, the privacy assessment and the vendor assessment should share one record; see How to Connect DPIAs, AI Reviews, and Vendor Reviews.

Contract negotiation: the clauses three regimes agree on

The contract is where the assessment's conditions become enforceable. The Interagency Guidance lists seventeen contract considerations, from nature and scope through default and termination. DORA Article 30(2) lists nine provisions for every ICT contract and Article 30(3) six more for critical or important functions. EBA/GL/2019/02 paragraph 75 lists seventeen minimums for critical or important outsourcing. Read together, they agree on a core set.

Contract negotiation: the clauses three regimes agree on

Clause	Interagency Guidance	DORA Article 30	EBA/GL/2019/02 paragraph 75
Description of the service, and whether subcontracting is permitted and on what conditions	a. Nature and scope; n. Subcontracting	30(2)(a)	(a), (e); sub-outsourcing conditions in 76 to 78
Locations where the service is performed and data is processed, with notice of changes	o. Foreign-based third parties	30(2)(b)	(f)
Data protection: availability, integrity, confidentiality; access and return of data on insolvency or termination	c. Information; h. Confidentiality and integrity	30(2)(c), (d)	(g), (m)
Service levels with measurable targets and reporting	b. Performance measures	30(2)(e); 30(3)(a) quantitative and qualitative targets	(i), (j)
Incident notification and assistance	h. Breach disclosure	30(2)(f) assistance at no additional or pre-agreed cost; 30(3)(b) notify developments with material impact	(j)
Cooperation with regulators and resolution authorities	q. Regulatory supervision	30(2)(g)	(n), (o)
Right to audit and require remediation, for the organization and its regulators	d. Right to audit	30(3)(e) unrestricted rights of access, inspection and audit	(p); Section 13.3
Business continuity, testing and security measures	i. Operational resilience and business continuity	30(3)(c) contingency plans and ICT security measures; 30(3)(d) participation in threat-led penetration testing	(l), (k) insurance
Termination rights, notice periods and transition period	p. Default and termination	30(2)(h); 30(3)(f) mandatory adequate transition period; termination grounds in 28(7)	(q); Section 13.4
Compliance with applicable law and the organization's policies	e. Responsibility for compliance	Recital and 28(1)(a) responsibility retained	(a) with regulatory references
Costs, indemnification, liability, insurance, dispute resolution	f, j, k, l	Not specified	(d), (k)

Three points contract reviewers most often miss. DORA Article 30(1) requires the whole agreement, including service level agreements, to be in one written document in a durable format. The Interagency Guidance says that where negotiating power is limited the organization should understand the resulting limitations and decide whether the residual risk is acceptable, and that periodic reviews of executed contracts should confirm the provisions still address the risks. And EBA paragraph 78 requires, where sub-outsourcing of a critical function is permitted, notice of planned subcontracting changes long enough for the institution to assess and object, and a right to terminate for undue sub-outsourcing; DORA's equivalent is Commission Delegated Regulation (EU) 2025/532 of 24 March 2025.

Obligations that are tracked only in a PDF cannot trigger a monitoring task. Reporting frequency, audit rights, notice periods and exit terms belong on records linked to the vendor, which is what the Contract Lifecycle Management product is for.

Ongoing monitoring

The Interagency Guidance gives monitoring three purposes: confirm the quality and sustainability of the third party's controls; escalate significant issues such as "material or repeat audit findings, deterioration in financial condition, security breaches, data loss, service interruptions, compliance lapses"; and respond to them. Monitoring may be periodic or continuous and should be more frequent for critical activities. Typical activities are reviewing performance and control reports, periodic visits and meetings, testing the organization's own controls over the relationship and, where warranted, direct testing of the third party's controls.

The factors to watch are the ones that can change the tier or the residual rating: the third party's strategy and its agreements with others; financial condition and insurance; audit and test results; performance against the contract; key personnel; reliance on subcontractors and their location; response to new threats and incidents; business continuity testing; external conditions; and customer complaint trends.

A workable cadence by tier:

• Tier 1: quarterly performance and control review with the vendor; annual full reassessment with refreshed evidence; continuous external signals (financial, cyber rating, sanctions, news) where available; event-driven reassessment on any incident, subcontractor change, ownership change or failed control test.
• Tier 2: annual reassessment; semi-annual review of service levels and open findings; event-driven triggers as above.
• Tier 3: reassessment at renewal or every two years; event-driven triggers.
• Tier 4: contract renewal only.

Findings, exceptions and remediation belong in the issues process rather than in email. DORA Article 28(6) asks for audit frequency and scope to be set on a risk-based approach, and Article 28(7) lists the grounds on which termination must be possible, including "evidenced weaknesses pertaining to its overall ICT risk management". Monitoring is what produces that evidence. How Issues Management Becomes the Backbone of Connected GRC describes the issue record; Vendor Portals and the Hidden Work of Third-Party Risk covers the collection mechanics.

Concentration risk and fourth parties

Concentration risk is the exposure that arises when many functions depend on one provider, or when the provider that supports a critical function cannot be replaced. It appears in every source in this guide, and it is the risk that individual vendor assessments cannot see, because each assessment looks at one relationship.

DORA is the most explicit. Article 3(29) defines ICT concentration risk as an exposure to individual or multiple related critical ICT third-party providers that creates a dependency such that their unavailability or failure "may endanger the ability of a financial entity to deliver critical or important functions". Article 29(1) requires the pre-contract assessment to consider whether the arrangement would mean contracting a provider "that is not easily substitutable", or "multiple contractual arrangements" with the same provider or closely connected providers. Article 29(2) extends the analysis to subcontracting chains: the entity must assess whether "long or complex chains of subcontracting" may impair its ability to monitor the function, and must consider third-country subcontractors, data protection and insolvency law.

EBA/GL/2019/02 paragraph 66(a) uses the same two tests, a dominant provider that is not easily substitutable and multiple arrangements with the same or closely connected providers, and adds aggregated risk across the institution and step-in risk. The Interagency Guidance is quieter but present: "dependency on a single provider for multiple activities" appears in the due diligence factors on resilience and subcontractors, and again in the list of what to report periodically to the board.

At the system level, DORA Article 31 lets the European Supervisory Authorities designate critical ICT third-party providers on four criteria: the systemic impact of a large-scale failure, the systemic importance of the entities that rely on the provider, the degree of reliance for critical or important functions, and substitutability. The ESAs published the first designations on 18 November 2025 and now oversee those providers directly through a Lead Overseer. A vendor on that list is, by definition, one your peers also depend on.

What a program needs to manage this:

1. A register that can be queried by provider and by parent, not just by contract. DORA Article 28(3) and EBA/GL/2019/02 paragraph 52 require the register at entity level and, where applicable, at sub-consolidated and consolidated levels, which is what makes the "same provider across the group" query possible. The EBA register asks for each provider's parent company (54(e)), and the 2026 guidelines for the ultimate parent and an identifier, which is what makes "closely connected providers" visible.
2. A substitutability rating on every critical arrangement. EBA/GL/2019/02 paragraph 55(h) asks for it as "easy, difficult or impossible"; the 2026 guidelines refine the scale to easy, medium, highly complex or impossible, dated, with alternative providers identified.
3. A fourth-party map for Tier 1. Subcontractors to which material parts of a critical function are sub-outsourced, their country of registration, where the service is performed and where data is stored (EBA 55(g)); the 2026 guidelines add the rank in the chain. Fourth-Party Risk Management covers how to build it.
4. A link from each critical vendor to the service and impact tolerance it supports. Concentration is only meaningful against what would be lost; the business impact analysis holds that. See Business Impact Analysis in Connected GRC and Risk Appetite vs Risk Tolerance vs Impact Tolerance.
5. A concentration view on the dashboard. Providers by number of critical functions supported; critical functions by number of viable alternatives; fourth parties shared across Tier 1 vendors. The Interagency Guidance names the first of these as a board reporting item.

Termination and exit

Exit is planned at intake and written into the contract, not improvised when the relationship fails. The Interagency Guidance lists the termination considerations: options for transition, including alternate providers; the capabilities, resources and time needed to transition or bring in-house; costs and fees; data retention and destruction, system connections and access control after the relationship ends; joint intellectual property; and the impact on customers if termination follows a vendor failure.

The EU sources go further for critical functions. DORA Article 28(8) requires documented exit strategies for ICT services supporting critical or important functions, with transition plans and identified alternatives, so that exit does not disrupt business, breach regulatory requirements or harm service continuity. EBA/GL/2019/02 paragraph 106 requires a documented exit strategy covering termination, provider failure, deterioration of service and material risks; paragraph 107 requires exit plans that are "comprehensive, documented and, where appropriate, sufficiently tested"; and paragraph 108 says how to build one: define objectives, run a business impact analysis to size the resources and time an exit would need, assign roles, define success criteria, and define the monitoring indicators, including unacceptable service levels, "that should trigger the exit". The 2026 guidelines ask the register to record whether an exit plan exists, with the function's recovery time and recovery point objectives.

The offboarding checklist itself is covered in Vendor Offboarding in Connected GRC. Two additions from the sources: keep the record of an ended arrangement in the register for an appropriate period (EBA paragraph 52; 2026 guidelines paragraph 59), and make sure the contract's transition period is long enough for the exit plan you actually tested.

Governance, the register and reporting

The Interagency Guidance assigns roles plainly. The board "has ultimate responsibility for providing oversight", sets risk appetite and approves policy; management implements the policies, directs the lifecycle activities, reports to the board, escalates significant issues and terminates arrangements that no longer meet expectations. Periodic independent reviews assess whether relationships align with strategy and policy, whether risks are identified, measured, monitored and controlled, whether staffing and expertise are adequate, and whether conflicts of interest are avoided.

The record that makes this possible is the inventory or register. The Interagency Guidance lists "a current inventory of all third-party relationships (and, as appropriate to the risk presented, related subcontractors)" that identifies those supporting critical activities, alongside risk assessments, due diligence results, executed contracts, remediation plans, monitoring reports, incident reports, independent review results and board reporting.

In the EU the register is prescribed. DORA Article 28(3) requires a register of information on all contractual arrangements for ICT services, at entity, sub-consolidated and consolidated levels, distinguishing those that support critical or important functions, with an annual report to the competent authority on new arrangements and timely notification of planned arrangements for critical or important functions. Commission Implementing Regulation (EU) 2024/2956, published in the Official Journal on 2 December 2024, sets the templates. EBA/GL/2019/02 paragraph 54 lists the minimum fields for every outsourcing arrangement, from reference number and dates through provider identity and parent, countries of service and data, the criticality flag with reasons, and the date of the last criticality assessment; paragraph 55 adds the fields for critical functions, including approver, governing law, audit dates, subcontractors and their locations, substitutability, alternatives and annual budget. Paragraph 56 requires the register to be available to the authority in a processable electronic form. The 2026 guidelines carry the same list across and ask for the non-ICT register to be consistent with the DORA register or combined with it.

Even outside the EU, those fields are the right schema. A program that can produce that register on demand can answer any question a board, an auditor or an examiner is likely to ask. Connected GRC for TPRM Teams describes the reporting layer by role.

Common mistakes

1. An inventory built from accounts payable. Payment records miss relationships without remuneration, which the Interagency Guidance says still count, and miss affiliates, referral partners and free-tier software. Build the inventory from intake and reconcile it against spend, not the other way round.
2. Tiering by spend. Contract value is a poor proxy for either criticality or data access. A low-cost identity provider can be Tier 1. Use the two axes above.
3. Sending the full questionnaire to everyone. It exhausts vendors, delays onboarding and buries the answers that matter. SIG Lite exists for Tier 3; attestation is enough for Tier 4.
4. Treating a SOC 2 report as the assessment. Both the EBA (paragraphs 92 and 93) and the Interagency Guidance require the scope of the report to be checked against the activity, and the EBA says not to rely solely on reports over time for critical functions.
5. Reducing residual risk for controls with no evidence. A "yes" on a questionnaire is a claim. The residual rating should move only for controls with evidence on file.
6. Contract conditions that never reach monitoring. If the assessment required MFA within 90 days, something must check at day 90. Findings become issues with owners and dates, and contract obligations become scheduled tasks.
7. No substitutability rating, and no tested exit plan. Without the rating, concentration risk cannot be assessed; without a tested plan, the exit is a hope. The EBA has required both in some form since 2019 (paragraphs 55(h) and 107).
8. Ownership in the wrong place. The Interagency Guidance allows accountability to sit with business lines or with a central function, but not nowhere. Every vendor record needs a business owner and a risk reviewer.
9. A register that cannot be exported. EBA paragraph 56 and the DORA templates both assume a structured, machine-readable register. A folder of PDFs is not one.

How SmartSuite does this

SmartSuite's Third-Party Risk Management product holds the program as linked records rather than a spreadsheet and a shared drive. The product page lists the capabilities that map to the lifecycle above: vendor inventory management with risk tiers on the vendor record; vendor risk assessments that standardize due diligence questionnaires across domains; risk tiering and segmentation; ongoing monitoring and reassessment; third-party issue management; contract and obligation tracking; dashboards and vendor analytics; and no-code workflow automation for onboarding and approvals.

In practice the tiering matrix becomes a scoring rule on the intake form, which sets the questionnaire scope and the reassessment cadence. The questionnaire template below imports as an assessment with domains, questions, evidence fields and weights, and the Vendor Portal lets the vendor complete it and upload evidence without an account on your workspace. Findings open as records in Issues Management, and contract obligations sit in Contract Lifecycle Management with renewal, notice and audit-right dates that trigger tasks. The register fields from EBA paragraphs 54 and 55 and the DORA templates are fields on the vendor and arrangement records, so the register is an export rather than a project. For concentration risk, each vendor links to the critical services it supports in Business Impact Analysis, and dashboards group by provider and parent. The solution overview is at Third-Party Risk Management; Third-Party Risk Management: Connecting Vendors to Controls, Issues, and Resilience shows the full connected map.

Template

The companion file third-party-risk-questionnaire-template.csv holds 70 questions across the 21 SIG domains in the table above. Each row has a domain code and name, a question identifier, the question, the evidence to request for a "yes", a weight from 1 to 3, the tiers it applies to and the source the question is anchored to. Import it as the question library for your assessment, or filter it by tier to produce a short and a full set.

Template

Column	Contents
domain_code, domain	Short code and SIG domain name
question_id	Stable identifier, for example AC-02
question	The question, written to be answered yes, no, partial or not applicable
evidence_requested	What to ask for when the answer is yes
weight	3 for questions that alone can fail an assessment, 2 for material, 1 for informational
applies_to_tiers	Which tiers from the matrix receive the question
source_reference	The regulatory or standards clause the question traces to

The weights are an example. Set them to match your control framework before you score anything, and score a "no" on a weight-3 question as a finding, not a deduction.

FAQs

What is the difference between third-party risk management and vendor risk management? Vendor risk management usually means the assessment and monitoring of suppliers you pay. Third-party risk management is wider: the Interagency Guidance covers any business arrangement, including affiliates, referral partners, joint ventures and relationships without a contract or payment, and the EBA's 2026 guidelines treat outsourcing as a subset of third-party arrangements. In practice the program is the same; the scope of the inventory is what differs.

How often should a vendor risk assessment be repeated? The sources require the frequency to match the risk rather than a fixed calendar. A common pattern is an annual full reassessment for critical and high-tier vendors, reassessment at renewal or every two years for the rest, and event-driven reassessment on an incident, a subcontractor change, a change of ownership or a failed control test. The Interagency Guidance allows periodic or continuous monitoring and expects more for critical activities.

Do we have to use the SIG questionnaire? No regulator requires it. The Interagency Guidance and EBA/GL/2019/02 both allow reliance on industry utilities, pooled audits and third-party certifications, provided the organization checks the scope against its own activity. The SIG's advantage is reuse: vendors that already hold a completed SIG answer faster, and assessors compare vendors on one structure. Use it for Tier 1 and 2, SIG Lite for Tier 3, and accept certifications for the domains they cover.

What counts as a critical or important function under DORA? Article 3(22) defines it as a function whose disruption would materially impair the financial performance of the entity, the soundness or continuity of its services and activities, or its continuing compliance with authorization conditions and obligations. EBA/GL/2019/02 paragraph 29 applies the same test and adds outsourced operational tasks of internal control functions. The classification, its reasons and its date go in the register.

How do we assess concentration risk across vendors? Build the register so it can be grouped by provider and by parent company, rate the substitutability of every critical arrangement, map the subcontractors behind Tier 1 vendors, and link each critical vendor to the service and impact tolerance it supports. DORA Article 29 and EBA/GL/2019/02 paragraph 66 both frame the test as two questions: is the provider easily substitutable, and do multiple arrangements depend on the same or closely connected providers.

Does the 2023 Interagency Guidance have the force of law? No. The guidance states that supervisory guidance does not have the force and effect of law and imposes no new requirements. It describes the risk management principles examiners expect to see, and each agency reviews third-party risk management as part of its standard supervisory process. For banking organizations that is a distinction without much practical difference.

Sources

• Board of Governors of the Federal Reserve System, Federal Deposit Insurance Corporation and Office of the Comptroller of the Currency, Interagency Guidance on Third-Party Relationships: Risk Management, final guidance 6 June 2023, Federal Register 9 June 2023 (FR Doc. 2023-12340). Sections A to E of the final guidance text. https://www.federalregister.gov/documents/2023/06/09/2023-12340/interagency-guidance-on-third-party-relationships-risk-management (PDF: https://public-inspection.federalregister.gov/2023-12340.pdf; OCC Bulletin 2023-17: https://www.occ.treas.gov/news-issuances/news-releases/2023/nr-ia-2023-53.html; FDIC: https://www.fdic.gov/news/press-releases/2023/pr23047a.pdf; Federal Reserve SR 23-4: https://www.federalreserve.gov/supervisionreg/srletters/sr2304.htm)
• Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA). Articles 3(19), (21), (22), (23), (29); 28; 29; 30; 31; 64. https://eur-lex.europa.eu/eli/reg/2022/2554/oj. SmartSuite framework page: https://www.smartsuite.com/frameworks/eu-dora-digital-operational-resilience-act
• Commission Implementing Regulation (EU) 2024/2956, standard templates for the register of information under Article 28(9) of DORA, Official Journal 2 December 2024. https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj
• Commission Delegated Regulation (EU) 2024/1773 of 13 March 2024, regulatory technical standards on the policy regarding contractual arrangements on the use of ICT services supporting critical or important functions (Article 28(10) of DORA), Official Journal 25 June 2024. https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj
• Commission Delegated Regulation (EU) 2025/532 of 24 March 2025, regulatory technical standards specifying the elements a financial entity has to determine and assess when subcontracting ICT services supporting critical or important functions (Article 30(5) of DORA). https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AL_202500532
• European Supervisory Authorities, European Supervisory Authorities designate critical ICT third-party providers under the Digital Operational Resilience Act, press release, 18 November 2025. https://www.eiopa.europa.eu/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital-2025-11-18_en
• European Banking Authority, Final Report on EBA Guidelines on outsourcing arrangements, EBA/GL/2019/02, 25 February 2019, applying from 30 September 2019. Paragraphs 26 to 31, 52 to 57, 64 to 73, 75 to 78, 87 to 93, 106 to 108. https://www.eba.europa.eu/regulation-and-policy/internal-governance/guidelines-on-outsourcing-arrangements (PDF: https://www.eba.europa.eu/sites/default/files/documents/10180/2551996/38c80601-f5d7-4855-8ba3-702423665479/EBA%20revised%20Guidelines%20on%20outsourcing%20arrangements.pdf)
• European Banking Authority, Final report: EBA Guidelines on the sound management of third-party risk regarding non-ICT services, EBA/GL/2026/09, 18 September 2026. Definitions (paragraph 17), implementation (18 to 22), documentation requirements (58 to 63). https://www.eba.europa.eu/sites/default/files/2026-09/dc9ccbb3-79b9-493d-b693-c21adeffbcc9/Final%20report%20on%20GL%20on%20third-party%20risk%20management.pdf. Press release: https://www.eba.europa.eu/publications-and-media/press-releases/eba-publishes-its-final-guidelines-management-third-party-risk-delivering-more-proportionate-and
• NIST SP 800-161 Rev. 1 (Update 1), Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, National Institute of Standards and Technology, May 2022, updated 1 November 2024. Sections 1.5.2, 2, 2.3, 3.4.1. https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final (PDF: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161r1-upd1.pdf). SmartSuite framework page: https://www.smartsuite.com/frameworks/nist-sp-800-161-rev-1-cybersecurity-supply-chain-risk-management-c-scrm
• ISO/IEC 27036-1:2021, Cybersecurity — Supplier relationships — Part 1: Overview and concepts. https://www.iso.org/standard/82905.html
• ISO/IEC 27036-2:2022, Cybersecurity — Supplier relationships — Part 2: Requirements. Clause 6 structure (agreement, organizational project-enabling and technical management processes) from the ISO preview. https://www.iso.org/standard/82060.html (preview: https://cdn.standards.iteh.ai/samples/82060/a5104be6bea04f23bbd92af29bc634d8/ISO-IEC-27036-2-2022.pdf)
• ISO/IEC 27036-3:2023, Cybersecurity — Supplier relationships — Part 3: Guidelines for hardware, software, and services supply chain security. https://www.iso.org/standard/82890.html (preview: https://cdn.standards.iteh.ai/samples/82890/a08a697db8b84e5e96f14173d2ae8d9a/ISO-IEC-27036-3-2023.pdf)
• ISO/IEC 27036-4:2016, Information technology — Security techniques — Information security for supplier relationships — Part 4: Guidelines for security of cloud services. https://www.iso.org/standard/59689.html
• Shared Assessments, Standardized Information Gathering (SIG) questionnaire, 2026 workbook (licensed). https://sharedassessments.org/sig/. Domain names, SIG Lite and SIG Core scopes and the 2026 scoping presets as described by licensee Mitratech: https://mitratech.com/resource-hub/blog/standard-information-gathering-sig-questionnaire-explained/ and https://mitratech.com/resource-hub/blog/sig-2026-key-updates-and-considerations/. SmartSuite framework page (2024 edition): https://www.smartsuite.com/frameworks/shared-assessments-sig-2024-standardized-information-gathering-questionnaire
• NIST IR 8179, Criticality Analysis Process Model: Prioritizing Systems and Components, April 2018, as referenced by NIST SP 800-161 Rev. 1. https://csrc.nist.gov/pubs/ir/8179/final

Related: GRC Foundation · What is third-party risk? · What is supplier risk scoring? · ISO/IEC 27001:2022 · EU NIS2 Directive · DORA and Connected GRC