Employee Offboarding Evidence Checklist for Lean IT Teams

An employee offboarding evidence checklist is a structured record of what was checked, changed, reviewed, and left open when someone leaves — proof that their access was handled. It is deliberately separate from the act of handling it: the checklist proves offboarding happened; it does not perform offboarding. The actual disabling of accounts happens in each underlying system, by a person; the checklist is where you record that each step was done, when, and by whom.

That separation is the whole point, and it keeps a lean IT team honest. You can run a flawless offboarding and still fail the only test that comes later — "show me it was handled" — if nothing was recorded. This is the evidence half of having access under control, and what a people and accounts register is well suited to hold.

The Critical Distinction: Offboarding Actions vs Offboarding Evidence

These are two different things, done in two different places, and conflating them is the most common offboarding mistake:

| Dimension | Offboarding action | Offboarding evidence | |---|---|---| | What it is | Actually disabling or removing access | The dated record that it was done | | Who or what does it | A person, in each system's own admin console | A person, recording it in a register | | Where it lives | Google Workspace, the SaaS tool, the finance app | The people & accounts register and reports | | What it proves | Nothing on its own — it leaves no record | That offboarding was handled, and what remains open | | CertPilot's role | None — CertPilot does not act on accounts | This — CertPilot records the evidence |

Read the right-hand column carefully: everything CertPilot touches is a record. The left column — the operational work of changing access — happens in the systems themselves, performed by your team. A register does not reach into those systems. Keeping the two columns distinct is what makes the rest of this checklist safe to follow.

Why Offboarding Evidence Gets Missed in Lean IT Teams

In a small team, offboarding usually happens — the accounts do get disabled. What goes missing is the record that it happened, for predictable reasons:

• It feels redundant in the moment. Whoever disabled the account knows it is done, so writing it down feels like overhead — until months later when no one can prove it.
• The accounts were never fully listed. Without a current record of what a leaver held, "did we get everything?" has no answer, and a forgotten account lingers.
• The proof lives in scattered places. A console screenshot here, a chat message there — nothing dated, owned, and in one place.

The cost shows up at the worst time: a security questionnaire, an insurer's checklist, or an incident where someone asks whether a former employee still had access. At that point, "we always handle it" is an assertion; a dated record is proof — and recording it as you go is far cheaper than reconstructing it under pressure.

What Evidence to Record Before the Employee Leaves

Offboarding evidence starts before the last day. Ahead of departure, record:

• That the person is leaving — mark their status offboarding and set an end date, so the upcoming change is visible and dated.
• Every account they hold — confirm the list of their accounts is current, so nothing is offboarded from memory. The fields that make each account record reviewable matter most here.
• Any exceptions to plan for — shared mailboxes, license seats to reassign, or data to transfer, captured in notes so they are not discovered late.

This pre-departure pass turns the leaving date from a scramble into a worked list.

What Evidence to Record on the Leaving Date

On the day access actually changes, the evidence to capture is the disposition of each account — what was decided and done, in its own system, recorded against the person:

• Mark each account's status as the change is made in its system — for example disabled, pending_removal, or deleted — with the status-change date.
• Note any account deliberately retained, with the reason and a review date (a contractor's handover login kept for a week, say).
• Update the person's status to left once the planned changes are made.

The wording matters: you are recording that an account was disabled in its system, not asking CertPilot to disable it. The register holds the disposition; the system holds the act.

What Evidence to Record After Access Changes Are Completed

Offboarding evidence is finished not when the last account is changed, but when the record is complete and confirmable:

• Confirm nothing is left active unintentionally — check that each of the person's accounts has a recorded disposition, not a blank.
• Record who actioned and who reviewed — the person who made the changes and, ideally, a second who confirmed them.
• Log remaining open items — anything still pending (a license to reclaim next cycle) with an owner and a date, so "open" is tracked, not forgotten.

A worked example: a leaver is set to left with an end date; their three accounts are listed; each is marked disabled with its date; and that same record surfaces in the next access review as proof the offboarding held. None of it requires CertPilot to touch a system — only to record what your team did.

How Account Ownership Helps Offboarding Evidence

Offboarding is far easier to evidence when accounts already have owners. Because each account is attached to a person, marking that person offboarding turns their account list into a ready-made offboarding worklist — there is no hunt for "what did they have?" This is the everyday payoff of account ownership tracking: the ownership you maintain in normal operation becomes the leaver checklist automatically.

Shared and service accounts are the exception ownership handles best. An account owned by "everyone" is the one most likely to be missed at offboarding; one with a single named responsible owner is not. Recording an owner for shared logins ahead of time is what keeps them on the checklist when someone leaves.

How People & Accounts Records Support Access Reviews

Offboarding evidence and access reviews reinforce each other. A periodic access review is where lingering access gets caught — a missed account shows up attached to a person marked left. The offboarding record makes the review faster; the review catches anything offboarding missed. Together they form a loop: offboarding records the intended dispositions, and the review confirms they held.

This is the checks + registers → evidence reports model applied to leavers — internal records holding what no external scan can see, surfacing later as real governance evidence.

What Not to Claim or Store

Offboarding evidence is powerful precisely because it stays narrow. Do not overstate it, and do not overfill it:

• Do not claim the record removed the access. It documents that access was changed in each system; it is not the mechanism that changed it.
• Do not store credentials. Passwords, recovery codes, and secrets never belong in an offboarding record. Record that an account was disabled, never how to log into it.
• Do not store sensitive HR detail. Why someone left, performance notes, or disputes belong in the HR system, not the account record — see register vs HRIS, MDM, and spreadsheets for that division of labor.
• Do not imply certification. A complete offboarding record is governance evidence; it is not a certification or an audit guarantee.

How CertPilot Fits — With Strict Boundaries

CertPilot's People & Accounts register is built to hold offboarding evidence: mark a person offboarding or left with an end date, record each account's disposition and status-change date, and carry that into access reviews and the cross-module evidence reports, where People & Accounts appears as summary counts, not names. The sample reports gallery shows the artifacts, and management-ready evidence reports explains how to frame them for leadership.

What it does is record. What it does not do is the boundary that keeps this honest:

• It does not perform offboarding, and it does not remove, revoke, disable, close, or deprovision access. Those actions happen in each system, performed by your team; the register records that they were done.
• It does not discover accounts automatically or sync with Google Workspace or Microsoft 365 today. The records are customer-maintained.
• It does not monitor employee activity or scan email, documents, chats, or files.
• It is not a certification or an audit guarantee. It supports internal governance routines and evidence preparation.

A Practical First Version for a Lean IT Team

You can put a defensible offboarding evidence routine in place without new tooling:

1. Adopt a three-stage habit — before, on, and after the leaving date — using the table below as the prompt for what to record at each stage.
2. Start from the account list. If a leaver's accounts are not already recorded, that gap is the first thing to fix for the next departure.
3. Record dispositions as you make them, in their own system, marking each account's status and date in the register as you go.
4. Have a second person confirm the record is complete, and log anything still open with an owner.
5. Check it in the next access review, so the offboarding record is verified, not just filed.

| Stage | Evidence to record | Why it matters | Example record | |---|---|---|---| | Before leaving | Person marked offboarding, end date, full account list, planned exceptions | Turns the leaving date into a worked list, not a scramble | "J. Doe — offboarding, end date 2026-06-30; 3 accounts; transfer shared inbox" | | On the leaving date | Each account's disposition and status-change date; person marked left | Captures what was done, when, in each system | "CRM account — disabled 2026-06-30; person set to left" | | After access changes | Confirmation nothing is unintentionally active; who actioned/reviewed; open items | Makes the record complete and confirmable | "Reviewed by M. Lee 2026-07-01; 1 license reclaim open, owner IT" |

The first leaver you run this way produces a record you could hand to a skeptical reader — the entire goal.

In Short

• An offboarding evidence checklist records what was checked, changed, reviewed, and left open when someone leaves — proof that access was handled.
• Keep actions and evidence distinct: the act of changing access happens in each system; the record happens in the register.
• Record across three stages — before, on, and after the leaving date — including each account's disposition and dates.
• Account ownership turns a leaver's records into a ready offboarding worklist, and access reviews later confirm it held.
• CertPilot records offboarding evidence; it does not perform offboarding, remove access, discover accounts, sync directories, or monitor anyone.

Frequently Asked Questions

Does CertPilot automatically disable accounts when someone leaves?

No. CertPilot does not disable, remove, revoke, or deprovision access, and it does not connect to your systems to act on accounts. Your team disables accounts in each system's own admin console; CertPilot is where you record that a person is leaving (status and end date) and that each of their accounts was reviewed and marked disabled, with dates.

What counts as proof that offboarding happened?

A dated record showing the person was marked leaving, every account they held was listed, each account's disposition was recorded (disabled, transferred, or retained with a reason), and who actioned and reviewed it. Screenshots alone are weak — undated and scattered; a structured register record is far stronger as proof.

How do I handle shared or service accounts at offboarding?

Record a single named responsible owner for each shared mailbox or service account ahead of time, so they appear on the checklist when someone leaves. At offboarding, record the disposition — reassigned, password rotated in its own system, or retained with a reason — rather than letting a "no individual owner" account fall through.

How long should I keep offboarding records?

Keep them as long as you may need to demonstrate the offboarding — typically aligned with your review cadence and any internal retention policy. Because the record holds operational facts (statuses, dates, dispositions) and never credentials or sensitive HR detail, it is low-risk to retain as a governance trail.

Does this connect to my email or directory?

No. The register does not sync with Google Workspace, Microsoft 365, an identity provider, or any directory, and it does not discover accounts automatically. It reflects exactly what your team records or imports by CSV — it is customer-maintained by design.