Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

01.01 What is a Risk Register and Why Every Program Needs One

A risk register is the single source of truth for what could go wrong, who owns it, and what's being done about it — here's how to think about one and how SimpleRisk implements it.

Why this matters

A risk register is the running record of everything that could go wrong, who is responsible for it, and what is being done about it. That's the whole job of the artifact. If your program has a register, you can answer the questions that get asked of you — by leadership, by auditors, by a board member who reads one news headline and pings the CISO. If your program doesn't, you're guessing.

Every GRC program runs the same loop: identify the risks, assess them, decide what to do, monitor those decisions, and report on the result. NIST, ISO, and COSO each describe a version of that loop in their own language. The loop is the same regardless, and the register is what holds it together across the iterations. Without one, "identify" produces a list that disappears into a meeting minute, "assess" gets done in someone's head, and "monitor" stops the day that someone takes a new job.

We've watched a lot of programs try to skip this step. The pattern is consistent: a security team gets a directive to "stand up risk management" the quarter before an audit, builds a spreadsheet, populates it in a panic with sixty risks scraped from a scanner and a recent assessment, and then the spreadsheet sits untouched for the rest of the year. The auditor opens it, finds no owners assigned and no scoring done, and the program is right back where it started — except now the spreadsheet has a creation date and an air of permanence that makes it harder to abandon than to fix.

That's the pattern. The fix is the discipline of keeping a register, not the format you keep it in.

The point isn't the spreadsheet (or the database row). It's the discipline of keeping one. Every accepted risk has a record. Every mitigated risk has a plan attached. And for every transferred risk, the contract is referenced. When the CISO asks "what's our exposure on the new vendor?" the register answers in thirty seconds, not three days.

How frameworks describe this

A short orientation. None of these frameworks invents the register; they describe what it should contain and how it should be maintained.

  • NIST Risk Management Framework (RMF) — The seven-step lifecycle (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor) treats the categorized list of information system risks as the artifact carried forward through every step. The register is what gets categorized in step two and what monitoring revisits in step seven.
  • ISO/IEC 27005 Information Security Risk Management — Clauses 7 and 8 describe risk identification, analysis, evaluation, and treatment as a connected process. The register is the output of identification and the input to every later clause; the standard is explicit that it must be reviewed and updated continually, not produced once and shelved.
  • COSO Enterprise Risk Management — The COSO ERM framework places the register inside the Performance component (along with risk assessment, prioritization, and response). The framing is broader than information security — strategic, operational, financial, compliance, and reporting risks all share the same artifact.

Use whichever framework anchors your program. The register's job doesn't change.

How SimpleRisk implements this

In SimpleRisk, the risk register lives in the Risk Management module — the entry in the main navigation, with risks tracked in the underlying risks database table. New entries come in through the form on the Submit Risk page (the first numbered step in the Risk Management workflow). Once submitted, a risk gets reviewed, scored using one of several methodologies (Classic, CVSS, DREAD, OWASP, Custom, or Contributing Risk — see Risk Scoring Methodologies), assigned an owner, and either mitigated, accepted, or transferred. The register grows from there.

SimpleRisk's roots are in NIST 800-53, which is why the register treats controls and mitigations as first-class objects rather than afterthoughts. The register works the same way regardless of which framework anchors your program. For the longer story, see Introducing SimpleRisk.

The walk-through of the submission form is in Submitting a Risk. The rest of this chapter covers what happens to a risk after it lands in the register: review, scoring, mitigation, tracking, and the dashboards that turn the register from a storage bin into something that answers questions.

Common pitfalls

A handful of register failure modes show up over and over. Most of them aren't tooling problems — they're discipline problems that the tooling can either help with or quietly enable.

  • The register that nobody reviews. A register without a review cadence isn't a register; it's a snapshot. We recommend at least a monthly pass on the register as a whole and tighter review intervals on the higher-tier risks (90 days for highs, 180 for moderates is a reasonable default). If a risk's review date is older than a year, treat the entry as untrustworthy until someone re-reads it.

  • One giant "cybersecurity risk." A single entry that says "the threat landscape is bad" can't be scored, can't be assigned an owner who can act on it, and can't be mitigated by anything short of "do all of cybersecurity better." Break it down. Phishing leading to credential theft on the finance team's accounts is a risk you can score, own, and treat. Cybersecurity is a topic.

  • Risks without owners. Every risk on the register has exactly one human accountable for it. Not a team. Not "IT." A name. If you can't put a name there, the risk isn't ready for the register yet — it needs a conversation first about who owns the work.

  • Same person scores everything, every time. Self-scoring drifts. The submitter's gut feel becomes the score, the score doesn't get challenged, and over time the register skews toward whatever that one person finds scary. Build review into the workflow so a second pair of eyes touches every score before it's locked in.

  • Treating threats and vulnerabilities as risks. A vulnerability ("the database server is missing the latest patch") isn't a risk. A threat ("nation-state actors targeting financial data") isn't a risk either. A risk is a threat exploiting a vulnerability against an asset, with a likelihood and an impact attached. Mixing the three on a single register makes scoring inconsistent and reporting confusing — see From Vulnerability to Risk for how the relationship works.

  • The register that's a spreadsheet nobody trusts. A spreadsheet with a dozen risks for one team is workable. At a hundred risks across five teams, the same spreadsheet collapses: simultaneous edits clobber each other, the column count balloons, formulas drift, and the file lives on someone's laptop. By the time anyone notices, the trustworthy register is a tribal-knowledge story about what the spreadsheet used to contain. Move to a tool before you hit sixty rows; you'll thank yourself later. (Excel is our biggest competitor. We say that on purpose.)

  • The pre-audit register cram. A sixty-risk register populated in two weeks before an audit, scored on the same afternoon by one analyst, isn't a register — it's a compliance prop. Auditors notice. Build the register over time, even if you start with five risks; the maturity matters more to a serious assessor than the row count.

Related