Critical Infrastructure Regulation Map: Cyber Rules for Essential Services by Region

Operators of energy, water, transport, telecoms and other essential services now answer to several overlapping cyber regimes at once, each with its own scope test, reporting clock and regulator. A gas network with assets in Germany, Great Britain, the United States and Australia can face NIS2, the CER Directive, the UK NIS Regulations, TSA security directives, the future CIRCIA rule and the SOCI Act, with incident clocks ranging from 12 hours to one month. This map summarises the main critical infrastructure instruments by region, compares who is in scope, what they must do and how fast they must report, and links to the detailed NHI Mgmt Group guides rather than repeating them. It is written for CISOs, OT security leads and compliance teams in operators, and for suppliers whose services those operators depend on. Status as of 25 October 2026: several instruments are still moving, so check each one against the primary source before relying on a date.

Key takeaways

• Two layers in most regions. A cyber layer (NIS2, UK NIS, Singapore Cybersecurity Act, SOCI Part 2B) sits beside a wider resilience or physical layer (CER Directive, SOCI risk management programmes), and most large operators fall under both.
• Reporting clocks differ sharply. NIS2 expects a 24 hour early warning and 72 hour notification, CER a 24 hour initial notification, SOCI 12 hours for critical incidents, and the proposed CIRCIA rule 72 hours for incidents and 24 hours for ransom payments.
• Several dates are live or slipping. CER critical entity identification fell due on 17 July 2026, the UK Cyber Security and Resilience Bill is at Lords report stage, and the CIRCIA final rule had no confirmed effective date when this map was checked.
• Accountability moves to the top. NIS2 makes management bodies approve and oversee risk measures, SOCI requires board-approved annual reports, and Singapore keeps CII owners responsible even when systems run in the cloud.
• Machine access is in scope even when unnamed. Remote access accounts, vendor connections, service accounts and AI agents touching OT or control systems are covered by the access, supply chain and incident duties in every regime here.

Regulations and frameworks at a glance

For the wider picture across all sectors, see the Global Cybersecurity Regulatory Map. Banks and payment systems that are also designated critical infrastructure should read this page alongside the Financial Services Cyber Regulation Map. Hospitals and health providers in scope should also check the Healthcare Cyber Regulation Map.

Scope: who and what is covered

Every regime here starts with a scope test, and that test decides everything else.

European Union

• NIS2: Applies by sector (Annex I high criticality, Annex II other critical) and, as a rule, by size, with some entities in scope regardless of size, such as DNS providers and qualified trust service providers. Entities are classed as essential or important, which changes supervision and fine levels rather than the core measures. The NIS2 Readiness Checklist walks through the scoping questions.
• CER Directive: Member States identify critical entities, they do not self-designate. Under Article 6(1) each Member State had to identify its critical entities by 17 July 2026 and must notify them. An entity providing essential services to or in six or more Member States can be a critical entity of particular European significance under Article 17, which brings Commission advisory missions.
• How the two fit: CER Article 1(2) says the directive does not apply to matters covered by NIS2, so cyber measures sit under NIS2 and the physical, natural hazard, insider and wider resilience measures sit under CER. Under Article 8, critical entities in banking, financial market infrastructure and digital infrastructure are excluded from the CER resilience measures and reporting chapters, because DORA and NIS2 already cover them.

United Kingdom

• NIS Regulations 2018: Cover operators of essential services in energy, transport, health, drinking water and digital infrastructure, plus relevant digital service providers (online marketplaces, search engines, cloud computing), each with a competent authority such as Ofgem, the Drinking Water Inspectorate or the ICO.
• Cyber Security and Resilience Bill: The Bill would bring managed service providers and data centres into scope and let regulators designate critical suppliers. It completed its Commons stages on 16 June 2026, had Lords second reading on 14 July 2026 and Grand Committee from 1 September 2026. Treat its provisions as proposals until Royal Assent and commencement regulations. See the UK Cyber Security and Resilience Bill Guide.

United States

• CIRCIA: The statute covers entities in critical infrastructure sectors, but the covered entity definition is set by the final rule. The April 2024 proposal used sector-based criteria plus a size test, and both were heavily debated at CISA's June 2026 town halls.
• TSA directives: Apply only to owners and operators TSA has notified as critical. Separate directives cover pipelines, freight rail (1580) and passenger rail and public transport (1582).
• Sector regulators: Electricity (NERC CIP), water and nuclear have their own rules. This map does not cover them in detail; see the Energy Sector Identity and OT Access Guide and the Water and Wastewater Cybersecurity Guide.

Asia Pacific

• SOCI Act (Australia): Covers 11 sectors, from communications and energy to healthcare, transport, water and data storage or processing. Duties are switched on by asset class, so one entity may hold assets with different obligations. Systems of National Significance (SoNS) carry enhanced cyber security obligations.
• Cybersecurity Act (Singapore): Designated CII in energy, water, banking and finance, healthcare, transport, infocomm, media, security and emergency services, and government. The 2024 amendments added foundational digital infrastructure (such as cloud service providers and data centres), entities of special cybersecurity interest and systems of temporary cybersecurity concern.

Key obligations

The regimes use different words for much the same core duties. The table maps them so one control set can serve several regulators.

Article numbers for NIS2 refer to Directive (EU) 2022/2555; the national transposing law is what binds you, and some Member States have added to the list. For the NIS2 and DORA boundary, see the DORA and NIS2 Overlap Mapping Guide.

Timeline and current status

CISA's own CIRCIA page describes the final rule's effective date as yet to be determined, and law firm reviews in July and September 2026 reported repeated target dates (May 2026, then September 2026) and the possibility of further delay through White House review. Australia's Cyber and Infrastructure Security Centre has also said its regulatory approach will change from 2026-27, informed by the 2026 Independent Review of the SOCI Act.

Enforcement and penalties

• NIS2: Maximum administrative fines of at least EUR 10 million or 2% of worldwide annual turnover for essential entities, and EUR 7 million or 1.4% for important entities, whichever is higher, plus the power to hold management personally accountable and, for essential entities, to suspend certifications or managers temporarily.
• CER: Article 22 leaves penalties to Member States, requiring them to be effective, proportionate and dissuasive. Expect national figures to vary widely.
• UK NIS: Regulation 18 caps penalties at £17 million for a material contravention that caused or could cause a significant risk or impact on the service, £8.5 million for other material contraventions and £1 million for non-material ones.
• US: Under CIRCIA, CISA can request information and issue subpoenas for non-reporting, with referral to the Department of Justice. TSA directives are mandatory for notified operators and enforced through TSA inspection and civil penalty powers.
• Australia and Singapore: Both regimes include civil penalties for failing to report or maintain programmes, and both give government step-in or direction powers for serious incidents, which in Australia apply only where an incident would cause serious harm to prosperity, national security or defence.

The practical lesson from enforcement is that regulators look first at whether a basic, documented control existed. The Colonial Pipeline ransomware attack began with a legacy VPN account that was no longer used, had never been disabled and did not require MFA; the operator shut the pipeline from 7 to 13 May 2021. The TSA pipeline directives followed that incident, and their access control and segmentation requirements read as a direct answer to it.

What it means for AI agents and non-human identities

None of these instruments mentions AI agents by name, but all of them regulate access to the systems that deliver an essential service, and much of that access is held by machines.

• Remote and vendor access: Service accounts used by OEMs, integrators and managed service providers are the commonest route into OT. NIS2 supply chain security, the UK Bill's critical supplier provisions and SOCI supply chain hazards all reach them. See the OT Remote Access Guide.
• Machine credentials in control systems: Shared engineering workstation accounts, historian service accounts and hard-coded PLC credentials are rarely rotated. Inventory them as part of asset management (NIST CSF 2.0 ID.AM) and manage them under PR.AA. See the OT and ICS Identity and Access Guide.
• AI agents in operations: Agents used for maintenance planning, alarm triage or grid forecasting that can read or write to operational systems inherit the same duties: least privilege (SP 800-53 AC-6), credential management (IA-5) and logging good enough to support a 12 to 72 hour report.
• Incident evidence: Every reporting clock assumes you can tell quickly which identity did what. Machine identities with shared or generic names make the first report slower and less accurate.

For a sector view of identity controls, see the Critical Infrastructure Identity Security Guide.

Compliance steps

1. Map entities to regimes. For each legal entity and each country, record which instruments apply, which authority supervises you and whether you are essential, important, critical or a SoNS.
2. Build one control baseline. Use NIST CSF 2.0 or IEC 62443 as the spine and map NIS2 Article 21, the CAF, the TSA directive measures, CIRMP and the Singapore code onto it. The NIST SP 800-82 OT Security Guide covers the OT specifics.
3. Design a multi-clock reporting path. One triage process, one severity model, then a jurisdiction table that fires the right notifications: 12 hours (SOCI critical), 24 hours (NIS2 early warning, CER, TSA), 72 hours (NIS2, UK NIS, SOCI other, proposed CIRCIA). Pre-draft templates and test them in exercises. Map this to CSF 2.0 RS.CO and SP 800-53 IR-6.
4. Close identity gaps first. Disable dormant remote access accounts, enforce MFA on all external access, inventory service accounts on OT boundary systems and remove shared vendor logins. These are the controls regulators test first after an incident.
5. Bring suppliers into scope. Add notification, access and evidence clauses to contracts with OEMs, MSPs and cloud providers (CSF 2.0 GV.SC, SP 800-53 SR-6). See the Third-Party Risk Management Guide.
6. Exercise and prove recovery. Run at least one cross-border scenario a year that triggers several reporting regimes at once, and test recovery plans (CSF 2.0 RC.RP, SP 800-53 CP-2). Roll back gracefully: if a new segmentation rule or access restriction disrupts operations during testing, keep the previous configuration documented and approved so it can be restored within the outage window.
7. Brief the board. Give management bodies the scope map, the open gaps and the reporting design, and record their approval, since NIS2 and SOCI both expect evidence of board oversight.

Measuring progress

• Scope coverage: percentage of entities and sites with a confirmed regime mapping and named authority.
• Reporting readiness: time from detection to draft notification in the last exercise, against the shortest applicable clock.
• Remote access hygiene: number of dormant or MFA-less remote access accounts on OT boundaries (target zero).
• Supplier coverage: percentage of critical suppliers with notification and access clauses in contract.
• Machine credential age: share of OT service account credentials rotated within policy.

Common failure patterns

• Waiting for the final text. Teams that wait for the CIRCIA rule or the UK Bill to finish lose the lead time needed to build reporting and supplier processes that will be required anyway.
• One clock for all. Using a single 72 hour target misses SOCI's 12 hour and NIS2's 24 hour early warning duties.
• Treating CER as a physical security matter only. CER risk assessments cover personnel security, supply chain and recovery, and they need the cyber team's input even though cyber measures sit under NIS2.
• Forgotten access. Legacy VPN, vendor and service accounts outliving their purpose, as at Colonial Pipeline.

Practitioner checklist

• Maintain a dated register of every regime, authority and designation that applies to each entity.
• Check the status line of each instrument monthly while CIRCIA and the UK Bill are in motion.
• Prepare for CER notification and the nine month risk assessment deadline that follows it.
• Publish a jurisdiction-by-jurisdiction incident clock table to the incident response team.
• Remove or MFA-protect every external access path into OT, including vendor accounts.
• Inventory service accounts and AI agents with access to operational systems, with an owner for each.
• Embed regulatory notification and access clauses in critical supplier contracts.
• Run a yearly multi-regime exercise and record lessons learned.
• Record board approval of the cyber risk management measures.

Standards and references

• EUR-Lex: Directive (EU) 2022/2555 (NIS2 Directive)
• EUR-Lex: Directive (EU) 2022/2557 on the resilience of critical entities
• legislation.gov.uk: The Network and Information Systems Regulations 2018, regulation 18
• UK Parliament: Cyber Security and Resilience (Network and Information Systems) Bill
• CISA: Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA)
• TSA: Security Directives and Emergency Amendments
• Cyber and Infrastructure Security Centre: Security of Critical Infrastructure Act 2018
• Cyber Security Agency of Singapore: Cybersecurity Act

This guide summarises critical infrastructure cyber regulation for security practitioners and is not legal advice; confirm obligations with your legal and compliance teams and the primary texts. Related NHI Mgmt Group resources: Global Cybersecurity Regulatory Map · Critical Infrastructure Identity Security Guide · OT Security Guide · Regulatory Change Management Guide