Who is accountable when employees keep using former employer accounts or data?

Why This Matters for Security Teams

When former employees can still use an old account, shared workspace, or cached data path, the issue is no longer just people policy. It is an identity lifecycle failure that can expose customer data, internal systems, and audit integrity. NHI Management Group’s research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a useful proxy for how often lifecycle control is incomplete across modern identity estates; see the Ultimate Guide to NHIs — Key Research and Survey Results. The accountability question matters because access rarely ends at HR termination alone. It spans SaaS, shadow IT, delegated access, personal devices, and tokens that outlive the employment relationship.

That is why NIST Cybersecurity Framework 2.0 places lifecycle governance and access control inside an organisation’s core risk responsibilities, not as an afterthought. If an employee can keep using former employer accounts or data, the root cause usually sits in ownership gaps: unclear offboarding triggers, weak entitlement review, and poor telemetry across connected applications. In practice, many security teams encounter this only after a stale account is used in an incident review, rather than through intentional lifecycle assurance.

How It Works in Practice

Accountability should be assigned to the organisation that owned the access pathway, because the organisation is the only party that can actually trace, disable, and verify revocation across systems. The practical control model starts with a complete inventory of identities and entitlements, then ties HR offboarding to IAM, SaaS admin consoles, PAM, and data-sharing tools. A good programme does not stop at disabling the primary directory account. It also revokes session tokens, removes group membership, invalidates API keys, and checks for forwarded mail, delegated access, OAuth grants, and personal exports.

Current guidance suggests that access review should be evidence-based, not assumption-based. That means the owner of the data path must confirm:

• where the account existed
• which applications trusted it
• whether privileged access was inherited
• which tokens or credentials remain valid
• who approved the final revocation

This is consistent with lifecycle and visibility findings in the Ultimate Guide to NHIs — Key Research and Survey Results, especially the reported lack of formal offboarding for credentials and the low visibility into service accounts. The same governance logic applies to human and non-human identity paths: if a system can still authenticate, the lifecycle is not complete. Organisations should pair that operational discipline with access-control and governance requirements described in NIST Cybersecurity Framework 2.0.

In practice, the best control owner is usually the application, platform, or identity team that can verify actual revocation, while HR only supplies the termination trigger. These controls tend to break down when SaaS sprawl and unmanaged device access prevent the organisation from seeing every place the former account still authenticates.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance rapid deprovisioning against investigations, legal holds, and business continuity. Not every lingering account is the same. A retained mailbox for legal or payroll reasons may be appropriate if it is heavily restricted, while a live login with active data access is not. Best practice is evolving here, and there is no universal standard for how long every access artefact should be retained once employment ends.

Two edge cases matter most. First, shared or delegated accounts can blur accountability because the named user is not the only person with practical access. Second, externally managed services can delay revocation because the organisation does not directly control the downstream platform. In both cases, the accountable party remains the organisation that failed to design and verify the access boundary. The worker may misuse what still works, but the control failure belongs to the entity that allowed the access to persist.

This distinction becomes especially important in audits and incident response, where teams need to separate policy violation from control failure. If access survives termination, the question is not only who clicked after leaving, but why the organisation could not prove that access had been removed.

Related resources from NHI Mgmt Group

• Who is accountable when a cloud misconfiguration exposes production data?
• Who is accountable when an agentic browser changes data or permissions?
• Who is accountable when unsanctioned SaaS stores sensitive business data?
• Who is accountable when browser-based identity risk causes a data leak?