A green security dashboard can coexist with an unanswered question: could the company deliver to customers tomorrow if its main system stopped working? For a board, that gap matters more than the colour of the dashboard.
My recommendation is to organize cyber reporting around a few business consequences and the evidence behind management’s assessment. The report should help directors decide whether the exposure is acceptable, whether priorities need to change, and when they need stronger assurance.
It should also make uncertainty visible. An honest “not tested” gives the board something to act on. An unsupported green light can close the discussion too early.
Begin with the service customers depend on
Choose a small set of critical activities, such as accepting orders, paying employees or delivering a contracted service. Management should explain what an interruption or data compromise would mean for each: missed deliveries, customer notification, cash delays, manual work or contractual consequences.
Describe a plausible scenario and the important dependencies. Avoid turning a speculative maximum loss into a precise-looking forecast. If management estimates an amount in NOK, ask for the assumptions, the period covered and whether it describes revenue delayed, margin lost or cash required. Those are different business effects.
NSM’s principles for security management support adapting security work to the organization and integrating it into management. The reporting format below is my practical proposal, not an NSM template or a statement that every company is subject to the Security Act.
Replace a status colour with an evidence statement
Consider a hypothetical Norwegian distributor. Its monthly report says backups are successful and security status is green. In a recovery exercise, however, the order database is restored in six hours while the warehouse integration remains unavailable. The company’s internally agreed target is to resume dispatch within eight hours.
“Database restored” is a technical result. It does not demonstrate that the company can dispatch orders within its target. The useful board statement is: the database test passed, end-to-end dispatch recovery has not been demonstrated, and management cannot yet substantiate the eight-hour target.
That wording preserves both progress and the gap. It does not mean the board must choose backup software. It means management must present a credible next step and the board must consider the consequences of continuing with the unresolved exposure.
A short report the board can challenge
For each material scenario, ask management to provide these six elements:
- Business exposure: the activity at risk, the likely operational consequences and the assumptions behind any financial estimate.
- Expected outcome: the recovery or protection objective, who agreed it and why it fits the business.
- Evidence: the last relevant test or review, its date, scope and observed result.
- Limitations: excluded systems, untested dependencies, stale information and conflicting findings.
- Response: the responsible executive, next action, due date and any temporary measure.
- Board decision: the options, resources or risk acceptance requested, including when that decision must be revisited.
Not every row requires a new board decision. Some belong in ordinary management follow-up. Make the distinction explicit so directors spend time on matters that need their attention.
Keep detailed technical material available behind the report. A concise first page should make the evidence easier to examine, not conceal it.
Measures need a denominator and a business meaning
“95% protected” is incomplete unless the board knows what is counted and what is missing. Coverage of staff accounts says little about a powerful supplier account excluded from the calculation. A falling incident count could reflect better protection, reduced activity or weaker detection.
Ask for trends only when definitions and scope are comparable. If the scope changes, say so. Pair implementation measures with outcome evidence: not only whether a control is installed, but whether a relevant test shows that it works under the conditions the company depends on.
The board does not need a catalogue of every alert. It needs to understand which exceptions could materially affect the business, how long they have remained open, and why management believes the response is adequate.
Decide when management’s assurance needs checking
A small AS may get useful assurance from a focused recovery exercise with clear evidence and an independent challenge of its most important assumptions. A more complex or exposed business may need specialist testing or a wider review. Set the scope around the consequence being assessed, rather than buying an audit simply to obtain a reassuring label.
NSM’s guidance on management review identifies incidents, audit findings and changes as relevant inputs to improvement. It is guidance for management review, not a substitute for deciding what the board needs to see. Sources were checked on 12 October 2026.
Where IT is outsourced, ask whose evidence supports each claim and whether it covers the company’s actual service. The allocation of responsibility deserves separate attention: outsourced IT still needs an internal owner.
Agree what cannot wait for the next meeting
Set triggers for prompt escalation with the CEO: for example, a material incident, a failed critical recovery test, or a significant exposure that remains unresolved beyond an agreed deadline. Adapt them to the company, and distinguish board escalation from external notification duties.
In an incident, management must be able to act within its mandate without waiting for a scheduled board presentation. The CEO’s decisions during a cyber incident are a separate operational task.
At the next board meeting, take one green status and ask: “What was tested, what did the result demonstrate, and what remains unknown?” The quality of that answer is a better starting point than another dashboard colour.