--- title: "How to apply ISO IEC 27090 to AI in process control and safety-instrumented systems" description: ISO IEC 27090 explains lifecycle controls for AI in control and safety systems, helping teams record decisions and evidence. url: "https://mangansoftware.com/docs/iso-iec-27090/" updated: "2026-10-28" category: Functional Safety News --- # How to apply ISO IEC 27090 to AI in process control and safety-instrumented systems # How to apply ISO IEC 27090 to AI in process control and safety-instrumented systems ISO IEC 27090 is the focus of this article. ISO/IEC 27090:2026 provides life‑cycle guidance on AI‑specific security threats and mitigations and is directly relevant to facilities that use AI for control‑room analytics, anomaly detection, predictive maintenance or limited autonomy. Teams responsible for process hazards, SIL/PL decisions, SIS verification, management of change (MOC), proof‑testing and evidence capture should map the standard’s life‑cycle guidance into existing IEC/ISA safety activities so decisions, ownership and evidence remain discoverable throughout the asset lifecycle. [![ISO IEC 27090 shown as a technical diagram for the BetterDocs news article](https://mangansoftware.com/wp-content/uploads/2026/10/iso-iec-27090-technical-diagram-1024x683.jpg)](#elementor-action%3Aaction%3Dpopup%3Aopen%26settings%3DeyJpZCI6IjE5MzAyIiwidG9nZ2xlIjpmYWxzZX0%3D) ## ISO IEC 27090: Latest Evidence and Technical Context The new international standard is published as ISO/IEC 27090:2026 (Edition 1). The formal publication date is 2026‑10‑14 and the document is framed as life‑cycle guidance on security threats and compromises that are specific to artificial intelligence systems. Its main structure groups practical material on security practice, enumerates types of compromise and then sets out mitigations: Clause 5 covers security practice, Clause 6 describes types of compromise and Clause 7 lists mitigations. Three annexes provide additional mapping and notes, including an attack‑to‑asset mapping and commentary on federated learning. The standard is intended to be broadly applicable and states it is relevant to all sizes and types of organisations that develop or use AI systems. Together, those elements provide the technical context teams need to assess whether an AI element in a control or safety workflow introduces novel risk, and where to focus life‑cycle controls and evidence capture. The original evidence can be reviewed in [ISO / Joint ISO/IEC JTC 1/SC 27 — ISO/IEC 27090:2026 — Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems](https://www.iso.org/cms/live/live/en/sites/isoorg/contents/data/standard/05/65/56581.html?Offer=ab_ss_reeng_plt_var1). ## Why ISO IEC 27090 Matters Across the Lifecycle AI components bring attack surfaces that did not exist for classic control logic: data poisoning, model exfiltration, prompt injection and model compromise are examples called out by practitioners and now addressed directly in the standard. Those failure modes can undermine a safety argument unless they are handled within familiar safety lifecycle touchpoints — for example, process hazard analyses (PHA), layer‑of‑protection analysis (LOPA), SIL or PL allocation, SIS verification and proof testing. Operationally, ISO IEC 27090 matters because it translates AI‑specific threats into controls that must be reviewed, approved and evidenced in the same way other safety‑critical decisions are. Integrating those controls into management of change and verification steps preserves traceability for regulators, insurers and operations teams. The practical question for operating organisations is not only what could go wrong, but how any AI‑related information should change the content and outcome of reviews, the named approvers, the verification steps and the record‑keeping that proves mitigations remain effective in service. For related MSS guidance, see [Initiating a Management of Change](https://mangansoftware.com/docs/initiating-an-moc/), [What Is IEC 61511?](https://mangansoftware.com/docs/iec-61511/), [Checklists](https://mangansoftware.com/docs/slm-101-checklists/) and [Safety Requirement Specification (SRS)](https://mangansoftware.com/docs/instrumented-systems-safety-requirement-specification-srs/). ## Requirements and Practical Controls for AI in Safety Lifecycles ISO IEC 27090 bundles scope and mitigations with lifecycle guidance; for engineering teams the next step is to translate that into concrete, auditable actions. Use the following practical controls mapped to familiar PHA/LOPA/SIS activities as a starting point: 1) Establish data provenance and lineage as a prerequisite to any model used in decision support or control — record sources, preprocessing and retention policies in the PHA or systems diagram. 2) Require model integrity checks before and after deployment: checksums, cryptographic signatures and run‑time integrity monitoring should be part of SIS verification and periodic proof tests. 3) Store a golden offline model artefact under controlled access and record its provenance in the asset evidence pack so proof‑tests and comparisons can be repeated. 4) Implement model change MOC: any update to training data, retraining process, hyperparameters or external prompts must follow the site MOC workflow with named owners, impact assessment and approvals. 5) Retain evidence of training data, validation results and adversarial‑test outcomes as part of the SIS or safety document bundle for auditability. 6) Include adversarial and anomaly test cases in routine proof‑test schedules, and record the results against the safety requirement that the AI supports. 7) Maintain a configurable rollback plan and verified offline baseline so compromised or degraded models can be removed from operation without losing functional capability. 8) Map potential AI attack vectors to affected assets (controllers, HMIs, data pipelines) and capture those mappings in the PHA/LOPA worksheets for follow‑up actions. 9) Assign clear ownership, deadlines and acceptance criteria for each action, and require a later verification step that confirms the intended mitigations are effective in operation. For regulatory watch points, include AI‑specific documentation in relevant PSM/RMP submissions and ensure MOC records contain the evidence an inspector or insurer will expect. A practical workflow is always: define the decision, confirm the source information, involve the right disciplines, assign owners and deadlines, and verify the outcome — then keep that evidence linked to the asset. ## How MSS Supports Better Lifecycle Information Keeping decisions, evidence and ownership visible across long asset lifecycles is the operational challenge ISO IEC 27090 highlights. Mangan Software Solutions helps organisations link engineering information, lifecycle activities and accountable decisions inside a controlled environment so that source evidence, reviews, approvals and operating records remain discoverable. Relevant workflows can associate the original model artefacts, training evidence, MOC records and proof‑test outcomes with the PHA/LOPA and SIS verification artefacts without replacing specialist engineering judgement. The result is a clearer audit trail: when a verifier asks what basis supported a decision, teams can find the current technical basis and its chain of custody rather than chasing dispersed documents. That linkage reduces friction during inspections and helps teams run the verification and follow‑up steps ISO IEC 27090 expects for AI in safety‑related contexts. [Watch a recorded demo](#elementor-action%3Aaction%3Dpopup%3Aopen%26settings%3DeyJpZCI6IjE5NDk5IiwidG9nZ2xlIjpmYWxzZX0%3D)