Handover Playbook: Transferring Account Access Inside a Team

Most account handovers do not fail because of bad intentions. They fail because nobody wrote anything down. The person who set the account up knows the login, knows which email receives the codes, knows which phone holds the authenticator app, and knows the informal rules about who may approve a withdrawal. None of that is in a document. When that person leaves, goes on leave, or simply changes roles, the team discovers that access lived in one person's head, and recovering it becomes an urgent project instead of a routine task.

The cost of a bad handover is rarely just embarrassment. It is days of lost access, reset requests, support tickets, and in the worst case a locked account at exactly the moment the business needs it. A handover playbook exists to make that outcome boring instead of dramatic. It is a short, repeatable procedure that any two people in the team can follow, and it should be written before it is needed, not during a crisis.

Before anything changes hands, list every account in scope. For each one, record the platform, the account's purpose, the login email, who currently holds access, which devices hold two-factor authentication, and which recovery methods exist. You do not need to write passwords into this inventory; you need to know that the account exists, who can open it today, and what would break if that person disappeared. Teams are routinely surprised by this step, because accounts accumulate quietly: a trading account opened for one project, a payment account tied to an old email, an account whose only administrator left six months ago.

The inventory also needs an owner. One named person, not a committee, is responsible for keeping it current, and the inventory itself lives somewhere the team can reach without the departing person's help. Review it quarterly. A handover that starts from a stale inventory is only slightly better than a handover that starts from nothing, so the quarterly review is part of the playbook, not an optional extra. Our earlier guide on the /blog index about quarterly account hygiene covers that review in detail.

Transfer in an order that never leaves the account without an administrator. First, add the incoming person as an additional user or administrator where the platform supports team roles. Second, confirm the new person can log in, receive codes, and perform the account's normal tasks. Third, and only then, remove or downgrade the outgoing person's access. Reversing this order is the single most common handover mistake: removing the old administrator before the new one is verified working turns a routine transfer into a lockout.

Where a platform does not support multiple administrators, plan the transfer as a supervised session instead of a credentials handoff. The outgoing and incoming holders sit together, physically or on a call, and walk through login, two-factor authentication setup, recovery options and a test transaction. The session ends with the incoming holder logged in on their own device, not with a password passed in a chat message. Passwords sent through chat, email or shared documents are how credentials leak, and they are also how a team loses track of who actually holds access.

Two-factor authentication is where most handovers stall, because it is tied to a device rather than a password. If the only authenticator app lives on the departing person's phone, the team does not truly hold the account, however many passwords it knows. Before the handover, check whether the platform supports multiple authenticator devices, hardware keys held by more than one person, or administrator-managed recovery. Where it does, set those up first. Where it does not, transfer the authenticator deliberately: register the incoming person's device, confirm it works, and only then remove the old device.

Recovery methods deserve the same attention. A recovery email that belongs to the departing person, or a recovery phone number nobody on the team controls, is a future lockout waiting for a bad day. Move recovery contacts to team-controlled addresses as part of the transfer, and test at least one recovery path before you consider the handover complete. If a platform offers backup codes, store them in the team's password manager or vault, not in a personal notebook, and record that they exist in the inventory without writing the codes themselves into it.

A handover is not finished when access works; it is finished when it is written down. The handover note should record the date, the accounts transferred, the people involved, the new access holders, the recovery contacts now in place, and anything still outstanding. Keep it short: a page per account is too much, a paragraph per account is about right. Both the outgoing and incoming holders sign it, even informally, so there is no later argument about what was handed over and when.

Documentation also protects the outgoing person. A clean handover note is the evidence that they no longer hold access and are no longer responsible for the account. That matters for audits, for internal disputes, and for the simple human reason that nobody should carry responsibility for an account they no longer control. File the note where the team's records live, and link it from the inventory entry so the next handover starts from the last one's paperwork.

Treat the first month after a handover as a probation period for access, not as a formality. In the first week, the incoming holder should perform every routine task at least once: log in, check balances, approve a normal transaction, and confirm notifications arrive. In the second week, test a recovery path, even a low-stakes one, so a real emergency is not the first test. By day thirty, the outgoing person's access should be fully removed, the inventory updated, and the handover note filed. If any step is still outstanding at day thirty, it is a task with an owner and a date, not a vague intention.

Watch for the quiet failure mode: the incoming holder who can log in but never actually uses the account, while the team keeps asking the departed person for help informally. That arrangement feels friendly and it quietly defeats the whole handover. If the old holder is still being consulted after a month, the transfer did not take, and the team should repeat the supervised walkthrough rather than accept the informal workaround.

Sometimes there is no handover period, because someone resigns suddenly, falls ill, or is dismissed. This is the scenario the playbook exists for, and the inventory is what saves you. Work through it account by account: which accounts did this person hold, which have other administrators, and which are single-holder. For the single-holder accounts, start recovery immediately through the platform's documented process, because recovery can take days, and every day of delay is a day the business cannot act.

After the emergency, do the honest review. How did one person come to hold sole access to a business-critical account, and what changes prevent it recurring? The usual answers are team roles instead of shared passwords, a second administrator on every account, and a rule that no account is created without an inventory entry and a named backup holder. Write those rules down while the lesson is fresh. The /buy-crypto-accounts directory lists the account types businesses commonly manage, which is a useful checklist when you are deciding which accounts the new rules must cover.

Keep the template itself simple enough that people actually use it. One page: accounts in scope, current holders, incoming holders, two-factor authentication devices, recovery contacts, transfer date, supervised session date, outstanding items, and signatures. Run it for every role change, not only departures, so the team practises it when nothing is urgent. A playbook used twice a year in calm conditions is a habit; a playbook written during a crisis is a wish.

The measure of a good handover is uneventful. Nobody notices it happened, except that the new holder can do the job on Monday morning and the old holder is free of the responsibility. That is the standard to aim for, and it is reachable with an inventory, an ordered transfer, deliberate two-factor authentication handling, and a short written record. Teams that treat handovers as a procedure, rather than a favour between colleagues, rarely have account-access emergencies at all.