ISO 27001 Clause 8.1: operational planning and control in practice

The due-diligence questionnaire asks how ISO 27001 Clause 8.1 works in your firm. You have the policies and a polished risk register. What you don't have is a trail of tickets, approvals and supplier files showing any of it running, and Stage 2 is booked.

This guide is for CISOs and IT leads at 25–250 person firms. It shows how to turn Clause 6 plans into routines with pass/fail criteria, named owners and deputies, a change gate engineers will actually use, and supplier oversight that holds. It ends with the automation that makes the evidence produce itself.

What does ISO 27001 operational planning and control require under Clause 8.1?

Clause 8.1 requires you to run the processes decided in Clause 6 as real, daily operations. Each process needs defined success criteria and enough records to prove it ran as designed. The clause then adds two disciplines: governed change, and outsourced processes that touch the ISMS kept under your control.

The inputs come from Clause 6: the risk treatment plan and the security objectives. Clause 8.1 is where those documents stop being plans. Each decision in them needs a process that someone runs, a bar that says whether it ran properly, and a record that proves it.

The change discipline has two halves. Deliberate changes are assessed before they land, so nobody discovers the security impact in production. Surprises are reviewed afterwards and their fallout contained, so an out-of-band change becomes a finding you act on rather than a mystery.

Record-keeping follows the documented-information rules in Clause 7.5, which the FAQ below picks up. Most of the rest is good practice a competent IT team already wants: a ticket for each change, an owner for each task, and a contract that says what the host must do. The clause asks you to do these consistently and to show it.

How is Clause 8.1 different from the Annex A controls?

Annex A lists the individual safeguards, the what. Clause 8.1 is the mainline requirement that those safeguards run as controlled processes with criteria, owners and records, the how. A firm can hold every Annex A control on paper and still fail Clause 8.1, because paper shows intent while the clause demands operation.

Searches for ISO 27001 8.1 often land here, and so do searches for ISO 27001 Annex A 8.1. That is a different requirement: Annex A control 8.1 covers user endpoint devices. Clause 8.1 sits in the mainline requirements and governs how every Annex A control runs, that one included.

Test any Annex A control you claim against three questions:

• Criteria: what does "run properly" mean, in terms an auditor can test?
• Owner: which named person runs it, and who covers them?
• Records: which system output proves the last run?

A control that answers all three is operating. One that answers none is an entry in an inventory, and an inventory tells the auditor what you intend, not what happened last Tuesday.

Why does ISO 27001 Clause 8.1 decide certification?

Clause 8.1 is where the auditor stops asking for intent and asks for operational proof: tickets, approvals and logs. A firm with flawless policies and a tidy risk register can still fail Stage 2 here. Failing to produce that proof on demand routinely grades as a major nonconformity, which blocks certification.

Proof means a record the process produced at the time it ran. If the artefact can only be rebuilt from memory, the process did not run as designed.

The commercial damage arrives before the auditor does. Uncontrolled changes are the classic cause of self-inflicted outages, and an unmanaged IT supplier or MSP is a breach vector that no client contract will excuse.

Regulators read operational failure the same way. The ICO Guide to Data Security states that UK GDPR requires a process for regularly testing, assessing and evaluating the effectiveness of your security measures. Enforcement under GDPR's security article, NIS2 and DORA rests on operational control failures, not missing policy documents.

The way through is not more documentation. It is a short list of routines that run to a stated bar, a change gate people use, and supplier oversight that recurs. The next sections build each in turn.

How do you define pass/fail criteria for recurring security routines?

List every recurring security routine, then write a pass/fail bar for each. Joiner and leaver processing, patching, vulnerability scanning, backups and access reviews all need a definition of done that ties back to the Clause 6 treatment plan. A vague aspiration is not a criterion an auditor can test.

These examples show the shape of a usable bar:

• Joiners and leavers: access granted only against an approved ticket, and removed inside your agreed window of the HR leave date.
• Patching: patches applied inside the timelines in your patch policy, with exceptions logged and approved.
• Vulnerability scanning: scans completed on schedule, with every high-severity finding triaged into a ticket.
• Backups: jobs complete without error, and a restore test passes on its schedule.
• Access reviews: reviews finished on cadence, with every revocation actioned and recorded.

If the treatment plan says leaver access is a risk you are reducing, the bar must measure that reduction, not a convenient proxy such as the number of tickets closed.

The pitfall this prevents is paper compliance: policies that describe routines nobody runs. Clause 8.1 is designed to expose exactly that, so write each bar from what your team does today, then improve the practice rather than the prose.

Who owns each routine, and who covers when they leave?

A named individual owns each routine, and a designated deputy covers absence. Routines assigned to IT become nobody's job at the first reorganisation, and single-owner routines stop the week that person is on leave or resigns. Short procedures, around two pages each, keep the knowledge in a document rather than one engineer's head.

Write every procedure to the same shape, so auditors and deputies find the same things each time:

• Success criteria, taken from the pass/fail bar.
• A named owner and a named deputy.
• The steps, in the order an engineer follows them.
• The record the run produces, and where it lives.

Ownership needs one authoritative home, such as an asset or process register naming who runs what. When an auditor asks who ran vulnerability scanning during a holiday, the register and the ticket history should answer together.

Scale changes the mechanics, not the principle. At 25 people the deputy is often a peer from another team. At 250 you route by function, with a deputy inside each team. Either way, no routine has a single point of failure.

How much change governance is enough for a 50-person firm?

Enough is a lightweight gate: what is changing, what could break security, who approved it, and how to roll back. At 50 people that is a pull-request template or ticket form, not a change advisory board. Emergency changes get fast-tracked approval plus a mandatory look-back, and configuration drift gets measured and corrected.

Put the gate where engineers already work. For code and infrastructure that is a pull-request template with required fields. For SaaS and process changes it is a short ticket form. Four fields take minutes to complete, and the approver is a named reviewer rather than a committee.

An approval gate that takes a week isn't a control. It's a countdown to the workaround.

Emergencies need their own path, because pretending they won't happen guarantees an unrecorded one. Use this sequence:

1. Fast-track authorisation from a named approver, recorded in the ticket even if given by message or call.
2. Fix and contain the problem, noting every change made under pressure.
3. Retrospective soon afterwards: a security review of what changed and a cause analysis of why it was needed.
4. Baseline restoration to the last known-good configuration wherever the emergency fix departed from it.

Drift is the unplanned cousin of change. The NIST SP 800-128 Configuration Management Guide sets the goal of security-focused configuration management as managing and monitoring system configurations to achieve adequate security and minimise organisational risk. In practice you agree the approved baseline, compare it with the actual state, correct deviations to the last known-good state, and run a cause analysis when something slipped through.

How do you control MSPs, cloud hosts and other outsourced processes?

Outsourcing moves the work but not the accountability. Any supplier that matters to the ISMS needs security obligations in the contract, service commitments you track, an audit right where the stakes justify it, and periodic review of its assurance reports. A one-time onboarding check does not meet that standard.

The NCSC Supply Chain Security Guidance is direct on this: build the right to audit into contracts and exercise it, and require your suppliers to do the same for contracts they let. It also expects suppliers that are key to your security to report their security performance upward, under contract, which a one-off questionnaire cannot provide.

Keep one file per supplier that matters, covering hosting, MSPs, payroll and development shops. Each file should hold:

• Contract security terms that make the supplier's obligations explicit.
• Service commitments that you track against actual performance.
• An audit right wherever the stakes justify one.
• Assurance reports, such as SOC 2 reports or ISO certificates, with a record that someone read them.
• An offboarding routine for when the relationship ends, because a supplier you stopped using can still hold your data.

Proportion matters. A payroll bureau and your production host do not need the same scrutiny, so tier suppliers by what they touch and set the review cadence by tier.

What do auditors sample under Clause 8.1, and when does a gap become major?

Auditors trace individual changes from request to approval to implementation, pick a leaver from HR records and check access removal, pull one supplier file, and compare procedures with what staff describe. Missing records for a claimed process, or a supplier with no security control, grade major; a single skipped approval grades minor.

Expect questions along these lines:

• "Pick a recent infrastructure change. Show me the assessment and approval that preceded it."
• "Something changed outside the process last quarter. How did you find out, and what did you do?"
• "Who runs vulnerability scanning, and what happened when they were on holiday?"
• "Your hosting is outsourced. Show me how you know the provider meets your security requirements."
• "Show me last month's access requests and walk one through the approval workflow."

The sample follows from your answers, so every procedure you describe in the room should have a recent run you can open in the ticketing tool. Staff interviews are the cross-check: an engineer who describes a different routine from the written one creates a finding even when the records look clean.

Grading follows certification-body practice for nonconformities, and the boundary looks like this:

• Major: no operational records at all for a process you claim to run, or a supplier relationship with no security control whatsoever.
• Minor: a skipped approval on one sampled change, a procedure overdue for review, or a gap between the written routine and observed practice.
• Minor becoming major: minors that repeat across samples and form a pattern.

The practical reading is that isolated lapses stay minor, while absence is what fails you. A lapse your own ticket history already flags reads as a control working.

How do you automate Clause 8.1 so the evidence produces itself?

Treat each Clause 8.1 obligation as a system behaviour. Routines become scheduled tickets with deputy fallback, change approval becomes a required pipeline field, infrastructure-as-code diffing flags out-of-band changes, and the vendor register raises review tasks when due. The trail exists because the work went through the tool.

Each behaviour adds something a manual process cannot:

• Scheduled tickets are auto-assigned to the owner with fallback to the deputy, so a missed run is a visible overdue ticket rather than a silent gap.
• Pipeline gates make security assessment and approval required fields, and the tool blocks any merge without approval. The gate writes its own audit trail.
• Drift diffing compares infrastructure-as-code or monitored configuration with the approved state, then opens a review task with the evidence attached.
• Vendor register clocks carry renewal and assurance-report review dates, so oversight recurs by construction instead of by memory.

This inverts the scattered-evidence pitfall. Records no longer sit in personal inboxes and local folders, because the ticketing tool and system logs hold timestamped, attributable entries as a by-product of the work. When the auditor asks, you query a system.

A binder assembled the week before the audit proves only that you can assemble a binder.

At 50 people this is a few templates, a scheduling rule set and a register with dates, not a platform programme. A fractional CISO can define the rhythm and chair the change and supplier governance, while GRC engineering builds the automation. The auditor's sample then lands on records that already exist.

Frequently asked questions