Notifications
Clear all
Topic starter
06/06/2026 11:19 am
TL;DR: Third-party risk management is no longer just a procurement or compliance exercise: vendor access, sensitive data exposure, operational dependency, and offboarding failures all sit inside the identity perimeter, according to SecurEnds. The governance test is whether organisations can continuously validate vendor access, monitor risk drift, and revoke entitlements before relationships outlive accountability.
NHIMG editorial — based on content published by SecurEnds: third-party risk management process guidance
Questions worth separating out
Q: How should organisations manage third-party access as part of IAM governance?
A: Treat every vendor relationship as a governed identity relationship.
Q: Why do third-party relationships create ongoing identity risk?
A: Because vendor access can persist after the original business need changes.
Q: What breaks when vendor offboarding is only handled as a contractual task?
A: The technical controls break first.
Practitioner guidance
- Inventory all third-party access paths Map every vendor, supplier, and service provider to the systems, datasets, and workflows they can reach.
- Tier vendors by identity risk Classify third parties by access sensitivity, operational dependence, and regulatory impact before deciding review depth.
- Bind offboarding to technical revocation Require a documented exit workflow that removes system access, disables shared credentials, confirms data return or destruction, and records completion in the governance system.
What's in the full article
SecurEnds' full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step third-party risk management workflow from vendor identification through offboarding.
- Specific due diligence inputs such as security questionnaires, audits, certification checks, and financial review.
- Practical guidance on continuous monitoring and review cadence for changing vendor risk.
- Documentation and governance practices for tracking contracts, mitigation actions, and accountability.
👉 Read SecurEnds' guide to the third-party risk management process →
Third-party risk management process: what IAM teams miss most?
Explore further
06/06/2026 12:02 pm
Third-party risk management is an identity lifecycle problem, not just a vendor governance exercise. The article treats external suppliers as a broad risk category, but the operational reality is access management across the full relationship lifecycle. When a vendor can touch systems, data, or production workflows, the core question becomes who can still act, what they can still reach, and whether that access is still justified. Practitioners should treat vendor governance as an entitlement lifecycle, not a questionnaire.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slowly residual access can disappear in practice.
A question worth separating out:
Q: How can security teams know whether third-party risk management is working?
A: Look for evidence that inventory, review, monitoring, and revocation are all connected. A working programme produces up-to-date vendor ownership, current access maps, timely reassessments, and documented offboarding. If any of those signals are missing, the programme is probably managing paperwork rather than exposure.
👉 Read our full editorial: Third-party risk management process is an access governance problem
