Who owns this account when someone leaves? A worked example

Most small teams can tell you who answers the phone. Fewer can tell you who owns the account that holds the company domain, who can approve a change to the website, or where the recovery details are kept if the person who set it all up is away. The answer is usually "Jonah knows". That works until Jonah has a last day.

This guide follows a fictional five-person design studio through one afternoon of work: a short register of accounts, the dates that matter in December 2026 and January 2027, and the gaps that fall out when you put them side by side. The studio is made up, and so are its numbers, but the situations are the ones small teams meet every year. You can follow along on paper, or use the free handover register to do the same with your own list.

Why December and January are the risky weeks

Two things happen at once. People take leave, often in overlapping blocks, and people finish jobs at the end of the year, because a change of role is easier to plan around a quiet fortnight. At the same time, renewals pile up. Annual plans started in January come round again, domains fall due, and cards that were replaced during the year quietly fail.

A gap that costs nothing in October can cost a week in January. If the only person who can approve a change is on a beach with no signal, a payment that bounces is not an inconvenience, it is an outage. A register will not stop that from happening. It makes sure somebody has decided, in writing, what happens next.

If your website is part of the picture, read our website checklist before the holidays alongside this one. That one covers opening hours, forms and mobile pages; this one covers the people and accounts behind them.

The studio: five people, a handful of accounts

Marlow & Finch is a five-person studio.

• Ines founded it and approves anything that costs money.
• Tomas is the designer.
• Priya is the developer who built the studio website.
• Jonah runs operations and looks after most of the admin accounts. He has accepted a role elsewhere and finishes on 18 December 2026.
• Lena is the part-time bookkeeper, in on Tuesdays and Thursdays.

Dara, a project coordinator, joins on 11 January 2027. Priya is away from 21 December until 4 January, and Tomas from 28 December until 8 January.

Ines asks Jonah for a list of everything the studio pays for or signs in to. He sends back eleven items. For this walk-through we will look at six, which are enough to show every kind of gap.

None of this is unusual. Nobody did anything wrong. The register simply shows what was already true.

Step 1: one owner, one backup, and they are different people

Start with the plainest rule. Every account gets one named owner, meaning a person rather than a role or a shared mailbox. Every account also gets one backup owner, who is a different person.

The second half is where teams slip. Email and calendar lists Ines as owner and Ines as backup. It looks complete, because both boxes are filled in, but if Ines is unreachable nobody else is named. A register that treats "same person twice" as "no backup" catches it straight away.

The domain account is the starker case. It has an owner and nothing else, and the owner leaves on 18 December, a day before the renewal on 19 December. That single row is worth the whole afternoon. Ask who pays, who can sign in, and who receives the reminder emails. If the answer to the last question is Jonah's personal inbox, the reminder leaves with him.

Step 2: say where recovery details are kept, in words only

Every account needs a way back in if the owner is gone: a recovery contact, a spare method of proving who you are, a note held by someone trusted. What matters for a register is only where those things are kept, written in plain words.

Good entries sound like this:

• "Shared password vault, folder Website. Ask Ines."
• "Printed note in the office folder, shelf 2."
• "Sealed envelope in the office safe. Lena holds the key."

Notice what is missing. There is no password, no code, no phrase and no key in any of them. A register is a document that gets printed, emailed and pinned to a wall. It should never contain anything that would let a stranger sign in. If you are tempted to type one in, stop and describe the place instead. The handover register is built to refuse these: if a field looks like a password, a code or a long random key, it holds the field and asks you to reword it.

Team chat has an empty recovery field in the studio's list. That is a gap on its own, and an easy one to close in two minutes.

Step 3: put the dates next to the names

A list of accounts and a list of people are two separate documents until you put dates on both. Once you do, the problems show up quickly.

Jonah owns three of the six accounts, and he leaves on 18 December. Dara starts on 11 January, 24 days later, so there is no overlap in which Jonah could hand anything to Dara in person. The handover has to happen in the other direction: Jonah to Lena, Tomas and Ines before the 18th, and Dara added once they arrive.

Priya and Tomas are both away from 28 December to 4 January. They are owner and backup for the studio website and for design file storage. For a week, nobody named on those two rows is reachable. Ines can fix that by naming a third person for cover, or by asking Priya to push her leave by a few days, but she can only do either if she has seen the overlap.

Add the leave dates and the leaver dates to the same sheet as the accounts, and let the overlaps appear. Checking them by eye works for five people. It stops working around fifteen accounts.

Step 4: prove the backup restores

A backup you have never restored is a hope. The studio's log has three entries:

• Studio website: a full copy restored to a test folder on 20 November. It passed.
• Design file storage: one client folder restored on 2 August. It passed, but that was 121 days before the check date.
• Accounting software: a yearly invoice export on 10 October. Only part of it came back.

The studio chose a 90-day interval. That makes the design files stale and the accounting export a failure to follow up. It also leaves the domain account and email with no test at all. A restore test does not need to be grand. Pick one file or one record, put it somewhere safe, open it, and write down what you restored, the date and what happened.

Choose the interval yourself. Ninety days suits most small teams; some prefer thirty for the accounts that would hurt most to lose. What counts is that the number is written down and the log is read against it.

Step 5: a one-page escalation sheet

When something breaks at 8pm on 27 December, nobody wants to open a spreadsheet. They want one page with a role, a name and a way to reach that person.

Marlow & Finch's sheet lists three roles: first call (Ines), websites and email (Priya) and money and billing (Lena). It says Priya is away from 21 December until 4 January, so the sheet shows a note next to her name. That is a problem the sheet reveals, not hides: the websites role has no cover for two weeks.

The rule to test is simple. There should be at least two named people, in different roles, and neither should be away or leaving for the same dates. A sheet with one name is the single point of failure in miniature. Print it, and put it where the whole team can find it, including the person who joins next month.

What the studio found, in order

With dates and names side by side, the studio's gap list ran to seventeen items. The useful part is the order, because not everything can be done in a week.

1. Fix first: the domain account has no backup and its owner leaves a day before renewal. Ines names herself backup, Jonah walks her through the recovery note, and the renewal approver is set to Ines.
2. Fix first: the website and the design files have both owner and backup away from 28 December. Ines asks Lena to cover both for those days.
3. Fix first: email lists Ines twice. Tomas becomes the backup.
4. Check soon: accounting and team chat move from Jonah to Lena and Tomas before 18 December. The team chat renewal on 14 December falls before he goes, so Jonah handles it himself.
5. Check soon: three restore tests are run in the first week of December, and the failed accounting export is repeated.
6. Tidy up: design file storage gets a named approver.

Every one of those items came with a reason in plain words, such as "Owner and Backup owner are the same person, which counts as no backup". That matters, because a list nobody can explain is a list nobody acts on. The checklist then turned the gaps into dated actions for Jonah, Dara, Priya and Tomas, in date order, so that the 18th stopped being a surprise.

Official guidance worth a read

A register is documentation. The wider question of how to protect accounts, back things up and respond when something goes wrong is covered well by public bodies that write for small organisations. These are neutral starting points, and each one is written by the organisation named in the label:

• UK National Cyber Security Centre: guidance for small and medium-sized organisations
• US Cybersecurity and Infrastructure Security Agency: Cyber Essentials
• US Small Business Administration: strengthen your cybersecurity

If you are working through the website side of the same season, our explainer on security headers is a good companion, and the holiday opening hours guide covers the parts customers see.

Keep it going in January

Set one date, the first working day of January, to read the register again. Update the owners, remove people who have left, add the joiner, and re-run any restore test that is now older than your interval. Twenty minutes then saves a very long afternoon later.

A short routine helps:

• When someone joins, add them to the register on day one and show them where recovery details are kept.
• When someone leaves, treat their last day as a deadline for every account they own, back up or approve.
• When a renewal date moves, change it in the register as well.
• Once a quarter, run one restore test and log it.

Frequently asked questions

What is a handover register?

It is a short list of the accounts and systems a team relies on, with an owner, a backup owner, the person who approves changes, the renewal date and a note on where recovery details are kept. Its job is to make sure nobody has to guess when someone leaves or goes away.

Should I write passwords into it?

No. Write where things are kept, such as "shared vault, folder Website, ask Ines". A register is printed and shared, so it should describe places, never hold passwords, codes, keys or recovery phrases.

How many accounts should I list?

Everything that would hurt if it stopped working or if the person who knows it vanished. For a small team that is often between ten and forty items. Start with domain, email, website, payments, accounting and file storage.

How often should I test a backup?

Choose an interval you will keep, often ninety days, and run one restore of a single file or record each time. Write down what you restored, the date and whether it worked.