The new admin's first week: inherit the keys without breaking anything

You just became the admin of a small company's entire digital estate — the passwords, the DNS, the backups, the billing logins, the Wi-Fi password on the whiteboard. Nobody hands you a map. The failure mode of the first week is not a hack; it is ignorance wearing confidence: changing things you do not yet understand, promising restore times you have never tested, and discovering in month three that the only backup is a hard drive in the founder's drawer. This runbook is the opposite of that: five days, one deliberate act per day, and a strict rule — in week one you learn and you prove, you do not rebuild. The on-call onboarding checklist covers the new hire joining a rotation; this page covers the person who just inherited the whole castle.

1. Day zero: the read-only inventory

Look before you touch; change nothing. Day zero has exactly one job: find out what exists. Walk the estate read-only: where are the admin credentials (password manager? spreadsheet? the founder's memory?), who owns the DNS registrar account, where do backups land, which card pays for which SaaS. Write it all down as you go. The asset inventory checklist and the key inventory register are the two artifacts you build on day zero — not from memory, from inspection.
Follow the money first. The fastest complete map of a small team's stack is the last three months of card and bank statements: every recurring line item is a system with an owner, a login, and data. This catches the things nobody thought to mention — the invoice tool, the e-signature account, the marketing automation that emails customers nightly. Silence about a system is how it becomes a shadow IT finding later.
Interview the humans, not just the systems. Thirty minutes each with the founder, the finance person, and the most senior non-technical employee. Ask three questions: what breaks and ruins your week? what do you back up and where? what happens if I am unavailable tomorrow? Their answers are your risk register, and question three is a polite early warning about the bus-factor document in section 6.

2. Day one: prove one backup restores

The single most important act of your first week. Pick the most business-critical dataset you found on day zero and perform a real restore: file, database, or mailbox, into an isolated location, with a stopwatch. A backup you have not restored is a rumor. If the restore works, you have earned the right to promise recovery — and if it does not, you have found the landmine in week one instead of during an outage. The backup restore test checklist is the procedure.
Write down the restore time, not the backup time. Nobody cares how long the backup takes; they care how long the comeback takes. Record: which backup generation you restored, how long it took, what had to be re-created manually, and what data was lost between the last backup and the incident. That last number — the recovery point gap — is what leadership will quote back to you, so put it in writing while you control the wording.
Check the 3-2-1 shape while you are in there. Three copies, two media, one offsite. Small teams routinely have "a backup" that is a single copy on the same physical machine, or a cloud sync service that faithfully syncs ransomware along with everything else. Sync is not backup; replication is not backup; only a versioned, restorable, off-machine copy is backup.

3. Day two: the access audit and the break-glass account

Diff the seat list against the people list. Pull the admin list on every system that matters (identity provider, email, code, finance, DNS, the production box) and cross it against today's org chart. Every former employee, former contractor, and "we made it admin temporarily in 2023" account is a door that no longer has a reason to be open. The user access review checklist turns this from a one-time sweep into a quarterly habit.
Build the break-glass account before you need it. While you are the newest person with the keys, create the emergency admin identity: cloud-only where applicable, excluded from conditional-access policies, 20+ character password sealed offline, TOTP on a dedicated device, sign-in alerting on. Nobody is more motivated to do this than the admin who just discovered nobody else can get in. The break-glass account checklist is the full procedure.
MFA everywhere, but stage it. Enforce multi-factor on the crown jewels (email, identity, DNS, finance) this week; roll it out to the long tail over the coming month with a communication plan. Enforcing MFA on the entire company on day two is how the new admin becomes the villain of the week. Prioritize by blast radius: the mailbox that resets every other password is the first domino.

4. Day three: alerts that page versus emails nobody reads

Audit what is currently alarming. Find every monitoring, logging, and alerting channel that exists (you found most of them on day zero), then check two things: does it actually deliver (send a test), and does anyone act on it (ask who read last week's alerts). A dead alerting channel is worse than none — it manufactures false confidence at 2am.
Define the paging threshold before the first page. Small teams drown either in silence or in noise. Write one page: what wakes a human (production down, backup failure, security alert on a crown-jewel account), what waits for morning (a slow disk, a single failed login), and what goes to a weekly digest. Tie the wake-up levels to the severity matrix so the thresholds are already written down and someone else can apply them.
Build the escalation tree out loud. When you are unavailable, who is next? Put the on-call order, the vendor list with support tiers, and the "if all else fails" contact (usually the founder) on one page. The on-call handoff checklist makes the tree survive shift changes; the 2am handoff test shows what happens when it does not.

5. Day four: DNS, domain, and the things that end businesses

Find every domain the business depends on. Not just the website: email domains, API endpoints customers call, the domain the VoIP system registers to. Check registrar accounts (owner? expiry? auto-renew? registrar lock?), DNS hosting (who can edit records? is there a second admin?), and DNSSEC/2FA state. Domain hijack and expiry are business-ending failures that no server monitoring ever catches — they happen at the registrar, which is usually nobody's monitored system.
Document the DNS records you could rebuild from. Export or screenshot every record with its purpose: which record hosts mail, which points to production, which one the marketing agency set and nobody understands. The day a record is misconfigured, this list is the difference between a five-minute fix and an archaeology dig.
Calendar the silent killers. Domain expiry, SSL certificate expiry, insurance renewal, the annual annual security review, the next quarterly backup restore test, the vendor contract auto-renewals you found in the statements. An admin's calendar is an ops system; the entries are cheaper than the incidents.

6. Day five: the bus-factor document

Write the document that would save the company if you vanished. One page, plainly written, stored where leadership can reach it without you (not inside the password manager only you unlock): where the credentials live, how to reach the break-glass account, how to restore the backups and how long it takes, who the vendors are and how to escalate (the vendor escalation ladder belongs in the appendix), and what to do in the first 30 minutes of a breach — the first 30 minutes page and the breach first-24-hours checklist are the two links that matter most.
Do not confuse the bus-factor document with documentation. The bus-factor doc is for your absence; system documentation is for everyone else's daily work. Start with the bus-factor doc because it is one page and forces the right questions; the fuller documentation builds over the following month as you actually use each system.
Hand it over, in person, with a rehearsal. Walk leadership through the document once. "If I am unavailable, here is the sequence" said out loud once is worth ten emails. Update the document whenever the estate changes — an out-of-date bus-factor doc is a false map, and false maps are worse than none.

7. What NOT to do in week one

Do not rip and replace. The backup that "looks bad," the email server that is "ancient," the Wi-Fi password "everyone knows" — in week one you do not have the context to judge them, and you certainly do not have the credibility to replace them. Every change you make before you understand the system is a change you cannot explain when it breaks something downstream. Month one is for plans; week one is for learning and proving.
Do not buy tools before you have inventoried what you own. The day-zero statements will show you how much of the stack is already paid for and unused. Most small teams do not have a tool gap; they have an adoption gap. New admin tool-shopping in week one is usually discomfort with the unknown dressed up as initiative.
Do not skip the boring days to chase the fun project. The AI assistant, the automation pipeline, the shiny monitoring stack — all of it is worth exactly zero if a former employee's account is still active and the backup does not restore. The order in this runbook is deliberate: proven recovery first, access control second, alerting third, domains fourth, the fun stuff after the foundations hold your weight.

8. The 30-day tail

Week one proves; the month hardens. By day thirty: the password manager rollout finished or scheduled, MFA on the long tail complete, the patch cadence running with a named window, the first weekly ops report delivered to leadership in their language (what held, what failed, what it cost, what changes next), and the quarterly calendar fully booked.
Report in the business's language, not yours. "I restored the finance database in 40 minutes" beats "RPO met." Your first-week artifacts — the inventory, the restore log, the access diff — are exactly the evidence a good report is made of, and they set the tone for every review that follows.
Give yourself a re-test. Book a day-30 self-drill: restore again, walk the bus-factor doc again, page yourself once on purpose. The drill schedule you set up in week one should already contain this date — which is itself proof the week worked.

Small-team honesty note: in a five-person company the "new admin" is often one person inheriting everything part-time, and this runbook is sized for that reality — one deliberate act per day, every artifact one page, no tooling purchases required. The trap this page exists to prevent is not incompetence; it is the competent admin's first-week instinct to fix everything at once. Inherit first. Prove the backup. Close the old doors. Then build.