My IT ButlerVisit Website →
← Back to blog

Audit Ready IT Offboarding Checklist for Australian Teams

September 10, 2026
Audit Ready IT Offboarding Checklist for Australian Teams

The single highest-priority action in any IT offboarding checklist is blocking sign-in at the identity provider and force-signing-out active sessions, before anything else happens. That one move shuts down token-based access that outlives a password reset. Everything after it, from device wipes to licence reclaims, follows a set order below in a copy-ready checklist and template, with each step tied to a named owner and a timestamp so you have evidence if an auditor ever asks.

TL;DR:

  • Revoking identity provider access and force-signing out active sessions are the critical first steps to prevent token-based access that survives password resets.
  • Ensuring immediate session termination and token revocation within the first hour of exit is essential, especially for involuntary departures, to reduce security risks.
  • Verifying completion of SCIM cascades, manually removing non-SCIM app access, and stripping users from all groups and permissions prevents lingering permissions.
  • Revoking OAuth tokens, API keys, and deauthorizing third-party integrations address continuity gaps often overlooked in standard offboarding.
  • Gathering timestamped proof of device wipes, license reclaims, and access revocations supports audit compliance and helps identify missed steps early.
Myitbutler
Keep IT Offboarding Audit Ready
Myitbutler provides remote IT support, ongoing supervision, and strategic coordination for distributed teams managing complex offboarding requirements.
Explore remote IT support

Table of Contents

IT offboarding checklist and templates you can copy today

A good IT offboarding checklist isn't a static PDF you glance at once a quarter. It's a working document, structured by timing, that someone actually fills in as they complete each task. Vendor guides that structure offboarding by a "T-timeline" (first hour, day-of, week one to two, closeout at 30 days) tend to produce far fewer missed steps than a flat, unordered list.

Here's the phase structure to paste into a spreadsheet, Google Sheet, or ITSM ticket template:

  1. T-minus (before the exit is public) — HR confirms departure date and type (voluntary, involuntary, redundancy); IT pre-stages revocation scripts; manager confirms data handover needs.
  2. Day-of (hour zero to hour one) — Block IdP sign-in, force sign-out, revoke MFA and VPN.
  3. T+1 to T+14 — Cascade through SaaS apps, OAuth grants, groups, and device recovery.
  4. T+15 to T+30 — Licence reclamation, mailbox conversion, audit evidence compiled and filed.

Every single line item in every phase needs four fields, no exceptions:

  • Owner — the named person (not "IT team") who executed the step.
  • Timestamp — the exact date and time the action was completed.
  • Outcome — confirmed, failed, or not applicable, with a one-line reason if it's not "confirmed."
  • Proof — a log ID, screenshot URL, or ticket reference an auditor could pull up cold.

If you're running this through an ITSM tool like Jira Service Management or Freshservice, build it as a checklist-type sub-task template attached to the offboarding parent ticket, so each sub-task carries its own owner field and closes with a mandatory comment. A minimal example ticket might read: "Sub-task: Revoke Salesforce OAuth grant — Owner: J. Nguyen — Completed 14:32 AEST — Outcome: confirmed — Proof: Salesforce audit log entry #48213." That level of detail is what turns a checklist into audit evidence rather than a to-do list nobody checks.

What happens in the first hour of IT offboarding?

The first sixty minutes decide whether the rest of the process is a formality or a scramble. For involuntary exits especially, sequencing matters more than speed for its own sake.

  1. Disable the IdP account and force sign-out across all active sessions. This is the step that actually matters, because it kills SSO-based access to everything downstream in one action rather than dozens.
  2. Revoke refresh tokens, hardware MFA keys and VPN access. Do this before the departing employee is notified for any high-risk involuntary termination, since a password change alone won't invalidate a live refresh token.
  3. Log who ran each action and where the evidence sits. Note the log ID or session-revocation record right then, not from memory an hour later.

Getting the order wrong is common. Teams often reset the password first and consider the job done, not realising session-block at the identity provider stops token-based access that survives a password reset entirely. If you're unsure whether your current authentication setup even supports instant session revocation, it's worth a proper look at your identity provider configuration before you need it in a hurry.

How do you handle identity, groups and SSO cleanup?

Blocking the IdP account handles the front door. What it doesn't always handle is every room behind it.

  • Verify SCIM cascades actually completed. Modern IdPs that support SCIM provisioning will deprovision connected apps automatically, but not every app in your stack supports it, so check the deprovisioning log rather than assuming success.
  • Document every non-SCIM app per user. Keep a running list, per employee, of apps that require manual removal, updated at onboarding so offboarding doesn't start from zero.
  • Handle admin-console-only apps manually. Some tools (certain finance or design platforms) only allow user removal through a native admin console, not through the IdP at all. Log into each one directly and remove the account.
  • Strip the user from every group, role and permission set, not just their primary account, and log each removal with a timestamp. Orphaned group memberships are one of the most common ways departed staff retain quiet access for months.

This is where applying least privilege from day one pays off. Managing access tightly at onboarding reduces the offboarding workload later, because there are fewer groups and permissions to hunt down and strip out.

What about SaaS tokens, API keys and OAuth grants?

Modern offboarding fails most often here, not at the IdP. A departing employee's personal Google or Microsoft account might still hold an OAuth grant into your CRM, your file storage, or your CI/CD pipeline, and that access has nothing to do with their corporate password.

  • Pull the OAuth grants report from your identity provider or from each major SaaS platform's admin console and revoke anything tied to the departing user.
  • Inventory API keys, service accounts and CI/CD secrets the person had access to or created, and rotate or decommission each one rather than assuming they're generic.
  • Check developer and third-party integration accounts separately. Engineers frequently hold personal API keys in GitHub Actions, AWS IAM, or Terraform Cloud that a standard offboarding script won't catch.

Pro Tip: Search your secrets manager (Vault, AWS Secrets Manager, or even a shared password vault) for the departing employee's name or username before you close the ticket. If their name shows up as the "created by" field on a live secret, that secret needs rotating, not just noting.

How do you recover devices and wipe them remotely?

Device recovery is logistics as much as security, and it's where offboarding checklists most often stall for remote and distributed teams.

  1. Track return logistics and update the asset register the moment a courier tracking number exists, marking status as "in transit," "received," or "unrecoverable."
  2. Trigger MDM unenrolment or a remote wipe through your device management platform the moment the device is confirmed out of the employee's possession, and save the wipe certificate as your proof.
  3. Have a documented fallback for devices that never come back. Remote wipe still works on a lost or stolen laptop if MDM enrolment was active; if it wasn't, escalate to a formal data-breach risk review rather than writing it off. Expats and long-term remote hires are especially prone to "the laptop's still in another country" delays, so tightening up device-recovery processes for scattered teams before you need them matters more than it sounds.

How do you transfer data and reclaim software licences?

Getting the person out of your systems is only half the job. Getting their data and their paid seats back is the other half, and it's the phase most likely to get skipped once the "security" boxes are ticked.

  • Decide the mailbox's fate deliberately — convert to a shared mailbox, archive it with a retention note, or forward to a manager for a defined period, and record which option you chose and why.
  • Transfer Drive or OneDrive ownership for every file and folder the departing employee owned, not just the ones a manager remembers, and reassign shared repositories to a named successor.
  • Reclaim every paid licence seat (Microsoft 365, Slack, Adobe, Salesforce, whatever the stack includes) and confirm the change with the vendor's billing contact so you're not still paying for a seat nobody's using. This is also the point to double check cross-border data continuity if the departing employee worked with data subject to a different country's retention rules.

How should privileged and admin accounts be offboarded?

Treat any privileged-user exit as a security event, not a routine HR ticket. Guides that focus specifically on admin departures consistently recommend a faster, more paranoid playbook than a standard offboarding run.

  • Rotate every shared password and vault credential the departing admin had access to, and revoke their vault permissions directly, don't just wait for the IdP cascade.
  • Rotate API keys and service-account credentials tied to their identity, even ones that look automated or "system-owned."
  • If the departing person was a domain admin, flag KRBTGT account hygiene for review and pull the last 90 days of privileged-account activity logs for a manual check.
  • Assign one named person as verification owner and schedule a follow-up check, not just a one-time sign-off.

Pro Tip: Never let the departing admin's own manager be the sole verification owner. Use someone from security or a second IT admin, so the person checking the work has no conflict of interest in signing it off quickly.

What evidence do auditors expect after offboarding?

ISO 27001 and SOC 2 auditors don't take your word for it. They sample former employees at random and ask for proof, and that proof needs to be timestamped, not reconstructed from memory.

  • Timestamped revocation logs from the IdP and every major SaaS platform touched.
  • Licence removal confirmation, ideally with a billing statement or vendor email attached.
  • A device-wipe certificate from your MDM platform.
  • The completed checklist itself, with owner and timestamp fields filled for every row, no blanks.

Two metrics are worth tracking monthly rather than just checking at audit time: same-day revocation rate (the percentage of exits where IdP access was disabled the same calendar day) and 14-day asset return rate (devices physically back in hand within two weeks). A 2023 study by Beyond Identity found 89% of former employees still had access to at least one corporate application after leaving, which is precisely the gap these two metrics are designed to catch before it becomes a breach. Run a 30/60/90 day check for sign-in attempts against disabled accounts, too, since a spike there usually means a missed group membership or a forgotten personal device.

A trusted IT support partner's perspective: running offboarding for distributed teams

Coordinating an offboarding run across four time zones is where checklists usually fall apart, because the person who should revoke a Manila-based SaaS licence is asleep when the Sydney manager sends the ticket. Managed support closes that gap by keeping evidence capture consistent regardless of who's awake when the exit happens.

Bring in outside support specifically for privileged exits, large redundancy rounds, or anything touching cross-border data. If your team would rather hand the operational load to someone else entirely, book a consultation and talk through what a managed offboarding run would look like for your setup.

— Thomas

Managed offboarding runs from a specialized remote IT support provider

A practical alternative to building an in-house offboarding runbook from scratch is to use a ticketed offboarding run with evidence capture built in from the first step.

Myitbutler

A managed run covers the full sequence: identity provider lockout, SaaS and OAuth grant cleanup, remote device wipe, and privileged-account rotation, with every step logged against an owner and a timestamp the way auditors expect. Pricing is fixed and there's no long-term contract, so a one-off privileged exit or a redundancy round doesn't lock you into an ongoing subscription you didn't ask for. If your business runs on passwordless authentication or is weighing a switch, that setup also simplifies offboarding considerably, since there's no password to reset in the first place, just a session to kill.

If your next departure involves a system administrator, a redundancy round, or staff spread across several countries, book a free consultation and Myitbutler will walk through what a managed offboarding run looks like for your specific stack.

Sources

FAQ

What is an IT offboarding checklist?

It's a structured, phase-by-phase list of security and administrative tasks (access revocation, device recovery, data transfer, licence reclaim) completed when an employee leaves, with each step tied to a named owner and a timestamp for audit purposes.

What should be included on an IT onboarding checklist?

An onboarding checklist should apply least privilege from day one, granting only the access, groups and licences a role genuinely needs, because narrower access at hire directly reduces the scope of work at offboarding.

What are the 5 C's of employee onboarding?

Definitions of onboarding frameworks vary widely across HR sources, and no single "C" model is consistently referenced in IT security guidance, so it's not a framework this checklist relies on.

What are common offboarding mistakes?

The most common mistakes are resetting a password instead of revoking the IdP session and active tokens, missing non-SCIM apps that don't deprovision automatically, and skipping licence reclamation entirely, which leaves you paying for seats nobody uses.