Why Founders Need a Digital Succession Plan, Not Just a Business One

Founders plan for the business ending them being unavailable in every way except the one that’s most likely to actually happen. There’s a will. There’s a shareholders’ agreement with a buy-sell clause. There’s key-person insurance, if the board insisted on it. There is almost never a documented answer to a much narrower, much more mundane question: who else can get into the accounts the business actually runs on if the founder is unreachable for two weeks?

This gap is easy to miss because it doesn’t feel like a governance problem — it feels like an IT detail, the kind of thing that’s “someone else’s job” until the day it very specifically becomes the board’s job, at the worst possible moment.

The Scenario That Exposes the Gap

It doesn’t require anything dramatic. A founder travels somewhere without reliable signal for a week. A founder is hospitalised, briefly but seriously enough to be unreachable. A founder simply forgets which recovery email is attached to an account set up four years ago, and the modern reality of automated account-recovery systems means “I am definitely the real founder” is not, on its own, sufficient proof to a support queue that doesn’t know that.

In any of these scenarios, if the founder is the only person with genuine access to the company’s primary email domain, its cloud infrastructure admin console, or its financial platform login, the business doesn’t merely lose convenience — it loses the ability to pay staff, respond to customers, or in some cases legally operate, for however long the recovery process takes. That process, run through a provider’s standard support channel rather than a pre-established second-person access path, routinely takes days to weeks for a business account, precisely because the provider has no faster way to verify legitimate ownership.

Why This Is a Governance Failure, Not an IT Oversight

Framing this as “an IT thing” is exactly how it gets deprioritised. It belongs in the same category as the will and the shareholders’ agreement, because it answers the same underlying question those documents answer: what happens to the things this person controls if they’re suddenly not available to control them. The only difference is that a will takes effect after death, and a digital succession plan needs to work for the much more common scenario of temporary unavailability too.

A board that has reviewed key-person insurance but never asked “who else can log into our own infrastructure” has covered the financial consequence of losing a founder without covering the operational one — and the operational gap is the one that causes the crisis in the first ninety-six hours, well before any insurance payout matters.

What an Actual Digital Succession Plan Contains

A documented inventory of the accounts that matter. Not every login the business uses — specifically the ones that can reset or control others: the primary email domain and its DNS, the identity provider or admin console, financial platforms, and any infrastructure the business’s product or operations genuinely depend on.

A second person with real, tested access to each one — not “would know who to call,” but actual, current, verified access. Password managers built for teams include an emergency access feature designed exactly for this; the same concept, formalised, should extend to every Tier 1 business account, not just the password vault.

Platform-native continuity features, actually configured. Major providers offer a mechanism for exactly this scenario — a designated contact who can assist with account recovery, or an automatic action triggered by extended inactivity. These features exist specifically to solve this problem and are, in my experience, almost never turned on for business accounts, only occasionally for personal ones.

A trigger condition and a review cadence. Access without a defined trigger for when the second person should actually use it is either unused when needed or misused when it isn’t. This needs to be specific — “unreachable for more than 72 hours during a declared incident,” not “if something happens.”

What This Actually Costs, Against What It Protects

Implementing this properly takes a founder an afternoon: auditing the accounts, formally adding a second authorised person to each, configuring the platform-native recovery features that already exist and cost nothing extra. Set against the alternative — a business genuinely unable to access its own email, its own infrastructure, or its own bank accounts for an unplanned week or more — the asymmetry is not close.

This is the same discipline I’ve argued for at the credential level in the three-key identity risk framework: identify the specific handful of things that, if inaccessible, take everything else down with them, and build deliberate redundancy around exactly those — not around everything equally.

The Uncomfortable Part Most Founders Skip

The honest reason this gets skipped isn’t ignorance of the risk — most founders, asked directly, will acknowledge the gap exists. It’s that formalising a second person’s access can feel like an admission of vulnerability, or a step toward being replaceable, in a way that a shareholders’ agreement somehow doesn’t trigger the same reaction. That instinct is understandable and also exactly backwards: a founder who has built in deliberate redundancy has made the business more resilient, not themselves less essential. The businesses that survive a founder’s unexpected unavailability are, without exception, the ones where this was decided in advance rather than improvised during the crisis.

Related reading: budgeting for the risk this plan is meant to contain; the first-100-days inventory a new technology leader should run.

Frequently Asked Questions

Isn’t this what a shareholders’ agreement or a will already covers? No — those documents address ownership and legal succession, typically after death or a formally triggered event. They don’t grant anyone practical, immediate access to log into the company’s email, cloud infrastructure, or banking platform, which is a separate and more time-sensitive problem.

Who should the second authorised person actually be? A co-founder, a senior trusted employee, or a professional advisor (accountant, lawyer, or managed IT provider) acting in a formalised capacity — the specific person matters less than the access being genuine, tested, and current rather than assumed.

Does this create a security risk of its own, by giving someone else access to critical accounts? It changes the risk rather than simply adding to it — an unplanned lockout with no recovery path is a near-certain, high-impact risk; a trusted second person with properly scoped, logged access is a materially smaller and better-understood one. The goal is deliberate, documented redundancy, not unrestricted access for its own sake.

How is this different from just writing passwords down somewhere for the team? Substantially — this uses the account-native recovery and emergency-access features providers already build for exactly this purpose, rather than an ad hoc password list that immediately becomes its own major security liability the moment it exists.

How often should a digital succession plan actually be reviewed? Annually at minimum, and immediately after any change to which accounts matter most or who holds the second-person access — a plan naming someone who has since left the business is functionally the same as having no plan at all.