6.5 Clause 8: Operation

Clause 8 is the "Do" phase of PDCA. It is short but central: it requires the organization to execute the risk assessment and risk treatment planned in Clause 6, and to plan, control, and review the operational processes needed to meet ISMS requirements. Although Clause 8 contains only three subclauses, the Foundation exam repeatedly tests the boundary between Clause 6 (planning) and Clause 8 (execution). Mastering this boundary is one of the highest-value study areas for the Foundation exam.

8.1 Operational Planning and Control

The organization must:

• Plan, implement, and control the processes needed to meet ISMS requirements, including the processes needed to address risks and opportunities in Clause 6.1 and to achieve information security objectives in Clause 6.2
• Implement change in a controlled manner
• Review the consequences of unintended changes and mitigate any adverse effects, if needed
• Ensure that outsourced processes are controlled

The wording "plan, implement, and control" mirrors the Plan–Do–Check loop within operations. Outsourced processes are explicitly in scope — a common exam point: the ISMS does not stop at the organization's boundary. Cloud providers, Managed Security Service Providers (MSSPs), shared-service data centers, payroll processors, and SaaS vendors must be controlled through contracts, SLAs, audit rights, or ISO/IEC 27001 certification verification.

A common trap: "outsourced processes are out of scope of the ISMS" is false. The organization remains accountable for the controls that depend on the outsourced provider — the risk owner inside the organization cannot transfer accountability by transferring operations.

Criteria for Operational Control

Operational planning and control under 8.1 must address:

• The processes needed to meet information security objectives (from Clause 6.2)
• The criteria for the processes (acceptance levels, thresholds, performance targets)
• The control of the processes per the criteria
• The documented information sufficient to have confidence that the processes have been carried out as planned

This explicit criteria-and-control structure distinguishes Clause 8.1 from generic operational planning — the ISMS treats operational processes with the same rigor as any other management system process.

8.2 Information Security Risk Assessment

Clause 8.2 requires the organization to execute the information security risk assessment process as planned in Clause 6.1.2. The assessment methodology, criteria, and scope were defined in Clause 6; Clause 8.2 is the operational act of running that method to produce the current risk picture.

Key requirements:

• Perform the assessment at planned intervals or whenever significant changes occur (organizational, technical, environmental, or regulatory)
• Apply the risk acceptance criteria established by top management (Clause 5.1) and operationalized in Clause 6.1.2
• Produce documented information of the risk assessment results (retained)
• Maintain the risk register as a living document, updated each time the assessment is executed

A common trap: the assessment methodology itself is defined in Clause 6.1.2; Clause 8.2 is NOT where you choose NIST SP 800-30, ISO/IEC 27005, OCTAVE, or any other method — it is where you run whichever method you chose in Clause 6. The exam frequently asks "in which clause is the risk assessment performed?" — the answer is 8.2, not 6.1.2. The two clauses form a Plan/Do pair: Clause 6.1.2 plans the assessment process; Clause 8.2 executes it.

When to Execute the Risk Assessment

The organization defines its own planned intervals in the risk assessment procedure (e.g., annually). Significant changes that trigger a fresh assessment include:

• New products, services, or processes
• Major organizational restructuring or mergers
• Significant changes to the threat landscape (new attack patterns, geopolitics)
• Material changes to assets (new systems, locations, data categories)
• Significant security incidents revealing previously unidentified risks

8.3 Information Security Risk Treatment

Clause 8.3 requires the organization to implement the information security risk treatment plan (RTP) produced in Clause 6.1.3. The RTP lists the chosen controls (from Annex A or elsewhere), the responsible owners, the planned dates, and the expected residual risk.

Implementation requirements:

• Implement the controls selected in the risk treatment process
• Produce documented information of the risk treatment implementation and results
• Update the Statement of Applicability (SoA) as needed if controls are added, removed, or change in status during implementation

A trap: the SoA is produced in Clause 6.1.3 d) as one of the four outputs of the risk treatment process; Clause 8.3 may update it during implementation, but the SoA is not created in Clause 8.3. The Foundation exam often tests which clause produces the SoA versus which clause implements it.

What the SoA Contains

The Statement of Applicability is a cornerstone document. It must include:

• The controls from Annex A that are determined to be necessary
• The controls from Annex A that are justifiably excluded (with justification)
• The status of each control (implemented, in progress, planned)
• The justification for including or excluding each control

The SoA is not a one-time artifact — it is updated whenever risk treatment changes (Clause 8.3) or risk assessments reveal new risks (Clause 8.2).

PDCA Mapping

Clause 8 is the engine of the ISMS — it is where plans become operations. Without execution in Clause 8, the risk register and RTP are paperwork, and the SoA becomes a static list rather than a living management instrument.

Common Traps

1. "Perform the risk assessment" = 8.2, not 6.1.2. Clause 6.1.2 establishes the process; Clause 8.2 runs it.
2. "Implement the RTP" = 8.3, not 6.1.3. Clause 6.1.3 produces the RTP and SoA; Clause 8.3 implements it.
3. Outsourced processes are in scope. Clause 8.1 explicitly requires control of outsourced processes — a common exclusion trap.
4. Unintended changes must be reviewed. 8.1 requires reviewing the consequences of unintended changes and mitigating adverse effects — not just controlling planned changes.
5. The SoA is created in 6.1.3, not 8.3. Clause 8.3 may update the SoA as controls change, but the original SoA originates in the risk treatment process.
6. Risk owner accountability is not transferable. Outsourcing an operation does not transfer the organization's accountability for the dependent controls.