River
Y CombinatorBacked by Y Combinator
FREE TEMPLATE

Technical Risk Register Template

Three documents and three sheets that replace a likelihood-times-impact score with a named trigger and an indicator someone actually checks on schedule.

Free download  ·  No account needed

Early Warning Indicators

One row per risk, checked separately from the score

Filled in after the register exists, in priority order. A likelihood and impact score decides which risk gets an indicator first. It does not decide whether the indicator was actually checked.

Likelihood x Impact

The initial filter, set once at intake, exactly the way most registers already work.

Named Trigger

The specific, observable sign that this risk is beginning to happen, not a feeling about the vendor or the team.

Checkable Indicator

Where to look, and the threshold that counts as crossed.

Checked on Schedule

Whether the last check actually happened when it was due. An indicator that exists on paper and goes unchecked is its own finding.

Every technical risk register template on the market opens with the same eight columns: id, description, category, likelihood, impact, the two multiplied into a score, owner, mitigation plan. A 2008 peer-reviewed analysis of that exact structure found it can rate a smaller risk higher than a larger one, and for risks where likelihood and impact move in opposite directions, the ranking can be worse than a coin flip. The score filters what to look at first. It is not evidence that anything has changed since the meeting where somebody set it.

The Department of Energy's own risk management guide solves that gap differently: assign a trigger metric to every risk when it enters the register, with a date attached, so the owner and the programme know whether it was checked. At Anchorpoint Systems, a fictional payments infrastructure company, 22 of 34 tracked risks carry that kind of indicator. Only 16 were checked on schedule last cycle. The other 6 carry an indicator that exists on paper and has gone quietly unchecked, treated here as its own finding, not a lower-priority monitored risk.

Five of Anchorpoint's risks materialized into a real incident over two quarters. Three had a checked indicator that crossed its threshold first, an average of 6.3 weeks of lead time, enough to run the plan instead of scrambling. Two had no indicator, or an overdue one, and were found only once impact was already happening. Built for the engineer inheriting a register nobody has touched since kickoff, next to the technical program plan tracking the same dependencies and the exec update reporting what a landed risk costs.

64.7% of risks carry an indicator. Only 47.1% were actually checked on schedule.

The Early Warning Indicators sheet, and the gap between having an indicator and checking it.

Early Warning Indicators

Anchorpoint Systems, a fictional payments infrastructure company. 34 risks in the full register; 6 of the 22 indicator-bearing rows shown here.

RiskCadenceChecked on scheduleCrossed
RISK-01, fraud-scoring vendor deprecationMonthlyYesYes, 11 wks early
RISK-03, PCI re-attestation deadlineWeeklyYesNo
RISK-04, sandbox/production mismatchMonthlyNo, overdueUnknown
RISK-08, idempotency-key capacityMonthlyNo, 106d overdueUnknown
RISK-10, Payments Core ledger v3 dateBiweeklyYesYes, 5 wks early
RISK-12, chargeback volume vs. capacityWeeklyYesNo

RISK-04 and RISK-08 are indistinguishable from a well-monitored risk on the score alone. Both carry a legitimate score of 12. Neither indicator has been checked in over two months, and nothing on the Risk Register itself would show that.

RISK-01 and RISK-10 are the two crossings that gave Anchorpoint time to act. Both got caught because somebody was checking a specific number on a schedule. RISK-10 scored the highest in this sample, 16, and still needed its indicator to actually fire before anyone moved.

6 of 22 indicator-bearing risks shown. The other 16, and all 12 score-only risks, are in the full sheet.

Monitored vs. Materialized

The same 34 risks at Anchorpoint Systems, read two ways.

Question askedAnswer
Risks with an indicator at all22 / 34, 64.7%
Risks actually checked on schedule16 / 34, 47.1%
Gap between having one and checking it17.6 points
OutcomeCountShare of materializationsWhat it means
No warning240%No indicator, or an overdue one; found only once impact was already happening
Caught early360%Indicator crossed its threshold first, average 6.3 weeks of lead time

64.7 percent looks like healthy coverage. Checking the same 34 risks for whether the indicator was actually looked at on schedule drops that to 47.1 percent, a 17.6-point gap a coverage number alone cannot show.

Every no-warning materialization came from the 52.9 percent of risks with no indicator or an overdue one. The score predicted neither outcome: RISK-02, a no-warning case, scored 15; RISK-05, still just monitored with nothing crossed, scored 9.

Zero of the 3 early catches came from reading the score. All 3 came from checking a number somebody had defined in advance.

What's in the pack

01

Risk Assessment

How a risk enters the register, gets scored, and gets a trigger candidate defined before the meeting ends.

02

Mitigation Plans

The specific first action, a named owner, and whether the required lead time actually fits inside the indicator's warning window, the same margin an estimation and capacity forecast treats as a committed date's real buffer.

03

Escalation Criteria

Three separate triggers for escalation: a crossed threshold, an overdue indicator, and a first reading that contradicts the intake score.

04

Risk Register

The standard structure, scored on entry, with every risk marked as indicator-defined or not yet, instead of left blank.

05

Early Warning Indicators

Every indicator, its threshold, its cadence, and whether the last check actually happened when it was due.

06

Decision Log

What happened the last time a threshold crossed, the false alarms included, one step earlier than a postmortem.

How to use it

  1. 1

    Open in River, or take it blank

    Claim the pack in River and hand it your current risk list, however informal, or take the blank documents and sheets and fill them in yourself.

  2. 2

    Share what you already know

    The risks that already worry the team, what has gone wrong once before, and what kind of system is actually at stake.

  3. 3

    Assign triggers by priority

    Starting with the highest-scored risks, define a specific, checkable indicator and a realistic review cadence for each one.

  4. 4

    Get the checked register

    Not a score sitting untouched since intake. A register where every indicator's last-checked date is visible, and overdue ones are flagged on sight.

Frequently asked questions

Is this template free?

Yes, no account or card needed to download it. Edit with AI is the optional half, where River reads your risk list and builds the indicator tracker itself. Every other pack sits in the template library.

What format are the downloaded files?

Three documents as Word files and three sheets as CSVs, zipped together. The sheets ship with Anchorpoint Systems' illustrative rows in place, so the monitored-versus-materialized split is visible before you replace them with your own risks.

Isn't a likelihood and impact score already how everyone does this?

It's how every template on the market does this, and a peer-reviewed analysis of that exact structure found it can rate a smaller risk higher than a larger one. The score is a real first filter. It is not a monitoring system, which is what the indicator tracker adds.

How is an indicator different from just reviewing the register more often?

A review re-reads the same score. An indicator is a specific, checkable fact with a threshold, so a reviewer can tell whether it was actually looked at on schedule, rather than just discussed again from memory.

What if we can't define an indicator for every risk?

Then it says so directly, as indicator not yet defined, rather than leaving the field blank. That keeps an unmonitored risk visible as unmonitored instead of quietly implying a coverage nobody actually has. Define it once real evidence exists to build one from.

Does this replace our program management tool?

No. It is the register your programme's delivery metrics and dependency dates already assume exists, checking whether a declared risk is actually being watched rather than only scored once at intake. Run both side by side.

Our risk data can't leave our network. Can we still use this?

Yes. A private AI workspace builds the register, the indicator tracker and the decision log inside your own tenancy, so no risk description, vendor name or dollar figure crosses a boundary your security team hasn't reviewed and approved in advance.

Find out which of your risks would materialize with no warning at all

Start from the blank documents and sheets, or send River your current risk list and let it assign a checkable indicator to the ones that matter most.

Edit with AI