Account Retention Policy

What retention means for leavers and system continuity

An account retention policy is really a lifecycle rule: it decides which access paths end immediately, which are held for a period, and which remain active because the account supports continuity, legal hold, or administrative functions. The security challenge is not just removal, but choosing the right end state for each account type without breaking operations.

That distinction matters because some accounts represent a person, while others support systems, integrations, shared workflows, or service processes. A leaver policy that treats every account the same can create either excess exposure or avoidable disruption.

Why retention is used instead of blanket deletion

Retention exists because immediate deletion can remove evidence, interrupt approvals, orphan data ownership, or break dependent systems. A controlled retention window gives teams time to verify whether the account is tied to mailboxes, application ownership, delegation, scheduled jobs, or administrative tasks that still need to be handed over.

It is also used to avoid permanent loss where an account must remain available for a defined business, security, or compliance purpose. In practice, the policy acts as a decision rule for when deactivation is enough, when deletion is safe, and when continued activity is justified and documented.

For organisations that need a wider control baseline, an Access Control Policy Template helps place joiner, mover, and leaver decisions inside a broader access governance model.

What should be covered in a retention decision

The policy should classify accounts by function rather than by convenience. Human user accounts, privileged administrative accounts, shared accounts, service accounts, and vendor or automation accounts often need different retention outcomes because their risk, dependencies, and recovery needs differ.

Good retention rules also define who approves exceptions, how long a disabled account may be preserved, what records must be kept, and when related secrets, sessions, or delegated access should be removed. Without that structure, retention becomes an informal habit instead of a repeatable control.

Where the account is part of a broader offboarding or transition process, the policy should connect to related access review and decommissioning steps. The same logic that governs access lifecycle decisions is often needed for passwords, sessions, and dependent account relationships.

For continuity scenarios, an account may remain necessary temporarily, but the retention decision should still be explicit. The right question is not whether the account can exist, but whether it should remain usable, disabled, or only preserved for reference.

How account retention affects security and administration

Retention is a control over lingering access. If an account is left active after an employee departs, the organisation keeps an unnecessary path into systems, data, or admin functions. If an account is deleted too quickly, the organisation may lose access to records, ownership chains, or system functions that still depend on that identity.

This makes retention a balancing act between security and continuity. The policy should reduce standing access where it is no longer needed, while preserving only the minimum account state required for business operations, investigation, or regulated retention.

Teams often pair account retention with log retention, because account changes and post-departure activity need auditability. A useful companion reference is the Log Management and Retention Guide, which helps preserve the evidence needed to review account state changes and later activity.

When deletion is the goal, the retention policy should be aligned with data disposal practice so that account removal does not accidentally destroy records that must still be preserved. For that part of the lifecycle, the Data Retention and Secure Deletion Guide provides the right disposal context.

How organisations apply retention without creating unmanaged risk

Practitioners usually treat retention as a controlled exception process, not an open-ended permission to keep old accounts around. That means documenting the reason for retention, defining an expiry point, and ensuring the account is either disabled, transferred, or removed once the purpose ends.

Where an account must remain active, the safer pattern is to narrow its privileges and monitor use closely rather than leave its original access intact. Where the account no longer has a valid purpose, removal should also include any associated credentials, session tokens, or delegated access that could still be abused.

If the policy is being written for a broader retention framework, the most relevant operational companion is a general retention and disposal rulebook. The Data Retention and Disposal Policy Template covers the surrounding retention schedule, legal hold, and deletion decisions that often shape account handling as well.

For organisations that want the leaver process tied directly to access governance, the Shared and Generic Accounts Governance Guide is especially useful where accounts are not uniquely owned by one person and need tighter classification before they are kept or removed.

Related resources from NHI Mgmt Group

• Who should own help-desk verification policy when account changes affect IAM and PAM?
• Who should own account recovery policy in a zero-knowledge password system?
• Who should own backup policy when IAM roles and account connections are part of the setup?
• Who should own routing and retention policy when telemetry spans security and IT?