Documenting your access setup so someone else can take over
Every access setup eventually gets inherited — by a colleague, a successor, a client, or by you after eighteen months away from it. What they inherit is usually a vault full of entries with no explanation, which is only marginally better than nothing. The document that fixes this is smaller than you'd think, and it's worth writing before you need it.
What the document is for
Be clear about the job, because it determines what goes in.
It is not a place to store credentials. Those live in the password manager, and duplicating them into a document creates a second, weaker copy that goes stale. The document explains the shape of the setup: what exists, why, who owns it, and what depends on it.
The test to write against: could a competent person who has never seen your systems, given access to the vault, work out what everything is and what would break if they changed it? Credentials answer "how do I sign in". This answers everything else — and everything else is what actually takes weeks to reconstruct.
The account table
The core of it, and mostly a byproduct of the inventory you already have. One row per login:
| Column | Why it earns its place |
|---|---|
| Service | The product name. |
| What it's for | One phrase in plain language. "Sends transactional email." Names alone don't survive a year. |
| Login URL | The exact page, including any separate SSO or admin host. |
| Identity | Which address or username signs in. The most-needed column, and the one nobody can answer from memory. |
| Auth method | Password, social, SSO, passkey. Determines how recovery works. |
| Second factor and where it lives | An account with 2FA and no record of the factor's location is a lockout waiting to happen. |
| Owner of record | Whose organisation and card. The column that prevents ownership disputes. |
| Who has access | Names, not "the team". |
| Tier | Blast radius. Tells a successor what to be careful with. |
| Depends on / depended on by | What breaks if this changes. The column people wish they'd had. |
| Vault location | Which collection holds the credential. |
That's a spreadsheet, and a spreadsheet is fine. Resist building anything more elaborate — tooling is how this turns into a project that doesn't get finished.
The parts that aren't a table
Rows capture state. These capture the reasoning, and they're what makes the difference between a list and a handover.
The exceptions, with reasons. Every shared login, every over-broad permission, every account still on SMS 2FA — with why. "Vendor sells one seat; re-check at renewal in March" tells a successor this was a decision, not an oversight, and gives them the date to act on. Without it they either leave it alone forever or break something removing it.
The recovery map. For Tier 1 only: which mailbox receives resets for what, where backup codes are filed, who the emergency contact is, and where the break-glass kit lives. Not the codes themselves — where they are.
Long-lived tokens and integrations. What each token is for, what depends on it, when it expires. These are invisible in a user list and are the leftovers that most often break things or leave doors open — see the tokens guide.
The routines. The monthly report someone pulls, the quarterly review, the annual domain renewal. Tasks that only exist in one person's head are the ones that silently stop happening.
Vendor contacts. Account manager, support portal, contract renewal dates. Trivial to note, genuinely tedious to reconstruct.
Known problems. The account nobody can recover because it's registered to someone who left. The integration held together with a personal token. Writing these down is uncomfortable and it's the most valuable section — an inherited problem you were warned about is manageable; one you discover during an outage isn't.
Known problems. It reads like admitting failure. It's actually the difference between handing over a system and handing over an ambush — and every experienced successor will judge the handover by whether this section is honest.
What to leave out
- Passwords, tokens, and TOTP seeds. The document says where they are; the vault holds them. A document containing credentials has to be protected like a vault and won't be.
- Backup codes. Same reasoning — record the location.
- Step-by-step UI instructions. They rot within months as interfaces change, and they're the bulk of most bloated handover docs. Document what and why; the how is discoverable.
- Anything the platform already shows. Don't mirror user lists — they drift out of date immediately and a successor should read the live one.
- Commentary about people. Facts about systems only.
Where it lives
Somewhere your successor can reach without the access it describes — that's the constraint that rules out most options. A document explaining how to recover your accounts, stored in an account you can't recover, is a joke you only get to hear once.
Practically: a shared team drive or wiki that isn't gated behind the systems it documents, with the vault holding a note pointing to it. For a client engagement, hand over a copy as a deliverable. And keep an offline copy with the break-glass kit — this is the case where paper earns its place.
It contains no credentials, but it's still a map of your infrastructure and who has access to it. Treat it as internal, not public.
Keeping it current without it becoming a job
Documentation dies from maintenance cost. Three habits keep it alive:
Update at the moment of change. Adding a service, granting access, issuing a token — one line, thirty seconds, while you're already there. Batched updates never happen.
Attach it to something already scheduled. The quarterly review already walks the accounts; correcting the document as you go costs almost nothing and is the natural moment to do it.
Keep it small enough to stay true. A hundred pages of screenshots is worse than two pages that are accurate, because nobody trusts a document they've caught being wrong. Cut anything you won't maintain.
Date it. A document with no date has unknown reliability, and a successor will assume the worst — correctly.
The handover itself
When it's time, the document does most of the work, but a few things only happen live:
- Walk through it together rather than emailing a link. An hour of questions surfaces the assumptions you didn't know you'd made.
- Have them log in to the Tier 1 accounts while you're there. This is the step that catches the broken thing. Access that's never been tested by the new person is access you're guessing about.
- Transfer ownership, not just access. Owner of record, billing contact, recovery addresses, domain registrant. Access without ownership leaves them dependent on you.
- Rotate shared credentials after you leave — and make sure someone owns that task.
- Remove your own access and confirm it in writing.
- Agree a grace period — a few weeks where they can ask questions. Cheap for you, and it's what turns a clean handover into a good reference.
Start with fifteen minutes
Don't plan a documentation project. Open a spreadsheet and fill in the Tier 1 accounts — usually five to eight rows. Add the recovery map. Note the two or three known problems you already know about.
That's fifteen minutes, and it covers the accounts that actually matter. Add rows as you touch other services, and in a couple of months it's complete without a single dedicated session. The version that exists and is 70% complete beats the thorough one you were going to write next quarter.