A common mistake is assuming the vendor owns the whole risk. In practice, the customer still remains accountable for compliance, access, and oversight. Another error is focusing only on onboarding checks while ignoring ongoing changes in vendor financial health, security posture, and operational resilience. Risk management has to be continuous, not a paper exercise.
Where Organisations Misread Third-Party Risk
The biggest error is treating the vendor relationship as if risk transfers with the contract. It does not. Sensitive data and critical services may be delivered by a third party, but accountability for access, oversight, and compliance remains with the customer, especially when the service touches regulated information or business-critical operations.
Another common failure is to overvalue onboarding due diligence and undervalue continuous monitoring. A vendor can be acceptable at procurement and become risky later through financial stress, control degradation, ownership changes, insecure integrations, or service disruption. Third-party risk is a lifecycle issue, not a one-time approval.
A third mistake is assuming that a vendor’s controls are equivalent to your own control environment. Even when a supplier has strong security, the customer still needs to know what data is shared, who can access it, how access is revoked, and what happens when the relationship ends. For sensitive services, governance has to cover both the data and the dependency.
For readers looking at the control side in more depth, the supply-chain and vendor-security themes in Scania Supply Chain Data Breach and the exposure patterns in Klue OAuth Supply Chain Breach show how third-party access can become a direct path to sensitive systems and data.
What Makes Third-Party Dependence Riskier Than It Looks
Third-party risk increases when the vendor is not just handling data, but also operating systems, integrating into core workflows, or holding credentials that can reach production services. That creates a wider blast radius than organisations often assume, because compromise, misconfiguration, or poor vendor offboarding can expose both information and operational continuity.
Contract terms also tend to lag reality. A service may start as a narrow engagement and later expand through new integrations, shared identities, API access, subcontractors, or administrative exceptions. If oversight does not keep pace, the organisation can end up with more external exposure than it can actually describe, let alone control.
Visibility is usually the weakest point. Teams may know a supplier exists, but not which datasets, secrets, sessions, or service accounts are in scope, or whether those access paths are still needed. That is why vendor oversight should be tied to asset inventory, data classification, and access review rather than legal review alone. The risk is not only breach exposure, it is also loss of control over revocation and recovery.
Useful reference points for this operational reality include SOC 2 Trust Services Criteria (AICPA) for vendor assurance, and EU Digital Operational Resilience Act (DORA) where third-party operational resilience and ICT dependency are part of the regulatory problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while DORA and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV — Oversight | Vendor dependency and accountability require ongoing governance oversight. |
| ID.SC — Supply Chain Risk Management | The topic is fundamentally about supplier exposure, dependency, and continuity risk. | |
| Recommendation — Establish continuous third-party oversight for sensitive data and critical service dependencies. Identify, assess, and monitor supplier risks that affect sensitive data and critical services. | ||
| CIS Controls v8 | 15 — Service Provider Management | Directly addresses supplier risk, monitoring, and third-party security obligations. |
| 5 — Account Management | Third-party access lives or dies on provisioning, review, and revocation discipline. | |
| Recommendation — Maintain an active service provider management program with periodic reassessment and escalation. Review and revoke vendor access promptly when scope, risk, or relationship changes. | ||
| DORA | ICT third-party risk — ICT Third-Party Risk Management | DORA directly governs critical third-party dependencies, resilience, and oversight for financial entities. |
| Recommendation — Map critical vendor dependencies and test contractual, operational, and exit resilience. | ||
| NIS2 | Article 21 — Cybersecurity Risk-Management Measures | NIS2 requires risk-management measures that include supply-chain and third-party exposure. |
| Recommendation — Apply supply-chain risk controls and verify third-party security measures continuously. | ||
Practitioner Guidance
What to prioritise: Build a live view of which vendors can reach sensitive data, production services, or privileged workflows. If you cannot answer that quickly, your risk register is more mature than your control environment.
What to verify: Check whether exit and revocation are operational, not just contractual. The practical test is whether access can be removed, data can be recovered or deleted, and dependencies can be substituted without waiting on the vendor’s schedule.
Common mistake: Treating annual reviews as sufficient. For critical services, change detection matters more than point-in-time assurance, especially when financial health, subcontracting, incident history, or integration scope shifts during the year.
Practitioner takeaway: The real question is not whether a third party is “trusted”, but whether your organisation can still govern access, data exposure, and service continuity when that trust fails.
Related resources from NHI Mgmt Group
- What do organisations get wrong when they rely on legacy DLP policies for modern data security?
- What do organisations get wrong when they rely only on manual compliance reporting in financial services?
- What do organisations get wrong when they treat a data catalog as a marketplace?
- What do organisations get wrong about separation of duties for sensitive data?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
