ISO 27001 clause 9 without the slide deck: internal audit and management review on a derived posture

What clause 9 asks for

Clause 9 of ISO/IEC 27001:2022 is the “check” of plan-do-check-act, in three parts: 9.1 monitoring, measurement, analysis and evaluation — what to monitor, by which methods, when, by whom, and the results kept as documented information; 9.2 internal audit at planned intervals, with a programme, criteria and scope, impartial auditors, and results reported to management; 9.3 management review at planned intervals, with a prescribed set of inputs (status of previous actions, changes in context, feedback on performance including nonconformities and audit results, risk assessment results, opportunities) and outputs (decisions on improvement and changes).

The clause is not asking for a deck. It is asking for a repeatable evaluation of the same things, at intervals, with the results kept — and for management to decide on them. The deck is what organisations produce because the underlying data is not in a shape that can be compared across intervals.

Management review needs two things: a state at time A, a state at time B, and the reasons for the difference. A slide can show one of those.

9.1 — Monitoring on records, not on status columns

“Determine what needs to be monitored and measured” is a question about which records carry the numbers. If posture is derived — adoption, applicability, coverage, evidence with dates — the monitoring is already defined: applicable requirements, covered requirements, controls with current evidence, open findings by severity, overdue actions. Each of those is countable from the record at any time, by anyone, with the same result. Compare that with a status column typed by the control owner before the review: monitored, technically; measured, not really.

Documented information for 9.1 then stops being a report someone writes and becomes a snapshot someone takes — a frozen copy of the derived state on a date.

9.2 — Internal audit against the same record

An internal auditor needs criteria and scope, and evidence. When applicability decisions carry reasons and scopes, when controls link to requirements and to the assets they protect, when evidence carries collection dates, the audit trail is the record itself: pick a requirement, follow it to the decision, the control, the assets, the evidence, the newest date. Sampling becomes cheap, which means the audit programme can cover more, which is what impartial auditors have always wanted and rarely get.

Two audit findings that a derived posture makes hard to hide, and which the auditor should look for first: requirements nobody decided on (undecided is not “not applicable”), and controls whose evidence has aged past their own review period.

9.3 — Management review as a delta

Take the inputs clause 9.3 lists and map them onto two snapshots, taken at the last review and now:

9.3 input	Where it comes from
Status of actions from previous reviews	Findings and treatment actions closed / still open since snapshot A
Changes in external and internal issues	Framework version adopted (a new Annex A edition, a new pack version), scope changes, new services or providers in the inventory
Feedback on performance — nonconformities and corrective actions	Findings opened and closed between A and B, by severity
Monitoring and measurement results	Coverage and evidence-currency figures at A and B
Audit results	Internal audit findings recorded as findings
Fulfilment of objectives	The objectives you set as targets on the same figures
Risk assessment and treatment status	Register entries assessed since A; treatments due, done, overdue; acceptances expiring
Opportunities for continual improvement	What the delta suggests

The review’s outputs — decisions on improvement, changes to the ISMS, resource needs — become findings and actions with owners and dates, which are the “status of actions” input of the next review. The loop closes on records, and the deck, if you still want one, is a rendering of the delta.

What changes for the team

• Nobody prepares “the review numbers” — they are taken, not made.
• The uncomfortable rows (undecided, stale, overdue) are on the same list as the good ones; nothing is filtered by the person being reviewed.
• Two reviews apart, the trend is a diff with reasons attached to every line, which is what “continual improvement” is supposed to mean.

In Secantra

Posture is derived from adoption, applicability, coverage and evidence and cannot be typed; a posture snapshot freezes the derived state at a moment — adoptions, applicability buckets, coverage buckets, open work items — as an immutable copy, so “state as of the last review” and “state as of today” are two records to compare. Findings carry severity, owner and status; treatment actions carry due dates; risk register entries carry assessments over time and acceptances with expiry; framework packs are versioned and adopted at a pinned version, so “we moved to the new edition” is a dated event, not a memory. There is no report generator: the review is yours to write, from the two snapshots.

Checklist

• 9.1: the monitored quantities are countable from records, not typed; results kept as dated snapshots
• 9.2: audit samples follow requirement → decision → control → asset → evidence; undecided and stale are the first two questions
• 9.3: inputs mapped onto two snapshots; outputs recorded as findings and actions with owners and dates
• Framework edition changes are dated adoption events
• No number in the review that cannot be recomputed from the record