Notifications
Clear all
Topic starter
11/07/2026 8:27 pm
TL;DR: Third-party risk management is about identifying and reducing the risks introduced by vendors, suppliers, partners, contractors, and service providers, with OneTrust arguing that tiering, automation, and broader risk coverage are the core program patterns. The real governance issue is that third-party access often outlives its business need, which turns vendor management into an identity and lifecycle control problem, not just a questionnaire exercise.
NHIMG editorial — based on content published by OneTrust: What Is Third-Party Risk Management?
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
Questions worth separating out
Q: What breaks when third-party risk management stops at initial assessment?
A: Programmes become stale because supplier access, data use, and operational dependence change after onboarding.
Q: Why do third-party relationships create identity and access risk?
A: Third-party relationships create identity risk because external parties often receive real credentials or delegated access into sensitive systems.
Q: How do security teams know if lifecycle automation is actually working?
A: Measure removal completeness, not just provisioning speed.
Practitioner guidance
- Define tiering criteria from live exposure Base vendor criticality on current data access, integration depth, business criticality, and continuity impact.
- Attach reassessment to lifecycle triggers Trigger reassessment on contract renewal, scope change, failed controls, or offboarding events.
- Map third-party access to identity controls Inventory service accounts, API keys, certificates, and federated roles used by suppliers, then assign an owner, expiry rule, and revocation path for each one.
What's in the full article
OneTrust's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for building a third-party inventory from contracts, CMDBs, SSO data, and business-owner inputs.
- Operational examples of vendor tiering, including how to score inherent risk and decide when on-site assessment is justified.
- Workflow detail on automating onboarding, reassessment, alerts, and offboarding across the TPRM lifecycle.
- Coverage of non-cyber risk categories such as privacy, geopolitical, financial, reputational, and business continuity exposure.
👉 Read OneTrust's guide to third-party risk management best practices and lifecycle controls →
Third-party risk management: what IAM and security teams miss?
Explore further
11/07/2026 8:55 pm
Third-party risk management is increasingly an identity lifecycle problem in disguise. The article describes TPRM as a broad governance discipline, but the operational reality is that third parties arrive with credentials, access paths, and offboarding obligations. That makes vendor oversight inseparable from IAM, PAM, and NHI governance, especially where service accounts, API keys, or federated access are involved. Practitioners should treat third-party reviews as lifecycle controls, not one-time procurement checkpoints.
A question worth separating out:
Q: Who is accountable when a third-party incident occurs?
A: Accountability should be shared but explicit. The business owner, security team, procurement, and legal function each have a role, but the policy must name who receives the incident report, who approves escalation, and who owns remediation follow-through. Without that structure, vendors can report events without anyone taking operational control.
👉 Read our full editorial: Third-party risk management and the governance gap in vendor access
