How to build a risk register for an early-stage startup (the document investors love).

Startup risk register: the framework, the common mistakes, and the evidence that separates a defensible answer from a confident one.

Most startups do not maintain a risk register. The ones that do tend to close fundraises faster, recruit better, and run with fewer surprises. The reason is not that the document itself produces better outcomes. The reason is that the act of maintaining it forces the founder to name the failure modes explicitly, which prevents the avoidable ones and creates clarity about which risks are deliberate trade-offs.

A risk register is a simple table tracking the failure modes that could materially affect the business. The format is straightforward: risk description, category, likelihood (high, medium, low), impact (high, medium, low), current mitigation, owner, and review date. The document is typically a single page when filtered to the active risks.

The discipline matters more than the format. A risk register that gets updated monthly is useful. A risk register written once and never revisited is theater. The companies that get value from the document are the ones where the CEO reviews it before every board meeting, every fundraise, and every major hire.

Five categories of risk appear in nearly every early-stage risk register. Market risk: the segment is smaller than projected, the buyer behavior shifts, or the timing of adoption changes. Product risk: technical execution stalls, a critical feature does not work as designed, or a dependency breaks. Team risk: a key person leaves, a critical hire fails to perform, or the founder team fractures. Financial risk: the next round does not happen on the expected timeline, customers churn faster than modeled, or unit economics degrade. Regulatory risk: a rule changes, a license becomes required, or a market becomes restricted.

For most B2B SaaS startups, financial and team risks are the most common to materialize, and market risk is the most existential. Product risk tends to be addressable through engineering effort. Regulatory risk is category-specific and often dormant until it activates suddenly.

A useful risk entry is specific, actionable, and falsifiable. A vague entry: "Risk of losing customers." A specific entry: "Customer X (representing 22 percent of ARR) is using the product less in the last 60 days. If they churn, year-end ARR drops by $480K. Mitigation: weekly check-ins from VP of Sales, executive sponsor relationship reactivated, contract renewal conversation moved up by sixty days."

The specific entry tells the team what to do, who is doing it, and how to know if it worked. The vague entry produces no action because there is nothing concrete to do.

Investors at Series A and beyond will ask about risks. The conversation goes better when the founder has already thought about them. A founder who pulls out a current risk register and walks the partner through it signals operational maturity. The partner does not need to extract the risks through diligence; the founder has already done the work.

This works against founders who hide risks in the pitch and discover them later. Hiding risks does not make them go away. It just shifts the cost of discovery onto the investor, which damages the relationship and often kills the deal when the risks emerge in late-stage diligence.

Board meetings work better when they include risk review. A standard format is to spend the first ten minutes of the meeting reviewing the top three risks from the register, what changed in the last month, and what mitigation is underway. This anchors the rest of the meeting in the operational reality of the business rather than the optimistic version that often dominates board updates.

Board members who have seen the risk register are also more useful contributors. They can offer specific advice, introduce specific contacts, and apply pressure on specific mitigations. Board members who see only the optimistic version provide generic advice because they do not know what is actually at risk.

The risk register is also useful in hiring conversations. When a senior candidate asks about the company's challenges, the founder who can pull up a current risk register and walk through the top three risks gives a more credible answer than the founder who answers in generalities. Senior candidates have heard the optimistic version many times. They are evaluating the founder's self-awareness as much as the company's opportunity. A documented, honest view of the risks signals self-awareness more credibly than any verbal pitch.

The two common mistakes are over-listing and under-listing. Over-listing produces a register with thirty entries, none of which are reviewed, because the volume itself prevents engagement. The fix is to keep the active register to five to ten entries and move resolved or low-priority items to an archive.

Under-listing produces a register with three entries that all describe the same risk in different language. The fix is to challenge each entry: is this a distinct risk, or is it a symptom of another risk already listed? The discipline of keeping entries distinct forces the founder to think structurally about the business.

A risk register is a simple table that forces the founder to name failure modes explicitly. The companies that maintain one tend to close rounds faster, recruit better, and run with fewer surprises. The format is a one-page table with five fields per row, updated monthly, reviewed before every board meeting and every fundraise. The work to maintain it is small. The benefits compound. For how Verdikt builds risk registers automatically inside every report, see the Verdikt methodology and what a kill criterion actually is.

Market risk: the assumption that the buyer exists at scale, will pay the price, and is reachable through a channel that math out. The headline assumption to register: bottom-up TAM source, ACV midpoint with comparable wedges, CAC ceiling at which the channel works.

Product risk: the assumption that the technical approach can produce the experience the customer expects within the cost and time budget. The headline assumption: the riskiest engineering bet (a model that has to perform at X latency, an integration that has to ship within Y weeks, an algorithm that has to maintain accuracy at Z load).

Team risk: the assumption that the founding team can recruit and retain the people who will execute the next 18 months. The headline assumption: the role that is hardest to hire (typically a senior engineer with domain experience or a sales leader with category relationships) and the timeline by which the hire must close.

Capital risk: the assumption that the next round will be raisable on the milestones the current round funds. The headline assumption: the specific metric thresholds that unlock the next round at the planned valuation.

Regulatory or external risk: the assumption that the regulatory environment will not change in a way that invalidates the wedge. The headline assumption: the regulation or platform policy that, if changed, would alter the business materially.

Each register row has the same five fields. Assumption (one sentence, declarative). Tier (Tier 1 to 4 by impact). Falsifier (the specific evidence that would prove the assumption wrong). Test (the action that would produce that evidence, with cost and timeline). Owner (the human responsible for running the test).

Twenty rows are typically enough. More than that, and the register stops being scanned weekly. Fewer than ten, and you have likely missed something obvious. The register lives in a shared document that the founding team reviews on a fixed cadence. Without the cadence, the register becomes a one-time exercise and stops driving behavior.

Assumption: "Practice managers at outpatient mental health groups with 2 to 10 clinicians will pay $200 per month per practice for the workflow speed advantage." Tier: 1 (kills the company if wrong). Falsifier: "Fewer than 4 of the next 25 cold demos convert to paid trial within 14 days at the $200 price point." Test: "Run 25 cold demos in the next 30 days at the $200 price, track conversion by demo source." Owner: Founder. Date assigned: 2026-05-17. Date to revisit: 2026-06-17.

That entry is one row in the register. The whole register has 15 to 20 of them. The cadence is weekly: every Monday morning, the team reviews the register, updates the test status, and adds new assumptions as the company learns. The register is the operational backbone of the diligence work.

The most common failure is not running the tests. The register identifies the assumption, but the team gets pulled into product work and never runs the demo. Six months later, the assumption is still there, still untested, and the company has burned half its runway. The fix is to schedule the tests as calendar work, not as opportunistic work.

The second failure is the silent update. A team member runs a test, gets a result that invalidates the assumption, and does not update the register. The register stays stale and the rest of the team continues to operate from the original assumption. The fix is to make register updates a standing agenda item in the weekly team meeting.

Verdikt’s methodology treats the risk register as a first-class output: every verdict ships with a risk register that names the top three weakest claims and the re-run hooks for each. The hook is the explicit test that, if it produced a different result, would change the verdict. That structure is the same one a founder should be using internally. The discipline maps directly to the project-management risk register pattern documented by PMI’s standard risk-management framework and adapted by Y Combinator’s Startup School for early-stage founders. See also B2B SaaS benchmarks 2026 for the metric thresholds that anchor the capital-risk row.