When to delete a former employee's account (and how)

This offboarding system is built on not trusting my memory. The day-of-departure script disabled the account and preserved everything it owned. The access hunt tracked down everything that lives outside the directory. Which leaves the account itself, sitting disabled in a quarantine OU, waiting for the one step in the whole lifecycle you cannot undo. This post is about when to delete a former employee’s account, what has to be true first, and what actually happens when you do.

I have been burned enough to respect this step. Early on I deleted quickly, because tidy felt like done. Every fast delete I have performed came back on me within the month: a calendar someone still needed, a file tree owned by an account that no longer existed. Deletion is not cleanup. It is the deliberate end of a record, and it deserves the same discipline as a records decision, because that is what it is.

Key takeaways

• A disabled account is a paused decision, not a completed one. Decide on purpose, on a schedule.
• My default grace period is 90 days, extended whenever a retention or records question is open.
• The pre-delete checklist is five questions, and “who answers” matters as much as “what’s asked”.
• In a synced environment, deleting the directory account can take a shared mailbox down with it. Check what the object still anchors.
• Deletion destroys the SID. Everything that SID owned becomes an orphan, so reassign ownership first.

Why not just leave accounts disabled forever?

Because in my experience a quarantine OU with no exit becomes a junk drawer, and junk drawers hide problems. Every disabled account is still an object that can be re-enabled by mistake or by an attacker who gets far enough, still appears in audits I then have to explain, and still anchors resources I have stopped thinking about. Disabled is safer than deleted on day one. It is not safer forever.

The honest version is that “keep it disabled for now” is a decision with no owner and no deadline, and this whole system exists because undecided things in a one-person shop quietly become permanent. The fix is the same as always: put the decision on a schedule, in a system, with a checklist.

How long should the grace period be?

Ninety days by default, longer whenever a question is still open. In the day-of-departure post I defined the grace period as the stretch where an account stays disabled but not gone, long enough that you are sure nothing still depends on it. I found ninety days long enough for a monthly process to fail twice and still get caught, and short enough that the quarantine OU stays a queue instead of an archive.

The one thing the grace period must never shortcut is a retention obligation. A records hold is any legal or policy requirement to preserve someone’s data past their departure, and in local government that bar is lower than people expect, because public-records rules reach routine email. Whether a hold applies is not an IT call. I ask, in writing, and an open question pauses the clock. The delete waits on the answer; the answer never waits on the delete.

What has to be answered before the delete?

Five questions, each with a named owner. The account is deletable when every row has an answer in the departure ticket, and not before.

Question	Who answers it
Is there a records hold or open retention question?	Records/legal contact, in writing
Has the data handoff happened (files, mailbox, calendar)?	The departed person’s manager
Does anything still authenticate as this account?	IT, from logs and the access inventory
Does the object still anchor a resource (shared mailbox, delegations)?	IT
Is ownership reassigned (files, groups, app records)?	IT

The third row earns its place. A “user” account that is quietly running a scheduled task or a service is a thing that breaks the day after the delete, and the only way to know is to look: sign-in logs, service accounts audit, the access inventory from the ghost-hunt post.

What survives the delete, and what is gone?

Gone: the SID, and with it every ownership and permission relationship the person had. Files owned by a deleted account show a raw orphaned SID where a name used to be, which is why ownership gets reassigned before the delete, not discovered after. Group memberships, delegations, and the audit trail of “what could this person reach” all end with the object, which is why the day-of-departure script recorded them at disable time.

The near-miss that taught me the anchoring lesson: a mailbox I had converted to shared on departure day was still attached to the synced directory account, and deleting that account would have deleted the shared mailbox with it. In a synced environment the on-prem object is the anchor, and Microsoft documents that a deleted mailbox is only recoverable for 30 days by default. If the mailbox must outlive the account long-term, either keep the account (disabled, unlicensed, excluded from sync cleanup) or move the mail somewhere that does not depend on it. For long-term preservation under a hold, an inactive mailbox retains content without a license or a live account. Decide which situation you are in before the delete, because 30 days after a mistake is not a long time to notice it.

How does delete day actually run?

On a monthly reminder, from a report, never from memory. The report lists every account that has aged past the grace period in the quarantine OU, and each one either gets deleted (checklist complete), gets a documented extension (a question is open), or exposes a stalled process (nobody answered, which is its own finding).

# Accounts that have sat disabled past the grace period. Each row
# is a decision owed, not an automatic delete.
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -SearchBase 'OU=Disabled Users,DC=example,DC=local' `
    -Filter { Enabled -eq $false } -Properties whenChanged, Description |
    Where-Object { $_.whenChanged -lt $cutoff } |
    Select-Object Name, SamAccountName, whenChanged, Description |
    Sort-Object whenChanged

The delete itself stays manual, one account at a time, exactly as the day-of-departure post promised it would. I archive the home folder, note the completed checklist in the ticket, and only then remove the object. The automation’s job ends at putting the account in front of me with its paperwork done. The click is mine.

What broke, and what I would change

The quarantine OU filled up silently, which by now should surprise nobody. For a year I had a grace period policy and no report, so “90 days” meant “whenever I remembered,” and the OU held accounts old enough to vote on their own deletion. The monthly report is what made the policy real. I learned that a policy without a recurring surface to appear on is a wish.

The other change: I now write down why an account was extended, right in its description attribute. Six months later, “still here because of the records question on the audit” is the difference between an informed decision and re-investigating from scratch. Deletion is a records decision, and records decisions get reasons.

FAQ

Should you ever delete a former employee’s account?

Yes, deliberately and on a schedule, once the grace period has passed and the pre-delete checklist is answered: no records hold, data handed off, nothing still authenticating, nothing anchored to the object, ownership reassigned. Disabled forever is not a policy; it is a postponed decision.

How long should an account stay disabled before deletion?

Ninety days is a sane default for a small shop: long enough for monthly processes to surface a dependency twice, short enough to keep the quarantine OU meaningful. Any open retention or records question pauses the clock, and the extension gets documented on the account.

What happens to the mailbox when you delete the account?

In a synced environment, the on-prem account anchors the mailbox, shared or not, and a deleted mailbox is recoverable for only about 30 days. Keep the anchor account if the shared mailbox must live on, or use an inactive mailbox for long-term retention under a hold.

What does deleting an account actually destroy?

The SID, permanently. Every file, permission, and membership tied to that SID becomes an orphan, and no recreated account gets the old SID back. That is why ownership is reassigned and memberships are recorded before the delete, and why the delete is the last step instead of the first.