An ISO 27001 risk assessment must show how your team identified a risk, judged its likelihood and impact, and selected a treatment. If that chain is unclear, even strong policies and technical controls can look improvised when an auditor asks why a risk was scored or treated in a particular way. These are the five mistakes that most often weaken the process.
Treating risk assessment as a one-off project
Many teams complete a solid risk assessment before their initial audit, then put it aside until recertification approaches. That is a problem. Clause 6.1.2 expects reassessment at planned intervals and when circumstances change.
A review scheduled every 18 months simply because the annual surveillance audit falls in September misses the point. A new email platform launched in March, a company merger, or a contract with a supplier that processes customer data can each change your risk profile.
If your risk register is unchanged between audits, an auditor may reasonably see it as a dead document rather than a working management tool. Put recurring review dates in the calendar, ideally at least quarterly, and trigger an additional review when your business changes: new infrastructure, new compliance duties, or new suppliers handling customer data.
Overengineering the scoring matrix
Five-by-five matrices often become nine-by-nine matrices because one stakeholder wants more precision. More categories usually create more argument. Decision-makers can spend hours debating one score in a matrix with more than 100 rows, often because they do not share the same definition of likelihood or impact.
Keep the matrix simple enough that a risk owner without a security background can understand what a score means. A 3×3 or 5×5 scale, supported by clear written definitions for each likelihood and impact level, is more useful than a granular model nobody trusts.
NIST frames risk assessment as a process that must be prepared, conducted, and maintained, not as a mathematical exercise for its own sake. Your team should also check its assumptions. A recent outage may cause people to overstate the likelihood of a business-process failure, while familiarity with a process can cause them to understate the impact of a data breach.
Writing treatment plans with no owner and no budget
A risk treatment plan that lists actions but not who is responsible, by when, and with what resources is not a plan. It is a wish list. When nobody owns a treatment action, it rarely gets implemented, and residual risk is accepted by default instead of through an informed decision by the actual risk owner.
This is also where ISO 27001 certification submissions can fall apart. Auditors reviewing your Statement of Applicability (SoA) will ask why each Annex A control was included or excluded, and they expect the answer to trace back to a specific risk finding, not a checklist completed from memory. If you are building or refreshing your SoA, it helps to work from a structured breakdown of what ISO 27001 certification requires at each stage, so control selection and the risk register stay connected during implementation.
Using the assessment to justify a predetermined outcome
Some companies conduct the risk assessment and then implement every Annex A control regardless of the results. They would rather include too many controls than explain an exclusion. Others rule out costly controls first, then ask risk owners to supply a justification after the fact.
Neither approach estimates the actual risk or creates an evidence trail an auditor can follow. The assessment should determine which controls are necessary. If a control is excluded, the Statement of Applicability should identify the related risk and show that the risk owner accepts the residual risk. It should never be a mere assumption.
Treating the whole thing as a certification checkbox
The most serious mistake beneath all the others is treating an information security risk assessment as a task completed solely to satisfy an audit. When that happens, it gets rushed, assigned to the first available person, and abandoned once the certificate is issued.
The financial stakes are real. IBM’s 2026 Cost of a Data Breach Report puts the global average cost of a breach at $4.99 million. A current, well-scoped risk register gives leadership a practical way to spot, fund, and track material risks before they become incidents.
For your business, the next step is straightforward: treat the register as part of risk management, not as certification paperwork. Run an honest gap analysis before the first certification cycle, then use management review to challenge overdue treatments, changing assumptions, and the biases in your security strategy that can quietly distort the next decision.
