A Same-Day Access Offboarding Checklist

Coordinate access around the authorized departure time

Organize access offboarding around one authorized access-end time: prepare before it, coordinate the approved actions at that time, and inspect the results afterward. A message saying “done” is not the same as evidence that every relevant access path has ended.

This checklist is for a small-team owner or operations lead coordinating a departure. “Same-day” describes the coordination window, not a promise that every provider, session or shared credential can be resolved that day. Authorized leadership supplies the timing; this guide does not decide employment, legal or records-retention questions.

NCSC identity and access guidance mentions joiner, mover and leaver processes as a typical way to manage access. The three time bands below are PlainFort’s way of organizing the work, not a universal technical sequence.

Use exactly three time bands

The bands and their order are PlainFort editorial judgment, not NCSC requirements or a universal technical sequence.

Before the effective time

Who authorized the change, when does it take effect, which paths are in scope, and who will retain necessary business access?

Confirm authority and timing; assemble non-secret inventory and rollout, MFA, administrator-account and shared-login decision references; assign owners, backup, escalation, communication boundary, and evidence locations; identify last-administrator, root, financial, production, recovery, shared-access, automation, personal-device, legal-hold, records, privacy, and incident concerns; and stop unresolved destructive actions. For an unplanned departure, record when this band is compressed or unavailable rather than fabricating preparation.

At the effective time

Which separately authorized actions should occur now, who owns each, and what provider-dependent behavior remains unresolved?

Coordinate separately authorized actions in dependency-safe order: attributable accounts and access paths, administrative privilege, relevant authenticators and recovery authority, sessions where supported, shared-access membership or the agreed shared-login pattern, and approved automation or delegation paths. This guide describes what must be accounted for; it supplies no platform commands and executes nothing.

After immediate revocation

Which results have been inspected, which are only reported, and who owns every delay or unknown?

Inspect non-secret evidence; reconcile blocked, deferred, and unknown items; confirm a surviving authorized administrator and continuity path; preserve provider delays and offline sessions as open; route device handoff without device-loss procedures; record exceptions and residual risk; communicate closure to authorized roles; and schedule follow-up.

Record one result for each access path

1. Path and time band: non-secret category/reference; before, at or after.
2. Expected result and owner: bounded authorized outcome and responsible role.
3. Dependency and continuity: necessary approval, provider behavior and surviving access.
4. Evidence and observed result: what was actually inspected; distinguish reported completion from pending or contradicted evidence.
5. Open issue and next check: residual risk, escalation owner and next review trigger.

This is a quick view of the detailed record below. Keep authority, effective time and timezone, communication limits and closure responsibility with the full record; this summary does not authorize any account action.

Keep every access path visible

Use generic categories only: individual work identities; password-manager membership; MFA authenticator and recovery-authority references; administrative identities and privilege; shared, delegated, brokered, or controlled-shared access; sessions and provider-dependent tokens without values; automation, integrations, forwarding, delegation, and ownership transfers; and business-owned device handoff as a reference only.

Unknown SaaS, personal devices, offline sessions, cached access, provider delays, undiscovered automation, retained copies, and data ownership remain residual risks. Known rows being complete does not prove complete discovery.

Stop before continuity loss or destructive handling

Stop and escalate when:

• authority or effective time is unclear or contradictory;
• an action may remove the last administrator, recovery authority, financial approver, production operator, root access, or essential business path;
• a personal device, disputed ownership, legal hold, records retention, privacy, surveillance, employee communication, or data-ownership question is involved;
• the departure is contentious, evidence is missing, compromise is suspected, or an incident is active;
• an action may delete data, transfer ownership, wipe a device, rotate a shared secret, invalidate recovery, or interrupt production;
• provider behavior, offline sessions, automation, or revocation evidence cannot be established safely.

Use Blocked — authority unclear, Blocked — last administrator, Blocked — legal or records review, Blocked — incident path required, Deferred — provider delay, or Unknown — follow up. Do not replace a blocked high-risk item with an easier task and then declare completion.

Break-glass is only a dependency here. This checklist does not create, configure, reveal, test, remove, or rotate an emergency-access path.

Route device loss and incidents by trigger

Device-loss guidance is triggered by loss or theft and owns containment, remote-management decisions, evidence preservation, and recovery for that trigger. The offboarding checklist records only an authorized device-handoff dependency. A missing device changes the trigger and routes to device-loss or incident guidance; do not wipe, inspect, search, or recover it here.

Incident roles and trigger-specific runbooks own incident-wide accountability, communications, evidence preservation, containment, and recovery. Suspected compromise, malicious activity, missing evidence, or an active incident stops routine offboarding. The offboarding checklist is not an incident playbook.

Related access decisions

See password-manager rollout and recovery planning for ordinary credential migration, recovery readiness, adoption and legacy-storage decisions. The offboarding checklist may coordinate authorized membership removal or transfer under the approved pattern; it does not run a rollout, move credentials, export a vault, execute recovery, or delete legacy material.

See MFA methods and recovery tradeoffs for method properties, fallback, accessibility and replacement. The offboarding checklist may reference separately authorized authenticator removal or recovery-authority change; it does not choose a method, perform recovery, reveal material, or improvise replacement.

See administrator-account separation for privilege, elevation, backup and steady-state exceptions. The offboarding checklist consumes that map; it does not redesign roles, rescore privilege, or create an administrator without separate authority and continuity review.

Use shared-login alternatives and their limits to decide whether sharing is eliminated, individualized, delegated, brokered, controlled or exceptionally retained. The offboarding checklist applies that pattern; it does not reveal or rotate a shared secret or rerun the six outcomes. Do not claim a person’s access is removed when the shared credential remains usable through an unresolved path.

Detailed offboarding record

Use one block per target access path, not a wide table.

1. Authorized departure trigger reference — a controlled non-secret reference to the authorized instruction that offboarding must occur. Confirm the authorized request, effective time and timezone, scope, confidentiality boundary, coordinator, executor roles, backup, closure authority, and escalation. Do not record the departure reason.
2. Effective access-end time and timezone — supplied by authorized leadership, never inferred by the checklist.
3. Confidentiality and communication boundary — authorized roles and channel category; no message content. Record owners, backup, authorized communication channel, evidence locations, exception authority, provider dependencies, and stop conditions. Preparation is not execution.
4. Internal coordinator and closure authority — roles accountable for coordination and residual-risk acceptance.
5. Authorized executor and backup/escalation role — who coordinates or later executes, with authority and backup coverage; naming a role does not create competence or authority.
6. Non-secret person-role and target access reference — role plus invented or controlled reference; no identity or account ID. A non-secret identity, authenticator, session, privilege, shared-access, automation, or device-handoff reference.
7. Access-path category and privilege/business impact — generic category and interruption consequence.
8. Source inventory and rollout, MFA, administrator-account and shared-login decision references — non-secret references and any missing input. Consume existing non-secret inventory and rollout, MFA, administrator-account and shared-login decision references. Include identities, authenticators, sessions, privileges, shared paths, automation, delegation, integrations, and device handoff as categories. Mark unknown SaaS and incomplete inputs visibly.
9. Time band — before, at, or after the effective time.
10. Expected bounded action or handoff — outcome category only; no platform instruction. The bounded result plus rollout, MFA, administrator-account and shared-login decisions or provider dependencies, not a command. Record the expected authorized result for each path without commands, secrets, hands-on claims, or destructive instructions. Keep unsupported session, token, automation, and provider behavior explicit.
11. Continuity, surviving administrator, and interruption check — surviving authority, backup, and stop threshold. Preserve a surviving authorized path. Stop before last-administrator lockout, loss of recovery authority, interruption of financial or production work, or an action whose ownership is unclear.
12. Provider, offline-session, automation, device, or recovery dependency — unknowns remain visible.
13. Non-secret evidence required and evidence location — what will be inspected and where its controlled reference exists. Non-secret evidence actually inspected, separate from a report that work occurred.
14. Observed result and evidence strength — inspected, reported, pending, unknown, or contradicted. Separate reported completion from inspected evidence. Keep provider delays, offline sessions, shared-credential uncertainty, missing inventory, personal-device dependencies, and unresolved automation open with owners and escalation.
15. Exception, blocked, deferred, or unknown reason, and residual risk — reason, owner, expiry or retry where applicable. Completed, blocked, deferred, exception, or unknown, with reason and escalation.
16. Escalation destination and required decision — role or qualified-help category, not personal contact data.
17. Closure state and unresolved follow-up owner — truthful closure or named role for open work. Who accepts residual risk, what remains open, and when the record reopens. Record accepted residual risk, surviving ownership, unresolved items, closure authority, and next review. Do not close the checklist merely because the effective time has passed.
18. Next review, retry, or exit trigger — provider response, evidence result, discovered access, returned/missing device, role change, incident, or contradiction.

States include Prepared — not yet effective, Completed — evidence inspected, Reported complete — evidence pending, Blocked — authority unclear, Blocked — last administrator, Blocked — incident path required, Deferred — provider delay, Unknown access — follow up, Exception — owner and expiry required, and Closed with residual risk accepted. They are workflow labels, not proof of complete discovery or revocation.

Completed — evidence inspected is different from Reported complete — evidence pending. Provider confirmation, an administrator’s report, and independently inspected state are different evidence types. A message that says done is not automatically completion evidence.

Fictional example — do not copy as a completed offboarding record

Example Co. is preparing for an invented departing support role with the synthetic effective time Day 0, 17:00, Example Time. No person, account, employment fact, provider, device, credential, incident, or real timestamp is represented.

1. Authorized departure trigger reference: Synthetic authorization A-01; reason not recorded.
2. Effective access-end time and timezone: Day 0, 17:00, Example Time; invented and supplied, not inferred.
3. Confidentiality and communication boundary: Authorized operations and leadership roles — controlled channel category.
4. Internal coordinator and closure authority: Operations lead coordinates; Business owner accepts residual risk.
5. Authorized executor and backup/escalation role: System administrator role; backup coverage is incomplete.
6. Non-secret person-role and target access reference: Departing support role — ExampleDesk membership S-01; no identity.
7. Access-path category and privilege/business impact: Individual support membership — business-hours continuity; privileges remain bounded by the administrator-account guide.
8. Source inventory and rollout, MFA, administrator-account and shared-login decision references: Inventory incomplete; rollout membership, MFA authenticator, administrator privilege and shared-path decision references remain visible.
9. Time band: At effective time; related preparation and evidence checks also appear in the before/after bands.
10. Expected bounded action or handoff: Separately authorized membership removal expected; no command or action occurs here.
11. Continuity, surviving administrator, and interruption check: Blocked — last administrator for an invented administration path until backup is confirmed.
12. Provider, offline-session, automation, device, or recovery dependency: Deferred — provider delay for session confirmation; device handoff recorded without device-loss procedures.
13. Non-secret evidence required and evidence location: Membership-state evidence — controlled reference E-01; no screenshot or identifier appears.
14. Observed result and evidence strength: Completed — evidence inspected for the fictional individual membership only; shared and offline paths remain unproven.
15. Exception, blocked, deferred, or unknown reason, and residual risk: Unknown access — follow up; incomplete SaaS input and shared-path uncertainty remain.
16. Escalation destination and required decision: Business owner and qualified administrator; determine continuity before the blocked path changes.
17. Closure state and unresolved follow-up owner: Open — operations lead; provider delay, the shared-login decision dependency, and inventory reconciliation remain.
18. Next review, retry, or exit trigger: provider response, backup confirmation, discovered SaaS, returned or missing device, evidence contradiction, or suspected compromise.

The example exercises all three bands: preparation before Day 0, the expected at-time membership result, and after-time evidence reconciliation. Its closure remains open. It performs no offboarding and does not claim the provider, shared path, session, device, or inventory is resolved.

Know what completion means

A row is complete only when authority, timing, target, dependency, expected action, evidence, observed result, continuity, exception/escalation, and follow-up are truthful. The overall checklist closes only when every in-scope row is complete or visibly blocked, deferred, or excepted with an owner and next trigger; a surviving authorized path exists; and closure authority accepts the recorded residual risk.

Closure does not prove complete discovery, provider-side revocation, session invalidation, device return, absence of retained data, successful recovery, evidence preservation, legal compliance, or security. Reopen on discovered access, provider response, failed evidence, a returned or missing device, ownership change, suspected compromise, or contradiction.

The NCSC Cyber Assessment Framework discusses access review and revocation when rights are no longer needed, in its essential-functions context. It does not establish a universal small-business deadline. The record and closure criteria are PlainFort editorial choices.