They often stop at contract language and overlook technical offboarding. If the vendor still has API access, admin roles, or OAuth grants after the relationship changes, the organisation has not actually reduced risk. A GDPR-ready programme treats offboarding as a technical identity event, not only a procurement milestone.
Why This Matters for Security Teams
SaaS vendor risk is often treated as a procurement and legal problem, but the real exposure lives in identity state. If a vendor retains API tokens, privileged admin roles, SSO assignments, or OAuth grants after a contract change, the organisation still has active reach into business data and administrative surfaces. That gap shows up in incidents such as the Salesloft OAuth token breach, where third-party access became a direct path to customer environments.
NHI Management Group’s research shows why this matters at scale: in the Ultimate Guide to NHIs, only 20% of organisations report formal offboarding and revocation processes for API keys. That is not a policy gap only; it is an operational failure that leaves vendor access live long after the relationship changes. The NIST Cybersecurity Framework 2.0 reinforces that access governance must be continuously managed, not assumed from contract terms alone.
In practice, many security teams encounter lingering third-party access only after a breach review or a SaaS audit, rather than through intentional offboarding controls.
How It Works in Practice
A GDPR-ready vendor risk programme treats third-party access as a lifecycle of identities, credentials, and permissions. The starting point is to inventory every vendor touchpoint: human admin accounts, service accounts, API keys, OAuth consents, SCIM or provisioning connectors, and delegated roles inside the SaaS tenant. Contracts matter, but they do not deactivate tokens. Revocation has to happen in the systems where access actually exists.
Practical controls usually include:
- Tracking vendor identities separately from internal user accounts so offboarding is visible and testable.
- Requiring just-in-time access for vendor support where feasible, rather than standing admin entitlements.
- Revoking OAuth grants, rotating shared secrets, and disabling dormant integrations when a vendor relationship ends or changes scope.
- Reviewing SaaS admin and API permissions on a fixed schedule, with evidence that deprovisioning occurred.
- Mapping each vendor integration to a business owner and a technical owner so no access path becomes orphaned.
This is where the Top 10 NHI Issues become relevant to SaaS programmes: over-privileged service identities, weak rotation, and poor visibility routinely defeat otherwise sound vendor governance. The same pattern appears in the BeyondTrust API key breach, where exposed machine credentials created an access path that contracts could not mitigate after the fact.
For GDPR, the operational question is simple: can the organisation prove that vendor access was removed quickly, completely, and across every connected system? If the answer depends on manual follow-up between procurement, legal, and IT, the programme is already behind. These controls tend to break down when the SaaS stack includes many unsupervised app-to-app integrations because revocation becomes fragmented across tenant settings, IdP assignments, and vendor-owned automation.
Common Variations and Edge Cases
Tighter vendor access control often increases administrative overhead, requiring organisations to balance faster onboarding and support against stronger offboarding discipline. That tradeoff becomes more visible in SaaS environments with frequent integrations, where vendors need temporary access for troubleshooting, migration, or managed services.
Best practice is evolving, but current guidance suggests treating high-risk vendor access as ephemeral wherever possible. Short-lived credentials, scoped OAuth grants, and explicit expiry dates reduce the chance that access survives beyond the approved business purpose. In higher-risk cases, organisations should consider whether the vendor needs direct tenant access at all, or whether a brokered support model is safer.
There are also edge cases where the vendor is technically a processor but operationally acts like an administrator. In those situations, the distinction between procurement risk and identity risk disappears. The Ultimate Guide to NHIs — Why NHI Security Matters Now is a useful reminder that third-party exposure is now a default condition in modern estates, not an exception. Under GDPR, that means offboarding evidence, access reviews, and revocation logs should be treated as audit artefacts, not optional housekeeping.
There is no universal standard for this yet, but security teams that can prove technical deprovisioning usually have a much stronger position than those relying on signed exit letters alone.
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 and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Vendor offboarding failures often leave secrets and grants active. |
| NIST CSF 2.0 | PR.AC-4 | Third-party access must be managed and removed when no longer needed. |
| NIST AI RMF | Governance should cover accountability for autonomous access and connected systems. |
Assign ownership for vendor access decisions and evidence retention across the AI and SaaS lifecycle.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
