ICT Third-Party Risk is the chance that an outside technology supplier, service provider, or connected partner will weaken an organisation’s confidentiality, integrity, availability, or compliance posture. In practice, it covers vendor access, data handling, resilience, subcontractors, and security controls across cloud, software, networks, and support services.
What ICT Third-Party Risk Actually Covers
ICT third-party risk is broader than vendor vetting at contract time. It includes the ongoing exposure created when an external supplier can touch data, systems, identities, networks, or support workflows, especially where the organisation depends on that supplier for availability or privileged access.
The key point is that the risk sits in the relationship, not only in the vendor itself. A weak integration, a shared service account, an over-permissive support channel, or a subcontractor with poor controls can all create a path into the organisation even when internal controls are otherwise strong.
Why It Becomes a Security and Resilience Problem
Third-party risk becomes dangerous when the supplier’s security posture effectively becomes part of your own. If a provider handles sensitive data, remote administration, software updates, or business-critical connectivity, its compromise can weaken confidentiality, integrity, availability, and regulatory compliance at the same time.
That is why supply-chain incidents often spread through trusted channels such as OAuth apps, remote support tools, signed software, or support portals. The organisation may not have directly invited the attacker in, but it may have accepted the trust path that made the intrusion possible.
Where Organisations Usually Misjudge Exposure
Exposure is often underestimated when inventory is incomplete. Organisations may know their major vendors, but not all connected apps, subcontractors, delegated administrators, API tokens, or privileged support pathways that sit underneath those relationships.
- Internet-exposed admin consoles and support tooling can extend vendor compromise into internal systems.
- Shared credentials, long-lived tokens, and certificate-based trust can survive far beyond the business need that created them.
- Subprocessors and embedded services can create hidden dependencies that are not obvious in the primary contract.
For sectors governed by operational resilience requirements, this is not just a procurement issue. It is a control problem that affects continuity, incident response, and the ability to prove oversight across the full service chain.
How to Reduce Third-Party Risk Without Blocking the Business
Effective treatment starts with mapping which vendors actually have access, what kind of access they have, and what data or operational function they can reach. The same review should cover remote support, integrations, privileged break-glass paths, and offboarding of supplier access when the relationship ends.
Where a supplier cannot meet the required control level immediately, organisations should narrow the blast radius through segmentation, least privilege, token rotation, tighter session controls, and stronger monitoring of vendor-driven activity. Independent review of critical suppliers is especially important when the organisation cannot fully inspect the supplier’s internal controls.
Useful external references include EU Digital Operational Resilience Act (DORA) for ICT third-party resilience obligations and SOC 2 Trust Services Criteria (AICPA) for assurance expectations around vendor controls.
What Good Oversight Looks Like in Practice
Strong oversight treats third-party risk as a lifecycle discipline, not a one-time review. That means setting an owner for each critical supplier, tracking the access the supplier actually has, and reviewing whether the relationship still needs the same trust level as the original onboarding decision.
It also means checking for dependency drift. A supplier that began as a narrow SaaS service may later gain administrative reach, data replication, or deeper API integration, which changes the risk profile even if the contract never changed. Where software supply chain integrity is part of the relationship, NIST SSDF (SP 800-218) and SLSA are useful references for build and provenance assurance.
For organisations that depend heavily on third-party software or support channels, the practical question is simple: can you still contain, detect, and recover from a supplier compromise before it becomes your compromise?
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while DORA and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | ICT Third-Party Risk Management | DORA directly governs ICT third-party risk, resilience, and oversight for financial entities. |
| Recommendation — Map critical suppliers, test resilience assumptions, and enforce contractual oversight for ICT third-party services. | ||
| SOC 2 (AICPA) | CC9.2 — Vendor and third-party risk | SOC 2 assurance addresses controls over vendors that can affect security, availability, confidentiality, and privacy. |
| Recommendation — Review vendor controls and evidence for third-party dependencies that affect service trust. | ||
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | SA-9 addresses managing services received from external providers that can affect security and operations. |
| SR-3 — Supply Chain Controls and Processes | SR-3 addresses supply chain control processes that reduce third-party compromise risk. | |
| Recommendation — Define security requirements and oversight for externally provided system services. Apply supply-chain controls to verify providers and limit inherited risk. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | CIS-15 directly covers managing service provider relationships and associated risk. |
| Recommendation — Track service-provider access and verify controls before and during the relationship. | ||