Begin with a complete vendor inventory, then classify vendors by data access, service criticality, and regulatory exposure. Build a simple lifecycle workflow for onboarding, assessment, monitoring, remediation, and offboarding. The programme becomes useful when it produces repeatable decisions, clear ownership, and measurable review cycles instead of one-off questionnaires.
Why This Matters for Security Teams
A third party risk programme is not just a procurement exercise. It is the control point that determines whether external services can touch sensitive data, create privileged pathways, or extend your attack surface through OAuth, APIs, and shared infrastructure. NHI Management Group research shows the scale of this visibility problem: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security from Astrix Security & CSA. That is why vendor risk cannot be treated as a one-time questionnaire.
Security teams should anchor the programme in how identities, secrets, and access actually behave over time. A vendor may begin as low risk and become high risk once it gains production access, long-lived API keys, or administrative integrations. This is where guidance from OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 is useful: classify by exposure, then enforce repeatable governance across the lifecycle. In practice, many security teams encounter vendor misuse and stale access only after an incident forces a retroactive inventory.
How It Works in Practice
Start with a minimum viable operating model, not a perfect policy set. First, define the intake criteria for every new vendor: what data it can access, whether it handles secrets or tokens, which business owner accepts the risk, and what evidence is required before go-live. Then standardise a tiering model that is simple enough to use consistently. For most organisations, the best split is by data sensitivity, service criticality, connectivity type, and regulatory impact.
From there, build four controls into the workflow:
- Onboarding approval that checks security, privacy, legal, and procurement sign-off.
- Assessment that matches depth to risk tier rather than using one questionnaire for all vendors.
- Monitoring that tracks changes in access, scope, incidents, renewals, and sub-processors.
- Offboarding that verifies data return, access removal, token revocation, and contract closure.
This approach becomes much stronger when paired with lifecycle thinking from NHI Lifecycle Management Guide and the broader guidance in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, because vendor access usually fails at renewal, not just at onboarding. For regulatory mapping, align evidence collection to EU Digital Operational Resilience Act (DORA) or EU Cyber Resilience Act where they apply, because both reinforce traceability, resilience, and supplier accountability. These controls tend to break down when the organisation has hundreds of low-touch SaaS vendors and no system of record for who owns each relationship.
Common Variations and Edge Cases
Tighter vendor control often increases procurement friction and review overhead, so organisations need to balance speed against assurance. That tradeoff is real, especially for startups, M&A integrations, and SaaS-heavy environments where business units buy tools before security is engaged. Current guidance suggests risk-tiered assessments are more effective than blanket annual reviews, but there is no universal standard for exactly how many tiers or evidence items a programme should use.
Some edge cases need special handling. Cloud and platform vendors often inherit shared responsibility boundaries, so the assessment must distinguish between what the provider secures and what the customer still owns. Resellers and managed service providers may hide the true subcontractor chain, which makes downstream visibility essential. For vendors that issue machine credentials or automation tokens, the review should include rotation, expiry, and revocation controls, not just contract terms. NHIMG research in Top 10 NHI Issues shows why this matters: static credentials and poor lifecycle control are recurring failure modes. In high-regulation sectors, teams should also reference The 52 NHI breaches Report to pressure-test assumptions about third-party access persistence and cleanup discipline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Sets governance for managing third-party cyber risk consistently. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret rotation and lifecycle control for vendor-issued credentials. |
| DORA | Relevant where vendor services support regulated operational resilience. |
Require expiring access, rotation, and revocation for all vendor machine credentials.
Related resources from NHI Mgmt Group
- How should security teams use AI in third-party risk management without over-automating decisions?
- How can IAM and security teams reduce third-party risk from AI-enabled SaaS tools?
- How should security teams manage third-party cyber risk in practice?
- Why does AI change third-party risk management for IAM and NHI teams?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
