The Single-Point-of-Failure Register for Small Teams

Every small team runs on single points of failure — not because anyone chose them, but because hiring one person, buying one laptop, and picking one payment processor are the cheap decisions. They stay invisible until the day the one thing fails. A single-point-of-failure (SPOF) audit is two hours with a spreadsheet that turns “we think we'd be fine” into a written register of what can take you down, how bad it would be, and what you decided to do about it. The goal is not to eliminate every SPOF — that costs more than most outages — it is to choose them on purpose instead of inheriting them by accident.

The Five Passes: Where SPOFs Hide

Walk the business five times, once per layer. In each pass, ask the same question: if this one thing disappeared right now, what stops? If the answer involves revenue, customers, or a promise you made, it goes in the register.

Pass 1: People

• Name every task only one human can do: the payroll run, the deploy, the vendor negotiation, the “why is the invoice number like that” knowledge. The key-person dependency checklist does the deep version; this pass just finds the rows.
• Count the credentials only one person holds: the domain registrar login, the hosting root account, the social accounts, the 2FA device that is also their personal phone.
• Count the availability dependencies: one founder who is the only approver, the only escalation contact, the only one awake in the vendor's timezone.

Pass 2: Machines and Software

• The one laptop with the only working build environment, the license locked to one machine, the NAS nobody else can unlock.
• The self-hosted box with no second copy: if that VM dies, how long to rebuild it from documentation — and does the documentation exist? Pair this pass with the backup restore drill: a backup of a SPOF is only half a fix if the restore was never tested.
• The one automation nobody else can maintain. A cron job only the person who wrote it can safely edit is a person-SPOF wearing a machine costume.

Pass 3: Vendors and Services

• Services with no fallback named in writing: the email provider, the payment processor, the cloud host, the 3PL. For each, ask “what is our second option and how long to switch?” — if nobody can answer, that is the finding. The vendor outage runbook covers the day it happens; this pass makes sure it never becomes a total outage.
• Contracts that lock you in: one-year terms, data export only through support tickets, the domain registered at the same registrar as everything else.
• Vendors who are themselves SPOFs: the tiny SaaS run by two people, the local ISP with one fiber line into the building.

Pass 4: Access and Secrets

• Count the secrets that exist in exactly one place: the API key on one laptop, the 2FA recovery codes in one drawer, the signing certificate with no export. The secrets rotation checklist fixes the hygiene; the audit finds the concentration.
• Accounts with one admin: the workspace owner account, the store admin, the DNS account. One admin means one resignation, one lost phone, or one locked account away from a hostage situation.
• Access that silently concentrates: every new service added to one person's password vault, one card in one wallet, one person's phone number as the fraud-call contact.

Pass 5: The Money Path

• Trace one dollar from a customer's card to your bank account and list every single link: checkout, processor, payout schedule, bank, and the human who reconciles it. Any link with no second option is a revenue SPOF. The payment outage playbook tells you what to do when a link breaks; this pass tells you which link is load-bearing.
• One bank account, one card, one signer. A frozen account with no second account is a company that cannot pay rent while it argues.
• One revenue channel? That is a strategic SPOF — record it in the register too, with a different fix timeline than the operational ones.

The Register: Six Columns, No More

One row per SPOF, six columns. If a column starts an argument, shrink it — the register's job is decisions, not documentation.

• Component — the thing: “payroll run”, “checkout plugin license”, “DNS account”. One line, no essays.
• What breaks if it fails — the customer-visible sentence: “no new orders can check out”, “staff not paid on the 30th”.
• Blast radius — minutes, hours, or days: how long until revenue or trust takes a measurable hit if nothing else changes.
• Backup today — what exists right now, written honestly: “none”, “Dave, untested”, “a second laptop, 6 months stale”. The gap between this column and what people say in meetings is the audit's main product.
• Evidence — when was the backup last tested, with a date. “Assumed” is a red flag the register exists to catch.
• Decision — one of the four, plus a date. See below.

Blast Radius: Score It in Money, Not Vibes

“High/Medium/Low” invites wishful thinking. Score in one question instead: if this failed right now, what revenue or promise is at risk in 24 hours? A checkout path that does $2,000/day is a $2,000/day problem. Payroll on the 30th is a dated promise to your own team. Write the number next to the row — it makes the four decisions obvious and depoliticized: nobody argues to “accept” a $60k/day blast radius for free.

Worked Example: A Five-Person Online Store

A five-person store runs the audit in one afternoon. Three real findings:

• Checkout plugin licensed to one email. The license is bound to the founder's address, and renewal reminders go to an inbox she reads “most Fridays.” If it lapses on a Saturday, checkout dies until Monday. Blast radius: ~$9k over a weekend. Decision: duplicate — move the license to a shared ops address, add a renewal-date line to the standing orders sheet, calendar reminder 30 days out. One hour, done.
• Shipping labels: one vendor API, one integration, no export. If the vendor has a bad day, labels stop and the day's orders queue. Blast radius: a day of delayed shipments, angry email. Decision: document, don't duplicate — write the fallback (manual label purchase on the carrier's site) into the vendor outage runbook and test it once for twenty minutes. Full redundancy isn't worth it at this volume; a tested fallback is.
• The founder's phone is the 2FA device for the store admin, the processor, and the bank. Phone in a lake = locked out of the money path. Blast radius: days. Decision: duplicate — hardware key in the office safe as second factor, recovery codes split between two people, done the same week.

Total fix cost: an afternoon and a $25 hardware key. Before the audit, all three lived in “we'd figure it out.”

The Four Decisions

Every row ends in exactly one of four words, each with a date:

• Eliminate — remove the dependency entirely. The most underrated option: drop the feature, the vendor, or the manual step that is only load-bearing out of habit.
• Duplicate — make a real second one: second admin account, second signer, second factor on a device that lives elsewhere, second person trained with a shadow test. Duplicates decay, so each one gets an entry on the drill calendar.
• Document — a tested fallback procedure instead of a second system. Cheap, but only valid if someone has actually walked through it once. Untested documentation is a SPOF with a nicer font.
• Accept in writing — for low blast radius or expensive fixes: keep the SPOF, write the number next to it, set a revisit date. An accepted SPOF is a decision; an unexamined one is a landmine.

Cadence: Pair It With the Restore Drill

• Quarterly: run the register pass in the same session as the backup restore drill — the drill finds dead credentials and stale exports, and those are usually register rows. Thirty minutes of updates, not a rewrite.
• On every new hire: the audit doubles as onboarding — a new person's fresh eyes find the “everyone knows that” dependencies fastest. Ask them: “what would break if [person] vanished today?”
• After every incident: the postmortem adds one line to the register: which SPOF did this incident expose, and did its blast-radius number hold?
• When anything doubles: revenue, headcount, or traffic doubling changes blast-radius math. Re-score the money-path rows before you feel it in an outage.

SPOF Audit Anti-Patterns

• Auditing the org chart instead of the tasks. “Bob is a SPOF” is not actionable. “The payroll run is” is.
• Duplicating without testing. The second laptop that has not booted in six months is a doorstop with a title. Test duplicates on the drill calendar or write them down as assumed.
• Fixing the cheap ones and forgetting the scary ones. Sort the register by blast radius and start at the top; the satisfying easy wins are not the point.
• Registers nobody revisits. A SPOF register with no cadence is a museum. Tie it to the quarterly drill and the postmortem, or it will be stale exactly when you need it.
• Treating redundancy as the only answer. Sometimes the right fix is to eliminate the dependency, or to accept it in writing with a number attached. The register exists to force the choice, not to mandate purchases.

Instant-Download Ops Kits

This checklist is part of the Hive80 Lab ops kit line — field-tested, instantly downloadable:

• The First 30 Minutes — free incident quick-start
• Ops Field Cards — 12 printable incident checklists — $4
• Ops Starter Kit — full incident-response kit for small teams — $14
• Ops Mega Bundle — all 5 kits in one download — $29

⚡ Launch pricing is live at the store — check the banner for today's code.

Related Ops-Notes Pages

• Single Point of Failure Audit — the two-hour walk that finds the suspects; this register prices and decides them
• Key-Person Dependency Checklist — the people-layer deep dive: second person per critical task
• Backup Restore Drill Checklist — prove restorability, find dead rows for the register
• Vendor Outage Runbook — the day a documented fallback gets used for real
• Payment Outage Playbook — when a money-path link snaps
• Hot-Spare Loaner Laptop Checklist — a tested duplicate for the machine layer
• Secrets Rotation Checklist — de-concentrating the access layer
• Uptime & Downtime Budget — how much failure you can tolerate, decided on purpose
• Incident Commander Checklist — who runs the day a SPOF fires anyway
• After-Action Report Template — feeding incident lessons back into the register
• Patch Management Checklist — keeping the duplicate healthy enough to matter

You cannot un-single-point your whole business, and you don't need to. Two hours with the five passes, one register, four decisions with dates — and the next surprise outage becomes a row you already priced, not a company-level emergency.

Related: home-office security checklist