Skip to main content
Readiness Authority
Category: Third-Party & Supply Chain Risk

ICT Third-Party Risk Management

Also known as: ICT TPRM, ICT third-party risk management, third-party risk management (ICT context)
Simply put

ICT Third-Party Risk Management is the practice of identifying, assessing, and controlling the risks that arise when an organization relies on outside providers for information and communication technology services, such as software, cloud hosting, or data processing. Rather than simply keeping a list of these providers, it involves actively governing those relationships throughout their lifecycle. It is a resilience and governance discipline, not an insurance product, and it does not by itself transfer or fund the financial consequences of a third-party failure.

Formal definition

ICT Third-Party Risk Management is the structured process of identifying and reducing risks relating to the use of third parties that are integrated into an organization's IT environment, covering security, compliance, and operational dimensions across the relationship lifecycle. Under the EU Digital Operational Resilience Act (DORA), it is a regulatory obligation for in-scope financial institutions to actively govern all ICT third-party relationships, not merely document them, supported by technical standards intended to enhance digital operational resilience; the specifics of DORA's requirements are set out in its rules and associated draft technical standards. As a risk mitigation and governance discipline it is distinct from risk transfer through cyber insurance: it aims to lower the likelihood and impact of third-party incidents but does not indemnify losses, and whether any resulting loss is covered depends on separate policy wording, endorsements, and exclusions. This entry does not address incident classification requirements or the detailed content of specific DORA technical standards.

Why it matters

Modern organizations rarely run their information and communication technology entirely in-house. They depend on software vendors, cloud hosting providers, and data processors that are integrated directly into their IT environment. When one of those providers suffers an outage, a security breach, or a compliance failure, the disruption can cascade into the organizations that rely on it. ICT Third-Party Risk Management exists to address this dependency: it aims to reduce the likelihood and impact of third-party incidents by governing those relationships rather than merely documenting them.

The discipline has taken on regulatory weight in the EU financial sector. Under the Digital Operational Resilience Act (DORA), in-scope financial institutions are required to actively govern all ICT third-party relationships, and supervisory bodies have issued technical standards intended to enhance digital operational resilience. This shifts ICT TPRM from a discretionary good practice to a compliance obligation for affected firms, with the specifics set out in DORA's rules and associated draft technical standards.

It is important to be precise about what this discipline does and does not do. ICT TPRM is a risk mitigation and governance activity: it seeks to lower the probability and severity of a third-party failure. It is not a form of risk transfer and does not fund or indemnify the financial consequences when a provider fails. Whether a resulting loss is covered is a separate question that depends on cyber insurance policy wording, endorsements, and exclusions. Effective third-party governance and appropriate insurance coverage are complementary but distinct, neither substitutes for the other.

Who it's relevant to

Resilience and Business Continuity Planners
For those responsible for operational resilience, ICT TPRM is a core input. Because critical services are often delivered by outside providers, understanding and governing those dependencies is essential to assessing how a third-party failure could disrupt operations. It is a mitigation and governance discipline, distinct from the recovery objectives and continuity planning that address how the organization responds once a disruption occurs.
Chief Information Security Officers and Security Teams
CISOs and their teams use ICT TPRM to evaluate the security posture of vendors integrated into the IT environment and to apply consistent, framework-based assessment criteria across the vendor population. The discipline covers security, compliance, and operational dimensions, and helps translate third-party exposure into actionable controls throughout the relationship lifecycle.
Legal, Compliance, and Risk Professionals
For firms in scope of DORA, ICT TPRM is a regulatory obligation rather than an optional practice. Compliance and legal teams must ensure the organization actively governs all ICT third-party relationships as required, supported by DORA's rules and associated technical standards. These professionals also need to distinguish governance obligations from separate questions of insurance coverage.
Cyber Insurance Underwriters and Brokers
Underwriters and brokers may treat an insured's ICT TPRM maturity as an indicator of risk quality, since stronger third-party governance can reduce the likelihood and impact of incidents. However, it is important to keep the two concepts separate: ICT TPRM mitigates risk but does not transfer it, and whether a third-party-related loss is covered depends on the specific policy wording, endorsements, and exclusions rather than on the existence of a TPRM program.

Inside ICT TPRM

Third-Party Inventory and Mapping
A maintained register of ICT service providers, subcontractors, and the critical or important functions each supports, including identification of concentration risk where multiple functions rely on a single provider or where many organizations depend on the same provider.
Risk Assessment and Due Diligence
Evaluation of a provider's security controls, resilience capabilities, and financial stability before and during engagement. This is a risk mitigation and governance activity distinct from risk transfer through insurance; it aims to reduce the likelihood or impact of a provider-related incident rather than fund losses after one occurs.
Contractual Provisions
Terms governing security obligations, audit rights, subcontracting, incident notification timelines, service levels, and exit or termination arrangements. Contractual recovery obligations placed on a provider are separate from any first-party or third-party coverage an organization may hold under its own cyber policy.
Continuous Monitoring and Performance Oversight
Ongoing tracking of provider security posture and service performance against agreed measures. Service-level commitments (for example, availability targets) are operational metrics and should not be confused with policy coverage triggers, waiting periods, or sublimits under an insurance program.
Resilience and Exit Planning
Arrangements addressing how the organization continues critical functions if a provider fails or is disrupted, including exit strategies, substitutability, and integration with business continuity and disaster recovery plans. Recovery time objective (RTO) and recovery point objective (RPO) considerations for provider-dependent functions belong here as resilience metrics, not insurance terms.
Governance and Accountability
Assignment of internal ownership, board or senior-management oversight, and escalation paths for third-party risk. Reliance on a provider does not transfer accountability for the organization's own obligations, and outsourcing a function does not outsource responsibility for it.
Incident Coordination Arrangements
Defined roles for incident response and crisis management involving providers, including notification, cooperation, and evidence-sharing expectations. Incident response (technical containment and recovery) and crisis management (organizational decision-making and communications) remain distinct activities within these arrangements.

Common questions

Answers to the questions practitioners most commonly ask about ICT TPRM.

Does having a cyber insurance policy mean my ICT third-party risk is transferred and I no longer need to manage vendors directly?
No. Insurance is a risk-transfer mechanism that may fund certain losses after an incident; it does not reduce the likelihood that a vendor will fail, be breached, or cause an outage, and it does not perform the operational work of vetting, monitoring, or managing third parties. ICT third-party risk management is a mitigation and governance activity, not a coverage instrument. Whether losses arising from a vendor event are actually covered depends on the specific policy wording, endorsements, exclusions, and conditions precedent, and some policies impose obligations to maintain due-diligence or oversight practices as a condition of coverage. The two are complementary, not substitutes.
Is ICT third-party risk management the same thing as managing a supplier's contractual performance or its financial stability?
Not exactly. Traditional supplier or procurement risk management often focuses on commercial reliability, service levels, and solvency. ICT third-party risk management is narrower and more specific: it addresses the technology, security, resilience, and data-handling risks that a provider introduces into your environment, including access to systems, handling of sensitive data, concentration and dependency risk, and the provider's own downstream sub-processors. A vendor can be financially sound and contractually compliant while still representing significant ICT risk. The disciplines overlap but should not be treated as interchangeable.
How do I decide which third parties require the most scrutiny?
A common approach is to tier or classify third parties by the risk they introduce rather than applying uniform diligence to all of them. Relevant factors typically include the sensitivity of data the provider handles, the level of access it has to critical systems, whether it supports functions tied to your recovery objectives (such as those relevant to RTO and RPO), and the degree of concentration or dependency the relationship creates. Higher-tier providers generally warrant deeper assessment, contractual controls, and more frequent monitoring, while lower-risk providers may be handled with lighter-touch review. The specific criteria and thresholds vary by organization and sector.
What contractual provisions are commonly used to address ICT third-party risk?
Organizations frequently seek provisions covering security and control requirements, data handling and processing terms, incident notification obligations and timelines, audit or assessment rights, requirements around sub-processors or fourth parties, and expectations relating to the provider's own continuity and recovery capabilities. Terms addressing liability, indemnification, and cooperation during an incident are also common. The enforceability and practical value of these clauses depend on drafting, bargaining position, and jurisdiction, and contractual language alone does not guarantee that a provider actually performs as promised, which is why ongoing monitoring typically supplements contract terms.
How does third-party risk management connect to my incident response and business continuity planning?
Third-party dependencies should be reflected in both incident response and continuity planning, but these are distinct activities and should not be conflated. Incident response addresses detection, containment, and remediation when an event occurs, including events originating at a provider; this requires knowing whom to contact, what notification obligations apply, and how coordination will work. Business continuity and disaster recovery address maintaining or restoring functions that depend on the provider, which means understanding whether a vendor outage would breach your recovery time and recovery point objectives and what alternatives or workarounds exist. Mapping critical third parties into these plans is generally considered a core part of the discipline.
How should ICT third-party risk be monitored on an ongoing basis rather than only at onboarding?
Point-in-time assessment at onboarding captures a provider's posture at a single moment, but risk changes over time as services, sub-processors, and threat conditions evolve. Ongoing approaches may include periodic reassessment, review of the provider's own attestations or third-party audit reports, tracking of relevant security events or disclosures, and reassessment when the relationship or the provider's role materially changes. The appropriate cadence and depth generally scale with the provider's risk tier. Monitoring supports both mitigation and, where applicable, the ability to demonstrate the due diligence that some insurance policies expect as a condition of coverage, though the specific evidentiary expectations depend on the policy wording.

Common misconceptions

Buying cyber insurance addresses third-party ICT risk, so detailed provider management is unnecessary.
Insurance is a risk-transfer mechanism that may fund certain losses subject to the specific policy wording, exclusions, and conditions; it does not reduce the likelihood of a provider incident and does not by itself constitute resilience. Whether losses arising from a provider's failure are covered depends on the policy terms and applicable endorsements, so provider risk management and insurance are complementary rather than interchangeable.
Outsourcing an ICT function transfers the associated risk and accountability to the provider.
Contractual arrangements may shift certain obligations and provide recovery rights against a provider, but the organization typically retains accountability for its own regulatory, operational, and resilience responsibilities. Contractual recourse against a provider is also distinct from insurance recovery under the organization's own program.
A provider meeting its service-level targets means the organization is adequately protected.
Service-level measures are operational performance metrics and are not the same as resilience assurance or insurance coverage. They do not equate to recovery objectives (RTO/RPO), and they do not function as coverage triggers, retentions, or waiting periods under a cyber policy.

Best practices

Maintain a current inventory that maps each ICT provider to the critical or important functions it supports, and explicitly identify concentration risk where many functions or many organizations depend on the same provider.
Perform proportionate due diligence and periodic reassessment of providers covering security controls, resilience capabilities, and stability, treating this as risk mitigation distinct from any insurance the organization carries.
Embed clear contractual provisions for security obligations, incident notification timelines, audit rights, subcontracting oversight, and exit arrangements, and understand how these contractual recovery rights differ from first-party and third-party cover under your own policy.
Develop and test exit and continuity plans for provider-dependent functions, setting resilience objectives such as RTO and RPO for those functions rather than assuming insurance restores operations.
Coordinate incident response and crisis management roles with key providers in advance, defining notification and cooperation expectations so containment and organizational decision-making are not confused during an event.
Assign internal ownership and senior-management oversight for third-party risk, and separately review how the organization's cyber insurance program responds to provider-related losses, recognizing that coverage depends on the specific wording, exclusions, and jurisdiction.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide