In short: Risk assessment is the core of every ISMS under ISO/IEC 27001:2022. Clause 6.1.2 requires a risk assessment with defined criteria and named risk owners, clause 6.1.3 requires risk treatment including a Statement of Applicability, and clause 8.2 requires the assessment to be repeated at planned intervals. Which method you use is up to you. This article shows how a mid-sized company can carry out an ISO 27001 risk assessment in seven steps, which mistakes come up again and again, and what auditors want to see.

What ISO 27001 requires for risk assessment

An ISMS (information security management system) manages information risks through defined roles, rules and processes. Anyone building an ISMS starts with the risk assessment right after defining the scope, because it decides which controls you implement and why. ISO/IEC 27001:2022 covers this in three clauses:

  • 6.1.2 Risk assessment. You define risk acceptance criteria and criteria for performing assessments. Repeated assessments must produce consistent, valid and comparable results. You identify risks to the confidentiality, integrity and availability of information within the scope and name a risk owner for each one. You then analyse potential consequences and realistic likelihood, determine the level of risk and evaluate the result against your criteria.
  • 6.1.3 Risk treatment. You select treatment options, determine the necessary controls, compare them with Annex A and produce the Statement of Applicability and a risk treatment plan. Risk owners approve the plan and accept the residual risks.
  • 8.2 and 8.3 Operation. The assessment is repeated at planned intervals and whenever significant changes occur, and the treatment plan is implemented. You retain the results of both as documented information.

A dedicated guideline covers the details: ISO/IEC 27005:2022 describes information security risk management in a way that fits ISO 27001. It cannot be certified against, but it provides the terms and approach that consultants and auditors refer to. Organisations working with the German BSI IT-Grundschutz methodology use BSI Standard 200-3 instead.

Two approaches from ISO/IEC 27005

ISO/IEC 27005:2022 describes two ways to identify risks. Both are valid and can be combined.

  • Event-based approach. You start from scenarios such as “ransomware encrypts the ERP system” or “a service provider loses customer data”. It is quick, matches the way management talks about risk and works well as a starting point.
  • Asset-based approach. You start from your assets, meaning information, systems, processes and suppliers, and ask about threats and vulnerabilities for each one. A threat is a potential cause of harm, a vulnerability is a weakness a threat can exploit. This approach is more thorough but takes more time.

For mid-sized companies a middle path is often practical: scenarios for the most important business processes, backed by a lean asset inventory so that nothing essential is missed.

The risk assessment in seven steps

  1. Adopt the scope. The assessment covers exactly the scope of the ISMS, meaning the sites, departments and systems you defined under clause 4.3. Anything outside the scope that affects it, such as an external data centre operator, is included as an interface.
  2. Define the criteria. Set scales for impact and likelihood, each with a few levels and a description per level, for example by downtime, financial loss or effect on customers. Decide at which risk level action is required and who may accept which risk. Top management approves these criteria.
  3. Record assets and processes. Capture critical business processes, the information behind them, the systems that support them and the suppliers involved. Work at the level at which you make decisions: groups of systems rather than individual machines.
  4. Identify risks and name owners. Collect scenarios in short workshops with the business units. Every risk gets a risk owner, a person with the authority to decide on treatment and budget. This is usually a head of department, not automatically IT.
  5. Analyse and evaluate. Estimate impact and likelihood, taking into account the controls already in place. Compare the result with your acceptance criteria and rank the risks.
  6. Decide on treatment. ISO/IEC 27005 names four options: modify the risk with controls, retain it deliberately, avoid it by stopping an activity, or share it, for instance through insurance or a service provider. Compare the selected controls with Annex A.
  7. Produce the Statement of Applicability and treatment plan. The plan names an owner, a deadline and resources for each control. Risk owners approve it and accept the residual risks in writing.

The Statement of Applicability

The Statement of Applicability (SoA) is the mandatory document that links the risk assessment to the controls. Under clause 6.1.3 d) it contains the necessary controls, the justification for including them, whether they are implemented, and the justification for excluding any Annex A control. Annex A lists 93 controls in four themes: organisational, people, physical and technological.

Annex A is a cross-check, not a checklist. Under 6.1.3 c) you use it to verify that no necessary control has been overlooked. Controls from other sources are explicitly allowed. Every exclusion needs a traceable reason, for example “no in-house software development within the scope” for A.8.25 on the secure development life cycle.

Common mistakes and what auditors want to see

  • Too granular. Every laptop as a separate asset, every threat as a separate row. The register grows to hundreds of entries, nobody maintains it and the important risks get lost.
  • No risk owners. All risks sit with the head of IT, or with nobody. Then the approval required by 6.1.3 f) is missing and residual risks are accepted by someone without the authority to do so.
  • A spreadsheet without treatment. Risks are rated, but high risks have neither a control nor a documented acceptance, and the plan has no deadlines.
  • Done once, never again. The assessment is produced shortly before the audit and never touched afterwards. Clause 8.2 requires repetition at planned intervals and after significant changes.
  • Undefined criteria. “High” without a description gives two results from two people. That conflicts with the requirement for comparable results.

In the certification audit, stage 1 reviews the documents: method, criteria, risk register, Statement of Applicability and treatment plan. Stage 2 looks at how the system works in practice. Auditors may, for example, follow one risk from the register to the implemented control, talk to risk owners, review approvals and acceptances, and ask how a new supplier or an incident was reflected in the assessment.

How GermanAI Defense helps

We went through the risk assessment for our own ISMS and have been certified to ISO/IEC 27001:2022 since May 2026 (certificate no. 26052601). Together with your team we define the criteria, run the workshops with the business units and build the risk register, Statement of Applicability and treatment plan so that they can be maintained in day-to-day operation. On request we also take on technical controls such as penetration testing and SOC monitoring around the clock, with service and response times as agreed in the contract.

→ From current state to audit: ISO 27001 consulting

→ What an ISO certificate means for NIS2: ISO 27001 and NIS2 compared

→ Testing vulnerabilities technically: Penetration testing

Sources

As of 28 October 2026. This article is a professional overview and does not replace advice in individual cases.