ISMS management review: How do you prepare decisions?

A good ISMS management review ends with decisions: what do we change? Which resources do we approve? Who takes the next step? A report on completed tasks is an input, rather than the result. Our ISMS guide explains how this management perspective fits into the overall security process.

This guide shows how to turn existing reports into a concise decision brief. The proposed structure is a working aid, not a complete standards checklist.

What must management be able to decide?

The management review considers whether your ISMS suits the organisation and operates effectively. In its comparison with ISO 27001, EASA explicitly places this evaluation within management’s remit. Risk assessments and the status of risk treatment are relevant inputs. The additional aviation-specific requirements of Part-IS cannot be generalised to every organisation. EASA, Appendix IV

For preparation, this means reports must reveal where a decision is missing. “Four measures overdue” does not explain whether staffing is insufficient, a dependency is blocking progress or priorities are wrong.

Instead, write: “The customer service recovery test has been postponed because the same person is handling the migration. We need a decision on capacity and how to deal with the remaining uncertainty.”

Gather inputs with a specific review question

Define a reporting period and data cutoff. Link to original records rather than copying them in full into slides. This selection helps with preparation; add the requirements that apply to your ISMS.

Identify gaps. If a report is outdated or excludes an important location, a green overall assessment must not conceal that uncertainty. Check whether your ISMS evidence is still current and suitable for the question.

NIST CSF 2.0 connects evaluation of security work with adjustments to the risk strategy. It also treats clear responsibilities and appropriate resources as part of governance. This supports a review that leads to decisions. NIST CSF 2.0, GV.OV and GV.RR

Write a short brief for each decision

A decision brief needs six elements:

1. Finding: What is evidenced, by which source and from which date?
2. Impact: Which business process or information asset is affected?
3. Options: Which realistic courses of action are available?
4. Recommendation: Which option does the subject-matter owner propose?
5. Resources: What working time, budget or support is missing?
6. Decision needed: Who must decide what, and by when?

Separate the recommendation from the actual decision. “Budget requested” is not approval. “Risk discussed” is not a documented risk decision. Accepting a residual risk requires reasoned risk acceptance with owners and a review trigger.

Example: A test is missing, yet the schedule is green

Fictional case: An IT service provider has configured new backups. The measure is marked as implemented. A recovery test under the conditions required by customer service is still missing.

The brief records that setup is evidenced, but recovery within the required scope is not. The options are to prioritise a test with reserved capacity or justify postponement with clear responsibility for the residual risk. Merely changing the due date does not answer this question.

In this example, management allocates capacity for the test. The operations owner schedules it. The result is documented against the measure and assessed by the relevant specialist. Only then can the team judge whether further treatment is necessary.

This example sets no universal test frequency or acceptable downtime. Those depend on your needs and requirements.

Record decisions so someone can act on them

Use this row as a decision template. Enter the decision only after it has actually been made.

A useful record includes the decision, reasoning, owner, deadline and expected verification result. If a decision is deferred, add an investigation task and a new decision date.

Link the record to the affected tasks. At the next review, you can see whether the decision was implemented and what it achieved. A completed task list is insufficient if the original problem persists.

For metrics, distinguish activity from effect: the number of completed tests describes work. Whether critical services could actually be recovered describes a result. Read more in our article on ISMS metrics.

How Kopexa supports preparation

In Kopexa, you can manage objectives and KPIs and update metrics through the API. In work item management, measures hold their evidence and are mapped to controls. These relationships help you bring implementation and evidence together for a finding.

Assessment remains your responsibility: which deviation matters? Which resource is needed? What does management decide? A current metric does not automatically answer these questions.

Check before the meeting

Can management make a decision using the brief without first reconstructing the data? Are unresolved uncertainties visible? Does every decision have an owner, a deadline and a verifiable result?

If those details are missing, improve the brief. More slides will not solve the problem.