ISO 27001 Clause 4.4: run the ISMS as a system, not a binder

The surveillance audit is booked, and the ISMS you built for certification has quietly stopped moving. The risk register hasn't changed since the last visit, and nobody can say which process feeds which. That is the position ISO 27001 Clause 4.4 is written to prevent.

This guide is for CISOs, security leads and compliance owners at 25–250 person firms heading into certification or surveillance. It covers what the clause demands and why documented systems still fail. Then it walks through the operating loop, the one-page process map, what auditors sample, and how to automate the rhythm so evidence appears as a by-product.

What does ISO 27001 Clause 4.4 require?

ISO 27001 Clause 4.4 requires the organisation to establish, implement, maintain and continually improve an information security management system. It must also understand which processes the system needs and how they connect. Certification attests to a working system, not a stack of policies, and the joins between processes are part of the requirement.

The ISO/IEC 27001 standard overview describes the ISMS as something companies of any size establish, implement, maintain and continually improve. Clause 4.4 turns that sentence into an obligation, and every other clause fills in the detail.

Read the four verbs in plain English:

• Establish: stand the system up inside the boundary set by Clause 4.3.
• Implement: run it, with processes that have owners, cadences and outputs.
• Maintain: keep it current as the company, the stack and the suppliers change.
• Continually improve: feed incidents, audit findings and review decisions back into the system.

The 2022 edition sharpened one point. You are expected to know your processes and how they connect: what each consumes, what it produces, and which other process picks that output up. Risk assessment feeds treatment. Incidents feed improvement. Everything surfaces at management review.

A platform purchase is not an ISMS. A policy pack answers what you say you do, whereas Clause 4.4 asks what happens on an ordinary Tuesday and who notices when it doesn't.

Clause 4.4 also sits in a sequence. Scope comes first under Clause 4.3, and the operating rhythm of Clauses 9 and 10 comes after. The clause is the frame between them. That is why it has no deliverable of its own, and why auditors read it through everything else they sample.

The clause scales down but not out. A 50-person firm runs a handful of recurring processes with named owners, not a sprawling architecture. Each of those processes still has to turn, and still has to hand something to the next.

Why does a documented ISMS still fail surveillance audits?

Surveillance audits, the yearly check-ins between certifications, exist to catch systems that ran once. A binder ISMS has complete documents but nothing running. A platform-as-ISMS shows green dashboards with no human rhythm of review, audit and decision behind them. Auditors certify operation, so the binder ISMS fails its first surveillance visit.

The NCSC Risk Management Guidance advocates risk management that reflects your real risks and how you operate, not techniques that just satisfy compliance. Auditors apply the same instinct to an ISMS. A system built to pass one audit is built for the audit, not for the company.

A risk register untouched since the consultant left isn't a risk register.

Four more patterns recur beside those two:

• Isolated processes. A risk assessment never alters treatments, or incidents never reach lessons learned.
• Stale documentation. Procedures describe the company of two years ago, and pre-migration architecture diagrams are an auditor favourite.
• Knowledge in one head. When that person leaves, the system provably stops.
• Open-ended actions. Corrective actions get raised but never closed.

The two traps fail on different questions. The binder fails on history: "show me the register over the last six months." The platform fails on decisions: "what did you change after that alert?" Both lack the same thing: evidence of a person acting on what the system shows.

Failure here is rarely dramatic. It is a quiet drift: a review that slips a month, an owner who moves teams, an action that nobody chases.

A system that survives surveillance looks unremarkable. The register shows dated movement, reviews sit in calendars with minutes behind them, and actions close only once someone has checked the fix.

How does the ISMS operating loop turn between audits?

The core loop at 50-person scale runs risk assessment, risk treatment, control operation, monitoring and internal audit, management review and corrective action, with incident learnings fed in wherever they land. Each stage has an owner and a calendar slot: monthly or quarterly security reviews, an internal audit plan, and management review at least annually.

Start from objectives leadership actually cares about, so the review loop discusses performance rather than paperwork. The NCSC Cyber Governance for Boards describes cyber risk as a principal business risk that boards have a critical responsibility to govern. Management review is where that duty meets the ISMS.

Put the rhythm in real calendars:

• Security operations review, monthly or quarterly: register movement, access review results, open actions and incidents.
• Internal audit, on a plan: different parts of the ISMS sampled across the year rather than one frantic week.
• Management review, at least annually: inputs from every earlier stage, with decisions minuted.
• Incident feedback, whenever it lands: each incident ends in a register update, a control change or a procedure fix.

The ISMS is these meetings happening, with evidence behind them. Owners matter as much as slots, because each stage needs one name rather than a team.

Corrective actions need the tightest loop of all, because an open-ended action list is the most common way an otherwise good system fails surveillance. Run each one through five steps:

1. Finding raised from an audit, an incident or a review.
2. Owner assigned by name, with a due date.
3. Action taken and recorded in the ticket.
4. Verification that the fix worked, by someone other than the owner where practical.
5. Closed only after verification.

Keep documents current with the company as it is today. When you migrate cloud providers, change identity provider or lose a key supplier, update the register, the diagrams and the procedures in the same change.

Expect the loop to need two full cycles before it feels routine. Certification bodies want to see at least one completed cycle before they issue the certificate, so start the calendar early.

How do you map ISMS process interactions on one page?

Sketch one page listing each ISMS process, what goes into it, what comes out, and which other process uses that output. This map is the cheapest artefact that meets the interactions expectation. It also exposes orphaned processes producing reports nobody reads, before an auditor finds them.

Build it in four passes:

1. List the recurring activities. Risk assessment, treatment, access review, internal audit, incident handling, management review and corrective action are the usual set.
2. Record inputs and outputs for each, in one line apiece.
3. Name the consumer. For every output, write down which other process takes it.
4. Mark the orphans. An output with no consumer, or an input with no producer, is a gap to fix or a process to drop.

Interactions are easiest to understand through one process. An access review takes the user list from the identity provider and produces removals and exceptions. The removals become tickets in control operation, exceptions that persist feed the risk register, and the monthly security review hears the totals. That chain is what "interactions" means in daily operation.

Resist adding processes the standard doesn't demand and you won't run. Every process you declare is one the auditor may sample, so a map of eight processes you operate beats one of twenty you don't.

Alongside the map, the evidence an auditor expects to see is ordinary:

• The core ISMS document set, with the map on top and reviewed at each management review so it changes when the processes do.
• A risk register with dated updates and treatments progressing.
• The Statement of Applicability, the master list of which Annex A controls apply and why.
• Minutes and outputs from security reviews, internal audits and management reviews.
• Corrective action records that show closure, not just capture.
• Operational exhaust such as tickets, access reviews and training completions, showing controls ran between audits.

What do auditors sample under Clause 4.4?

Auditors pick one thread and follow it round the loop: a risk into its treatment, the control and its evidence, or an incident into its corrective action and the management review that heard about it. Broken handoffs between processes are the finding, even where each process looks fine alone.

Expect questions like these in the room:

• "Draw me your ISMS. What are its processes, and how does the output of one reach the next?"
• "Show me the risk register's history over the last six months."
• "Take this internal audit finding and walk it to closure."
• "What has the ISMS changed about itself since the last cycle?"

Each question tests a different join. The first tests the map, the second tests whether the register moves, the third tests corrective action, and the fourth tests continual improvement. Answer with the artefact, not a description of it.

The fourth question deserves preparation. A system that changed nothing about itself in a cycle has not improved, however tidy it looks. Keep a short log of changes made after incidents, findings and reviews.

The thread instinct is deliberate. One thread touches several processes, so a single sample tests much of the loop.

A handoff nobody owns is a finding waiting for an auditor to pick the thread.

Questions drift toward ownership too. Expect "who owns this?" at every join. The answer should be a person, with a deputy who could run the next review if the owner left.

Grading follows certification-body practice, in three levels:

• Major: a system that is clearly not operating, with no reviews, a static register and no audit cycle.
• Minor: a single stalled handoff, an out-of-date procedure or a late review.
• Minor aggregating to major: the same weaknesses repeating across processes, which reads as a pattern rather than a slip.

The practical consequence is to close the first stalled handoff before a second appears. One late review is a minor you can fix, whereas late reviews in several processes tell the auditor the system has no rhythm.

How do you automate the ISMS operating rhythm?

Encode the process map as workflows: reviews, audits and corrective actions become scheduled, owned tickets with due dates and escalation. Continuous control monitoring on the IdP, MDM, cloud posture and CI lets controls produce their own evidence. Management review packs then build from live data, not hand-made decks.

Corrective actions route through the same ticketing system, with closure requiring verification, so the closed-loop trail assembles itself. The operating rhythm becomes infrastructure rather than willpower.

In practice, the build looks like this:

• Calendar-driven tickets. Quarterly access reviews, monthly security reviews and the internal audit plan open themselves, assigned to named owners with escalation when overdue.
• Identity and device telemetry. Joiner, mover and leaver data from the IdP and compliance status from MDM show control operation without a screenshot hunt.
• Cloud and pipeline signals. Posture drift and failed CI checks raise tickets that flow into the register when they matter.
• Live review packs. Risk deltas, incident statistics and action ageing pull from the systems of record.

Management review is where this pays off most. A pack generated from live data means the meeting starts with current numbers rather than last quarter's slides, and the minutes record decisions against them.

A dashboard with no meeting behind it is a status light, not a management system.

The meeting is the control and the pack is its input. Keep the human layer for judgement: accepting a risk, funding a treatment, changing an objective.

Start with the loop's weakest join, not the whole stack. If corrective actions stall, automate those first; if the register is stale, schedule its review and wire incident closure to it. A working join in one place beats a platform rollout across all of them.

Everything later gets cheaper. When evidence is a by-product of work, certification, surveillance and a customer's due-diligence request all draw on the same trail. The questionnaire that once meant a hunt through inboxes becomes an export. A security lead who answers from live records gives the buyer something a policy PDF can't: proof the system runs.

Automation removes willpower, not accountability. Someone still has to own the rhythm, chair the reviews and drive actions to closure. A fractional CISO supplies that coordination layer, and GRC engineering builds the workflow-encoded version of the clause: scheduled ownership, continuous monitoring and self-assembling evidence. GRCMANA does both, and Clause 4.4 is covered as part of every whole-standard ISO 27001 engagement.

Frequently asked questions