Third-party risk across the contract lifecycle

Scope: one supplier estate, end to end · Who: the officer who owns supplier assurance · Prerequisites: a contract inventory and the official texts · First result: a tiered supplier list

1. Why this exists (the failure mode it prevents)#

Most supplier assurance programmes are one assessment long. A questionnaire goes out before signature, a clause goes into the contract, and the file closes. No tiering, so every supplier gets the same form. No ongoing assurance, so the answer ages. No exit plan, so leaving is theoretical.

It surfaces in three ways. An incident exposes a dependency nobody recorded: the service that stopped was reached through a subcontractor two links down, and the contract names no subcontractors.

A supervisory question is answered with a folder of questionnaires. Under NIS2 the measure is not the questionnaire but a judgement about each direct supplier ¹. A returned form evidences a returned form.

A contract turns out to carry no audit right and no exit terms at the moment those are needed. In the financial sector the gap is explicit. Arrangements behind critical or important functions carry unrestricted access, inspection and audit rights, plus exit strategies with a transition period ². A right never negotiated cannot be exercised later.

The method below fixes the order. Tier first, because tiering decides how much of everything else applies.

2. Definitions (only the ones that cause disputes)#

Term	Working definition	Source
Third party, supplier	Any organisation providing products or services the organisation depends on. NIS2 frames the measure around direct suppliers and service providers.	3
ICT third-party service provider	An undertaking providing ICT services: digital and data services delivered through ICT systems on an ongoing basis.	4
ICT subcontractor	DORA defines the third-country case: a legal person outside the Union that has contracted with an ICT third-party service provider.	5
Critical or important function	A function whose disruption would materially impair financial performance, service soundness or continuity, or continued compliance with an authorisation.	6
Tier	A local label, not a regulatory one. It records how much assurance a relationship earns.	Method definition; criticality anchored above
Due diligence	The pre-contract assessment of a prospective provider's suitability.	7
ICT concentration risk	Dependency on individual or multiple related critical providers, where a shortfall may endanger critical or important functions.	8
Exit strategy	A documented, tested plan for leaving without disrupting the business, breaching regulation or degrading client service.	9

Two control vocabularies sit behind those rows. ISO/IEC 27002:2022 controls 5.19 to 5.23 are the supplier-relationship controls. ISO/IEC 27036 is the dedicated series. Part 1 covers overview and concepts, Part 2 requirements, Part 3 hardware, software and services supply chain security, and Part 4 cloud services ¹⁰.

3. The method — the lifecycle#

Ten steps in dependency order. Steps 1 to 3 run before signature, steps 4 to 9 while the relationship lives, step 10 keeps the set current.

3.1 Tier before you assess#

Tiering makes every later step affordable. Five factors carry it, each a closed-option score rather than free text: data sensitivity, function criticality, access, substitutability and regulatory reach.

Function criticality is the anchor. In the financial sector it is a defined term ⁶; elsewhere the same question is asked against the organisation's own critical services. Substitutability comes from the concentration test: before signing for a critical or important function, an entity considers whether the provider is not easily substitutable ¹¹.

Access records what the supplier touches; regulatory reach, whether the service sits inside a regulated perimeter. ISO/IEC 27002:2022 control 5.19 is "Information security in supplier relationships" ¹². It asks the organisation to identify the supplier types that can affect the confidentiality, integrity and availability of its information, and to set out how suppliers are evaluated by sensitivity. The framework wording is shorter: suppliers are known and prioritised by criticality ¹³.

• Input: the contract inventory; the service catalogue; the critical-service list.
• Activity: score every supplier on the five factors, then band the scores into three tiers. Record the score, not only the tier. The tiering workbook carries both.
• Output: tiering register, one row per supplier, with score, tier and next review date.
• Owner: supplier assurance; service owners confirm criticality.

3.2 Pre-contract assessment, scaled by tier#

Not one questionnaire at three lengths, but a different question set per tier. The strictest version is written down in law.

Before entering an arrangement a financial entity assesses five things, at points (a) to (e) ¹⁴. They are: whether the arrangement covers a critical or important function; whether supervisory conditions are met; all relevant risks, including concentration; due diligence on the provider; and conflicts of interest. It contracts only with providers meeting appropriate information security standards, and considers the highest quality standards for critical or important functions ¹⁵.

Delegated Regulation (EU) 2024/1773 splits that in two. Article 5 is "Ex-ante risk assessment" ¹⁶. It requires the business need first, then a risk assessment naming operational, legal, ICT and reputational risk, data protection and availability, processing and provider locations, and entity-level concentration risk. Article 6 is "Due diligence" ¹⁷. It asks whether the provider has the reputation, expertise, resources, security standards, risk management, internal controls and required authorisations. It also asks whether the provider uses subcontractors, stores data in a third country, and consents to audits.

Outside that sector the NIS2 wording is the test ¹. It names the vulnerabilities specific to each direct supplier, the overall quality of their products and cybersecurity practices, their secure development procedures, and the results of coordinated critical-supply-chain risk assessments.

For a product organisation the counterpart sits on the build side. Manufacturers exercise due diligence when integrating components sourced from third parties, so an integrated component does not weaken the cybersecurity of the product ¹⁸. The framework wording: due diligence is performed before entering formal third-party relationships ¹⁹.

• Input: the tier; the service description; the draft statement of work.
• Activity: run the tier's question set, recording answer, evidence and residual risk. Tier 3 may be a short screen; tier 1 is a file.
• Output: pre-contract assessment per arrangement, with a dated decision.
• Owner: procurement runs it; the service owner accepts residual risk.

3.3 The contract#

Assurance rights are created or lost here. Draft to a clause library organised by theme, not to a single template. DORA sets the baseline ²⁰. Rights and obligations are clearly allocated in writing, and the full contract includes the service level agreements in one written document in a durable, accessible format.

Every arrangement then carries nine elements, at points (a) to (i). The themes are the service description and whether subcontracting is permitted, the provision and data-processing locations, and data protection. Then access, recovery and return of data, service levels, incident assistance, cooperation with authorities, termination rights, and training participation ²¹. Critical or important arrangements add six more, at points (a) to (f) ²². They are quantitative service targets, notice and reporting duties, tested contingency plans, threat-led testing participation, unrestricted access, inspection and audit rights, and exit strategies with a transition period. The financial-sector reading of both lists sits in DORA implementation, section 3.8.

The sector-neutral version is shorter. ISO/IEC 27002:2022 control 5.20, "Addressing information security within supplier agreements", asks that security requirements be established and agreed with each supplier, by type of relationship. Its guidance lists terms worth considering ²³. Among them: sub-contracting provisions, a right to audit the supplier's processes and controls, third-party attestation evidence, incident notification, and personnel screening where legally permissible. The framework wording: supply-chain requirements are integrated into contracts and other agreements ²⁴.

• Input: the pre-contract assessment; the clause library; the tier.
• Activity: map each theme to a clause. Treat every refusal as a risk decision with a named acceptor.
• Output: contract compliance matrix, one row per theme per arrangement.
• Owner: legal counsel drafts; supplier assurance sets the themes.

3.4 Onboarding and access#

Onboarding turns the contract into operational reality, and is usually the weakest joint. The rule is least privilege in operational terms: the supplier gets the accounts, networks and data the service needs, for as long as it runs.

Control 5.19 asks the organisation to define which information, ICT services and physical infrastructure suppliers may access, monitor, control or use ¹². Control 5.20 asks that agreements set out the procedures for authorising, and removing authorisation for, supplier personnel using those assets ²³.

Where the service is an ICT supply chain, control 5.21 is "Managing information security in the ICT supply chain" ²⁵. It asks that security requirements be defined for acquisition, that product suppliers describe the software components used, and that deliveries be validated against those requirements.

Where the service is cloud, control 5.23 is "Information security for use of cloud services" ²⁶. It asks which controls the provider manages and which the customer manages, how assurance on those controls is obtained, and how incidents are handled. A shared-responsibility split nobody wrote down is a gap with two owners.

• Input: the signed contract; the access request; the service design.
• Activity: provision named accounts against the agreed access definition. Fix the joiner, mover and leaver route before the first login.
• Output: supplier access record, and a shared-responsibility statement per cloud service.
• Owner: the service owner; identity operations provision and revoke.

3.5 Ongoing assurance, by tier#

Assurance is a calendar, not a campaign. The tier sets the evidence type and frequency; the register records what arrived and who read it.

ISO/IEC 27002:2022 control 5.22, "Monitoring, review and change management of supplier services", asks the organisation to regularly monitor, review, evaluate and manage change in supplier security practices and service delivery. Its guidance names audits of suppliers and sub-suppliers alongside independent auditor reports, service reports, and review of the supplier's own supplier relationships ²⁷.

The financial-sector version names the evidence types. Access, inspection, audit and testing rights are exercised in four ways ²⁸. Through internal audit or an appointed third party. Where appropriate, through pooled audits and pooled ICT testing with other clients of the same provider. Through third-party certifications, and through audit reports the provider makes available. Monitoring is specified too ²⁹. Key indicators sit in the contract, with periodic, incident, service delivery, security and continuity reports. Performance is assessed through indicators, audits, self-certifications and independent reviews, and fed back into the risk assessment.

Audit frequency is pre-determined rather than improvised. The entity fixes, on a risk basis, how often audits happen and which areas they cover, using commonly accepted audit standards. It verifies auditor skills where the arrangement is technically complex ³⁰. The framework wording: supplier risks are monitored over the course of the relationship ³¹.

A workable default is tier 1 evidence yearly with a quarterly service review, tier 2 yearly, tier 3 at renewal. What matters is that the frequency is written down.

• Input: the tiering register; the contract's reporting clauses.
• Activity: run the calendar. Log evidence received, reviewer role and outcome. An overdue item stays open rather than being reset.
• Output: assurance calendar with outcomes, and findings routed into corrective action.
• Owner: supplier assurance; internal audit tests the loop.

3.6 Subcontracting and the chain#

A supply chain is assured only to the depth the contract reaches, and the financial-sector rules make that depth explicit. The entity decides before signing whether an ICT service behind a critical or important function may be subcontracted at all, and may contract only where ten conditions hold, at points (a) to (j). The ten cover four things ³². The provider's ability to select, identify and monitor subcontractors. The entity's own ability to monitor the subcontracted service. Equal access and inspection rights down the chain. Assessments of failure impact, location, concentration and audit obstacles. Points (f) to (j) are re-run periodically against changes in the business environment, threats, concentration and geopolitics ³³. Relying on the provider's own assessment does not limit the entity's final responsibility ³⁴.

The contract then names which services may be subcontracted and on what conditions, in twelve specified points. They put responsibility for subcontracted services on the provider, and require continuous monitoring, reporting and location-risk assessment. They push continuity, security and audit obligations down the provider's own contracts, and require notice of material change ³⁵. That change is notified in time to be assessed, and implemented only after approval or the absence of objection within the notice period ³⁶.

DORA adds the questions a long chain raises ³⁷. The benefits and risks of subcontracting, third-country subcontractors, applicable insolvency law, constraints on urgent data recovery, data-protection enforceability, and whether chain length defeats monitoring or supervision. The sector-neutral form is control 5.21 ²⁵. ICT service suppliers propagate the organisation's requirements through the chain when they subcontract, and product suppliers do the same for acquired components.

Record the chain by rank, so a subcontractor is visible rather than implied. The register of information starter carries that ranking; the radar entry tracks the instrument.

• Input: the provider's subcontractor list; the subcontracting clauses.
• Activity: decide eligibility before signature; record each subcontractor with its rank; re-run the periodic points on schedule.
• Output: supply-chain record, ranked, and a material-change log.
• Owner: supplier assurance; legal counsel confirms the clauses.

3.7 Concentration#

Concentration is a portfolio question, invisible from inside one contract file. The pre-contract test has two limbs: contracting a provider that is not easily substitutable, or holding multiple critical arrangements with the same or closely connected providers. The entity then weighs the benefits and costs of alternative solutions against its digital resilience strategy ³⁸. The third-party strategy itself takes account of a multi-vendor strategy where one applies ³⁹.

Run the test across the tiering register rather than per contract. Group by provider and corporate parent, then count the critical services behind each group. Two arrangements that look unrelated in procurement can share one platform.

• Input: the tiering register; corporate parent data per provider.
• Activity: aggregate by provider and parent; mark every group carrying more than one critical service; record the alternatives considered.
• Output: concentration view, refreshed with the register.
• Owner: the risk function; supplier assurance supplies the data.

3.8 Incidents involving a third party#

Two questions decide this step: who tells whom, and how fast the supplier must help. The help is a contract term. Every arrangement carries the provider's obligation to assist when an ICT incident related to the service occurs, at no additional cost or at a cost determined in advance ⁴⁰. Critical or important arrangements add notice periods and reporting duties covering any development material to the provider's ability to deliver ⁴¹.

The reporting duty stays with the regulated entity. In the financial sector it sits in DORA Article 19, "Reporting of major ICT-related incidents and voluntary notification of significant cyber threats" ⁴². Under NIS2 it sits in Article 23, "Reporting obligations": notification without undue delay of any incident having a significant impact on service provision ⁴³. A supplier does not report on the entity's behalf, and its silence does not stop the clock.

Control 5.19 says the same: incidents and contingencies associated with supplier products and services are handled, with both sides' responsibilities defined ¹². The framework wording: suppliers are included in incident planning, response and recovery ⁴⁴.

• Input: the notification and assistance clauses; the incident runbook.
• Activity: name the supplier contact and the internal decision-maker per tier 1 arrangement; exercise the path yearly.
• Output: supplier incident annex, and a dated exercise report.
• Owner: the incident manager; supplier assurance supplies the contacts.

3.9 Exit and termination#

An exit plan never tested is an intention. Termination rights come first. Arrangements can be terminated in four circumstances ⁴⁵. Significant breach of law, regulation or contract. Circumstances found through monitoring that could alter performance. Evidenced weaknesses in the provider's ICT risk management. Loss of the competent authority's ability to supervise the entity effectively.

Exit strategies are then a standing requirement for critical or important services. They take account of provider failure, quality deterioration, business disruption and termination. The entity must be able to leave without disrupting its activities, limiting regulatory compliance or harming client service. Plans are documented, tested and periodically reviewed, and identify alternative solutions and transition plans ⁹.

The policy standard adds the shape: a documented exit plan for each arrangement, reviewed and tested periodically, built around unforeseen and persistent service interruptions, inappropriate or failed service delivery, and unexpected termination. It carries a schedule compatible with the contract's exit terms ⁴⁶. The subcontracting standard preserves the right to terminate where the chain breaks the arrangement ⁴⁷.

Outside that sector, control 5.23 asks the organisation to define how cloud use would be changed or ended, exit strategies included ²⁶. The framework wording: plans cover activities after a service agreement ends ⁴⁸.

• Input: the exit and termination clauses; the data inventory for the service.
• Activity: write the plan against the three scenarios, then test one step each year. A restore from the supplier's export is a test; reading the plan is not.
• Output: exit plan per tier 1 arrangement, with a dated test record.
• Owner: the service owner; supplier assurance holds the schedule.

3.10 Keep it alive#

Six triggers cover most movement. Each names the artefact it reopens.

• A tier-changing event — a new data category, a new integration, a criticality change. Reopens the tiering register and the assurance calendar.
• Contract renewal, the only moment the clause set can be repriced. A renewal that changes nothing is still a minuted decision. Reopens the contract compliance matrix.
• The management-body review. The strategy is adopted and regularly reviewed, and the management body regularly reviews the risks in arrangements behind critical or important functions ³⁹. The policy is reviewed by that body at least once a year ⁴⁹. Reopens the policy and the strategy.
• A subcontracting change, material ones carrying notice, assessment and an approval gate ³⁶. Reopens the supply-chain record.
• A coordinated supply-chain risk assessment. The Cooperation Group, with the Commission and ENISA, may assess specific critical ICT service, system or product supply chains, taking account of technical and, where relevant, non-technical risk factors; the Commission identifies which are covered ⁵⁰. Results feed the Article 21(3) judgement, and reopen the affected assessments.
• A vulnerability in a supplied component. For a manufacturer, a vulnerability in an integrated component, including an open-source one, is reported to whoever maintains it and remediated under the vulnerability-handling requirements ⁵¹. Reopens the component inventory.

In a certified management system the loop lands on familiar clauses. Operational planning and control ⁵². Monitoring and evaluation ⁵³. Corrective action ⁵⁴.

• Input: the triggers, each with a date or an event.
• Activity: hold each review even when nothing moved, and record it.
• Output: change-trigger register, with a dated record per trigger.
• Owner: supplier assurance; the risk function reviews.

4. Deliverables (with template links)#

Deliverable	Format	Template	Retention
Tiering register	xlsx	/templates/third-party-tiering	Life of the estate, versioned
Due-diligence sets, by tier	markdown or docx	Template pending	Arrangement life plus the audit period
Contract clause library, by theme	markdown	Template pending	Life of the programme
Assurance calendar with outcomes	xlsx	/templates/third-party-tiering	Rolling three review cycles
Supply-chain record, ranked	xlsx	/templates/register-of-information	Life of the arrangement
Concentration view	xlsx	derived from the tiering sheet grouped by provider; template pending	With the register
Exit plan per tier 1 arrangement	markdown or docx	Template pending	Arrangement life plus one cycle

5. What the auditor or supervisor will ask [Callout: auditor-asks]#

• "Show the tiering decision for this supplier." — evidence: the tiering register row, with score and dated review.
• "What did you assess before signing, and who accepted the residual risk?" — evidence: the pre-contract assessment, naming the accepting role.
• "Where is the audit right, and has it been exercised?" — evidence: the contract compliance matrix, plus an audit or attestation record.
• "Name every subcontractor behind this critical service." — evidence: the ranked supply-chain record.
• "What assurance evidence was due last cycle, and what arrived?" — evidence: the assurance calendar, including the overdue rows.
• "Walk through the exit plan for this arrangement and show the last test." — evidence: the exit plan and its dated test record.
• "When did the management body last review third-party risk?" — evidence: the minuted review, with the artefact set it covered.

6. Failure modes and how they show up in findings [Callout: failure-mode]#

• One questionnaire for every supplier. Surfaces as: "the assessment process is not differentiated by risk, and evidence of assessment depth was not available for critical suppliers." Smallest fix: tier the estate, then cut the tier-3 question set so tier 1 can grow.
• Assurance that stops at signature. Surfaces as: "supplier assessments were performed at onboarding only; no evidence of periodic review was provided." Smallest fix: publish the assurance calendar and let overdue rows stay visible.
• The chain stops at the direct supplier. Surfaces as: "subcontractors supporting critical services were not identified in the organisation's records." Smallest fix: add a rank column and require the direct supplier to populate it at each review.
• Audit rights on paper only. Surfaces as: "contractual audit rights have not been exercised, and no alternative assurance was obtained." Smallest fix: accept an attestation report per cycle.
• Exit plans never tested. Surfaces as: "exit plans were documented but no evidence of testing or periodic review was available." Smallest fix: test one step per plan per year and date the record.

7. Mapping to standards and instruments (verified)#

Lifecycle step	NIS2	DORA	ISO/IEC 27002:2022 control	NIST CSF 2.0	Evidence
3.1 Tier	Art. 21(2)(d)	Art. 3(22); 29(1)(a)	5.19 Information security in supplier relationships	GV.SC-04	Tiering register
3.2 Pre-contract assessment	Art. 21(3)	Art. 28(4), 28(5)	5.19 Information security in supplier relationships	GV.SC-06; ID.RA-10	Pre-contract assessment
3.3 Contract	Art. 21(2)(d)	Art. 30(1), 30(2), 30(3)	5.20 Addressing information security within supplier agreements	GV.SC-05	Contract compliance matrix
3.4 Onboarding and access	Art. 21(2)(i)	—	5.21 Managing information security in the ICT supply chain	GV.SC-05	Access record; shared-responsibility statement
3.5 Ongoing assurance	Art. 21(2)(f)	Art. 28(6)	5.22 Monitoring, review and change management of supplier services	GV.SC-07	Assurance calendar with outcomes
3.6 Subcontracting	Art. 21(2)(d)	Art. 29(2)	5.21 Managing information security in the ICT supply chain	GV.SC-07	Ranked supply-chain record
3.7 Concentration	—	Art. 3(29); 29(1)	5.19 Information security in supplier relationships	GV.SC-03	Concentration view
3.8 Third-party incidents	Art. 23(1)	Art. 30(2)(f); Art. 19	5.19 Information security in supplier relationships	GV.SC-08	Supplier incident annex; exercise report
3.9 Exit and termination	Art. 21(2)(c)	Art. 28(7), 28(8); 30(3)(f)	5.23 Information security for use of cloud services	GV.SC-10	Exit plan with test record
3.10 Keep it alive	Art. 22	Art. 28(2)	5.22 Monitoring, review and change management of supplier services	GV.SC-01; GV.SC-09	Change-trigger register

Each NIS2 and DORA article here is verified where first cited. Control titles are as printed ⁵⁵; subcategory identifiers come from the framework core ⁵⁶. NIS2 Article 21(2) points (c), (f) and (i) are the continuity, effectiveness-assessment and access-control measures ⁵⁷.

8. Checklist#

• Every supplier in the inventory carries a tier and a dated score.
• Each pre-contract assessment names the residual risk and the role that accepted it.
• Every tier 1 contract carries an audit right naming who may exercise it.
• Every tier 1 contract carries termination rights with a minimum notice period.
• The assurance calendar shows evidence due, received, the reviewer role and the outcome.
• Subcontractors behind tier 1 services carry a rank and the service they underpin.
• Concentration is measured across the register, grouped by provider and corporate parent.
• The supplier incident path was exercised in the last cycle, and the report is dated.
• Every tier 1 arrangement has an exit plan built on the three exit scenarios.
• At least one step of each tier 1 exit plan was tested in the last cycle.
• The management body reviewed third-party risk in the last cycle, against a named artefact set.

References#

1. Directive (EU) 2022/2555 (NIS 2 Directive). CELEX 32022L2555. https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng ⁵⁸
2. Regulation (EU) 2022/2554 (DORA). CELEX 32022R2554. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng ⁵⁹
3. Commission Delegated Regulation (EU) 2024/1773. CELEX 32024R1773. https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng ⁶⁰
4. Commission Delegated Regulation (EU) 2025/532. CELEX 32025R0532. https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng ⁶¹
5. Regulation (EU) 2024/2847 (Cyber Resilience Act). CELEX 32024R2847. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng ⁶²
6. ISO/IEC 27002:2022, information security controls. https://www.iso.org/standard/75652.html ⁵⁵
7. ISO/IEC 27001:2022, information security management systems. https://www.iso.org/standard/27001 ⁶³
8. ISO/IEC 27036-1:2021, supplier relationships, part 1. https://www.iso.org/standard/82905.html ⁶⁴
9. ISO/IEC 27036-2:2022, supplier relationships, part 2. https://www.iso.org/standard/82060.html ⁶⁵
10. ISO/IEC 27036-3:2023, supplier relationships, part 3. https://www.iso.org/standard/82890.html ⁶⁶
11. ISO/IEC 27036-4:2016, supplier relationships, part 4. https://www.iso.org/standard/59689.html ⁶⁷
12. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29. https://doi.org/10.6028/NIST.CSWP.29 ⁵⁶

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication and is not affiliated with, authorized, sponsored or endorsed by any standards body.