Risk and continuity
How a Startup names what could go wrong, rehearses recovery, and keeps running when it does.
A Startup keeps what could go wrong, and how fast it recovers, as records its Controls cite. The Risk register names the harms; Recovery Objectives set how fast each Capability returns.
The Risk register
A Risk is something that could harm a Startup or a Portfolio, scored from 1 to 5 for likelihood and for impact. Each has an owning Role, a treatment, and a date for its next review.
A Risk's scope is the Startup, or the Portfolio for exposure that siblings share. One upstream that every sibling relies on is one Portfolio Risk, not 40 copies.
| Verb | What it does | Who |
|---|---|---|
| assess | Scores likelihood and impact from the Startup's records and sets the next review | Risk Analyst |
| treat | Links the Controls that lower the Risk and records the score it should reach | Risk Analyst |
| accept | Carries the Risk untreated until its next review, as a signed Decision | An officer, in person |
| close | Ends a Risk that can no longer happen and keeps it, with every score | Risk Analyst |
A score of 12 or more, likelihood times impact, raises the Risk to its owner. No Risk is ever deleted.
The quarterly assessment
Risk assessment scores every open Risk each quarter, links each to the Controls that treat it, and sends the result to an officer to accept. It is the running record behind the Risk assessment Control.
Every Control cites the Risks it treats, and every treated Risk names its Controls. An auditor reads either way: from a Risk to its Controls, or from a Control to its Risks.
A new Startup starts with the Risks its Startup Template carries: an upstream outage, the loss of its one human, a leaked secret.
Recovery Objectives
A Recovery Objective sets two numbers for one Capability. The recovery point is the most data a failure may lose, and the recovery time is how fast it returns. Each objective also sets a drill cadence, such as quarterly.
A drill restores one Capability's records into an isolated namespace and records whether the restore met both numbers. A missed objective opens an Incident. Restore drills passed is the share of drills that met both.
Backups and Point-in-time recovery provide what a drill restores. The drill proves it works.
Continuity
Continuity keeps a Startup running through three kinds of loss, and the Reliability Engineer owns it:
- An upstream fails. Each Capability names a second upstream, and the Capability fails over to it without a Change to the Startup's definition.
- A record is lost. The Recovery Objective sets how much, and the last drill shows the restore works.
- A person is gone. Every act on the legal floor names a successor signer, so a single-human Startup keeps signing when its human cannot.
A Studio Startup's successor is the holding Company's Officer desk. A self-serve Startup names its own successor before it goes Live.
Incidents with a clock
Some Incidents are notifiable: a breach of personal data, or an actively exploited flaw. A notifiable Incident starts a statutory clock, such as 72 hours to a data protection authority.
Notify regulator files every notice the Incident owes before its clock runs out, and records each filing. The Breach notification Control tests that it does. The Communications Lead drafts the public statement.
Next
- Incident response: detection to postmortem.
- Buying from upstreams: how upstream review scores continuity before first use.
- Inherited trust: how these records satisfy SOC 2 for every Startup.