How to offboard access without losing the work

Start with an authorized departure event and a clock

A team member leaves while they own a shared inbox, approve a pending request and authorize a scheduled workflow. Disabling their main login is necessary, but it does not answer who inherits the inbox, whether an app session still works or who stops tomorrow’s reminder. Treat this as one coordinated case with several independently verifiable outcomes.

Record who is authorized to start the case, the effective access cutoff, the systems in scope and the coordinator who watches every outstanding row. Use a restricted case reference in operational tools; do not copy names, reasons for departure or private account identifiers into the downloadable template. NIST SP 800-53 AC-2 addresses account management and PS-4 addresses disabling access, revoking authenticators, retrieving property and retaining access to information formerly controlled by a departing person. The organization must set its own timing and follow its applicable policy.

Separate the urgent access cutoff from later cleanup. A hold on deleting an account must never be read as permission to keep the person signed in. Conversely, a disabled account is not proof that records have a new owner or that automation has stopped.

List the routes in, then the work that depends on them

Inventory the identity provider, direct app logins, groups, privileged roles, devices, physical credentials, active sessions, OAuth grants, personal access tokens and locally issued credentials. For each system, name the administrator who can act and the verifier who can inspect the result. Do not assume a single sign-on change reaches an app that allows direct login or keeps its own session.

Next list records and processes the person controls: files, mail, calendars, open approvals, assigned tasks, customer handoffs, scheduled sends, webhooks and integrations. Mark whether each dependency needs transfer, cancellation, replacement or a deliberate hold. A shared credential or service account needs its own owner and impact check. If the departing person knows a shared secret, pause its consumers and revoke or rotate the old credential at the cutoff using the provider’s supported control; test a replacement before resuming the job, with a manual fallback if continuity is not possible. The connection-access guide owns one automation connector’s grant lifecycle, including its scope, replacement and provider-side revocation. This guide owns the whole person-departure case across accounts, records and queued work, with a cross-system completion gate.

• Access route: provider, identity or grant type, resource boundary, action owner and actual revocation method.
• Business dependency: record or queued action, intended successor or stop decision, prerequisite and safe hold.
• Evidence: provider result, target-state check, time, verifier and unresolved limitation, stored in a restricted case record.

Block sign-in, revoke sessions and remove app access

Have the authorized administrators block new sign-in and disable the relevant accounts at the agreed cutoff. Then use each provider’s supported controls to revoke refresh tokens or sessions, remove app assignments and direct logins, revoke personal tokens and remove privileged roles. Retrieve or disable devices and physical credentials under the organization’s procedure. Record the actual provider response and check the target state rather than treating a submitted request as completion.

Microsoft’s former-employee procedure separates password reset, session sign-out and blocked sign-in, and warns that blocking sign-in can take up to 24 hours to take effect. Its Entra guidance warns that existing access tokens and app session cookies may continue until expiry or until the application acts; synchronization and continuous access evaluation differ by app. OWASP says a server must invalidate a session, since deleting a browser cookie alone cannot invalidate a copied session ID. Plan provider-specific containment at the cutoff, then an app-specific check for remaining sessions and a safe denied-access test where the provider permits one.

If immediate revocation cannot be proved, mark the row “blocked: residual access possible,” record the known window or unknown, escalate to the security owner and apply supported compensating controls. Do not write “all access removed” merely because the identity provider shows disabled.

Preserve needed records before account deletion

A successor may need an open case, shared mailbox, calendar booking or file, while a retention rule may require other material to be held or erased. Have the record owner decide what must move, who may receive it and where the authoritative copy will live. Complete the approved transfer and test successor access before deleting the source account or releasing a license that affects data access. Never make a personal account the permanent archive.

Microsoft 365’s former-employee sequence explicitly treats mailbox and OneDrive access as decisions to make before deletion. Its deletion guidance warns that email should be moved before deletion and describes product-specific recovery periods; those periods are not a universal safety net. Ask the records or legal owner about preservation holds before destructive steps. Where UK data-protection rules apply, UK GDPR Article 5 limits identifiable personal-data retention to what is necessary for the processing purpose, subject to its stated exceptions. Decide and review retention for each record category rather than keeping all departing-person data indefinitely “just in case.”

Use a hold state when ownership, legal preservation, privacy or export completeness is unresolved. The hold applies to deletion or transfer, while access revocation proceeds. Record the decision and review date, then revisit the hold; an unowned indefinite hold is not a completed offboarding case.

Cancel or reassign work already in motion

Search the task queue and each connected tool for scheduled sends, reminders, recurring jobs, open approvals, webhook subscriptions and actions awaiting a retry. Decide whether each should be cancelled, reassigned or rerun under a new authorized identity. Disabling the old account may cause a job to fail, but it does not prove that a queued customer message was withdrawn or that a retry will not run later.

For every affected action, write the prerequisite and stop rule. Before a reminder or send executes, the workflow should check the current case and task state, intended recipient and authorization. A cancellation receipt proves only that a cancellation was accepted; inspect the scheduler or destination for the final state. If that item cannot be cancelled, use a supported technical pause of its schedule, workflow or destination before the next run and verify the pause. A note marked “manual hold” cannot prevent an automatic send. If no effective stop is available, escalate the uncontrolled-send risk immediately and keep the case open.

Keep the business decision separate from connector repair. The notification-design guide covers channel and delivery state, and failure recovery covers uncertain retries. The onboarding guide maps the opposite journey after an accepted engagement; it does not decide who inherits records and access when a person leaves.

Use the dependency and evidence matrix

Download the CSV above. Its first data row is blank; the remaining rows are a clearly hypothetical departure from a fictional equipment-service team, including an unresolved session and a records hold. They are planning examples, not Kinetivy client work, executed tests or a recommended deadline. Make one row per independently checkable access route or dependency. Keep the live copy in an access-controlled location: even a secret-free inventory can reveal sensitive operations.

The matrix links each action to a case stage and prerequisite. “Blocked sign-in” can close before “transfer needed records,” but “delete account” waits for an approved retention and transfer decision. A verifier checks the target state and records an evidence reference, not a raw token, private file or screenshot containing personal data. Make the review owner and next check explicit for any hold.

• Work item and target state | Trigger and cutoff | System and access or record type | Accountable owner and deputy | Prerequisite and safe hold | Allowed action | Downstream job or record dependency | Stop or successor decision | Evidence to inspect | Verifier and status | Exception and next check | Retention or privacy decision.
• Use “pending,” “blocked,” or “verified” only for the specific row. Do not collapse a provider acknowledgment into a verified outcome.
• Store actual names, account IDs, case links and evidence in an authorized operational system, not in a public download or general analytics.

Hypothetical rehearsal: a service coordinator leaves

Imagine a fictional equipment-service coordinator who holds a personal app login, an active session, ownership of a shared service calendar and approval of a scheduled reminder. At the authorized cutoff, the identity administrator blocks sign-in and the app administrator revokes the app’s sessions and direct login. The verifier checks both systems. If the app cannot confirm session invalidation, that row remains blocked and the security owner manages the residual risk.

The service owner assigns the open approval to an authorized deputy and cancels the old reminder before its next send. The records owner transfers only the bookings and files needed for continued service, checks the deputy can use them and records a retention decision. Account deletion waits for that check and any preservation hold. The CSV shows these dependencies and an exception row for a shared automation credential. None of these events or outcomes has occurred at a Kinetivy client.

Close the case with evidence, or leave an explicit hold

Rehearse with synthetic identities and tasks before using the process for a real departure. Test a direct app login after identity-provider disablement, a long-lived app session, a queued reminder, a delegated approval, a shared credential and a record that must be preserved. Verify that a failed transfer does not trigger deletion and a failed scheduler cancellation remains visible.

The coordinator closes only after access routes are verified removed, needed work has a successor or stop state, records have an authorized transfer and retention decision, and each row has a dated verifier. Keep the evidence proportionate and restricted. Review the map when systems, roles or retention requirements change. A case with residual access or another unresolved hold stays open with an owner and next check rather than being silently counted complete.