An ISO 27001 risk assessment an auditor will actually accept
The spreadsheet has 214 rows. Each has a likelihood between 1 and 5, an impact between 1 and 5, and a product of the two in a column shaded red, amber or green. It took a fortnight. It has not been opened since, and nobody can explain why row 87 scores 12 rather than 9.
An iso 27001 risk assessment is not judged on completeness. It is judged on whether the method is coherent, whether the owners are real, and whether it explains the controls you chose. A 30-row register that satisfies those three beats 214 rows that satisfy none.
What clause 6.1.2 actually requires
The clause is more prescriptive than most, and reading it properly saves a rewrite.
The clause text itself is worth buying the standard for rather than working from a summary, because the wording is precise and the precision is the point.
It requires a defined process that produces consistent, valid and comparable results. Defined and consistent are the operative words: two people assessing the same risk should land in roughly the same place, which means the criteria have to be written down before anything is scored.
It requires you to identify risks to confidentiality, integrity and availability, identify risk owners, analyse and evaluate the risks, and compare against criteria you established in advance.
And it requires retained documented information about the process. Not just the register, the method.
That last point is where most first attempts fail. They produce a register with no accompanying statement of how likelihood and impact were defined, so the numbers are unfalsifiable. An auditor asking "why is this a 4" has no way to check the answer, and neither do you in twelve months.
An iso 27001 risk assessment needs a method before a score
Write the method first, in one page, before the register exists. It needs four things.
Definitions of likelihood. Not "medium". Something anchored: 1 is once in ten years or less, 3 is annually, 5 is monthly or more. Frequency is easier to agree on than adjectives.
Definitions of impact, in terms your business recognises. Financial, and also operational and reputational. For a SaaS company, "platform unavailable to all customers for more than four hours" is a level everyone understands. Contractual thresholds are useful here because they are external and specific.
How the two combine, and where the acceptance line sits. A 5 by 5 matrix is fine. What matters is stating in advance which combinations require treatment, so the treatment decision is a rule rather than a preference.
Who owns the acceptance decision for a risk above the line. This should be a named role in management, not you, because accepting business risk is a leadership function and clause 5 wants leadership involved.
Write that page, get it approved, then score. The scores become defensible because the criteria predate them.
Owners who are real people
Every risk needs an owner, and the temptation in a small company is to put your own name against all of them because you do all the work.
That is wrong in a way an auditor will probe. The risk owner is not who implements the control, it is who owns the consequence and can accept the risk. For "customer data disclosed through a misconfigured storage account", you implement the fix; the person who owns the consequence is whoever answers to the customer.
Practically, in a company of forty, that means a handful of owners: a managing director, a head of engineering, possibly a finance lead for anything with a contractual penalty. Talk to them, tell them what they own, and record that conversation. A risk owner who does not know they own a risk is a finding at Stage 2, because the auditor will ask them.
Thirty rows that are maintained
The register that survives has a specific shape. Risks expressed as scenarios rather than as asset lists.
Not "Laptops". A laptop is an asset, not a risk. The risk is "a laptop with cached production credentials is lost or stolen, leading to unauthorised access to customer data". That phrasing does three things: it names the asset, the threat and the consequence, so the control that addresses it is obvious, and so is the reason you selected that control.
Somewhere between 20 and 40 scenarios covers a small SaaS company properly. Any fewer and you have missed categories. Many more and you are enumerating assets rather than assessing risk, and you will not maintain it.
The categories worth covering: identity and access, endpoints, cloud configuration, application security, supplier and sub-processor failure, data loss and backup, availability, insider risk including a departing employee, and the one people omit, key person dependency, which in a one-person IT function is a real and material risk that belongs in the register honestly.
Linking to Annex A through the SoA
This is the connection auditors check and beginners miss.
The risk assessment identifies risks. The treatment plan says what you will do about each. The Statement of Applicability records which Annex A controls apply and why. Those three documents have to agree.
So each risk in the register should reference the controls treating it, and each applicable control in the Statement of Applicability should be traceable to at least one risk. A control marked applicable that no risk requires invites the question of why it is there. A risk with no control is either accepted, which needs a recorded acceptance, or untreated, which is a finding.
That traceability is also how you justify exclusions cleanly. If no risk in your register touches physical media, the controls about physical media are not applicable, and the register is the evidence.
What gets asked at Stage 2
From experience of the questions rather than the theory:
How did you arrive at these criteria. Who approved the method. Show me a risk that changed after treatment and the evidence of the change. Who is the owner of this specific risk, and can I speak to them. When was the register last reviewed, and what changed. Show me a risk you accepted and the record of who accepted it.
Notice that none of those are about scoring. They are about whether the process is real. A register with modest scores, clear owners and a visible review history survives all six. An elaborate one produced in a fortnight and untouched since survives none.
Review it quarterly, and record that you did with the date and any changes, per scheduled evidence collection. The review history is what turns the register from a document into a system.
Questions
How many risks should the register have?
Between 20 and 40 for a small SaaS company. The real test is whether every applicable Annex A control traces to at least one risk, and whether you can maintain it quarterly. If you dread opening it, it is too long.
Do I need a formal risk assessment tool?
No. A spreadsheet is acceptable and common at this scale, provided the method is documented alongside it and there is a review history. Tooling helps with evidence collection rather than with the thinking, which is the compliance platform question.
Can I be the owner of every risk?
You should not be. The owner accepts the consequence, which is a leadership function. Expect three or four owners in a company of forty, and make sure each of them knows what they own, because the auditor may ask them directly.
What if a risk is above the acceptance line and we cannot fix it?
Then it is a recorded, accepted risk with a named accepter and a review date. That is a legitimate outcome and the standard provides for it. What is not legitimate is a risk quietly scored downward until it falls below the line, which is visible in a version history and reads badly.
How does this relate to the treatment plan?
The assessment identifies and evaluates. The treatment plan says what you will do, by when, and who owns it. They are separate documents because they change on different schedules, and an auditor will ask for both. The plan is what turns the assessment from an opinion into a commitment.