The security risk register, done usefully
A risk register earns its place when it drives spending decisions and records who accepted what. Most registers do neither. They are ninety rows in a spreadsheet, scored by one person, reviewed annually, and quietly ignored by everyone who could act on them.
A security risk register should be fifteen to thirty rows, each with a named owner who is not the security lead, a stated decision to treat, transfer, avoid or accept, and a date. Its job is to turn arguments about security spending into a record of choices somebody made. A register of ninety rows scored on a five by five grid by one person on a Friday afternoon does the opposite: it makes everything look equally urgent, which is the same as making nothing urgent.
15 to 30 Rows an executive will actually read
Quarterly Review cadence that keeps it alive
$4,000 to $12,000 Standalone build, CAD
What a register is for, and what it is not for
Three different documents get called a risk register and they have different readers. Confusing them is why the register ends up serving nobody.
| Document | Reader | Contains | Cadence |
|---|---|---|---|
| The executive risk register | Executive team and board | 15 to 30 business risks with owners and decisions | Quarterly |
| The control gap list | Security and engineering | Findings against a framework, remediation tasks | Continuous, lives in your ticket system |
| The vulnerability backlog | Engineering | Scanner output, patches, CVEs | Weekly, and never shown to a board |
Only the first belongs in front of executives. The common failure is pasting the second or third into a board pack, at which point directors either disengage or start asking about individual CVEs. Both are bad. What belongs in board material is on CISO board reporting.
Scoring that survives a hostile question
Every register uses likelihood times impact, and most of them collapse the moment someone asks what a 4 means. Fix that by defining the scale in observable terms before anything is scored, and by scoring impact in dollars or days rather than in adjectives.
| Score | Financial | Operational | Regulatory and customer |
|---|---|---|---|
| 1 | Under $25,000 CAD | Under 4 hours, internal only | Nothing reportable |
| 2 | $25,000 to $150,000 | Under a day, some customers notice | A customer asks questions |
| 3 | $150,000 to $750,000 | 1 to 3 days of degraded service | Reportable breach, or a contract breach |
| 4 | $750,000 to $3M | Multi-day outage of a critical operation | Regulator engaged, or a material customer lost |
| 5 | Over $3M, or existential | Extended loss of a critical operation | Enforcement, or the business model is affected |
Likelihood needs the same treatment: express it as a frequency over a stated window, such as "expected more than once a year" versus "plausible once in ten years", not as "medium". Two people scoring the same risk should land within one point of each other. If they do not, the scale is the problem rather than the people.
The heat map is not the deliverable
Coloured grids photograph well and decide nothing. What an executive actually needs is a ranked list with a dollar estimate, the cost of doing something about it, and a recommendation. If your register produces a heat map and no recommended action per row, it is a picture rather than a management tool. Quantifying badly, with a stated range and stated assumptions, is more useful than not quantifying at all, because a wrong number invites correction and a colour invites nothing.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
Formal acceptance is the whole point
The most valuable column in the register is the one recording who accepted a risk and when. Most security work is not eliminating risk, it is deciding which risks the business will carry. A register that does not record those decisions leaves the security lead personally holding every choice the company declined to fund.
- The owner is the executive who owns the affected part of the business, not the security lead. Security proposes, the business accepts.
- Acceptance is written, dated and has an expiry, usually a year. A risk accepted forever is a risk nobody will revisit when the company changes.
- Acceptance above a defined threshold goes to the board or to the audit committee. Set that threshold in advance, in dollars, so it is not negotiated per risk.
- An accepted risk that materialises is reviewed at the next quarterly session with the acceptance attached. Not to assign blame. Otherwise nobody learns how the company scores.
The risks that turn up on most Canadian registers
A register assembled from someone else's list is the kind that gets ignored. This is a starting set to argue with.
| Risk | Typical owner | Usual treatment |
|---|---|---|
| Ransomware disrupting a critical operation | COO or CTO | Treat: recovery testing, segmentation, offline backups |
| Loss of a key SaaS provider or its data | Business owner of the system | Treat and transfer: exit plan plus contract terms |
| Personal information exposure triggering PIPEDA or Law 25 duties | General counsel or privacy lead | Treat: minimisation, access control, retention |
| Enterprise deal lost or delayed on a security review | CRO or VP Sales | Treat: certification, trust page, questionnaire capacity |
| Single person holds critical system knowledge | Functional executive | Treat: documentation and a second pair of hands |
| Contractor or offshore access with weak controls | Whoever engaged them | Treat: see vendor risk management |
| Cloud misconfiguration exposing data | CTO | Treat: guardrails and detection rather than review |
| Business email compromise causing a payment loss | CFO | Treat and transfer: payment verification plus insurance |
| Credential compromise without MFA on a legacy system | CTO | Treat or accept explicitly, with a date |
| Insufficient logging to investigate an incident | CTO | Treat: this one is invisible until the day it matters |
| No named security accountability at executive level | CEO | Treat: internal owner plus fractional depth |
| Certification lapse breaching a customer commitment | Security lead | Treat: calendar and evidence discipline |
The eleventh row is uncomfortable to write and belongs on most registers. It is also the one risk this whole site sells the treatment for, so treat it with the same scepticism as the others. If nothing external is forcing the question and you are under 25 people, accepting it explicitly for a year is a legitimate decision. The tool at do you need a vCISO exists to make that call.
Keeping it alive
Registers die between the second and third quarterly review, and always the same way: the review becomes a read-through of unchanged rows. Three habits prevent it.
- Open with what changed. Rows that moved, rows that closed, rows that are new. Never start at row one.
- Close things visibly. A register that only grows teaches everyone that nothing gets fixed. If the top risk has not changed in three quarters, either the treatment is not funded or the score is wrong. Say which.
- Connect it to the roadmap. Every funded treatment should appear as a dated item on the plan, and every roadmap item should trace to a risk. See security strategy and roadmap. If an item traces to nothing, ask why it is being done.
On tooling: a spreadsheet is fine up to a few hundred people. Compliance platforms include a register and it is usually adequate. A register living in a system you will stop paying for is a register you will lose. Whatever you use, make sure you can export the whole thing in an editable format, which is also the clause worth having in a vCISO contract.
The middle option people forget is a free compliance workspace, which holds a register alongside the control set and the evidence it maps to. TrazTech, which operates this site, runs one at traztech Workspace, free with no seat limit and no export fee, and the register stays yours when an engagement ends. Whether it beats a spreadsheet depends on whether you want the risks sitting next to the controls and the evidence. It checks AWS, Okta, Google Workspace, GitHub, GitLab, Cloudflare and Jira daily, and anything else has to be described rather than picked off a list. Vanta and Drata carry hundreds of integrations, endpoint agents and HR systems, and a large estate is what that breadth is for.
Get a register built that executives read
A first risk register and the workshop that produces it is a fixed-scope engagement. Tell us your size and sector and we will get it quoted.
Get matchedCommon questions
How many risks should a security risk register have?
Fifteen to thirty for a company under 500 people. Below fifteen you are probably describing categories rather than risks. Above about forty nobody reads it, prioritisation stops happening, and the register becomes a record of thoroughness rather than a tool for deciding what to fund. Detailed control gaps and vulnerabilities belong in separate lists that never reach a board.
Who owns a risk on the register?
The executive who owns the part of the business the risk affects, not the security lead. If the security lead owns every row, the register records that security has been made solely responsible for decisions it cannot fund, which is the arrangement that produces a resignation about eighteen months later. Security owns the register as a document. The business owns the risks in it.
Should we quantify risk in dollars?
Yes, as ranges with stated assumptions. A range of $150,000 to $750,000 CAD with the working shown is more useful than "high", because it can be compared against the cost of the fix and it can be challenged. Precision is not the goal and false precision is worse than none, so publish the assumptions next to the number and expect the first few estimates to be corrected by people who know the business better than you do.
How often should the register be reviewed?
Quarterly with the executive team, and whenever something material changes: a new product, a new jurisdiction, an acquisition, a significant incident, or a new regulatory obligation. Annual review is what a register gets when it is a compliance artifact rather than a management tool, and you can usually tell which one you have by whether anything on it has closed in the last six months.
Do we need a risk register for SOC 2 or ISO 27001?
Yes for both, and the framework requirement is the weakest reason to have one. ISO 27001 requires a defined risk assessment and treatment process with documented results, and SOC 2 expects risk assessment under the common criteria. Auditors accept fairly modest registers, so building one that passes an audit and building one that runs your program are different exercises. Aim for the second and the first comes free.