Drill Offboarding Access Revocation With a Closure Register

Is the handoff ready?

Use these checks before access expands or the first ticket begins.

Inventory the grants before the drill

Start from the identity provider and work outward. Repository access, cloud roles, database accounts, package registry tokens, CI variables, monitoring seats, vendor dashboards, and shared mailboxes all count. A Philippines-based programmer often holds fewer production rights than a local employee, but the vendor seats and tokens are easy to forget.

Record the grant type, the owner, the business purpose, the last used date, and the removal method. If a grant has no owner, that is already a finding worth reporting before the drill.

Include indirect access: a personal access token in a laptop keychain, an SSH key in an agent, a saved password in a browser profile, and a deploy key on a repository. Removal that stops at the identity provider leaves those paths open.

Write the drill ticket and name the stop signal

The ticket names the person, the systems, the start signal, the expected removal time per system, the verifier, and the escalation path. Ask for a timestamped log of each action and a check per grant.

The start signal must be a person and a channel, not a vague date. In a drill, the signal is simulated but the clock is real. In an actual offboarding, the same record applies, which is why the rehearsal is worth the effort.

Keep the first drill to one role and one set of systems. A full identity review across the company is a different project with legal and HR involvement.

Run the drill in the order a real exit follows

Revoke the highest risk access first: production, customer data, source control, and payment systems. Then remove vendor seats and communication channels. Then rotate any shared secret the person could read, and finally close the identity record.

Time each step and record who performed it. The interesting number is not the total, it is the gap between the stop signal and the first revocation, and the gap between the last revocation and the verification.

Test the removal while the account is still present but disabled. A disabled account can be re-enabled by mistake, while a deleted account can hide a lingering token issued earlier.

• Disable the identity and revoke active sessions.
• Remove repository and cloud role bindings.
• Revoke personal tokens, deploy keys, and CI variables.
• Remove vendor seats and shared mailbox access.
• Rotate shared secrets the person could read.

Verify in the source system, not the summary screen

The admin console shows an account as removed while a role binding, a team membership, or a token still exists. Query the source system for the identifier and record the empty result.

Check the audit log for the removal event and for any access after the stop signal. Access after the signal is the finding that matters most, because it shows the revocation did not take effect.

Have a second person run the verification. The person who removed the access is the least reliable verifier of their own action.

Capture the exact query and its empty result for each system. A note that access was removed is a claim, while a query, a timestamp, and a zero row result is a record that survives a staff change.

Probe shared accounts, tokens, and vendor gaps

Shared accounts are the common failure. If a password is shared, removing one person does not remove access, and rotation is the only real fix. Record each shared account and who owns the rotation.

Personal tokens created outside the identity provider are the second failure. Search the repository and CI settings for tokens issued by the departing account, and check package registries and cloud keys.

Vendor dashboards often sit outside single sign on. If the vendor has no administrative API, the removal is manual and needs a screenshot of the seat list plus a named owner for the next check.

• Shared password with no rotation after the drill.
• Personal access token still valid after account disable.
• Vendor seat removed from the list but active in the product.
• Repository deploy key issued by the departing account.

Keep the decision and the exceptions with the company

The programmer can prepare the inventory, run the sandbox drill, and document the gaps. The company owner decides when an account is disabled, who may keep a vendor seat for a transition, and which exceptions are accepted.

Write the exception with an expiry. A temporary seat that nobody removes becomes permanent access, and the next drill will find it again.

Do not let a drill become a performance assessment of the person leaving. The record is about the system's ability to revoke, not about the individual.

Measure time to revoke and residual access

Measure minutes from the stop signal to the first revocation, minutes to the last verified removal, and grants verified removed divided by grants inventoried. Report the role, the systems, and the drill date.

Track residual access found in the next drill. A grant that survives two drills is a design problem that needs an owner and a date.

Run the drill quarterly for roles with production or customer data access, and after any change to the identity provider or a major vendor. Update the inventory when a new system is added.

Close with a closure register a reviewer can audit

The register lists each grant, the removal action, the verifier, the timestamp, and the evidence reference. It also lists shared accounts, exceptions with expiry, and grants that could not be removed.

Accept the drill when a reviewer can pick three grants and confirm from the source system that each is gone, and when every remaining grant has a named owner and a date.

Add the next drill date and the person who will run it, so the register has a successor rather than a historian.

Frequently asked questions

Sources

1. NIST Role Based Access Control

   Role and permission modelling reference for grant inventories.

2. CISA Zero Trust Maturity Model

   Identity centric access framing for revocation and verification.

3. NIST SP 800-53 Rev. 5

   Access control and account management control family.

4. NIST Privacy Framework

   Data access minimisation relevant to customer records.