The risk register nobody builds until it's too late
Every startup has risks. Very few have an honest, board-level view of what they actually are.
That's not because founders are careless. It's because the risk register most startups build — if they build one at all — is written for the wrong audience. It's the version that goes in the investor data room: comprehensive-looking, professionally formatted, and carefully worded to project control rather than surface uncertainty. It is a document about appearances, not a tool for governance.
A real risk register looks different. It makes people uncomfortable. It names the things the board would rather not say out loud — the founder dependency that would sink the company if she left, the technical debt that's quietly compounding into a future crisis, the regulatory obligation nobody has fully understood yet. It assigns owners to things that nobody wants to own. It gets looked at regularly, not filed and forgotten.
Most startups don't have that document. This piece is about why they should, what it should contain, and what a board that takes it seriously actually does with it.
Why risk registers fail
The failure mode is almost always the same. A risk register gets created — often under pressure from an investor, an auditor or a new board member — and in the weeks after it's written, it genuinely is useful. It reflects real thinking about real risks. Then it gets filed somewhere, nobody is assigned to update it, and it quietly becomes a historical document pretending to be a current one.
Eighteen months later, the company has pivoted twice, added forty people, signed three major enterprise contracts and taken on a new cloud infrastructure provider. The risk register still describes the business as it was when there were eight employees and a single product in beta.
The second failure mode is softer but equally damaging: the register lists risks without honesty. Probability and impact are assessed optimistically. Mitigations are described in terms of intent rather than actual controls. Risks that are genuinely alarming get softened into language that sounds manageable. The document becomes a way of demonstrating that risk has been considered rather than a way of actually managing it.
Both failures have the same root cause: the risk register is being written for external consumption rather than internal use. The moment that happens, it stops being a governance tool and becomes a compliance artefact.
A risk register written for external consumption stops being a governance tool and becomes a compliance artefact.
The six categories startups consistently underestimate
Based on what I've observed across consulting engagements, angel investments and board conversations, these are the risk categories that appear most often in the gap between what a startup's risk register says and what the actual exposure looks like.
-
Scenario-specific, not generic
Not "we might get hacked" — but: ransomware locking your build pipeline mid-sprint, a credential compromise during a live fundraising process, a customer data breach triggering ICO enforcement while you're in Series A due diligence.
-
Understood but not operationalised
Most technical founders have read about NIS2, the AI Act, DORA or FCA registration obligations. Far fewer have translated those obligations into concrete controls, ownership and a plan for what happens if they get it wrong.here
-
Named but unmitigated
Almost every startup board knows who the irreplaceable people are. Almost none have done anything serious about it — documented knowledge, succession thinking, retention structures or emergency protocols.
-
Rarely a board-level conversation
Accumulated shortcuts in architecture become security vulnerabilities, scaling failures and acquisition blockers. When an acquirer's technical due diligence uncovers a codebase built on shortcuts, valuations fall and deals collapse.Item description
-
Moves faster than your response
In an AI era, reputational risk moves at the speed of social media. A product decision that generates public controversy, a careless statement from a founder, or a customer incident handled badly can cause lasting damage within hours.
-
The invisible dependency stack
Your SaaS dependencies, cloud provider, key contractors and data processors. Most startups couldn't answer honestly: what happens if our top three vendors go dark tomorrow? That's a risk that belongs on the register.
The thread running through all six is the same: these risks are known in the abstract and unmanaged in the specific. The job of a board-level risk conversation is to close that gap — to move from "yes, we know that's a risk" to "here is who owns it, here is what we're doing about it, and here is how we'd know if it was getting worse."Item description
A closer look at the ones most often ignored
Technical debt as a board risk
Technical debt rarely appears on a startup's risk register in any meaningful way, and when it does, it's usually framed as an engineering challenge rather than a business risk. This is a category error.
Accumulated technical debt is a security vulnerability — shortcuts in authentication, unpatched dependencies and insufficient logging are not just code quality issues, they are exploitable weaknesses. It is a scaling risk — architecture decisions made for a ten-user product frequently fail at ten thousand users in ways that are expensive and slow to fix under pressure. And it is an exit risk — technical due diligence in acquisitions is thorough, and a codebase that tells a story of accumulated shortcuts will affect both valuation and deal confidence.
The board doesn't need to understand the code. It needs to ask, regularly: is our technical debt increasing or decreasing, who owns the decision about when to address it, and what would it cost us in a sale process if we don't?
Key-person dependency
This is the risk that every board names and almost no board does anything about. The conversation typically goes: yes, we know the company depends heavily on two or three people; yes, we know that's a vulnerability; and then nothing happens until one of those people hands in their notice.
Meaningful mitigation here isn't complicated, but it requires honesty and some deliberate effort. It means documenting critical knowledge so it doesn't live only in one person's head. It means thinking seriously about retention — not just compensation, but role, autonomy and trajectory. It means having at least a sketch of what the company would do in the first thirty days if a critical person left unexpectedly. None of this is pleasant to discuss. All of it is cheaper to do before the crisis than during it.
Supply chain and third-party risk
A startup's actual attack surface is much larger than its own codebase. Every SaaS tool in the stack, every cloud service, every contractor with access to production systems represents an extension of that surface. The company's security posture is, in practice, the weakest link across all of those dependencies.
Most startups have never mapped this properly. They couldn't tell you, under pressure, which third parties have access to what data, which of those third parties have themselves been subject to incidents, or which ones represent a single point of failure in their operational infrastructure. That mapping doesn't need to be elaborate — but it does need to exist and to be reviewed.
What a board-level risk review actually looks like
A risk review that works isn't a reporting exercise. It's a conversation with three questions at its centre: what has changed since we last looked at this, are our mitigations actually working, and are there risks on this register that should worry us more than they do?
Quarterly is the right cadence for most startups — frequent enough to catch things that are moving quickly, infrequent enough not to become a box-ticking exercise. Each category on the register should have a named owner at executive level. That person is accountable not for preventing every bad outcome, but for ensuring the board always has an accurate picture of where the company stands.
The tone matters enormously. A board that punishes honesty about emerging risks will get a risk register full of optimistic assessments and a set of surprises it could have seen coming. A board that treats honest escalation as good governance — that responds to "this risk is getting worse" with curiosity and problem-solving rather than alarm — will get the kind of risk intelligence that actually helps.
The timing problem
The best time to build a real risk register was at founding. That's not when most companies think about it and that's fine — the first months of a startup are about survival, not governance infrastructure. But there is a second-best time and it is before one of these risks materialises rather than after.
The cost of building this properly, in time and attention, is low. The cost of not having it — in a due diligence process, an incident response, a regulatory inquiry or a board-level surprise — is almost always higher than anyone anticipated when they decided to defer it.
The risk you're most exposed to right now probably isn't the one you'd name if asked. It's the one that isn't on anyone's register yet.
