How to Run an ISMS Risk Assessment: 6 Steps from Asset Inventory to the Statement of Applicability

Where Risk Assessment Sits in ISO/IEC 27001

Risk assessment is the only bridge in an ISMS between what you protect and which controls you implement. Pick controls first and reason backwards, and an auditor will ask for the justification every time. The standard asks for four things.

• Clause 6.1.2 (information security risk assessment) — define risk acceptance criteria and criteria for performing assessments, so the process produces consistent, valid and comparable results. It covers identifying, analysing and evaluating risk, and identifying risk owners.
• Clause 6.1.3 (information security risk treatment) — select treatment options, determine the necessary controls, compare them against Annex A to check nothing was overlooked, and produce a Statement of Applicability (SoA). Risk owners must approve the treatment plan and the residual risks.
• Clauses 8.2 / 8.3 — perform assessments at planned intervals and when significant changes occur, implement the treatment plan, and retain the results as documented information.
• Annex A — a reference list of 93 controls. It is not a menu to pick from, but a checklist you compare your determined controls against.

For the wider timeline, see our guide to the ISO 27001 certification process. As a rule, start right after the scope is fixed and well before you implement controls.

Step 1: Define Risk Criteria Before You Touch the Assets

The first thing you decide is criteria, not assets. Start listing assets without criteria and every reviewer scores differently, which means rescoring everything later. You need four things: a likelihood scale, an impact scale, a scoring method, and risk acceptance criteria. For a smaller organisation, three levels are enough.

Measure impact as the business consequence of losing confidentiality, integrity or availability (CIA). Worked examples in the criteria document, such as "customer data disclosed externally is Major (3)", keep scoring stable. State the risk acceptance criteria numerically too, for example "scores of 3 or below are accepted; 4 and above require treatment".

Step 2: Inventory Information Assets and Build the Asset Register

Next, inventory the information assets inside your scope. That means not only the data itself but the systems that hold and process it, and the people and places involved. At minimum, the register should carry these fields.

Granularity is where this succeeds or fails. Counting individual files gives you thousands of rows nobody maintains; lumping everything into "internal systems" is too coarse to map to controls. A workable unit is one business system, one database, or one shared folder, which lands around 50 to 150 entries for an organisation of up to 100 people. The register is also a document certification expects, so organise it alongside the ISMS documents you need.

Step 3: Identify Threats and Vulnerabilities (Asset-Based and Event-Based)

There are two broad approaches to identifying risk, and ISO/IEC 27001:2022 does not mandate either. In practice, combining them works best.

• Asset-based approach — for each asset, pair a threat (what could happen) with a vulnerability (why it could happen). For example: customer master data, misconfigured permissions, dormant accounts of former employees, leading to unauthorised access. Coverage is strong, but the row count grows quickly.
• Event-based (scenario) approach — start from plausible events such as "ransomware halts the core system". Fewer entries and easier to explain to management, but you need a separate checklist to confirm nothing is missing.
• Combining them — use the asset register for coverage, then add high-impact events (supply chain, insider misuse, disaster, cloud provider outage) as separate scenarios.

Assign a risk owner to every risk at this point. The standard asks for owners of risks, not owners of assets: the person who decides the treatment and approves the residual risk. In practice that is department-head level.

Steps 4 and 5: Analyse and Evaluate to Set Priorities

Using the scales from step 1, assign likelihood and impact to each identified risk and calculate the score. Analyse the risk as it stands with existing controls in place. Score everything as if nothing were in place and every row comes out critical, which gives you no priorities at all.

Evaluation compares those scores against the acceptance criteria and selects the risks that need treatment. When scores tie, ordering by legal or contractual obligation, then business continuity impact, then cost-effectiveness is the easiest to defend. What comes out of this is the risk assessment table.

Step 6: The Four Treatment Options and Selecting Annex A Controls

For every risk that needs treatment, choose one of four options. You do not have to mitigate everything; what matters is that the reasoning behind accepting or sharing a risk is on record.

The Statement of Applicability and the Risk Treatment Plan

Once options are chosen, determine the necessary controls and compare them against the 93 Annex A controls to confirm nothing was overlooked. That comparison produces the Statement of Applicability (SoA), recording applicable controls, the justification for including them, implementation status, and the reason for excluding any control. Marking a control as not applicable is fine; the reason just has to be consistent with the assessment results.

1. Decide the treatment option (modify, avoid, share, retain) for each risk
2. For risks you decided to modify, determine the specific controls needed
3. Compare the determined controls against Annex A and check for overlooked areas
4. Record applicable controls, justification, implementation status and exclusion reasons in the SoA
5. Break the work down in the risk treatment plan: actions, owners, deadlines, resources
6. Calculate residual risk and obtain risk owner approval for it and for the treatment plan

Residual Risk Approval and Review Frequency

Residual risk is what remains after controls are applied. Re-evaluate it, confirm it sits within the acceptance criteria, and record the risk owner approval. Going into operation without that approval on record is a common finding. Plan a review at least once a year, and re-assess on top of that whenever something changes: a new system, an office move, a serious incident, or a change of key supplier. For the overall effort involved, see the cost of ISMS certification.

Common Failures and Practical Tips

• Too many assets — past a few hundred file-level rows, the annual review stops happening. Roll up to system, database or shared-folder level.
• Vague criteria and drifting scores — without worked examples for "Moderate impact", the same asset scores differently next year under a new reviewer. Always attach examples to the criteria document.
• SoA and risk assessment table out of step — a control marked applicable in the SoA that is not linked to any risk in the treatment plan. Keep the two cross-referenced.
• Risk owners who are individual contributors — an owner without approval authority makes residual risk approval a formality. Assign roles that can actually sign off.

Managing the Register and the Matrix in a Tool

The outputs so far are four artefacts that all reference each other: the asset register, the risk assessment table, the SoA and the risk treatment plan. Spreadsheets are a fine starting point, but past roughly 100 assets you see register updates that never reach the SoA, forked versions from concurrent editing, and no change history to show who changed a score and when.

Linking the four as one dataset, with change history and approvals captured automatically, turns the annual review into a diff rather than a full re-inventory. Riscala AI for ISMS is built around that shape. If you first want to see how far along your own organisation is, start with the ISMS readiness self-check.

This article is for general information only and does not guarantee any audit outcome or certification. Schemes and costs change, so confirm the latest details with certification bodies.