The risk assessment is the document ISO 27001 builds everything else on, and the one most often bought as a spreadsheet template with someone else's risks in it. Clause 6.1.2 does not ask for a template; it asks for a process that produces five things: risk criteria, both for accepting risks and for performing assessments; an identification of the information security risks, with their owners; an analysis of the potential consequences and the realistic likelihood, giving a level; an evaluation against the criteria, with the risks prioritised for treatment; and results that are consistent, valid and comparable from one assessment to the next. Clause 6.1.3 continues with the treatment: the options, the controls needed, the comparison with Annex A so that nothing necessary has been left out, the Statement of Applicability, and the risk treatment plan approved by the risk owners with their acceptance of the residual risk. This article reads the two clauses for a software company and describes the method the free page uses to write the register and the plan, against the 93 controls the package holds as data and the starter risks the product seeds on day one.
A method the standard leaves to you
ISO 27001 requires criteria and a repeatable process; it does not require a particular scale, a heat map or a formula, and ISO/IEC 27005 gives guidance rather than rules. StandardOS's method, stated on the document it writes, is deliberately small: likelihood scored from 1 to 5, impact scored from 1 to 5, the level as their product from 1 to 25, four bands (low up to 4, medium to 9, high to 15, critical above), and an acceptance threshold the company chooses, by default 4, so that a risk at or below it is retained with an owner named and a risk above it is treated. A five-point scale is enough for an auditor to see that two assessments of the same risk a year apart are comparable, and small enough that a team of ten can score twenty risks in an hour. What makes the method defensible is not the numbers but the consistency: the same criteria written down, the same scale for every risk, the same threshold, and the same owner's signature on the residual risk.
The starter risks a software company carries
The identification step is where a template misleads most, because a template's risks are someone else's. A software company's risks are nevertheless largely known before the first workshop, and the free page starts from the set the product seeds: phishing that compromises a credential, a lost or stolen laptop, the unavailability of a critical cloud service, a backup that does not restore, a departing employee whose access stays open, equipment disposed of with data on it, a supplier or cloud provider breach, an incident not detected or reported in time, a legal or contractual requirement missed, security responsibilities unowned, people joining or leaving without the security basics, information shared insecurely; and, where the answers say so, a vulnerability introduced in the company's own software, supplier-written code reaching production unreviewed, an unauthorised disclosure of personal data, and unauthorised physical access to premises. Five answers pick the set: how many people, whether the company builds software, whether it outsources development, whether it has premises, whether it processes customers' personal data. Each starter risk comes with a likelihood, an impact and the Annex A controls that treat it, all editable, and a risk that does not apply is removed; a risk the set lacks is added with its own controls.
From the plan to the Statement of Applicability
Clause 6.1.3 turns the register into decisions. For each risk above the threshold the company chooses an option: modify the risk with controls, retain it, avoid the activity, or share it with an insurer or a supplier; for a modified risk it names the controls, and the union of those controls is what the Statement of Applicability then carries as applicable. That is why the two documents have to be written in this order: a Statement that names A.8.13 as applicable without a risk that a backup fails to restore has no justification for the row, and a register that treats that risk without A.8.13 has no control for it. The free page writes both directions: the plan lists the controls each treated risk names, and the last section of the document lists every control the plan names, which is the input to the Statement of Applicability written on the next page, control by control.
Owners, acceptance and the interval
Two things an auditor reads before the scores are the owner column and the acceptance. Every risk has an owner (Clause 6.1.2(c)(2)), and every residual risk is accepted by its owner (6.1.3(f)), which is why the page keeps an owner field per row and writes "not named yet" where it is empty rather than leaving the cell blank. The acceptance threshold is a management decision, and a company that raises it from 4 to 9 to make the plan shorter should expect the question of why a high-likelihood, moderate-impact risk is being retained. Clause 8.2 then has the assessment repeated at planned intervals or when significant changes are proposed or occur: a new product surface, a new hosting region, a new sub-processor, a new team. The link the page writes carries the answers, the threshold and each starter risk's scores in the address, so a version is a link that can be kept and compared with the next one.
What to do with it
Answer the five questions and read the starter risks against your own product, removing the ones that do not apply and adding the ones the set lacks. Score each with the five-point scale, set the threshold, name an owner per row, and choose the option for every risk above the line. Copy the document, date it, have the owners accept the residual risks, and take the list of controls at its end into the Statement of Applicability. StandardOS seeds the same starter risks on day one, keeps the score, the owner and the review date on each, and turns every treatment into a position on the Statement; the cost page says how many auditor days the scope buys, and the controls guide what each control the plan names asks for.