Information Security for Industrial AI Systems
Requirements to establish, implement, maintain and continually improve an Industrial AI Security Management System (IAISMS). Where ISO/IEC 27001 protects the organisation's information, IRIS-SEC 27001 protects the model, the process data and the automated decision.
Complete normative text, published openly and free to read.
The Gap No Standard Covers Today
A factory deploying artificial intelligence over its production process finds three mature standards that surround its problem without solving it. None of the three was written for a model making decisions on a running production line.
Information security management system. Excellent for corporate information assets: servers, applications, people, processes.
Does not cover: the model as an asset, training data poisoning, adversarial attacks, or the automated decision as evidence.
Artificial intelligence management system. Brings governance, risk management and AI impact assessment with a generalist approach.
Does not cover: cybersecurity depth, nor the specificity of the industrial environment and the control layer.
Security for industrial automation and control systems. The real OT reference: zones, conduits, security levels.
Does not cover: it predates industrial AI. It addresses neither models, nor training, nor drift, nor decision autonomy.
The intersection of all three. Information security applied specifically to AI systems operating on real industrial processes.
Adds: 54 controls covering the model, process data, IT/OT convergence, AI supply chain and effective human oversight.
The IRIS-SEC 27000 Family
Information Security in Industrial AI
IRIS-SEC 27001 is the certifiable standard of the family: it defines the management system and the controls. Certifications 27010 to 27090 are specialised modules audited on top of the 27001 baseline when the organisation's scope requires them.
Security Certification Catalogue
| IRIS Code | Designation | Scope | ISO/IEC · Regulatory Ref. |
|---|---|---|---|
| IRIS-SEC 27001 | IAISMS — Certifiable Base Standard | Industrial AI security management system: clauses 4–10 and full Annex A | Equiv. ISO/IEC 27001 + 42001 + IEC 62443 |
| IRIS-SEC 27010 | Model Security | Data poisoning, adversarial examples, model extraction and inversion, backdoors | No specific ISO equivalent |
| IRIS-SEC 27020 | Industrial Data Integrity | Sensors, telemetry, process historians, data lineage and provenance | Complements ISO 8000 · ALCOA+ |
| IRIS-SEC 27030 | IT/OT Convergence with AI | Zones and conduits, AI/control separation, write channels onto the process | Complements IEC 62443-3-3 |
| IRIS-SEC 27040 | AI Supply Chain | AIBOM, third-party pre-trained models, dataset provenance, suppliers | Complements ISO/IEC 27036 |
| IRIS-SEC 27050 | Data Sovereignty and Localisation | Data and compute jurisdiction, reversibility, extra-EU dependency | Complements ISO/IEC 27018 · GDPR · Data Act |
| IRIS-SEC 27060 | Industrial Copilots and LLMs | Prompt injection, know-how leakage, conversational assistants on the shop floor | No specific ISO equivalent |
| IRIS-SEC 27070 | Continuity and Safe Degradation | Fallback on model or supplier failure, operation without AI, resilience | Complements ISO 22301 |
| IRIS-SEC 27080 | AI Incident Response | Forensics of automated decisions, notification to authorities, lessons learned | Complements ISO/IEC 27035 · NIS2 |
| IRIS-SEC 27090 | AI Act Compliance | High-risk systems, risk management, technical documentation and post-market monitoring | Complements ISO/IEC 42001 · EU AI Act |
Naming: the IRIS-SEC family mirrors the ISO/IEC 27001 numbering under the same criterion already applied in IRIS-EDU 21001 with respect to ISO 21001. The number signals equivalence of subject matter; the IRIS-SEC prefix unambiguously identifies the scheme owner.
IRIS-SEC 27001:2026 Normative Text
The complete body of the standard, in the open. ISO charges for its standards; we believe a standard that aims to protect European industry should be readable before it is bought.
1 · 2 · 3 — Scope, References and Definitions
1 Scope
This standard specifies the requirements for establishing, implementing, maintaining and continually improving an Industrial AI Security Management System (IAISMS) within the context of an organisation that designs, integrates, operates or supplies artificial intelligence systems influencing industrial processes.
1.1 Applicability
The standard applies to any organisation, regardless of size, sector or legal form, falling under at least one of the following profiles:
- Developer — designs or trains models intended for industrial environments.
- Integrator — deploys, adapts or connects AI systems to a third party's production infrastructure.
- Operator — runs AI systems on its own production process, whether owned or third-party.
- Service provider — supplies compute, data, models or maintenance to any of the above.
1.2 Material scope
The IAISMS covers the full lifecycle of the industrial AI system: data origin and acquisition, training, validation, deployment, operation, monitoring, updating and decommissioning. It comprises both the information technology (IT) layer and the points of contact with the operational technology (OT) layer where the AI reads from the process or writes to it.
1.3 Scope exclusions
This standard does not establish machinery functional safety requirements (IEC 61508, ISO 13849), nor does it replace the conformity assessment required by Regulation (EU) 2024/1689 on Artificial Intelligence for high-risk systems. Nor does it constitute a certification accredited by ISO, IEC, CEN, AENOR or ENAC.
1.4 Conformity
All requirements in clauses 4 to 10 are mandatory and cannot be excluded. Annex A controls apply by default: any exclusion shall be formally justified in the Statement of Applicability in accordance with clause 6.1.3.
2 Normative references
The following documents are referred to in whole or in part and are indispensable for the application of this standard. Where an edition is stated, only that edition applies; otherwise the latest edition in force applies.
- ISO/IEC 27001 — Information security management systems. Requirements.
- ISO/IEC 27002 — Information security controls.
- ISO/IEC 42001 — Artificial intelligence management systems.
- ISO/IEC 23894 — Artificial intelligence risk management.
- IEC 62443-2-1, 62443-3-2, 62443-3-3, 62443-4-1 — Security for industrial automation and control systems.
- ISO 22301 — Business continuity.
- Regulation (EU) 2024/1689 — Artificial Intelligence Act.
- Directive (EU) 2022/2555 — NIS2.
- Regulation (EU) 2016/679 — GDPR.
- IRIS 14001 — Base certification for industrial AI software.
- IRIS 14090 — Industrial Safety AI.
3 Terms and definitions
For the purposes of this standard, the following terms apply. Terms not defined here are taken from ISO/IEC 27000 and ISO/IEC 22989.
3.1 industrial AI system
System applying machine learning or inference techniques to data originating from an industrial process, in order to predict, classify, optimise or decide on that process.
3.2 IAISMS
Industrial AI Security Management System. Set of interrelated elements of an organisation to establish policies and objectives, and to achieve them, regarding the security of its industrial AI systems.
3.3 model asset
The combination of architecture, trained weights, hyperparameters, inference code and associated documentation of a model. It is considered an information asset for all purposes of this standard.
3.4 autonomy level
Degree to which an AI system acts on the process without prior human confirmation. Classified as: N0 informational, N1 recommendation with explicit approval, N2 action under supervision with override capability, N3 autonomous action with subsequent review.
3.5 data poisoning
Deliberate manipulation of training, fine-tuning or feedback data with the purpose of altering the behaviour of the resulting model.
3.6 adversarial example
Input deliberately constructed to induce in the model an erroneous output that a human observer would not consider ambiguous.
3.7 drift
Degradation of a model's performance caused by divergence between the distribution of operational data and that of the training data.
3.8 safe degradation
Predefined operational state to which the process transitions when the AI system ceases to be reliable, available or trustworthy, without compromising the safety of people or the integrity of the product.
3.9 AIBOM
Structured inventory of all components of an AI system: base models, datasets, libraries, pre-trained weights, inference services, and their respective provenance and licences.
3.10 effective human oversight
Condition in which the responsible person simultaneously has sufficient information, sufficient time and sufficient authority to override an AI system decision before it produces irreversible effects.
4 to 10 — Management System Requirements
These seven clauses follow the harmonised high-level structure (Annex SL) common to ISO/IEC 27001, ISO/IEC 42001, ISO 9001 and ISO 22301. The numbering is deliberately identical so that an organisation with a certified management system can absorb IRIS-SEC 27001 by extending its existing procedures rather than duplicating them.
4 Context of the organisation
4.1 Understanding the organisation and its context
The organisation shall determine the internal and external issues relevant to its IAISMS, expressly including: the industrial sector and its criticality, the threat landscape applicable to industrial AI, technological dependency on non-EU suppliers, and the regulatory framework of every jurisdiction in which it operates.
4.2 Understanding the needs and expectations of interested parties
The interested parties of the IAISMS and their requirements shall be identified. As a minimum: industrial customers, workers and their legal representation, model and data suppliers, insurers, market surveillance authorities and competent cybersecurity authorities.
4.3 Determining the scope of the IAISMS
The scope shall be stated in writing and identify: the AI systems included, the plants or facilities affected, the production processes involved and the interfaces with third-party systems. Exclusions shall be justified and may not leave out any AI system with autonomy level N2 or N3.
4.4 Industrial AI security management system
The organisation shall establish, implement, maintain and continually improve the IAISMS, including the processes needed and their interactions, in accordance with the requirements of this standard.
5 Leadership
5.1 Leadership and commitment
Top management shall demonstrate leadership and commitment with respect to the IAISMS by ensuring the availability of resources, the integration of requirements into business processes, and the communication of the importance of effective industrial AI security management.
5.2 Policy
An industrial AI security policy shall be established, appropriate to the purpose of the organisation, including the commitment to satisfy applicable requirements and to continually improve the IAISMS. The policy shall be documented, communicated within the organisation and available to relevant interested parties.
5.3 Roles, responsibilities and authorities
Top management shall assign responsibility and authority for the IAISMS. The following shall be designated by name:
- An IAISMS manager, with authority to halt the deployment of an AI system.
- An owner for each model asset in production.
- A human oversight officer for each system at autonomy level N2 or N3.
The model owner role shall not be held by the same person who approves its transition to production.
6 Planning
6.1 Actions to address risks and opportunities
6.1.1 General. When planning the IAISMS, the organisation shall consider the issues in clause 4.1 and the requirements in clause 4.2, and determine the risks and opportunities that need to be addressed.
6.1.2 Industrial AI security risk assessment. The organisation shall define and apply a risk assessment process which, in addition to the usual confidentiality, integrity and availability criteria, expressly evaluates:
- The physical consequence of an erroneous model decision on the process, the product and people.
- The AI-specific attack surface: training data, feedback channel, inference interface, model artefacts.
- The actual detection capability for silent manipulation of model behaviour.
- The reversibility window: time available between the automated decision and its irreversible effect.
6.1.3 Risk treatment. The organisation shall define and apply a risk treatment process selecting the appropriate options and determining the necessary controls. The determined set of controls shall be compared against Annex A and a Statement of Applicability shall be produced containing the necessary controls, their justification, implementation status, and justification for the exclusion of any Annex A control.
6.2 Industrial AI security objectives
Measurable objectives shall be established, consistent with the policy, communicated and updated. Examples of acceptable indicators: coverage of models with verified cryptographic signature, mean time to detect drift, percentage of N2/N3 decisions with complete forensic trace, time to transition to safe degradation.
6.3 Planning of changes
When the organisation determines the need for changes to the IAISMS, these shall be carried out in a planned manner. Any change to a model in production is considered a change to the IAISMS.
7 Support
7.1 Resources
The organisation shall determine and provide the resources needed for the establishment, implementation, maintenance and continual improvement of the IAISMS, including the technical capability to independently audit the behaviour of its own models.
7.2 Competence
The necessary competence of persons affecting industrial AI security performance shall be determined and ensured through training, experience or certification. IRIS-PRO certification at the level corresponding to the role is accepted as evidence of competence.
7.3 Awareness
Persons doing work under the organisation's control shall be aware of the policy, of their contribution to the effectiveness of the IAISMS and of the implications of not conforming to requirements. In particular, shop floor personnel shall know the reliability limits of the AI system they work with.
7.4 Communication
Relevant internal and external communications shall be determined, including what to communicate, when, to whom and by which means. A defined channel shall exist for any shop floor worker to report anomalous behaviour of the AI system.
7.5 Documented information
The IAISMS shall include the documented information required by this standard and that determined as necessary by the organisation. As a minimum the following shall be retained: the scope, the policy, the risk assessment methodology and results, the treatment plan, the Statement of Applicability, the AI system inventory, internal audit records and management review minutes.
8 Operation
8.1 Operational planning and control
The organisation shall plan, implement and control the processes needed to meet requirements and to implement the actions determined in clause 6. Documented information shall be retained to the extent necessary to have confidence that the processes have been carried out as planned.
8.2 Industrial AI security risk assessment
The organisation shall perform risk assessments at planned intervals and when significant changes are proposed or occur, retaining documented information on the results.
8.3 Industrial AI security risk treatment
The risk treatment plan shall be implemented and documented information on the results retained.
8.4 Secure operation of AI systems
A requirement specific to this standard, without equivalent in ISO/IEC 27001. Throughout the operational life of each AI system in scope, the organisation shall continually maintain:
- An operation record allowing subsequent reconstruction of which model version made each decision, with which inputs and at what confidence level.
- A defined and monitored degradation threshold, the breach of which automatically triggers transition to the safe degradation state.
- A periodic verification of human override capability, executed as a real test and not as a documentary review.
- A decommissioning procedure ensuring that a deactivated model cannot be reactivated without passing validation again.
9 Performance evaluation
9.1 Monitoring, measurement, analysis and evaluation
The organisation shall determine what needs to be monitored and measured, the applicable methods, when it is performed and when results are analysed and evaluated. The selected methods shall produce comparable and reproducible results.
9.2 Internal audit
Internal audits shall be conducted at planned intervals. The audit programme shall include, at least once per cycle, a practical safe degradation test on a production system or on its pre-production twin, not limited to documentary review.
9.3 Management review
Top management shall review the IAISMS at planned intervals. The review shall include the status of previous actions, changes in context and in the threat landscape, feedback on performance, risk assessment results, the status of the treatment plan, recorded AI incidents and opportunities for improvement.
10 Improvement
10.1 Continual improvement
The organisation shall continually improve the suitability, adequacy and effectiveness of the IAISMS.
10.2 Nonconformity and corrective action
When a nonconformity occurs, the organisation shall react to control and correct it, deal with its consequences, evaluate the need to eliminate its causes, implement the necessary actions and review their effectiveness.
Annex A (normative) — Industrial AI Security Controls
54 controls grouped into 7 domains. All apply by default. Excluding any of them requires documented justification in the Statement of Applicability and is subject to specific review during the certification audit.
| A.1.1 | Industrial AI security policyA policy specific to the security of industrial AI systems shall be defined, approved by management, published and reviewed. |
| A.1.2 | Ownership of models and datasetsEvery model asset and every training dataset shall have a named owner responsible for its security throughout its lifecycle. |
| A.1.3 | Inventory of AI systemsAn up-to-date inventory of all AI systems in production shall be maintained, including those deployed by business units outside the control of the technology department. |
| A.1.4 | Classification by criticality and autonomyEach AI system shall be classified according to its autonomy level (N0–N3) and the criticality of the process it acts upon, determining the rigour of the applicable controls. |
| A.1.5 | AI-specific threat modellingThreat modelling shall address vectors specific to AI and not merely those of the supporting infrastructure. |
| A.1.6 | Interface with the existing ISMSWhere the organisation holds an ISMS conforming to ISO/IEC 27001, the interface between both systems shall be documented, avoiding duplication and coverage gaps. |
| A.1.7 | Identification of legal and regulatory requirementsApplicable requirements arising from the AI Act, NIS2, GDPR, the Data Act and sectoral regulation shall be identified and kept up to date. |
| A.1.8 | Segregation of duties in deploymentModel development, independent validation and production release authorisation shall rest with different individuals. |
| A.2.1 | Security in model designSecurity requirements shall be incorporated from the model design phase and not added after functional validation. |
| A.2.2 | Access control to training dataAccess to training, fine-tuning and validation datasets shall be restricted, logged and periodically reviewed. |
| A.2.3 | Protection against data poisoningAnomaly detection, statistical validation and provenance control measures shall be applied to any data feeding a training or retraining run. |
| A.2.4 | Robustness against adversarial examplesModels operating on externally manipulable signals shall undergo adversarial robustness testing proportionate to their autonomy level. |
| A.2.5 | Protection against extraction and inversionInference interface exposure, query volume and response detail shall be limited to prevent reconstruction of the model or of its training data. |
| A.2.6 | Versioning and signing of artefactsEvery deployed model artefact shall be versioned and cryptographically signed, with integrity verified at each load. |
| A.2.7 | Segregation of the training environmentTraining and experimentation environments shall be segregated from production environments and from the control network. |
| A.2.8 | Pre-deployment security validationNo model shall enter production without passing a documented security validation independent of the team that developed it. |
| A.2.9 | Secure withdrawal and decommissioningModel withdrawal shall include revocation of its credentials, retention of its historical trace and the impossibility of reactivation without fresh validation. |
| A.3.1 | Authentication of telemetry sourcesThe authenticity of sensors, gateways and telemetry sources feeding the AI system shall be verified, preventing data injection by unauthorised sources. |
| A.3.2 | Data integrity in transit from OT to AIThe data flow from the control layer to the inference platform shall be protected against undetected modification. |
| A.3.3 | Data lineage and provenanceIt shall be possible to reconstruct the origin, transformations and responsible parties of any data that influenced training or a decision. |
| A.3.4 | Drift and input anomaly detectionThe distribution of input data shall be continuously monitored to detect drift, degradation or manipulation. |
| A.3.5 | Protection of the process historianHistorian systems constituting the source of truth for training shall be protected with integrity controls equivalent to those of an evidence record. |
| A.3.6 | Retention of decision dataInputs, outputs and metadata of automated decisions shall be retained for a period sufficient to allow subsequent investigation and regulatory compliance. |
| A.3.7 | Minimisation of worker dataData enabling individual identification or evaluation of workers shall be minimised, pseudonymised and subject to reinforced access control. |
| A.3.8 | Protection of embedded industrial knowledgeMeasures shall be applied to prevent extraction of the process know-how contained in data and models, particularly where compute is outsourced. |
| A.4.1 | Segmentation into zones and conduitsAI systems shall reside in defined security zones, with controlled conduits towards the control network, in line with the IEC 62443-3-2 model. |
| A.4.2 | Separation between AI layer and control layerProcess safety logic shall not depend on the availability or correctness of the AI system. |
| A.4.3 | Control of write channelsEvery channel through which the AI issues setpoints to the process shall be explicitly authorised, range-limited and logged. |
| A.4.4 | Edge compute securityInference devices deployed on the shop floor shall be protected against physical access, model extraction and firmware replacement. |
| A.4.5 | Hardening of inference platformsPlatforms executing models shall undergo secure configuration, attack surface reduction and documented patch management. |
| A.4.6 | AI credential and secret managementAccess keys to inference services, model repositories and data sources shall be safeguarded, rotated and audited. |
| A.4.7 | Immutable log of actions on the processAI actions on the process shall be recorded on a medium preventing their modification or deletion by the operators of the system itself. |
| A.4.8 | Reliable time synchronisationAll elements generating records shall share a reliable and protected time source, a necessary condition for forensic traceability. |
| A.5.1 | Inventory of AI components (AIBOM)An inventory of all components of the AI system shall be maintained, with their provenance, version and licence. |
| A.5.2 | Assessment of third-party pre-trained modelsAny externally sourced base model or pre-trained weights shall undergo security assessment before incorporation. |
| A.5.3 | Verification of dataset provenanceThe origin, licence and integrity of any external dataset used in training or validation shall be verified. |
| A.5.4 | Contractual security requirementsContracts with model, data or compute suppliers shall include security requirements, right to audit and incident notification obligations. |
| A.5.5 | Data and compute localisation and jurisdictionThe jurisdiction in which data resides and inference executes shall be known and documented, assessing the risk of access by foreign authorities. |
| A.5.6 | Reversibility and exit strategyA documented and tested plan shall exist to replace an AI supplier without loss of operational capability or historical data. |
| A.5.7 | Vulnerability management in AI dependenciesA process shall exist for monitoring and remediating vulnerabilities in frameworks, libraries and services of the AI stack. |
| A.6.1 | Continuous monitoring of model behaviourThe performance and decision pattern of the model in production shall be continuously monitored against an established baseline. |
| A.6.2 | Detection of misuse and probingQuery patterns consistent with attempts at model extraction, probing or evasion shall be detected. |
| A.6.3 | Degradation thresholds and fallback activationQuantitative thresholds shall be defined whose breach automatically triggers reduction of the autonomy level or transition to safe degradation. |
| A.6.4 | Degraded operation without AIThe process shall be capable of being maintained under safe conditions without the AI system, and this capability shall be verified through periodic real testing. |
| A.6.5 | AI incident response planA specific plan shall exist covering AI-specific scenarios: compromised model, sudden drift, detected poisoning, supplier outage. |
| A.6.6 | Forensic analysis of automated decisionsThe evidence necessary to reconstruct any automated decision after an incident shall be retained. |
| A.6.7 | Incident notification to authoritiesA procedure shall exist ensuring timely notification to competent authorities in accordance with NIS2, the AI Act and sectoral regulation. |
| A.6.8 | Continuity on AI supplier outageProlonged unavailability of an external model or inference supplier shall be addressed in the business continuity plan. |
| A.7.1 | Competence of shop floor personnelPeople working alongside AI systems shall demonstrate competence regarding their limits, failure modes and override procedures. |
| A.7.2 | Awareness of AI-assisted social engineeringPersonnel shall be trained against AI-generated voice, video and identity impersonation in industrial authorisation contexts. |
| A.7.3 | Effective human oversightIt shall be ensured that the supervising person has sufficient information, time and authority to intervene before the decision becomes irreversible. |
| A.7.4 | Periodic override verificationHuman override capability shall be tested under real conditions at defined intervals, documenting the response time obtained. |
| A.7.5 | Protected internal alert channelA channel shall exist enabling any person in the organisation to raise concerns about AI system risks without fear of retaliation. |
| A.7.6 | Security of copilots and LLM assistantsConversational assistants deployed in industrial environments shall be protected against prompt injection and against disclosure of restricted information. |
Annex A Summary
- A.1 Governance — 8 controls · policy, ownership, inventory, classification
- A.2 Model lifecycle — 9 controls · poisoning, adversarial, signing, decommissioning
- A.3 Industrial data — 8 controls · telemetry, lineage, drift, know-how
- A.4 IT/OT architecture — 8 controls · zones, write channels, edge, logging
- A.5 Supply chain — 7 controls · AIBOM, third parties, jurisdiction, reversibility
- A.6 Operation and response — 8 controls · monitoring, fallback, forensics, NIS2
- A.7 Human factor — 6 controls · competence, oversight, override, copilots
Total: 54 controls. None is optional by default.
Annex B (informative) — Statement of Applicability
The Statement of Applicability (SoA) is the document that connects risk to control. It is the first thing an audit team reads and, in practice, what determines whether a certification is solid or merely paper. Producing it is a requirement of clause 6.1.3.
B.1 Minimum required structure
The SoA shall contain one row for each of the 54 Annex A controls, with the following columns:
| Column | Content | Mandatory |
|---|---|---|
| Control | Code and designation per Annex A | Yes |
| Applicable | Yes / No | Yes |
| Justification | Reason for inclusion or exclusion, referenced to the risk identified in 6.1.2 | Yes |
| Associated risk | Identifier of the register risk this control treats | Yes, if applicable |
| Status | Not started / In implementation / Implemented / Verified | Yes, if applicable |
| Evidence | Reference to the document, record or test attesting implementation | Yes, if implemented |
| Owner | Named role responsible for the control | Yes, if applicable |
| Last review | Date of the last effectiveness verification | Yes, if verified |
B.2 Worked example
Illustrative extract for a manufacturing plant operating third-party machine vision at autonomy level N2.
| Control | Applicable | Justification | Status | Evidence |
|---|---|---|---|---|
| A.2.3 Data poisoning |
Yes | The model is retrained monthly with images labelled by line operators; risk R-014 of malicious or negligent labelling exists. | Implemented | PRO-AI-07 §4 Monthly statistical validation record |
| A.2.4 Adversarial examples |
Yes | The camera is accessible from a transit area; risk R-021 of physical manipulation of the scene. | In implementation | Plan PT-2026-03, testing scheduled Q4 |
| A.2.7 Training segregation |
No | Justified exclusion: the organisation does not train models. Retraining is executed by the supplier on its own infrastructure. The risk is transferred through A.5.4 and verified in the annual supplier audit. | — | Contract SUP-2025-11 clause 9 Supplier audit report 2026 |
| A.4.3 Write channels |
Yes | The system issues a reject signal to the line diverter; risk R-008 of undue mass rejection. | Verified | Test PT-2026-01 Rate limit configured in PLC, verification record 12/03/2026 |
| A.6.4 Degraded operation without AI |
Yes | Risk R-003: unavailability of the cloud inference service. | Verified | Drill 22/05/2026 Transition to manual inspection in 4 min 10 s |
B.3 Common errors that invalidate an SoA
- Justifying by convenience rather than by risk — "not applicable because we lack resources" is not an acceptable justification.
- Excluding A.6.4 or A.7.3 — degraded operation and effective human oversight cannot be excluded in systems at autonomy level N2 or N3.
- Declaring implemented without verifiable evidence — a written procedure is not evidence of implementation; its execution record is.
- Transferring risk to the supplier without verifying it — exclusion by transfer requires evidence of effective verification of the third party.
- SoA misaligned with the risk register — every applicable control shall be traceable to at least one identified risk.
Annex C (informative) — Correspondences with Other Standards
Equivalence table by domain. An already certified organisation can reuse much of its existing evidence: the "IRIS-SEC adds" column indicates what none of the other standards requires.
| IRIS-SEC domain | ISO/IEC 27001 | ISO/IEC 42001 | IEC 62443 | IRIS-SEC adds |
|---|---|---|---|---|
| A.1 Governance | High coverage | High coverage | Medium coverage | Classification by autonomy level N0–N3 and segregation of deployment authorisation |
| A.2 Model lifecycle | No coverage | Low coverage | No coverage | Entire domain: poisoning, adversarial, extraction, artefact signing |
| A.3 Industrial data | Medium coverage | Low coverage | Medium coverage | Process data lineage, drift and protection of embedded know-how |
| A.4 IT/OT architecture | Low coverage | No coverage | High coverage | AI/control separation and governance of AI write channels onto the process |
| A.5 Supply chain | Medium coverage | Medium coverage | Medium coverage | AIBOM, weight and dataset provenance, compute jurisdiction and reversibility |
| A.6 Operation and response | Medium coverage | Low coverage | Medium coverage | Degradation thresholds, tested fallback and forensics of automated decisions |
| A.7 Human factor | Low coverage | Medium coverage | Low coverage | Practical override verification and security of industrial copilots |
This table is indicative and does not replace a formal gap analysis. An organisation certified to ISO/IEC 27001 typically covers between 30 % and 45 % of IRIS-SEC 27001 controls with its existing evidence.
Certification Process
Third-party conformity assessment in two stages, on a three-year cycle with annual surveillance. The stage 2 audit is conducted on the shop floor: industrial AI is not certified from a meeting room.
Preliminary assessment of the starting position against the 54 controls. Recommended for organisations without a prior ISMS.
Review of scope, policy, risk methodology, treatment plan and Statement of Applicability. Determines readiness for stage 2.
Verification of implementation and effectiveness of controls on real systems, including a practical safe degradation and human override test.
Certificate valid for three years, with annual surveillance audit and full recertification at the end of the cycle.
Scheme conditions
- Typical total duration: 5 to 10 months from start to issue, depending on the starting position and the number of systems in scope.
- Significant retraining: requires notification to the certification body and may trigger an extraordinary audit.
- Serious AI incident: requires notification within 72 hours and review of the certificate.
- Modular scope: modules 27010 to 27090 are audited as a scope extension over a valid 27001 certificate.
- Cross-recognition: evidence from an ISO/IEC 27001 certified ISMS is accepted for controls with direct correspondence per Annex C.
Nature of the Scheme and Terms of Use
Transparency about what IRIS-SEC 27001 is and is not
What it is
IRIS-SEC 27001 is a sectoral certification scheme owned by European Initiative Industry 4.0, openly published, whose fulfilment is assessed through an independent third-party audit.
What it is not
It is not an ISO, IEC, CEN or UNE standard. It is not accredited by ENAC or by any national accreditation body. It implies no endorsement, approval or relationship whatsoever with the International Organization for Standardization (ISO) or the International Electrotechnical Commission (IEC). The numerical coincidence with ISO/IEC 27001 indicates equivalence of subject matter, not equivalence of origin or official recognition.
Obtaining IRIS-SEC 27001 certification does not exempt an organisation from any legal obligation, including the conformity assessment required by Regulation (EU) 2024/1689 for high-risk AI systems.
Terms of use of the normative text
The text of this standard is published openly and free of charge for reading, citation and internal use by any organisation. Partial reproduction is permitted with attribution. Use of the mark and of the designation "IRIS-SEC 27001 certified" is reserved to organisations that have passed the certification audit and maintain a valid certificate.
Want to Certify Your Organisation to IRIS-SEC 27001?
The usual first step is a gap analysis against the 54 Annex A controls. Tell us your scope and we will show you your real starting position.
Frequently Asked Questions about IRIS-SEC 27001
Does IRIS-SEC 27001 replace ISO/IEC 27001?
No. IRIS-SEC 27001 is built on the ISO harmonised structure (Annex SL), the same clauses 4 to 10, precisely so that it integrates into an existing ISMS without duplicating the management system. ISO/IEC 27001 protects the organisation's information; IRIS-SEC 27001 protects the model, the industrial data and the automated decision, which are assets that Annex A of ISO/IEC 27002 does not address. Holding both is ideal.
How does it relate to ISO/IEC 42001 and IEC 62443?
IRIS-SEC 27001 occupies the intersection of all three standards. ISO/IEC 42001 governs AI generically and without cybersecurity depth; IEC 62443 secures the OT environment but predates industrial AI and addresses neither models, training nor drift; ISO/IEC 27001 is IT-centric. A plant deploying AI on its process falls between the three. Annex C of the standard details the correspondence domain by domain.
Is the standard paid?
No. The complete normative text — scope, clauses 4 to 10, Annex A with all 54 controls and the Statement of Applicability guidance — is published openly on this page. Only the independent third-party certification audit carries a cost. You can self-assess before deciding whether certification interests you.
Can an organisation that only uses AI, without developing it, be certified?
Yes. Clause 1.1 distinguishes four profiles: developer, integrator, operator and service provider. A plant operating third-party AI certifies the controls that apply to it and transfers the rest to its supply chain through domain A.5, justifying exclusions in the Statement of Applicability. The Annex B example covers exactly that case.
How many controls does Annex A have, and which cannot be excluded?
54 controls across 7 domains. All apply by default and any exclusion requires documented justification referenced to an identified risk. In systems at autonomy level N2 or N3, exclusion of A.6.4 (degraded operation without AI) and A.7.3 (effective human oversight) is not permitted.
Is it accredited by ISO or by a national accreditation body?
No, and we state this expressly. IRIS-SEC 27001 is a certification scheme owned by European Initiative Industry 4.0, independent of ISO, IEC, CEN, AENOR and ENAC, without accreditation or endorsement from those bodies. The numerical coincidence with ISO/IEC 27001 signals equivalence of subject matter, just as IRIS-EDU 21001 does with respect to ISO 21001, not equivalence of origin.
We already hold ISO/IEC 27001. How much additional work is involved?
An organisation with a mature ISMS typically covers between 30 % and 45 % of IRIS-SEC 27001 controls with existing evidence, mostly in domains A.1 and A.5. The real effort concentrates in A.2 (model lifecycle) and A.6 (operation and response), the domains with no coverage in ISO/IEC 27002. The preliminary gap analysis quantifies that distance before you commit budget.
How long does certification take?
Between 5 and 10 months from start to issue, depending on the starting position and the number of systems in scope. The certificate is valid for three years, with an annual surveillance audit. Significant retraining of a model in scope requires notification and may trigger an extraordinary audit.