Risk Management

A risk register your engineers recognise and your auditor accepts.

The problem

You have a spreadsheet of risks that someone wrote before the last audit, scored red-amber-green, and never opened again. It does not reflect the systems you run, it does not drive any decision, and everyone knows it.

The method.

Fix a methodology before scoring anything

Define the risk assessment methodology ISO 27001 Clause 6.1.2 requires: asset-and-threat based or scenario based, the impact and likelihood scales, the risk acceptance criteria, and who is allowed to accept what. Without this, scores are opinions and an auditor will say so.

Identify risks from the real estate

Risks are derived from the actual asset inventory, data flows, cloud architecture and supplier list, not from a generic threat catalogue. Workshops with engineering, not just with management, because the people who know where the single point of failure lives are the ones on call for it.

Score, treat, and record the decision

Each risk gets an inherent score, a treatment decision (mitigate, transfer, avoid, accept), the Annex A controls that treat it, a residual score and a named owner. Accepted risks are signed by someone with the authority to accept them and carry an expiry date.

Drive the treatment plan into work

The risk treatment plan becomes a backlog with dates. Progress is reviewed monthly. A treatment that slips twice is escalated to a risk acceptance decision, because an untreated risk that is silently overdue is worse than one that has been consciously accepted.

Keep it alive against triggers

The register is re-assessed on events, not only on calendar: a new product, a new region, a new material supplier, a significant incident, a new regulatory obligation. This is what turns the register from an audit artifact into a management tool.

The ROC continuously tests whether the controls that treat each risk are still operating. When a control stops running, the residual score on the risks it treats changes automatically, so the register reflects reality between assessments instead of only after them.

What is an information security risk register?

A risk register is the maintained record of identified information security risks, each with an assessed likelihood and impact, a treatment decision, the controls applied, a residual score after treatment, and a named owner. ISO 27001 requires one, along with a documented methodology explaining how risks are scored and who may accept them.

How often should a risk assessment be reviewed?

At minimum annually, and additionally whenever something material changes: a new product or market, a significant architectural change, a new critical supplier, a serious incident, or a new regulatory obligation. Calendar-only reviews mean a risk register that describes the company as it was, not as it is.

Who is allowed to accept a security risk?

Only a person with the authority to bear the consequence, defined in the risk acceptance criteria before any scoring is done. In practice this usually means an executive for high risks and a system owner for low ones. Every acceptance should be recorded, signed and given an expiry date, so that accepting a risk is a decision rather than a way of ignoring it.