SECTOR NOTE · PUBLIC

AI-IRF Critical Infrastructure Sector Note

AI incident-response considerations for essential and cyber-physical services.

Publication content

ODA3 INSTITUTE — SECTOR APPLICATION NOTE

Critical Infrastructure

Applying AI-IRF® v1.0 in energy, water, transport, telecommunications, and industrial control systems — mapping controls to IEC 62443, NIS2, NERC CIP, and NCIIPC frameworks

1. Why AI Governance Certification Matters in Critical Infrastructure

AI is increasingly embedded in the operational technology (OT) and industrial control systems (ICS) that manage power grids, water treatment, pipeline networks, rail signalling, and telecommunications — systems whose failure or compromise has cascading societal consequences. Unlike enterprise IT, OT/ICS AI failure modes have physical consequences: incorrect grid balancing AI can cause blackouts; compromised water treatment AI can create public health emergencies; adversarial attacks on transport AI can cause accidents.

Regulators in the EU (NIS2), North America (NERC CIP), and India (NCIIPC) are now explicitly addressing AI in critical infrastructure governance expectations. IEC 62443 — the established cybersecurity standard for industrial automation and control systems — provides the security baseline against which AI-IRF® v1.0's security controls are aligned. This note explains how.

2. Regulatory Landscape

2.1 IEC 62443 — Industrial Automation and Control Systems Security

IEC 62443 is the international standard series for IACS cybersecurity, structured across four parts covering general (Part 1), policies and procedures (Part 2), system requirements (Part 3), and component requirements (Part 4). It defines Security Levels (SL 1–4) based on the attack sophistication an asset owner must defend against. AI systems embedded in or interfacing with IACS must be assessed against IEC 62443 requirements. Specific relevance:

IEC 62443-2-1 (security management system): requires a documented, risk-based IACS security management programme — AI systems are assets within this programme requiring specific risk assessment.

IEC 62443-3-2 (security risk assessment for system design): requires security risk assessments for OT system designs, including AI components that make operational decisions.

IEC 62443-3-3 (system security requirements): defines foundational requirements (FR) including FR 1 (identification and authentication), FR 2 (use control), FR 3 (system integrity), FR 6 (timely response to events), FR 7 (resource availability) — all directly applicable to AI systems in ICS.

IEC 62443-4-2 (technical security requirements for components): applies to AI components embedded in IACS — covers software application requirements, data flow control, and least privilege.

2.2 NIS2 Directive (EU) 2022/2555

NIS2, effective October 2024, applies to essential entities (energy, transport, banking, health, water, digital infrastructure, ICT service management) and important entities across 11 sectors. Article 21 requires these entities to implement cybersecurity risk management measures covering: risk analysis and information system security policies; incident handling; business continuity; supply chain security; secure development; and access control. AI systems embedded in essential services infrastructure are explicitly in scope.

Article 21(2)(a) — risk analysis and information security policies: AI-specific risk assessments are required where AI systems perform or support functions essential to the service.

Article 21(2)(b) — incident handling: AI-related security incidents (model manipulation, adversarial attacks, AI-driven process failures) must be handled under the NIS2 incident management framework.

Article 21(2)(d) — supply chain security: AI models, training data services, and AI platform providers are supply chain elements subject to NIS2 Article 21(2)(d) assessment requirements.

Article 23 — reporting obligations: significant incidents affecting essential services — including AI-driven failures — must be reported to national authorities within 24 hours (early warning), 72 hours (incident notification), and 1 month (final report).

2.3 NERC CIP (North America)

NERC Critical Infrastructure Protection (CIP) standards apply to the bulk electric system in North America. CIP-007 (Systems Security Management), CIP-010 (Configuration Change Management), and CIP-013 (Supply Chain Risk Management) are most directly relevant to AI deployments in grid management and energy trading systems. AI systems that perform or support operations affecting the reliable operation of the bulk electric system are subject to CIP controls.

2.4 NCIIPC Framework (India)

India's National Critical Information Infrastructure Protection Centre (NCIIPC) has identified critical information infrastructure across energy, transport, banking, telecom, space, and defence sectors. NCIIPC's guidelines on securing CII require risk-based security management, incident reporting to NCIIPC within prescribed timelines, and supply chain security assessments for technology components. The emergence of AI in grid management, traffic control, and pipeline monitoring systems in India makes AI governance a rapidly growing NCIIPC concern.

3. AI-IRF® v1.0 Control Mapping — Critical Infrastructure Note: The following mapping covers the 13 original AI-IRF® v1.0 domains. The 6 normative extension domains (CSS-1–7, FL-1–4, MMD-1–3, QBS-1–3, HAL-1–3, PQC-1) from ODA3-ECO-011/013/014/015 are additionally applicable in sectors handling synthetic media, federated model training, AI-generated content, or quantum-sensitive data.

4. Sector-Specific Control Guidance

4.1 Energy — Grid Management and Renewable Energy AI

SEV-CLS/SEV-RPT (model failure response): AI systems involved in grid balancing or demand forecasting must have defined failure modes and automatic fallback to deterministic control logic. The audit requires evidence that the fallback has been tested, not only designed.

MSR-3/REL-3 (kill switch): AI-driven grid management systems must have an authenticated, low-latency operator override that disconnects AI control and restores manual operation within a defined time. This is a Major NC risk if the mechanism is theoretical rather than operationally tested.

ZTA-3 (adversarial testing): grid AI systems are targets for nation-state adversarial attack — the AI-IRF® v1.0 adversarial testing requirement (ZTA-3) requires documented testing methodology. In the energy sector, red team exercises or tabletop simulations of AI manipulation attacks should be part of the evidence base.

BOM-4 (dependency mapping): grid management AI depends on SCADA, weather data, market data, and metering systems. Dependency maps must identify single points of failure and the operational consequence of each dependency failure.

4.2 Water and Wastewater

MLC-5 (performance monitoring): water treatment process AI (dosing, pH control, contamination detection) must be monitored continuously. Performance thresholds must be set with reference to safe operating limits — not just statistical thresholds. Evidence must show that threshold breaches trigger human review, not just automated adjustment.

APA-1 (human-in-the-loop): autonomous chemical dosing AI without operator oversight is a public health risk. APA-1 requires documented human oversight at defined intervals and for all outputs outside normal ranges.

SEV-RPT/MSR-3 (incident response): water infrastructure AI incidents must trigger NCIIPC/NIS2 reporting obligations. Incident response procedures must be AI-specific — generic IT incident response plans that do not address AI failure modes will be raised as observations or Minor NCs.

4.3 Transport — Rail, Aviation, Road

MLC-1 (model validation): transport AI used in safety-critical functions (collision avoidance, signal management, ATC support) must be validated under adversarial conditions as well as normal operating conditions. Validation must cover edge cases — low-visibility, sensor degradation, atypical traffic patterns.

REG-2 (explainability): transport AI outputs consumed by human operators (e.g. traffic management recommendations, ATC advisory outputs) must be explainable at a level sufficient for operator challenge and override. Black-box outputs in human-machine interfaces are a systematic concern in transport AI.

PHY-3/MSR-3 (recovery time): transport infrastructure AI must have defined and tested recovery times. The audit will verify that RTO/RPO targets are documented and that recovery procedures have been exercised.

4.4 Telecommunications

BOM-3 (supplier assessment): telecom AI — network optimisation, traffic routing, fraud detection — frequently uses third-party AI platforms. The supply chain assessment must evaluate the AI vendor's own security posture, not only contractual commitments.

ZTA-2 (access control): AI systems managing network infrastructure must enforce strict role-based access control. The audit will test whether AI administrative access is logged, reviewed, and restricted to authorised personnel.

SEV-CLS (AI incident register): telecom AI incidents (network routing failures caused by AI, fraud detection bypasses) must be recorded in a dedicated AI incident register — not only in generic network incident logs.

5. Certification Pathway for Critical Infrastructure Organisations

6. Frequently Asked Questions — Critical Infrastructure

Document Number	ODA3-2026-06-RPT-SCS-026	Version	1.0
Sector	Critical Infrastructure — Energy, Water, Transport, Telecom, Industrial Control Systems	Classification	Public
Primary regulations	IEC 62443 series; NIS2 Directive (EU) 2022/2555; NERC CIP (North America); NCIIPC framework (India); EU AI Act Annex III	Companion documents	ODA3-2026-06-TCR-HAI-001; ODA3-2026-06-EXB-HAI-002

PURPOSE	This Sector Application Note (covering AI-IRF® v1.0 — 79 controls across 19 domains) translates AI-IRF® v1.0 controls into the language and obligations of critical infrastructure regulators. It is a lead-generation and client-enablement document. Organisations in critical infrastructure sectors should consult qualified regulatory and security counsel before making compliance claims.

LICENCE NOTICE — GEL v1.0 | Public Document This document is part of the GAISSF Ecosystem published by ODA3 Institute (ODA3 Pvt Ltd) under the GAISSF Ecosystem Licence (GEL v1.0), effective 1 June 2026. GAISSF™, UAIF®, AI-IRF®, AI IRF CERT®, and ODA3® are registered trademarks of ODA3 Pvt Ltd (GEL §9.1). ODA3 Institute is the sole owner, proprietor, and governing body of the AI-IRF® framework and AI IRF CERT® scheme in perpetuity (GEL §10.5). Commercial Use of this document — including use in consulting, advisory, regulatory submissions prepared for fee, or training delivery — requires a separate written commercial licence from ODA3 Institute (GEL §3.4). AI training data use prohibited without licence (GEL §3.6). Disclaimer: provided “AS IS” without warranties (GEL §12). Governing law: Republic of India; DIAC arbitration, New Delhi seat (GEL §14). All enquiries: https://docs.oda3.org/ — Attribution (GEL §6): AI-IRF® v1.0 Sector Application Note — Critical Infrastructure © ODA3 Institute, GEL v1.0.

AI-IRF® v1.0 Domain	Regulatory obligation(s)	How AI IRF CERT® certification supports compliance
Model Lifecycle Security & Severity (MLC-1–5, APA-3, SEV-CLS/RPT)	IEC 62443-3-3 FR3 (system integrity); NIS2 Art. 21(2)(a) (risk analysis); NERC CIP-007 (systems security)	Verifies that AI models used in operational control have been validated, have defined performance thresholds, and have failure detection — provides evidence for IEC 62443 integrity requirements and NIS2 risk analysis documentation
AI Supply Chain & BOM (BOM-1–5, REG-4)	IEC 62443-4-2 (data flow control); NIS2 Art. 21(2)(a); NERC CIP-010 (configuration/baseline management)	Covers training data provenance and operational data quality for AI systems — addresses IEC 62443 data integrity requirements and NERC CIP configuration management obligations for AI system inputs
Regulatory Compliance & Transparency (REG-1–4)	NIS2 Art. 21 (governance expectations); IEC 62443-2-1 (security management — operator understanding)	Ensures that OT operators can understand AI system behaviour and outputs — critical for human override decisions in high-consequence operational environments
Agentic Permissions (APA-1–5, REL-2–3)	IEC 62443-3-3 FR6 (timely response to events); NIS2 Art. 21(2)(c) (business continuity); NERC CIP-007	Verifies human override mechanisms, emergency shutdown procedures, and AI decision intervention capabilities — directly addresses IEC 62443 FR6 and NERC CIP operational continuity requirements
Regulatory Compliance & Severity (REG-1–4, SEV-CLS/RPT)	NIS2 Art. 21(2)(a) (policies); NIS2 Art. 21(2)(f) (risk management practices); IEC 62443-2-1	Board-level AI governance, defined OT AI roles, and incident response procedures are verified — maps to NIS2 Art. 21 governance obligations and IEC 62443-2-1 security management system requirements
Physical AI Safety & Zero Trust (PHY-1–4, ZTA-3–4)	NIS2 Art. 21(2)(c) (business continuity, disaster recovery); IEC 62443-3-3 FR7 (resource availability); NERC CIP-009	Covers AI system continuity, failsafe degraded mode operation, and recovery time objectives — directly addresses NIS2 BCM requirements and IEC 62443 FR7 availability requirements for OT systems
Zero Trust AI Architecture & Model Extraction Defense (ZTA-1–4, MEX-1–2)	IEC 62443-3-3 FR1/FR2 (authentication/use control); IEC 62443-4-2; NERC CIP-005/CIP-007; NIS2 Art. 21(2)(e)	AI system access controls, adversarial attack testing, and network segmentation between AI systems and OT networks are audited — addresses IEC 62443 foundational requirements and NERC CIP electronic security perimeter requirements
AI Supply Chain & BOM (BOM-3–5)	NIS2 Art. 21(2)(d) (supply chain security); NERC CIP-013; IEC 62443-2-1; NCIIPC supply chain guidelines	Verifies that AI model vendors, training data providers, and AI platform operators serving OT environments are assessed and contractually obligated — directly addresses NIS2 and NERC CIP supply chain risk requirements

Step	Activity	Critical infrastructure context
1	Scope definition	Define which AI systems operating in or interfacing with OT/ICS environments are in scope. Prioritise AI systems that perform or support safety-critical control functions over administrative AI.
2	IT/OT boundary mapping	Map the data flows between AI systems (typically in IT network zones) and OT control systems. This boundary is a key audit focus — the audit will assess controls at the IT/OT interface.
3	IEC 62443 alignment check	Where the organisation holds or is pursuing IEC 62443 certification, map existing IEC 62443 documentation to AI-IRF® v1.0 controls using the mapping table in Section 3. Duplication of documentation effort should be minimised.
4	Stage 1 audit	Document review. OT organisations often have strong process safety documentation and security architecture diagrams — these can serve as partial evidence for AI-IRF® v1.0 controls if updated to reflect AI-specific elements.
5	Stage 2 audit	On-site assessment strongly preferred for OT environments — remote audit of OT systems has practical limitations. Audit team should include a Lead Auditor with OT/ICS sector experience. Expect 3–5 audit days.
6	Certificate and regulatory use	Use AI IRF CERT® in NIS2 Art. 21 compliance evidence packages, NCIIPC audit responses, NERC CIP compliance programmes, and IEC 62443 certification extension applications where AI systems are in scope.

Question	Answer
Does AI IRF CERT® replace IEC 62443 certification?	No. IEC 62443 covers the full IACS security programme. AI-IRF® v1.0 addresses AI-specific governance, model risk, bias, and explainability dimensions that IEC 62443 does not specifically cover. The two standards are complementary — AI IRF CERT® fills the AI-specific gap within an IEC 62443 programme.
Can AI systems in air-gapped OT environments be audited?	Yes, with modification. Remote proctored stages are not possible for air-gapped systems. Stage 2 must be conducted on-site. Documentation review can address most controls; direct observation of AI system operation is used for HOC, OPR, and PCS controls.
How does AI IRF CERT® support NIS2 Article 21 compliance?	AI IRF CERT® provides documented, independently audited evidence for the AI-specific dimensions of NIS2 Art. 21 cybersecurity risk management measures, including risk analysis (21(2)(a)), incident handling (21(2)(b)), business continuity (21(2)(c)), and supply chain security (21(2)(d)).
Our OT AI is vendor-managed — does our certification cover the vendor's AI?	No. Your AI IRF CERT® scope covers the AI systems you operate and the controls you implement. Where a vendor manages AI on your behalf, BOM-3–5 controls require you to assess, contract, and monitor that vendor — the vendor's own AI governance is a matter for their own certification.

Authoritative source

Download the approved DOCX source →

This accessible HTML rendering preserves the publication text for search and discovery. The approved source file governs where formatting differs.