Risk analysis: the input to your audit, not an appendix to it

In practice, most organisations manage with a qualitative approach — a likelihood × impact matrix — as long as they can defend it. A semi-quantitative approach works with indices, a quantitative one with financial modelling. The choice depends on the requirements that apply to you, on the standards you already use and on what the organisation needs.

If you want a reference process, ISO/IEC 27005 describes one: establishing the context, identifying, analysing and evaluating risks, treating them, and monitoring and reviewing the result. It is written to fit ISO/IEC 27001. If you already have a methodology in place — because of ISO/IEC 27001 or group rules, for example — there is no point in replacing it.

More than one framework asks you for a risk analysis at the same time.

• ISO/IEC 27001. Clause 6.1.2 asks for a defined information security risk assessment process, and clause 8.2 for the assessment to be repeated — on a schedule you set and whenever something significant changes. Alongside it, clause 6.1.3 expects a risk treatment plan and a Statement of Applicability, and the three have to tell the same story.
• GDPR. Article 32 requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the risk of varying likelihood and severity for the rights and freedoms of natural persons. The risk that counts is the risk to people, not to the organisation — the same assets, seen from the other side.
• DORA. Financial entities must have a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system (Article 6(1)). As part of that framework they have to identify, classify and adequately document all ICT supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions, and their roles and dependencies in relation to ICT risk (Article 8(1)). The framework has to be reviewed at least once a year (Article 6(5)); microenterprises review it periodically.

What follows in practice. If you face ISO/IEC 27001 certification and also answer to GDPR or DORA, do not build two analyses. One risk register with two views of the output is usually cheaper, stays consistent and is easier to defend at audit than two documents that rate the same asset differently.

For a first analysis a spreadsheet really is enough, and we will not claim otherwise. It stops being enough when someone has to show, a year later, what changed and who approved it.

• A spreadsheet has no history. It cannot show when and why a rating changed.
• A spreadsheet has no links. Asset, risk, measure and owner sit next to each other, not together.
• A spreadsheet has no approval. It does not show who signed off the acceptance of residual risk.

That is what Anrix is for: the same register, with the history, the links and the approval step.

We do the analysis with an auditor’s eye: the difference between an analysis that looks good and one that holds up is visible only from the other side of the table.

Neither a tool nor a consultant can decide for you which asset is critical and whether residual risk is acceptable. That is a decision management signs — and that is how it should be.

If you would rather run the analysis yourself, start with Anrix. If you want to talk it through first, the form below reaches us.

Status verified as of 10 October 2026.