Dormant identities can leave active data behind

Disabling an account feels final because the person can no longer sign in.

From an identity perspective, that may be exactly what the organisation needed to achieve.

The data connected to that identity does not become resolved simply because authentication has stopped.

Files remain. Sharing links remain. Collaborative content may still be used by other people. Records may be subject to retention. Personal storage may contain working material that the organisation still needs. A service or automated process may even depend on the account in ways nobody noticed while the person was active.

Identity closure and data closure are related decisions. They are not the same decision.

Access can end before responsibility does

The first priority in many offboarding or dormant-account situations is obvious: prevent inappropriate access.

Blocking sign-in, removing privileged roles and ending active sessions can be urgent and necessary.

Those actions reduce the immediate identity risk.

They do not determine what should happen to the information attached to the account.

That responsibility often lasts much longer. The organisation may need to preserve records, transfer active work, maintain access for a manager or service owner, respond to a future information request or delete material that no longer has a legitimate purpose.

The account can be closed while those obligations remain open.

Four lifecycles are often being treated as one

I find it useful to separate four lifecycles that are frequently collapsed into a single offboarding task.

The identity lifecycle determines whether the user can authenticate and whether the digital identity should continue to exist.

The privilege lifecycle determines which administrative, application or group-based rights need to be removed and whether any access was inherited indirectly.

The service lifecycle identifies dependencies such as workflows, shared resources, ownership roles or applications that may still refer to the account.

The data lifecycle determines what information should be retained, transferred, archived or deleted, under whose authority and for how long.

An account can be secure from a sign-in perspective while the other three lifecycles remain unresolved.

Blocking, unlicensing and deletion are different events

Cloud platforms do not necessarily treat every account action as equivalent.

Blocking sign-in, removing a licence and deleting the user can trigger different behaviours. Retention policies, legal holds, recycle periods, delegated access and platform-specific cleanup processes may also affect what happens next.

That is why offboarding should not rely on assumptions such as “the account is disabled, so the data is safe” or “the licence was removed, so nothing else remains”.

The organisation needs to know which event starts which lifecycle.

This is particularly important in hybrid environments, where an identity may be represented in more than one directory and where deletion or disablement can be synchronised differently from the data services attached to it.

Personal storage often contains organisational work

OneDrive and similar services are described as personal storage because the workspace is assigned to an individual.

The content is often organisational.

Draft reports, project records, working spreadsheets, meeting material, correspondence and operational notes can all sit inside a space owned technically by one person but relied upon by many others.

This creates a design question before anybody leaves.

Which information belongs in an individual workspace, and which information should already live in a shared service with durable ownership?

Good offboarding can rescue important information. Better information architecture reduces how much rescue is required.

Retention is not ownership

Keeping data is not the same as governing it.

A retention policy may ensure that content remains available for a defined period. It does not necessarily decide who is responsible for the content, who should continue to have access or whether the material remains operationally useful.

The opposite is also true. A manager may need access to complete a handover, but that does not mean every file should be retained indefinitely.

Data ownership, access and retention should therefore be explicit.

A service owner can decide what work needs to continue. A records or data-protection function can advise on legal and policy obligations. IT can implement the approved state and preserve evidence of what happened.

No single team should have to invent the entire answer while processing the account.

Offboarding should produce two closure decisions

A strong offboarding process should be able to answer two separate questions.

First: has the identity been closed safely?

Second: has the associated data reached an approved state?

The second decision may take longer. It may involve transfer, review, retention, archive or deletion.

That is acceptable as long as the outstanding work remains owned and visible.

The weakness is not that data decisions sometimes need time. The weakness is allowing the identity ticket to close while the data question disappears with it.

What remains difficult

There will always be awkward cases.

Users store information inconsistently. Shared links outlive their original purpose. Data may be duplicated across personal and collaborative spaces. Retention rules can prevent quick cleanup. A former user may have synchronised files to devices outside the organisation’s immediate control.

Those realities make perfect closure difficult.

They also make a documented decision more important. The organisation should be able to explain what it protected, what it transferred, what it retained, what it deleted and which limitations remained.

The broader lesson

Identity governance is not complete when access ends.

The data, services and responsibilities attached to the identity still need an owner.

Identity lifecycle ends access. Data lifecycle determines what happens to what the identity left behind.

Treating those as separate but connected controls creates a much more dependable offboarding model than relying on a disabled-account status as proof of completion.