8.1 — Operational planning and control

The requirement that keeps day-to-day operations aligned with what clause 6 decided, instead of quietly drifting from it.

Mandatory requirement · Documented information required: yes

In plain language

8.1 requires you to run the processes needed to meet your ISMS requirements and the risk treatment actions from clause 6 under defined criteria, keep enough evidence to show they ran as planned, control changes to those processes on purpose rather than by accident, and make sure any externally provided process, product, or service relevant to the ISMS is kept under control too.

Why this requirement exists

A risk treatment plan is only as good as its execution. This requirement exists because operational reality drifts from documented intent constantly—a process gets tweaked to save time, a vendor changes how they deliver a service, an emergency fix skips the usual review—and without deliberate control, those small drifts accumulate into a gap between what the ISMS says happens and what actually happens.

Scenario: a company outsources its backup infrastructure to a third party after certification, without ever assessing whether that provider meets the same security expectations as the in-house process it replaced. The service works fine technically, but nobody controlled the change, and nobody verified the vendor against the ISMS’s requirements. That gap surfaces exactly when an auditor asks who reviewed the switch.

What the standard expects

The standard expects the organization to plan, implement, and control the processes needed to meet requirements and to implement the actions determined in clause 6, by establishing criteria for the processes and implementing control of the processes in accordance with those criteria. Documented information must be available to the extent necessary to have confidence the processes were carried out as planned. The organization must control planned changes and review the consequences of unintended changes, taking action to mitigate adverse effects as necessary, and must ensure that externally provided processes, products, or services relevant to the ISMS are controlled.

In practice

• Define clear criteria for security-relevant processes (patching cadence, access review frequency, backup testing) so "running as planned" is verifiable, not subjective.
• Route changes to ISMS-relevant processes through a change control step, however lightweight, rather than letting them happen ad hoc.
• Assess new or changed external providers (cloud services, managed service providers, outsourced processes) against the same security expectations the ISMS already sets internally.

Evidence the auditor will ask for

• Documented criteria for key operational processes and evidence they are actually met.
• Change records showing planned changes were reviewed, and unintended changes were assessed for consequences.
• Evidence that externally provided processes or services relevant to the ISMS were assessed and are monitored.

Common pitfalls

• New vendors or outsourced services adopted after certification with no assessment against ISMS expectations.
• Emergency changes that bypass review entirely, with no after-the-fact assessment of their consequences.

Related requirements

• 8.2 Risk assessment (operational)—a significant unplanned change is one of the triggers for re-running risk assessment.
• 6.3 Planning of changes—sets the planning discipline that 8.1 requires you to actually apply operationally.
• Parent clause: Clause 8 Operation.