Almost every security framework asks you to identify and assess risk, and almost every team answers with a spreadsheet called the risk register. The spreadsheet usually exists. What auditors question is whether it is the record of a real process or a document assembled the week before fieldwork.
The difference shows up quickly. An auditor picks a risk, asks who owns it, asks how it was rated, and follows it to the controls and decisions that came out of it. A register built to be looked at fails that walk. A register built to be used passes it without anyone preparing.
This article covers what a register is for, the fields it needs, how to write risks that are actually risks, and the mistakes that most often become findings. Scoring and treatment each get their own articles in this series.
What the auditor is testing
The auditor is not checking whether you identified the right risks. They have no way to know that, and most will say so. They are checking that you have a defined method, that you followed it, and that its results drove decisions.
The requirements behind that test are short. In ISO/IEC 27001:2022, clause 6.1.2 requires a documented risk assessment process with defined criteria, identified risk owners, and analysis of consequence and likelihood. Clause 8.2 requires you to perform assessments at planned intervals and when significant changes occur, and to retain the results. The AICPA's trust services criteria ask the same thing in different words: CC3.2 expects the entity to identify risks to its objectives and analyze them as a basis for deciding how to manage them. The HIPAA Security Rule requires a risk analysis and risk management for ePHI, as covered in our piece on the Security Rule's three safeguard types.
None of these texts prescribes a register format. The register is the conventional way to show the results, which means its structure is yours to design and yours to defend.
The fields that make a register defensible
A register that survives sampling holds enough on each row for a stranger to understand the risk, see who decided what, and trace it forward. These are the fields that earn their place.
| Field | What it holds | Why the auditor cares |
|---|---|---|
| Risk ID | A stable identifier that never changes or gets reused | Lets controls, tickets and approvals point at the risk |
| Risk statement | Cause, event and consequence in one or two sentences | Shows you are describing a risk, not a control |
| Scope reference | The asset, process or service the risk applies to | Shows coverage of the scope you defined |
| Risk owner | A named person with authority over the affected area | ISO 27001 requires owners to be identified |
| Current rating | Likelihood, impact and the resulting level, with a sentence of rationale | Lets the auditor re-perform the rating against your criteria |
| Treatment decision | Mitigate, transfer, accept or avoid, and why | Connects analysis to action |
| Linked controls and actions | The controls that address the risk, and open actions with owners and dates | The trail the auditor follows next |
| Target or residual rating | Where the risk should sit once treatment is done | Shows the treatment was expected to work |
| Acceptance | Who accepted the residual risk, and when | The record most often missing |
| Last reviewed | The date the row was last examined, and by whom | Shows the register is maintained |
Resist adding more. Every column you add is a column someone has to fill in for every row at every review. Fields that are blank on most rows tell an auditor that the method is not followed.
Write risks, not missing controls
The most common register defect is a list of absent controls written as risks. "No MFA on the admin console" is not a risk. It is a gap. The risk is what could happen because of the gap, to what, and with what result.
A usable risk statement has three parts:
The cause. The weakness, threat or condition that makes the event possible.
The event. What actually happens.
The consequence. The effect on confidentiality, integrity or availability, and on the business.
Compare two versions. "Insider threat" names a category. "A departing engineer keeps access to the production database because offboarding depends on a manual ticket, which could expose customer records" names a cause, an event and a consequence. The second can be scored, owned and treated. The first cannot.
Specific statements also make the register shorter. Writing "cyberattack" as one risk feels thorough and produces nothing a person can act on. Writing 10 specific risks about the systems you actually run produces a register that explains itself.
Owners, dates and history
Ownership
A risk owner is the person with the accountability and authority to manage the risk. That is usually the person who runs the affected system or process: the head of engineering for production access, the head of people for HR data, the finance lead for payment systems. It is rarely the security team for every row.
When every risk belongs to the CISO, the auditor will ask whether ownership means anything. It also means the owner is accepting risks in areas they do not control, which defeats the purpose of naming one.
Dates
Every rating, decision and acceptance should carry a date. Without dates, the register is a statement about now, and the auditor is testing a period. A register with no dated entries cannot show that anything was assessed before the audit started.
History
A spreadsheet that is overwritten at each review loses the evidence that the review happened. Keep the prior state somewhere: version history, a dated export per review, or a change log column. You will need it when an auditor asks why a rating dropped between two assessments, and the honest answer is "we fixed the cause in March".
Mistakes that become findings
These are the patterns auditors raise most often. Each one is easier to prevent than to explain.
The register restates the control list. Every Annex A control or trust services criterion appears as a risk. The auditor reads this as a register built backward from the framework rather than from your environment.
Residual equals current, everywhere. If treatment never changes a rating, either the treatment is not working or nobody re-rated anything.
Treatments with no trail. The decision says "mitigate", but no control, ticket or project is linked. The auditor cannot tell whether anything happened.
No acceptance on file. Residual risks exist but nobody with authority accepted them. ISO 27001 clause 6.1.3 requires the risk owners' approval of the treatment plan and their acceptance of residual risk.
Stale since the last audit. Clause 8.2 expects reassessment at planned intervals and on significant change. A register untouched through a cloud migration or a new product line is a finding waiting to be written.
Ratings with no rationale. A score with no explanation cannot be re-performed. One sentence is enough.
Getting a first version in place
If you are starting from nothing, start from the scope, not from a template with dozens of prefilled risks. Prefilled risks feel like progress and produce a register nobody recognizes.
A workable sequence for a first version:
Write the method first. One or two pages: the scales, how ratings combine, who can accept what, and how often you review. This is the documented process clause 6.1.2 asks for, and it stops arguments later.
List what is in scope. The services, systems and data you defined as in scope for the ISMS or the SOC 2 report. Our explainer on what an ISMS is covers how scope anchors the rest.
Run short sessions with each owner. Ask what would hurt their area most, and what makes it possible. Write the risks in their words, then sharpen them into cause, event and consequence.
Rate, decide, link. Rate each risk against the method, decide a treatment, and link the controls that already exist.
Get the acceptances. Each owner reviews their rows and records acceptance of the residual risk.
The first version will be uneven. That is fine. A register that is honest about its gaps and visibly maintained is a better audit position than a polished document nobody uses. The same register can serve several frameworks at once, since ISO 27001 and SOC 2 both ask for risk assessment that drives control decisions.
How TrustLynce helps
TrustLynce's risk register keeps each risk with its owner, scoring, treatment plan and linked controls in one record, with dated history of every change. Acceptances are recorded against the named owner, so the trail an auditor follows is already in place when they ask.