Who is accountable when third-party access to personal data persists too long?

Why This Matters for Security Teams

When third-party access to personal data lingers past its useful life, the issue is rarely just contractual. It becomes an accountability problem: the organisation that granted the access, failed to review it, or never removed it is still responsible for the exposure. OWASP’s OWASP Non-Human Identity Top 10 reflects the broader reality that stale, over-permissioned access paths create avoidable risk, especially where service accounts, API keys, and vendor integrations outlive the business need that justified them.

NHI Management Group’s Ultimate Guide to NHIs shows how often organisations underestimate lifecycle control, with only 20% reporting formal offboarding and revocation processes for API keys. That matters because third-party access often bypasses the same scrutiny applied to human joiner-mover-leaver workflows. In practice, access does not become safe simply because a processor agreement exists or because the vendor was the last party to touch the data. In practice, many security teams encounter this only after a forgotten integration, inactive partner account, or retained token has already become the easiest path into personal data.

How It Works in Practice

Accountability should be assigned to the organisation that owns the data relationship and the system granting access, even when a processor operates the interface. That means the control point is not the vendor contract alone, but the lifecycle management of every external identity, token, and privilege path. Current guidance suggests treating third-party access like any other privileged access path: define an owner, set a review cadence, require expiry, and verify removal when the business purpose ends.

For access to personal data, practitioners should expect three control layers to work together:

• Ownership: one internal team or named role must approve, review, and retire the access.
• Evidence: offboarding should be provable through logs, tickets, or revocation records, not verbal assurance.
• Least privilege and time bounds: access should be scoped narrowly and expire automatically wherever possible.

This is where NHI discipline becomes essential. The 52 NHI Breaches Analysis and the Ultimate Guide to NHIs — Key Research and Survey Results both reinforce that lingering machine access is a common failure mode, especially where third parties are involved. Aligning with the OWASP NHI model and routine access attestation helps convert “someone else’s account” into a managed organisational risk. These controls tend to break down in environments with unmanaged integrations, shared service accounts, or no reliable inventory of which external parties can still reach production data.

Common Variations and Edge Cases

Tighter third-party controls often increase operational overhead, requiring organisations to balance privacy assurance against business continuity and vendor support needs. That tradeoff becomes sharper when a processor needs ongoing access for incident response, data migration, or support workflows. Best practice is evolving here, and there is no universal standard for how much access a vendor should retain by default.

Edge cases usually turn on whether the access is truly necessary and whether the organisation can prove timely review. A vendor may remain contractually engaged while the specific data access should already have been removed. Conversely, some regulated support arrangements may justify persistent access, but only with explicit scope, monitoring, and regular re-approval. The key question is whether the access is still justified at the time it exists, not whether it was ever justified in the past.

Where accountability becomes disputed, the deciding factors are usually internal governance gaps, not legal ambiguity. If the business owner cannot show who approved the access, who reviewed it, and who revoked it, the organisation has not operationalised accountability. That is why access reviews, offboarding checklists, and revoke-on-termination controls should be mandatory for every third-party path that can reach personal data.

Related resources from NHI Mgmt Group

• Who is accountable when third-party access stays active too long?
• Who should be accountable when sensitive data exposure is found through privileged access?
• Who is accountable when a third-party integration exposes corporate secrets?
• Who is accountable when third-party remote access is overused in public safety environments?