5.2 Clause 8 Operation & Operational Planning and Control
Key Takeaways
- Clause 8 has four subclauses — 8.1 operational planning and control, 8.2 AI risk assessment, 8.3 AI risk treatment, and 8.4 AI system impact assessment — and 8.1 requires planning, implementing, and controlling the processes needed to meet AIMS requirements and to implement the actions determined in Clause 6.
- Operational control includes establishing process criteria, implementing control of processes per those criteria, and keeping documented information necessary for confidence that processes were carried out as planned.
- Planned changes must be controlled; the organization shall review consequences of unintended changes and take action to mitigate adverse effects as necessary.
- Outsourced processes and third-party AI services remain within operational control expectations—the organization cannot claim “the vendor runs the model” as a free pass outside the AIMS.
- Auditors test the thread from Clause 6 plans into live process criteria, records of operation, change control, and supplier interfaces: cite Clause 6 when a required process does not exist and Clause 8.2–8.4 when the process exists but was not performed at planned intervals or repeated after significant change — the most common citation error on this exam.
5.2 Clause 8 Operation & Operational Planning and Control
Auditor focus: Did planning become controlled work? Are AI processes run to defined criteria? Are changes managed? Are outsourced AI services under organizational control? Do records show processes were carried out as planned?
Clause 8 is the Do phase of PDCA. Clause 6 decides what must be treated and achieved; Clause 8 makes those decisions operational. Clause 8 has four subclauses, and knowing which one to cite is the difference between a finding that survives review and one that gets rewritten:
| Subclause | Title | What it adds beyond Clause 6 |
|---|---|---|
| 8.1 | Operational planning and control | Processes are planned, criteria established, controls implemented, records kept, changes controlled, outsourced processes controlled |
| 8.2 | AI risk assessment | The Clause 6.1.2 process must actually be performed at planned intervals and when significant changes are made or occur |
| 8.3 | AI risk treatment | The Clause 6.1.3 treatment plan must actually be implemented, with documented results retained |
| 8.4 | AI system impact assessment | The Clause 6.1.4 process must actually be performed at planned intervals and when significant changes are proposed |
The Clause 6 / Clause 8 pairing is the single most common citation error on this exam. Clause 6 requires the organization to establish the process; Clause 8 requires it to run the process and keep the records. So:
- An organization with no defined AI risk assessment process at all → 6.1.2.
- An organization with a good documented process that last ran two years ago, despite three major model changes → 8.2, not 6.1.2.
- An impact assessment procedure that exists but was never repeated after a system moved from advisory to fully automated → 8.4.
- A risk treatment plan approved by the AI governance board and then never implemented → 8.3.
This section centers on 8.1 operational planning and control—the backbone for testing whether the AIMS is alive in production—and returns to 8.2–8.4 as the recurrence requirements you cite when a process exists on paper but has stopped running.
Where 8.1 Sits in the Chain
Clause 6 plans → 8.1 criteria & controls → operated AI processes → records (confidence)
risks, impact, objectives, changes
↓
change control · outsourced control · unintended-change review
Excellent Clause 6 files with ignored production deploys typically yield 8.1 findings (processes not implemented/controlled as planned).
8.1 Core Requirements
Plan, implement, and control processes needed to meet AIMS requirements and to implement actions determined in Clause 6:
| 8.1 element | Practice meaning | Evidence |
|---|---|---|
| Establish process criteria | Gates, thresholds, approvals, methods | Procedures, risk-tiered release criteria |
| Implement control per criteria | Gates actually run under pressure | Tickets, board minutes, CI/CD enforcement, rejected releases |
| Documented information for confidence | Records prove operation, not only intent | Approvals, pipeline logs, monitoring histories |
| Control planned changes; review unintended changes; mitigate adverse effects | Model/prompt/config/data changes are controlled | Change records, rollbacks, post-incident reviews |
| Control outsourced processes | APIs, labeling, hosting, fine-tuning managed | Contracts, intake assessments, ongoing monitoring |
Implementing Clause 6 Plans
| Clause 6 output | 8.1 operationalization |
|---|---|
| 6.1 risk/opportunity treatment | Treatments become process steps, technical controls, monitoring tasks, or acceptance criteria |
| 6.1.4 impact assessment results | Limitations, human oversight, transparency, and restrictions enter procedures and release criteria |
| 6.2 AI objectives | Metrics, owners, and activities scheduled and recorded |
| 6.3 planning of changes | Material AIMS/AI changes follow planned change under operational control |
Scenario: Claims-triage risk treatment requires human review above a confidence threshold and quarterly fairness monitoring. Operations fully automate decisions; no fairness job for nine months; docs still say "implemented." Finding: 8.1—Clause 6 actions not implemented/controlled; records do not support confidence processes ran as planned.
Process Criteria for AI Work
Criteria are auditable rules—not slogans—and should be risk-tiered:
| Process | Example criteria |
|---|---|
| Promote model to production | Evaluation passed; impact assessment current; residual risk accepted; model card updated; rollback tested |
| Prompt / config change | Change class; dual control if high impact; regression tests; version logged |
| Training data update | Provenance, license/consent, quality thresholds, re-evaluation triggers |
| Human oversight | Threshold or sampling rate; escalation SLA; stop authority |
| Third-party model API | Approved providers; data restrictions; filtering; incident contact |
Trap: Handbook criteria while personal API tokens push to production. Compare stated criteria with enforcement and records.
Planned Changes and Unintended Consequences
- Control planned changes — versioning, approval, testing, communication windows (model version, feature flag, prompt pack, threshold).
- Review unintended changes — silent library upgrades, auto-retraining, provider model swaps, schema drift.
- Mitigate adverse effects — rollback, user notice, human-only mode, data quarantine.
| Change type | Why sensitive |
|---|---|
| Retrain / fine-tune | Behavior shifts without UI change; may invalidate prior impact conclusions |
| Prompt packs | Small text edits can swing generative outcomes |
| Thresholds | Approval rates and fairness metrics move |
| Provider model updates | Upstream swap may be "unintended" from the customer view |
| Canary / feature flags | Partial rollout still needs control and monitoring |
Scenario: SaaS LLM provider silently upgrades the default model; chatbot behavior changes; no re-evaluation. Finding: outsourced process control + unintended-change review under 8.1. "We didn't change anything" fails when the operated service changed.
Outsourced Processes and Third-Party AI
Using AI you did not train does not exit 8.1:
- Define what is outsourced (inference, labeling, hosting, evaluation-as-a-service)
- Specify controls (contracts, privacy/security terms, audit rights, model-change notification)
- Monitor quality, bias incidents, availability, misuse
- Keep supplier interfaces inside scope when the AI system is in AIMS scope
| Weak | Stronger |
|---|---|
| "Vendor certified—skip controls" | Map outsourced AIMS process; residual accountability |
| Shadow SaaS on a card | Intake, inventory, acceptable use |
| No model-change notification right | Contract notice + re-evaluation triggers |
| High-stakes raw outputs | Filtering, human review, logging criteria |
Documented Information for Confidence
8.1 needs enough records to have confidence processes ran as planned—not infinite paper. For high-risk AI, sample:
- Release records tied to model/prompt versions
- Gate evaluation and acceptance results
- Impact and residual-risk references at release
- Monitoring job and review sign-offs
- Change tickets (including emergency path)
- Supplier assessment and oversight records
Method: Reconstruct one system's last material change: request → criteria → approvals → deploy → monitor. Any broken link is 8.1 evidence failure.
Common Nonconformities
Clause 6 plans not operationalized; criteria bypassed; no gate records; changes without re-assessment triggers; no handling of provider/auto-retrain unintended changes; core-process generative AI without outsourcing control; "operate" reduced to uptime while fairness and oversight treatments idle.
Lifecycle detail only counts when planned, implemented, controlled, and recorded under 8.1.
Which statement best describes the relationship between Clause 6 and Clause 8.1 in ISO/IEC 42001?
An organization has detailed AI release criteria in a handbook, but engineers can push models to production with a personal API token and no gate records. Which 8.1 failure is most accurate?
A foundation-model provider changes the default production model without notice, altering chatbot behavior. The organization takes no action because “we did not submit a change request.” What does Clause 8.1 expect regarding such events?
When sampling documented information under Clause 8.1 for a high-risk AI system, what is the auditor primarily trying to establish?
An auditee has a well-documented AI system impact assessment procedure that meets Clause 6.1.4. Records show one assessment completed 26 months ago; since then a fraud-triage model moved from advisory to fully automated decisioning with no reassessment. Which requirement is most precisely failing?