Joiners, movers, and leavers: keep access accountable

Access changes are a coordination problem as well as a technical one. An identity platform cannot remove a contractor’s account if nobody tells the owner that the contract has ended. Equally, a timely HR notification does not prove that every application stopped accepting the person’s credentials.

Joiners, movers, and leavers need a process that connects a business event to an approved access state, executes the necessary changes, and verifies the result. From a technical leadership perspective, the important question is not whether an offboarding checklist exists. It is whether the process covers the systems people actually use, handles failures, and leaves evidence of what changed and when.

Define the lifecycle and its handoffs

Treat each lifecycle event as a change to a person’s authorized access, not simply a ticket to create or disable an account. The event record should identify the person, employment or engagement status, manager or sponsor, effective date and time, and affected role. Use a stable identifier rather than relying only on names or email addresses.

HR will often initiate employee events. A procurement owner, project manager, or internal sponsor may initiate contractor events. Choose an authoritative source for each population and define how corrections, cancelled starts, contract extensions, and urgent departures reach IT.

Separate four responsibilities, even when a small team assigns several to the same person:

Name deputies and an escalation route. A scheduled departure must not depend on one administrator being available. For sensitive changes, an independent reviewer provides a useful check; where staffing prevents that, document the arrangement and use a subsequent review.

Define completion criteria for each event. A joiner is ready when approved access and required device controls are verified. A mover is complete when both additions and removals are checked. A leaver is complete when access paths are revoked and unresolved asset, data, or credential issues have explicit owners.

These are practical control-design recommendations, not universal statutory deadlines. Within an ISO 27001 ISMS, access controls should reflect the organization’s scope and risk treatment. See ISO 27001 Annex A in practice for the broader control context.

Establish coverage before automating changes

Start with the application inventory. For each system, record its owner, identity source, provisioning method, authentication method, supported revocation actions, and verification method. Include centrally managed applications and those with local accounts.

Single sign-on does not necessarily mean full lifecycle management. An application may authenticate through the identity provider while maintaining local administrators, API keys, active sessions, or recovery options. A provisioning connector may disable a user without removing every entitlement. Document what each mechanism actually does.

Include these less visible access paths:

• Privileged accounts separate from the person’s everyday account.
• VPN access, certificates, SSH keys, and remote-support tools.
• Personal access tokens, API credentials, and application passwords.
• Shared credentials the person knew or could retrieve.
• Guest accounts, external collaboration spaces, and customer-managed environments.
• Service identities whose owner or credential custodian is changing.

Do not automatically disable every service identity associated with a departing employee: it may run a production workload. Instead, transfer ownership, review permissions, and rotate exposed credentials where appropriate. The objective is to remove the person’s access without creating an avoidable outage.

Reconcile the inventory periodically with identity exports, device records, purchasing records, and team declarations. No single source will necessarily reveal every application. Unmanaged discoveries should enter the lifecycle process rather than remain informal exceptions.

Joiners: provision a controlled starting state

Build role baselines with bounded exceptions

Define access packages around responsibilities, not just job titles. A support analyst might need customer-ticket access but not billing exports. A software engineer might need source repositories and development environments without receiving production administration by default.

Each baseline should have an owner, a version, its included groups or entitlements, and a review date. Record which version was applied to a joiner. Otherwise, a later role update makes historical access decisions difficult to reconstruct.

Request additional access separately. The request should state the business purpose, approving system or data owner, permission level, and expiry where appropriate. Avoid copying an existing employee’s complete permission set: it can reproduce accumulated exceptions and privileges from previous roles.

Stage accounts before the start date where useful, but control activation. A cancelled hire should trigger cleanup of staged accounts, shipped devices, and invitations. Contractors should have an internal sponsor and an end or review date; extensions should require an affirmative decision rather than silently becoming permanent access.

Establish the device and authentication baseline

Record the device identifier, assigned person, handover date, and management enrollment. Check the relevant baseline before granting sensitive access: supported operating system, patch status, disk encryption, screen lock, endpoint protection, and an approved authentication setup.

These are risk-based implementation choices, not a claim that every organization must use identical settings. For personal devices, define permitted access and data handling explicitly rather than treating them as equivalent to managed laptops.

Use dated observations from device-management systems where available. A manual inventory can still be useful if reconciled and supported by evidence; a live inventory also needs scrutiny when a device has stopped reporting. Preserve observation times so an old healthy status is not mistaken for current assurance.

Verify authentication enrollment and initial credential delivery. Where your policy requires multifactor authentication, confirm that it is active before access begins, rather than recording only that an enrollment invitation was sent. Keep credentials and recovery codes out of lifecycle tickets.

Movers: remove the old role, not just add the new one

Transfers are often the hardest lifecycle events because the person remains employed and their existing account continues to work. New access gets attention because missing permissions interrupt work. Old access can persist without any visible symptom.

Treat the move as a comparison among three states: current access, the approved new baseline, and approved continuing exceptions. Determine which entitlements must be added, retained, reduced, or removed. Check direct assignments as well as groups, nested memberships, administrative roles, and local application permissions.

The previous manager should help identify responsibilities that have ended. The receiving manager confirms the new duties, while system or data owners approve sensitive access. This prevents a new manager from implicitly authorizing retained access to another department’s information.

A transition period can be legitimate. Someone moving out of finance may need limited access to complete a handover. Record the specific permission, justification, approving owner, and expiry. Where feasible, replace broad write access with narrower or read-only access. Put expiry into an executable task or system setting, not only into a comment.

Changes may also affect devices, shared mailboxes, data ownership, and privileged duties. Moving into an administrative role should not automatically convert the everyday account into a privileged identity.

After execution, compare the actual access set with the intended result. For a department transfer, granting the new role may be easy. The important check is whether old finance, customer, or administrative access remains. A mover sample that checks only new provisioning misses that risk.

Leavers: coordinate revocation, assets, and business continuity

Set timing according to risk and circumstances

Record an effective revocation time, including timezone. “Last day” is too ambiguous for distributed teams and scheduled automation. Distinguish a planned departure from an urgent termination, suspected compromise, or unexpected absence requiring temporary suspension.

Agree the timing with HR and relevant management. Restrict sensitive termination details to those who need them, while ensuring executors receive enough information to act. High-risk exits may require coordinated immediate action; routine departures may allow a planned handover before access ends.

Do not let data transfer or device shipping delay revocation. These activities can have separate completion dates and owners. If a trigger arrives late, record the intended cutoff, actual execution, and exposure interval rather than changing the paperwork to make the event appear timely.

Close all relevant access paths

Disable the primary identity and execute application-specific actions from the inventory. Address active sessions, refresh tokens, local accounts, privileged accounts, remote access, certificates, and personal credentials as applicable. A central account disablement does not prove every existing session or independently issued credential has become unusable.

Rotate shared secrets the person could access according to risk, and check that the rotation will not disrupt dependent systems. Remove recovery methods or delegated permissions that could restore access. Where customer or supplier environments are involved, request revocation from their owner and retain confirmation.

Capture individual outcomes. A connector timeout is not a successful closure merely because the overall job finished. Route failures to a named responder, use an approved fallback, and verify the final state. Urgent unresolved access should enter the security escalation process.

Recover devices without assuming remote commands succeeded

Track each assigned asset through return, inspection, and approved reset or disposal. For remote workers, record shipping arrangements and unresolved custody. Remove physical access and recover tokens or keys where relevant.

If return is delayed, use available lock or wipe controls according to policy and risk. Distinguish a command being issued from the device acknowledging and completing it. An offline laptop may not receive the command. Assess residual exposure using encryption status, local credentials, cached data, and available network restrictions rather than treating “wipe queued” as proof of erasure.

Preserve necessary data and reclaim licenses

Assign a successor for business documents, repositories, shared workflows, and service ownership. Use authorized administrative transfer mechanisms rather than asking someone to impersonate the former employee. Scope mailbox or file access, record the purpose, and limit the people who receive it.

Separate access revocation, license reclamation, retention, and deletion. Removing a license may affect data availability differently across applications. Check retention requirements and any legal hold before irreversible cleanup.

For personal data, GDPR Article 5 establishes storage limitation; it does not create one universal employee-account deletion deadline. Define justified retention periods and cleanup responsibilities. Article 32 requires security measures appropriate to risk, so document the reasoning behind offboarding controls rather than treating a checklist as legal compliance by itself.

Keep evidence of the actual change

The useful record connects the authorized decision to the observed result. Retain the event, approval, affected systems, execution times, verification results, and exception handling. Include the intended effective time so reviewers can assess timeliness.

A practical evidence package contains:

• A stable person and event identifier, with the initiating source.
• The approved baseline and any retained or additional permissions.
• Per-system actions, results, timestamps, and relevant log references.
• Verification showing the resulting access state.
• Asset, data-transfer, and license outcomes where applicable.
• Failed actions and exceptions with an owner, deadline, and closure evidence.

A policy demonstrates intent. A ticket demonstrates coordination. An application result or access export helps demonstrate implementation. None should be substituted for the others. Screenshots can be useful when stronger exports are unavailable, but include enough context to identify the system, subject, and observation time.

Protect these records: they contain employment information and security-sensitive details. Apply access restrictions and a retention schedule, and avoid collecting passwords, unnecessary termination narratives, or entire mailboxes as evidence. Historical records should remain understandable even after operational accounts are deleted.

Worked example: a transfer followed by departure

Consider an illustrative company with a central identity provider, managed laptops, and a finance application with local permissions. Assume an employee moves from finance operations to customer success on 1 June, needs a five-working-day handover, and later leaves on 30 September. These dates and arrangements are example assumptions, not prescribed timings.

For the move, IT captures the current entitlements. Customer-success access is approved, finance write access is removed at the effective time, and restricted finance read access is retained until the handover expires. The finance owner approves that exception. Because the finance application maintains local permissions, its administrator executes and verifies the change separately from the identity-provider group update.

At expiry, verification finds that a local export permission remains. The mover record stays open, the administrator removes it, and the reviewer records the final state. The lesson is specific: the role change succeeded centrally, but the application’s permission model required an additional action.

For the later departure, the process sets a precise cutoff, transfers business files to an approved successor, disables identities, revokes applicable sessions and tokens, and checks the finance account directly. The laptop has not yet arrived by courier. Its return remains an asset exception, with containment actions and device observations recorded separately from account revocation.

The resulting evidence shows both successful changes and the original removal failure. Hiding the failure would lose the information needed to improve the workflow.

Test coverage and make the next improvement concrete

Sample real lifecycle events against the application inventory. Include contractors, privileged users, remote workers, movers with temporary overlap, and applications outside the identity provider. Access reviews should also examine whether current permissions still match each person’s responsibilities; they complement event-driven changes rather than replace them.

Test failure paths as well as normal execution: a missed HR event, failed connector, unavailable administrator, delayed device return, or cancelled start. Check that alerts reach a responder and that retries or manual actions produce verifiable outcomes.

Useful measures include revocation delay against the agreed cutoff, failed actions awaiting resolution, overdue temporary access, and events closed without verification. Define what each measure counts. A good average can conceal one long-lived privileged exception. Use findings to update role baselines, connector behavior, ownership, and escalation rules.

Secani can support the reviewable control record by connecting requirements to systems, owners, evidence, and decisions. Keep account changes in the operational identity and device systems; use the compliance workspace to preserve scope, uploaded results, exceptions, and review decisions. Human reviewers should validate any AI-assisted evidence conclusions before relying on them.

Start with one representative team and a recent joiner, mover, and leaver. Trace each event from notification to actual system state. Correct the first uncovered handoff or access path, assign its owner, and retest it before expanding the process.