the hour you have not planned

The token guide gives difficult departures a few lines: suspend first, revoke the grants, force the sign-out, and do not announce anything until the short-lived tokens have expired.

That is correct and it is not enough. This is the rest of that hour.

Before any of it, three things have to be said plainly, because the version of this advice you will find elsewhere is usually written by people selling insider-threat products, and it gets all three wrong.

three things that are true and unwelcome

The decision that matters is made before the conversation, and usually not by you. Whether the technical work runs before the manager speaks, during, or afterwards is the whole question. Most companies default to afterwards because nobody was assigned the question, so it gets improvised on the day by whoever is nearest.

The damage model everybody uses is the wrong one. The canonical hostile-departure story is destruction: somebody learns they are being let go and wipes the servers on the way out. That story belongs to companies with servers in a cupboard. At a company running on a collaboration suite and thirty SaaS tools, the realistic act is copying, and nothing you do in the first hour reverses a copy.

And copying leaves little you can retrieve. How finely file access is logged, and for how long, depends on your plan and your tools. A document that was already synced to a laptop and moved onto a memory stick produces no event in your collaboration suite at all.

So treat the first hour as containment. What you are containing is the second act: continued access after the conversation, re-entry through paths that survive a suspension, and the mail-forwarding rule nobody thinks to look for.

Say that out loud at the start, or this becomes the fantasy it is trying to replace.

before the conversation

Discuss it off-system. Not in chat, not in a document, not in a calendar invitation with a revealing title, not on any surface the person can reach. This is the one instruction in this guide with no caveats.

Name two owners. One runs the human conversation, one runs the technical work. They should be different people. At your size they are usually the same person, which is the most common way the hour goes wrong.

Build the list in advance. Which systems this person touches, split into the ones behind your single sign-on and the ones that are not. The three lists guide gives you the raw material for that split at company level. Turning it into a per-person list is work you do now, because assembling it live is how the hour disappears.

Export the grant list before anything else. Pull the list of third-party applications holding grants for this account, and save it somewhere outside the console. You are going to revoke from that list later, and having your own copy means it does not matter what the console shows once the account is suspended.

Settle the device question. Company-owned and managed, or personal and unmanaged. If it is the second, you have no remote action available and most of what follows gets shorter. Decide now, in writing, who asks for the laptop back and when. If the machine is coming back at all, the ask happens in the conversation itself, by the person having it, and never afterwards by email.

Do not quietly trim their access in the days beforehand. It is visible in-product, it tips the person off, and if the decision changes you have created a fact you now have to explain to somebody who still works for you.

during

This is the genuinely contested step, and it is not settled.

The case for suspending before the manager speaks is that it closes the destructive minute. The case for suspending during or after is that until those words are said the person is an employee, and cutting a current employee’s access can be a contractual problem in several European jurisdictions unless a specific instrument covers it.

One reasonable default, and it is a judgement call: the technical work begins the moment the conversation begins, with both owners on a call together so the gap is seconds. Make that decision with somebody who knows your employment law, in advance, once, so that nobody is deciding it live.

Then, in order:

Suspend, do not delete. Suspension is fast, reversible and unambiguous. Deletion starts a clock: Google lets you restore a deleted user for 20 days, and after that the data is gone. Nothing you need in this hour requires deleting anything.

Then reset the password and sign them out, because suspension may not do everything you think. Suspension stops new sign-ins. Google’s documentation is not explicit about what it does to sessions and tokens already issued to applications, and it says a password change revokes tokens for some Google products. Do all of it: suspend, sign out, reset the password, then work the grant list.

Revoke their third-party application grants, working from the export you took earlier. This is the order the token guide gives, and the export is why you do not depend on the console for it.

Kill the paths that are not browser sessions. Application-specific passwords are listed on the user’s security page in the admin console, and each one can be revoked. Backup codes for the second factor live on the same page, and generating new ones invalidates the old set. A mail client holding an app password does not care that a browser session ended.

Know that you cannot see their mail rules, and plan around it. A forwarding rule or a filter set six weeks ago costs nothing to create and is invisible unless somebody looks, and the admin console has no view of an individual user’s forwarding rules, filters or delegates. The mail guide covers why. Reading those settings for one account means the Gmail API, or signing in as them, and signing in as them is the thing this guide tells you not to do. If the account matters, this is the point where you stop and get somebody who can do it properly. Do not tell yourself you checked.

Check the recovery address and recovery phone. Whatever can restore an account owns the account. A changed recovery address is both a re-entry path and a tell.

the first hour, in order

1. 1beforeTwo owners, a per-person system list, the grant list exported, the device question settled.
2. 2suspendNever delete. Deletion starts a 20-day clock.
3. 3sign out, reset, revokeSessions, password, grants from your export, app passwords, backup codes, recovery details.
4. 4mail rulesNot visible in the console. Get help if the account matters.
5. 5afterTransfer files, catch the automations, rotate what they knew, write everything down.

the hour after

Transfer what they owned. File ownership, calendar, group memberships. Keep the account suspended until that is done.

The automations that ran as them. Scheduled scripts, exports, connected automation tools, build jobs. These either break silently in three weeks or keep running as a departed identity for three years, which is the service accounts guide arriving at the worst possible moment.

Rotate the shared credentials they knew. Rotate them; removing the person is not enough. Anything in a shared vault they could open is now known, and removing their account does not unknow it. The shared vaults guide covers how to find the list. This is the step almost everyone skips and the one that matters most in a hostile case.

The tools that are not behind your sign-on. Top five in the hour. The rest is a week of work, and that is fine.

Preserve the logs, do not read the content. Export what exists to somewhere it will not roll over, and stop. Looking at who did what and when is ordinary administration. Reading what somebody wrote is something else. Do the first, and escalate before the second.

Write down every action and the time you took it. Write it as if a lawyer will read it, because one might.

what not to do in the first hour

Delete the account. Read their mail. Chase the copies, because if they copied it is gone and nothing here retrieves it. Work all forty systems, because you get five. Announce anything, to the team or to customers, which is a separate decision on a separate clock with a separate owner. Confront or accuse, which is a different act performed by a different person. Reset every password in the company, which is theatre unless you know a specific shared credential was exposed, in which case rotate that one. Buy anything.

the line you should not cross alone

This is not legal advice. Three things are worth knowing before the day arrives.

Suspension should never look like an accusation. The defensible position is that access is suspended at every departure, hostile or not, as a standard control. The moment it is applied selectively and described as a security measure about a named individual, you have created an exposure that has nothing to do with security. Make it the default for everyone and the hostile case stops being distinguishable by the control itself.

A person on notice is still an employee. That is a different legal position from a former employee, and cutting access during a notice period may need a documented instrument depending on where you are. Find out what it is called in your jurisdiction now, before the day.

Monitoring is a different category from administration. In several European countries, systematic review of an employee’s activity brings in works councils and data-protection obligations that routine access changes do not. Suspending access is the least contested of these, and even that is worth checking for your country. Reading a mailbox, or reviewing somebody’s logs as an investigation, is further along the same line, and it is where other people stop being optional.

And never log in as them to find out what happened. It contaminates the record and it is very likely a processing act you have no basis for.

the part nobody writes

Most difficult departures are not malicious. The person is angry, or frightened, or humiliated, and in most cases nobody does anything at all.

Designing this hour as though every leaver is out to wipe the servers is how a company ends up treating people who gave it years badly, and how it ends up buying monitoring software it does not need. Writing the sequence down in advance lets you act quickly without acting suspiciously, and it lets you apply the same procedure to everyone. That is the only version of this that is both effective and decent.

There is no good data on any of this for companies your size. The insider-risk cost figures that circulate most widely, such as the annual Ponemon Cost of Insider Risks report produced for DTEX, a company that sells insider-risk monitoring, survey large organisations. A dollar average drawn from companies of thousands of people tells you nothing about two hundred. What you can know is that this hour has an order, that the order matters more than the coverage, and that the worst time to work it out is while somebody is waiting in a meeting room.

Write it down this month. You will use it once, and once is enough.