Identity Lifecycle Policy Template: Joiner, Mover, Leaver and Non-Human Identities

Most identity incidents trace back to a lifecycle event nobody acted on: a leaver whose account stayed active, a mover who kept the old team's access, or a service account whose owner left two years ago. This template is a single policy that sets the rules, owners and deadlines for every identity from creation to removal, covering employees, contractors and other workforce users alongside service accounts, workload identities, API keys, certificates and AI agents. It states what must happen and by when; the how lives in your procedures and in the process guides linked from each section. It is for IAM, IGA and security governance leads who need a policy auditors can test and engineers can automate against.

How to use this template

• Placeholders: replace text in square brackets, such as [Organisation], [HR system] and [24] hours, with your own terms and values. The service levels in section 5 are the main numbers to set; the values shown are common starting points, not regulatory requirements.
• Must and should: "must" is mandatory; "should" is expected practice where a documented reason allows another approach. Keep the distinction when you edit.
• Where this sits: this policy governs lifecycle events. Your Access Control Policy Template governs how access decisions are made, the NHI Policy Template governs NHI credentials and storage in depth, and the NHI Security Standard Template holds technical values such as key lifetimes. Cross-reference them rather than repeating their rules.
• Procedures: step-level instructions belong in procedures, such as the User Access Provisioning Procedure Template, that cite this policy's statement numbers.
• Small organisations: sections 4 and 5 can be cut to the statements you can evidence today, with the rest added as automation arrives. Do not publish deadlines you cannot meet.

1. Purpose

1.1 This policy ensures that every identity used to access [Organisation] systems and data is created for an approved purpose, has an accountable owner, holds only the access its current role requires, and is disabled and removed promptly when that purpose ends.

1.2 It supports [Organisation]'s obligations under [Information Security Policy], [regulatory or contractual requirements, for example ISO/IEC 27001 certification scope] and the control objectives listed in section 9.

2. Scope

2.1 This policy applies to all identities with access to [Organisation] systems, applications, cloud tenants and data, wherever hosted, including:

• Workforce identities: employees, contractors, temporary staff, interns, partners and supplier staff with [Organisation] accounts.
• Privileged identities: administrator accounts, separate admin accounts and break-glass accounts.
• Non-human identities (NHIs): service accounts, workload and managed identities, cloud roles assumed by workloads, application registrations and service principals, API keys and tokens, certificates used for authentication, bots and robotic process automation accounts.
• AI agent identities: identities and delegated grants used by AI agents acting for [Organisation], treated as NHIs with the additions in 4.5.

2.2 Customer and consumer identities are out of scope and governed by [Customer Identity Policy].

3. Roles and responsibilities

4. Policy statements

4.1 General

• 4.1.1 Every identity must be recorded in [identity inventory / IGA platform] with a unique identifier, type, owner, purpose, creation date and, where applicable, an end date.
• 4.1.2 Workforce lifecycle events must be driven from the authoritative source ([HR system] for employees, [contractor system] for non-employees). Manual account creation outside that flow is an exception under section 7.
• 4.1.3 Every identity must have exactly one accountable owner. An identity whose owner leaves must be reassigned under 4.4.5.
• 4.1.4 Access must be granted on least privilege and need to know, using roles or access packages where defined.
• 4.1.5 Shared accounts used by people are prohibited except where listed in [approved shared account register] with individual accountability controls.
• 4.1.6 Identities must be disabled before they are deleted, and deletion must follow the retention rules in 4.3.6.

4.2 Joiners and onboarding

• 4.2.1 Accounts must not be created before an approved joiner record exists in the authoritative source.
• 4.2.2 Joiners must receive only birthright access defined for their role, department and location in [role catalogue]; additional access must be requested and approved.
• 4.2.3 Identity proofing must be completed before credentials are issued, at a level set in [Authentication Standard].
• 4.2.4 Accounts may be created in advance of start date but must remain disabled until [start date / day before start].
• 4.2.5 Privileged access must not be part of birthright access and must use a separate account under [Privileged Access Policy].
• 4.2.6 Non-employee accounts must carry an end date no later than the contract end date and no more than [12] months ahead.

Process detail: see the Joiner-Mover-Leaver Guide and the Identity Lifecycle Event Design Guide.

4.3 Movers and leavers

• 4.3.1 On a role, department or location change, access attached to the previous role must be removed within the mover deadline in section 5, unless the new manager approves a time-limited overlap of no more than [30] days.
• 4.3.2 The new line manager must confirm the mover's access within [10] working days of the change.
• 4.3.3 On a leaver event, all interactive access must be disabled by the leaver deadline in section 5, including single sign-on, directory, cloud console, VPN and remote access, and active sessions and refresh tokens must be revoked.
• 4.3.4 Involuntary or high-risk leavers must be disabled immediately on notification, coordinated between [HR] and [IAM team].
• 4.3.5 Before the leaver's account is disabled, the line manager must confirm the transfer of any NHIs, API keys, scheduled jobs, OAuth grants and shared credentials the leaver owns or knows. Shared credentials the leaver knew must be rotated.
• 4.3.6 Disabled workforce accounts must be deleted after [90] days unless a legal hold or retention requirement applies; mailbox and data retention follow [Records Retention Policy].
• 4.3.7 Contractor accounts must be disabled automatically at their end date unless extended through the contractor system.

Process detail: see the Contractor Identity Lifecycle Guide. If access is found after a leaver date, follow the Leaver Retained Access Incident Playbook.

4.4 Non-human identities: create, rotate, retire

• 4.4.1 Create: an NHI must be created only through [request process or pipeline] with a recorded owner, purpose, consuming system, environment, access requested and planned end date or review date. Names and tags must follow [Machine Identity Naming and Tagging Standard].
• 4.4.2 One NHI must serve one workload in one environment. Reusing an NHI across workloads or across production and non-production is prohibited.
• 4.4.3 Short-lived, platform-issued credentials (workload identity federation, managed identities) must be preferred over long-lived secrets where the platform supports them. Long-lived secrets must be stored in [approved secrets manager].
• 4.4.4 Rotate: long-lived credentials must be rotated at the intervals in [NHI Security Standard] and immediately on suspected exposure or when a person who knew the secret leaves.
• 4.4.5 Owner change: when an NHI owner leaves or changes role, the NHI must be reassigned to a new named owner within [10] working days. NHIs without an owner after that period must be disabled.
• 4.4.6 Access change: NHI access must be reviewed at least [annually] for standard NHIs and [quarterly] for privileged NHIs, and reduced to observed need.
• 4.4.7 Retire: when the consuming system is retired or the purpose ends, the NHI must be disabled, its credentials revoked, its access removed and its inventory record closed within the NHI retirement deadline in section 5.
• 4.4.8 NHIs with no authentication activity for [90] days must be flagged to the owner and disabled after a further [30] days unless the owner justifies them.
• 4.4.9 People must not use NHI credentials interactively, except through an approved break-glass procedure.

Process detail: see NHI lifecycle automation, the NHI Offboarding and Decommissioning Guide and the Secrets Rotation Runbook Template.

4.5 AI agent identities

• 4.5.1 AI agents must have their own identity, recorded in [agent registry], and must not run under a person's account or a shared service account.
• 4.5.2 Delegated grants, tool connections and scheduled triggers used by an agent must be recorded against the agent and removed when the agent is retired.
• 4.5.3 Agent identities must be re-certified by their owner at least [quarterly].

Process detail: see the AI Agent Lifecycle Management Guide and the AI Agent Decommissioning Checklist.

4.6 Privileged and emergency identities

• 4.6.1 Privileged accounts must be linked to a named individual's primary identity and disabled when that identity is disabled.
• 4.6.2 Break-glass accounts must be inventoried, monitored for every use and have their credentials changed after each use, following [Break Glass Access Procedure].

5. Service levels

The deadlines below are measured from the event time recorded in the authoritative source. Set values your automation can evidence; tighter values are common for privileged and high-risk identities.

6. Reviews and reconciliation

• 6.1 [IAM team] must reconcile accounts in each in-scope system against the authoritative sources at least [monthly] and treat any account without a matching active identity as an orphan to be disabled or assigned.
• 6.2 Access reviews must run at least [annually] for standard access and [quarterly] for privileged access and privileged NHIs, by the line manager or NHI owner and the system owner. See the Access Reviews Guide.
• 6.3 Review decisions to revoke must be actioned within [10] working days.
• 6.4 Orphaned and dormant identities found outside a review must be handled under 4.4.5 and 4.4.8. See Orphaned and Dormant Accounts.

7. Exceptions

7.1 Exceptions must be requested through [exception process], state the statement number, business reason, compensating controls and an expiry no later than [6] months, and be approved by [security risk owner]. 7.2 Expired exceptions revert to policy automatically. 7.3 [Security team] must maintain an exceptions register and report it to [governance body] [quarterly].

8. Compliance and monitoring

8.1 [IAM team] must report these metrics [monthly] to [policy owner]:

• Percentage of leavers disabled within the section 5 deadline.
• Number of active accounts with no matching active identity (orphans).
• Percentage of NHIs with a current named owner.
• Number of NHIs and agents past their end or review date.
• Percentage of review revocations actioned on time.

8.2 Breaches of this policy may lead to access removal and action under [disciplinary policy]. 8.3 Internal audit may test any statement by sampling HR events against system logs.

9. Control mapping

10. Review and approval

• Policy owner: [name, role]
• Approved by: [approving body] on [date]
• Version: [1.0]; next review due [date, no later than 12 months from approval]
• Related documents: [Access Control Policy], [NHI Policy], [NHI Security Standard], [Privileged Access Policy], [Break Glass Access Procedure], [User Access Provisioning Procedure], [Records Retention Policy]

Implementation guidance

1. Connect the sources first: integrate [HR system] and [contractor system] with the IGA or directory so joiner, mover and leaver events trigger automatically; without this, section 5 cannot be evidenced.
2. Baseline the gaps: run a one-off reconciliation of every in-scope system against HR, and an NHI ownership campaign. Disable, do not delete, unmatched accounts and unowned NHIs, with a documented re-enable path as the rollback.
3. Pilot the deadlines: measure current leaver and mover times for [30] days before publishing section 5 values, then set targets you can meet and tighten them each year.
4. Automate NHI creation: route new NHIs through a request form or pipeline that captures 4.4.1 fields, so the inventory stays current by design.
5. Monitor in report-only mode: run the section 8 metrics for one quarter before enforcing automatic disablement of dormant NHIs, to find hidden dependencies.
6. Scale by size: small organisations can start with the HR leaver feed and a spreadsheet NHI register reviewed monthly; large organisations should drive all of section 4 from the IGA platform, with the NHI inventory linked to the CMDB and secrets manager.

Sources behind this template: NIST: SP 800-53 Rev 5 · NIST: Cybersecurity Framework 2.0 · OWASP: Non-Human Identities Top 10 2025

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Joiner-Mover-Leaver Guide · NHI lifecycle automation · Contractor Identity Lifecycle Guide · Access Control Policy Template