A risk register is a running list of identified risks, each scored by likelihood and impact, used to decide what happens to it — accept it, reduce it, transfer it, or escalate it for immediate action. It's the single most common working document in GRC, and it's usually the first artifact a new GRC Analyst learns to maintain.
What actually goes in a risk register
Each row is typically one risk, with columns for a description, the asset or process it affects, a likelihood rating, an impact rating, a calculated risk score, an owner, and a status. A simple version might rate likelihood and impact from 1–5 and multiply them for a score out of 25 — more mature programs weight factors differently, but the core logic is the same everywhere.
How scoring drives action
The score isn't just a number for a spreadsheet — it maps directly to what happens next, usually against a pre-agreed rubric. A low score might mean "log it and monitor." A mid-range score means "assign an owner and fix it within a set timeframe." A high score means "escalate to leadership or a risk committee immediately." This is exactly the judgment call GRC Analysts make constantly: not just spotting a risk, but correctly deciding how urgently it needs to move.
A real example
Say a public-facing API is running software with a known vulnerability that's had a patch available for 60 days. Likelihood is high (the vulnerability is public, no compensating control exists); impact is severe (customer payment data could be exposed). Multiplied together, that score lands well into "escalate" territory — which is exactly the kind of scenario the Risk Register Builder Challenge walks through hands-on.
Why it matters beyond the spreadsheet
A risk register is also what an auditor asks for first. If your organization can't show a maintained, current risk register, that's often a finding in itself — it signals nobody is systematically tracking what could go wrong. Keeping it current, not just having one, is the actual job.