The original intention of this article was to provide guidance on structuring the “normal” ISO 27001 ISMS. Then reality hit. The ISMS cannot and should not be viewed in isolation. In real-world enterprise scenarios, many regulations, directives, and standards are in play, e.g., CRA, NIS2, AI Act.

Some overlap exists, with the risk of double governance, inefficiency, and quality problems.

The Cookbook remains ISMS-focused but now serves as the Unified Control Framework (UCF) operational engine. It consolidates overlapping legal mandates and translates them into a single, deduplicated set of daily policies, procedures, and technical controls.

DISCLAIMER: The interactive guides in this article have been designed with AI support. AI can make mistakes. I’ve done my best to quality-assure the guides. Do not use the material as legal or technical advice.

The Enterprise ISMS Cookbook

A practical guide to structuring, writing, and providing evidence for an Information Security Management System (ISMS) in a complex, multi-regulatory European environment.

VERIFIED COMPLIANT: ISO/IEC 27001:2022 | CRA | NIS2 (Lov nr. 434) | EU AI ACT

Welcome to the Cookbook

This document moves beyond the theory of ISO standards and demonstrates how a modern ISMS operates in a complex, multi-regulatory enterprise environment. By mapping the continuous improvement lifecycle directly to the 4-Tier Documentation Architecture, we bridge the gap between High-Level Policy and DevSecOps reality.

Glossary of Key Terms

To ensure a common understanding of cybersecurity management concepts, it is essential to align our vocabulary derived from ISO/IEC 27000:2018, modern enterprise risk practices, and EU regulatory frameworks (CRA, NIS2, and the AI Act).

Disclaimer: This document utilizes the vocabulary defined in ISO/IEC 27000:2018. Please note that a new 2026 version of the ISO/IEC 27000 standard is now available.

⚙️ ISMS (Information Security Management System)

›

An ISMS consists of the policies, procedures, guidelines, and associated resources and activities, collectively managed by an organization, in the pursuit of protecting its information assets. An ISMS is a systematic approach for establishing, implementing, operating, monitoring, reviewing, maintaining and improving an organization's information security to achieve business objectives (ISO/IEC 27000:2018, Clause 4.2.1).

⚖️ Risk Appetite & Tolerance

›

Risk Appetite is the broad type and amount of risk an organization is willing to accept in pursuit of its objectives, typically set by the Board of Directors. It dictates when a risk must be mitigated versus when it can be formally accepted via a Risk Exception. Risk Tolerance is the specific maximum acceptable variance around that appetite.

🎯 Statement of Applicability (SoA)

›

A mandatory ISO 27001 document (Clause 6.1.3d) bridging the risk assessment and treatment phases. It lists which of the 93 ISO 27001 Annex A controls are applied to the ISMS scope, the justification for their inclusion or exclusion, and their current implementation status.

⚠️ Nonconformity (Major & Minor)

›

The non-fulfillment of an ISMS requirement (ISO 27000:2018, 3.47). A Major Nonconformity indicates a systemic failure of the management system (e.g., failure to conduct management reviews or risk assessments) or a complete lack of a required control. A Minor Nonconformity is an isolated lapse in discipline (e.g., a single employee missing their mandatory security training).

🔐 CIA Triad (Confidentiality, Integrity, Availability)

›

The foundational model of information security. Confidentiality ensures data is only accessible to authorized users. Integrity ensures data remains accurate and unaltered. Availability ensures data and systems are accessible to authorized users when needed. Additional properties such as authenticity, accountability, non-repudiation, and reliability can also be involved (ISO 27000:2018, 3.28).

📦 SBOM (Software Bill of Materials)

›

A formal, machine-readable inventory containing details and supply chain relationships of various components used in building a software product. This is a crucial artifact for managing third-party vulnerabilities and is a legally mandated requirement under the EU Cyber Resilience Act (Annex I, Part II (1)).

🚨 CSIRT (Computer Security Incident Response Team)

›

A designated team of experts responsible for receiving, reviewing, and responding to computer security incident reports. Under the NIS2 Directive and the CRA, specific national CSIRTs act as the mandatory coordinators for critical incident and vulnerability reporting.

🧠 High-Risk AI System & General-Purpose AI Model (GPAI)

›

Terms derived from the EU AI Act (Reg EU 2024/1689). A High-Risk AI System is one that poses significant risks to health, safety, or fundamental rights, often acting as a safety component of regulated products (Art 6). A GPAI Model is trained on massive data at scale and displays significant generality, capable of performing a wide range of distinct tasks (Art 3(63)). Both require strict integration into enterprise risk and quality management systems.

🗄️ Information Asset

›

Any piece of information or data, hardware, software, or service that adds value to an organization. In an ISMS, assets must be identified, classified, and assigned an "Owner" responsible for their security lifecycle.

🧭 GRC (Governance, Risk, and Compliance)

›

A structured approach to aligning IT with business objectives, while effectively managing risk and meeting compliance requirements. Governance ensures organizational activities map to business goals, Risk identifies and mitigates risks associated with those activities, and Compliance ensures adherence to legal and regulatory mandates (like NIS2, CRA, and the AI Act).

📈 Splunk Monitoring

›

A specialized platform used for searching, monitoring, and analyzing machine-generated big data, via a Web-style interface. In an ISMS context, it typically serves as the primary SIEM (Security Information and Event Management) tool for real-time security alerting and historical log analysis.

🌐 NetOps

›

Network Operations. The specialized operational team responsible for deploying, configuring, monitoring, and managing the organization's network infrastructure, including essential security boundaries like firewalls, VPNs, and routing rules.

🔑 Entra ID

›

Microsoft's cloud-based identity and access management service (formerly known as Azure Active Directory or Azure AD). It is the centralized system used to enforce authentication, Multi-Factor Authentication (MFA), and conditional access policies across enterprise applications.

🌍 The Unified Compliance Landscape

›

Before diving into the documentation architecture, it is critical to understand the relationship between international standards and European law. The graphic below illustrates how the ISMS acts as the central engine, translating overlapping legal mandates into a single operational reality, built upon the foundation of ISO/IEC 27001.

🏗️ Recommended ISMS Structure (The 4-Tier Architecture)

›

While ISO/IEC 27001 Clause 7.5 broadly requires "documented information," the 4-Tier Architecture shown below is not a strict normative requirement of the standard. Rather, it is the globally recognized industry best practice (adopted from ITIL and ISO 9001 heritage) for large-scale ISMS implementations. It organizes documents in a hierarchy, ensuring that high-level management intent filters down into specific technical actions without blurring boundaries. Furthermore, borrowing heavily from ISO 9001 Quality Management principles, this tiered approach mandates rigorous document version control and ensures that every operational action (Tier 3) inherently generates the verifiable evidence (Tier 4) required for continuous auditability.

T1 Policies

The "Why"

Purpose Strategic documents approved by top management. They set the organization's overarching intentions, direction, and fundamental rules regarding information security.

Examples Overarching Information Security Policy, Access Control Policy, Acceptable Use Policy.

T2 Procedures

The "What & Who"

Purpose Tactical documents describing the sequence of steps necessary to execute a specific process required by a policy. They define who is responsible for what action, and when it should occur.

Examples Incident Response Procedure, Risk Assessment Methodology, Vendor Onboarding.

T3 Work Instructions

The "How"

Purpose Highly detailed, operational documents providing step-by-step technical instructions for performing a specific task. These are often system-specific and change frequently.

Examples Server Hardening Baselines, Firewall Configuration Guide, Runbooks.

T4 Records & Evidence

The "Proof"

Purpose Historical data demonstrating that policies, procedures, and work instructions were followed. Records cannot be changed once created; they represent facts in time.

Examples Completed Risk Register, CI/CD Logs, Signed NDAs, CAPA Tickets.

🛡️ The Three Lines of Defense (3LOD)

›

The Institute of Internal Auditors' 3LOD model overlays the document hierarchy, ensuring accountability across the continuous improvement lifecycle:

1st Line (Operations/IT) Own and manage risks daily. They execute Tier 3 instructions and generate Tier 4 evidence.

2nd Line (Security/GRC) Write Tier 1/2 policies and monitor 1st line metrics to ensure the ISMS functions.

3rd Line (Internal Audit) Independent function providing objective assurance to the Board by sampling Tier 4 records.

🔗 Bridging the Frameworks: The Harmonized Structure & The 4 Tiers

How do these concepts relate? The Harmonized Structure (Clauses 4-10) describes the chronological actions you must take, while the 4-Tier Architecture describes the documents you generate while taking those actions. For example, writing a Tier 1 Policy happens during the Context & Planning phase (Clauses 4-6), executing a Tier 3 Work Instruction happens during the Operations phase (Clause 8), and reviewing a Tier 4 Record happens during the Performance Evaluation phase (Clause 9).

🚀 Enterprise Case Study: NovaFlow Systems

NovaFlow Systems develops industrial IoT fluid controllers. They are a subsidiary of a larger Enterprise Group. Because they leverage the Parent Group's Corporate ISMS for physical facilities and standard IT endpoints, NovaFlow's local ISMS scope is strictly narrowed to: "The Engineering, Firmware Development, and Cloud Telemetry Platform."

This strict scoping allows NovaFlow to exclude a massive portion of the 93 ISO 27001 Annex A controls (handing them back to the Parent ISMS), focusing only on the 18 controls relevant to their digital operations. This interactive cookbook demonstrates how they map those 18 actively managed controls through all 4 documentation Tiers.

🏛️ Tier 1: Policies (The "Why")

›

Everything begins with Top Management's intent. A Tier 1 Policy outlines the "Why" and sets the mandatory rules within which the organization must operate.

📜 Artifact 1: Overarching Information Security Policy (Clause 5.2 Policy, A.5.1 Policies for information security, A.5.2 Information security roles and responsibilities)

›

POL-SEC-001: Information Security Policy

Approved by Board of Directors • Last reviewed Jan 05, 2026

1. Introduction & Commitment: NovaFlow Systems' Board of Directors is committed to preserving the Confidentiality, Integrity, and Availability of all engineering, firmware, and cloud telemetry assets.

2. Defined ISMS Scope: "The Engineering, Firmware Development, and Cloud Telemetry Platform." Physical security, enterprise HR, and standard IT endpoints fall outside this local scope and are governed by Parent Group ISMS policies.

3. Roles & Responsibilities:

CISO (Local): Accountable to the Board for maintaining the ISMS certification and reporting on metrics quarterly.
Cloud Architect: Responsible for enforcing "Security by Design" across Azure environments.
Firmware Lead: Responsible for cryptographic signing integrity of all IoT deployments.

4. ISMS Objectives:

Maintain 99.99% availability for the Azure Cloud Services platform.
Ensure zero major regulatory breaches regarding the EU NIS2 Directive.
Maintain zero Critical or High vulnerabilities in released IoT firmware (measured via CVSS).

5. Enforcement: Violation of this policy may result in disciplinary action. Exceptions must be formally managed via the Risk Exception Procedure (PROC-SEC-004).

📜 Artifact 2: Cryptographic Controls Policy (A.8.24 Use of cryptography)

›

POL-SEC-004: Cryptographic Controls Policy

1. Policy Statement (Firmware): All deployed firmware and Over-The-Air (OTA) updates for NovaFlow IoT controllers must be cryptographically signed prior to distribution to prevent unauthorized tampering.

2. Approved Algorithms:

Data at Rest: AES-GCM-256 for all Azure Blob Storage and databases.
Data in Transit: TLS 1.3 minimum. Legacy protocols (TLS 1.1/1.0, SSL) are strictly prohibited.
Firmware Signing: ECDSA with P-384 curve or RSA-3072.

3. Key Management: Private keys for firmware signing must never be stored on developer laptops. All signing operations must be executed via the centralized HashiCorp Vault cluster or Azure Key Vault using dedicated Hardware Security Modules (HSMs).

📜 Artifact 3: Logical Access Control Policy (A.5.15 Access control)

›

POL-SEC-005: Global Access Control Policy

1. Default Deny & Least Privilege: Access to NovaFlow cloud applications and source code repositories defaults to "deny." Access is granted strictly on a "Least Privilege" basis.

2. Authentication Requirements:

Multi-Factor Authentication (MFA) is mandatory for 100% of human users accessing in-scope systems.
Service Accounts and APIs must authenticate via certificate-based mutual TLS (mTLS) or managed cloud identities; static shared secrets/passwords are deprecated.

3. Privileged Access: Persistent administrative access (e.g., Global Admin, Contributor roles) is prohibited. Administrative tasks must be executed using Just-In-Time (JIT) access via Azure AD Privileged Identity Management (PIM), requiring active ticket justification and max 4-hour time bounds.

📜 Artifact 4: Asset Management & Classification Policy (A.5.9 Inventory of information and other associated assets, A.5.12 Classification of information)

›

POL-SEC-008: Asset Management & Classification

1. Asset Inventory & Ownership: All cloud resources (VMs, DBs, clusters) must be automatically tracked via Cloud Security Posture Management (CSPM) tools. Every asset must have a clearly assigned "Owner" tag corresponding to an active engineering team.

2. Information Classification Matrix: All unstructured documents and structured databases must be classified into one of four tiers:

Public: Marketing materials, open-source repos. No special protection.
Internal: Standard operational documents. Requires internal authentication.
Confidential: Financial data, standard source code, PII. Requires MFA, encryption at rest.
Restricted: Cryptographic signing keys, critical IP algorithms. Requires JIT PIM access, HSM storage, and strict network isolation.

🗺️ Tier 2: Procedures & Registers

›

A Tier 2 Procedure maps operational activities, establishing the "What" and "Who". Crucially, Tier 2 also houses foundational registers, such as the Statement of Applicability (SoA).

📄 Artifact 5: Statement of Applicability (SoA) - Full Annex A Tailoring

›

Per Clause 6.1.3d, NovaFlow must formally declare which of the 93 Annex A controls apply. Because NovaFlow relies heavily on its Parent Group for physical and HR security, only 18 digital controls are actively "IN" scope for this specific ISMS. Every control marked "IN" below maps directly to an artifact in this cookbook.

Control	Name (ISO/IEC 27001:2022)	Status	Justification	Mapping

📋 Artifact 6: Incident Response Procedure (A.5.24 Information security incident management planning and preparation, A.8.16 Monitoring activities)

›

PROC-SEC-08: Master Incident Response

This procedure defines the specific actions to be taken by the local SOC when Azure telemetry platforms detect anomalies.

PHASE 1

Detection & Triage (L1 SOC): Analyst identifies malicious activity (e.g., massive data egress) via Splunk Dashboards. Assesses impact. If categorized as High/Critical, immediately triggers PagerDuty to page the on-call Incident Commander.

PHASE 2

Containment: NetOps isolates affected subnets via Network Security Group (NSG) API calls. IT Identity revokes suspected compromised Entra ID tokens instantly.

PHASE 3

Eradication & Recovery: Forensics capture VM snapshots for investigation. Compromised pods/VMs are destroyed. Clean infrastructure is re-deployed via Terraform from known-good pipeline states.

PHASE 4

Lessons Learned (Post-Mortem): Mandatory meeting within 72 hours of incident closure. Root causes mapped to 5-Whys. Corrective Action (CAPA) tickets generated in Jira to prevent recurrence.

📋 Artifact 7: Secure Offboarding (A.5.18 Access rights, A.6.5 Responsibilities after termination or change of employment)

›

Defines SLAs and technical hand-offs between the Parent Group's central HR system and NovaFlow's local IT administration for engineering environments.

Trigger (HR) Group HR flags engineering employee as 'Terminated' or 'Resigned' in global Workday system.
Action (IT) Automated webhook triggers PowerShell Runbook. Entra ID account disabled, all active refresh tokens immediately revoked, SSH keys purged from Git within 1 hour.
Review (Sec) Local SOC reviews data exfiltration alerts for the user's last 30 days of activity to ensure IP was not transferred to external USBs/Drives.

📋 Artifact 8: Patch Management (A.8.8 Management of technical vulnerabilities)

›

Defines the Service Level Agreements (SLAs) for applying security updates across all cloud and firmware dependencies, driven by CVSS vulnerability scoring.

CVSS Severity	Deployment Strategy	Maximum SLA
Critical (9.0 - 10.0)	Emergency out-of-band release. Bypasses standard sprint planning.	Within 48 Hours
High (7.0 - 8.9)	Prioritized in current agile sprint. Standard QA regression testing.	Within 14 Days
Medium (4.0 - 6.9)	Added to product backlog. Applied during regular monthly maintenance cycle.	Within 30 Days
Low (0.1 - 3.9)	Opportunistic patching.	Within 90 Days

📘 Tier 3: Work Instructions (The "How")

›

A Tier 3 Work Instruction details the "How". It provides system-specific steps, code configurations, and CLI commands for engineers to physically implement the required controls.

💻 Artifact 9: The Developer Runbook (A.5.37 Documented operating procedures, A.8.24 Use of cryptography)

›

SOP-FW-005: Cryptographic Firmware Signing

This runbook details how CI/CD pipelines authenticate to Azure KeyVault to cryptographically sign Release Candidate (RC) builds before OTA deployment.

Step 1: Pipeline Authentication (OIDC)

Do not use static secrets. Use federated identity credentials.

$ az login --federated-token $ACTIONS_ID_TOKEN \ --service-principal -u $CLIENT_ID -t $TENANT_ID

Step 2: Sign the Binary via Azure SignTool

Retrieve the EV certificate digest from Key Vault and apply the signature.

$ AzureSignTool sign -kvu "https://nova-prod-kv.vault.azure.net" \ -kvi $CLIENT_ID -kvs $CLIENT_SECRET -kvc "NovaFirmwareCert" \ -tr "http://timestamp.digicert.com" -v ./build/pump_v2.bin [SUCCESS] Successfully signed: pump_v2.bin

☁️ Artifact 10: Entra ID Config Guide (A.5.37 Documented operating procedures, A.5.15 Access control)

›

IAM-01: Azure Identity Config Guide

Enforcing strict Conditional Access (CA) for Engineering:

Navigate to Azure Active Directory > Security > Conditional Access.
Create a new policy named `Engineering - Require MFA and Compliant Device`.
Under Users, select the `Grp_NovaFlow_Engineers` Entra group.
Under Cloud apps, select `All cloud apps`.
Under Conditions > Locations, exclude `NovaFlow HQ Trusted IPs` to reduce MFA fatigue locally, but enforce it everywhere else.
Under Grant, select Require multi-factor authentication AND Require device to be marked as compliant (Intune MDM check).
Set Enable policy to On.

🔥 Artifact 11: Firewall SOP (A.5.37 Documented operating procedures, A.8.20 Networks security)

›

All firewall rule changes must be tied to a Change Advisory Board (CAB) approved Jira ticket and executed via infrastructure-as-code or audited CLI.

# 1. Define the network objects

admin@PA-VM# set address obj-AppSubnet ip-netmask 10.0.1.0/24

admin@PA-VM# set address obj-DBSubnet ip-netmask 10.0.2.0/24

# 2. Apply security rule restricting access to DB subnet explicitly to SQL ports

admin@PA-VM# set rulebase security rules Allow-App-To-DB source obj-AppSubnet destination obj-DBSubnet application [ms-sql] action allow

# 3. Validate and commit (MUST reference approved Jira CAB ticket)

admin@PA-VM# commit description "CHG-2026-0892: Allow AppSubnet to DBSubnet"

Commit job 1492 is in progress...

Configuration committed successfully.

☸️ Artifact 12: AKS Hardening Baseline (A.5.37 Documented operating procedures, A.8.9 Configuration management)

›

Kubernetes clusters (AKS) must be deployed via Terraform using the approved, security-hardened module baseline.

Terraform Main.tf (Security Enforcements):

resource "azurerm_kubernetes_cluster" "aks_cluster" { name = "nova-prod-aks" # 1. Enforce Role-Based Access Control tied to Entra ID role_based_access_control_enabled = true # 2. Disable local admin accounts (Zero Trust) local_account_disabled = true # 3. Enable Azure Policy/Gatekeeper to block privileged pods azure_policy_enabled = true # 4. Restrict API server access to trusted IP ranges only api_server_access_profile { authorized_ip_ranges = ["198.51.100.0/24"] } }

📂 Tier 4: Records & Evidence (The "Proof")

›

Tier 4 Records are unalterable historical data demonstrating that policies and procedures were followed. This is what you hand to an ISO 27001 auditor.

🎫 Artifact 13: Risk Treatment Ticket (Clause 6.1.3 e & f Information security risk treatment)

›

RISK-892: Hardware Constraints Prevent Crypto Signing on V1 Pumps

Risk Description: Legacy V1 industrial pumps have insufficient ROM to store the public key necessary to verify the cryptographic signatures mandated by POL-SEC-004. This leaves them vulnerable to unverified OTA updates.

⚠️ Formal Risk Exception Request

Compensating Control: V1 pumps will be isolated to a dedicated, strictly firewalled IoT Hub endpoint. No further feature updates will be shipped to V1, only critical patches via hardwired serial connection by field techs.

Business Owner Approval (Clause 6.1.3f): ACCEPTED by SVP Engineering. (Valid until EOL in Q4 2027)

⚙️ Artifact 14: CI/CD Pipeline Log (A.8.28 Secure coding, A.8.24 Use of cryptography)

›

Immutable execution logs from GitLab/GitHub Actions prove that security scanning was not bypassed by developers.

user@novaflow-cicd:~$ tail -f /var/log/gitlab-runner/job-892.log

[Stage 1: SAST - Static Application Security Testing (A.8.28)]

Running SonarQube Scanner...

✔ 0 CRITICAL, 0 HIGH vulnerabilities found in source code.

[Stage 2: SCA - Software Composition Analysis (CRA SBOM)]

Generating CycloneDX SBOM for dependency tracking...

✔ SBOM artifact generated and uploaded to registry.

[Stage 3: Cryptographic Firmware Signing (A.8.24)]

Authenticating to Azure KeyVault via OIDC...

Applying ECDSA P-384 signature to release binary...

✔ Payload signed successfully. Checksum: e3b0c44298fc1c149afbf4c8996fb924

📊 Artifact 15: CISO Governance Dashboard (Clause 9.1 Monitoring, measurement, analysis and evaluation, Clause 9.3 Management review)

›

Aggregated metrics exported quarterly to provide Top Management with objective data on ISMS performance.

MTTR Critical CVEs

4.2 Days

Target: < 48 Hours (Missed by 2.2 days)

Phishing Failure Rate

6.8%

Target: < 5.0% (Action Required)

Open Major CAPAs

Target: 0 Open > 30 Days

MFA Enforcement

100%

Verified via Entra ID Posture

🔧 Artifact 16: CAPA Record (Clause 10.2 Nonconformity and corrective action, A.8.32 Change management)

›

CAPA-2026-042

Closed / Verified

Event Description

An unsigned firmware build bypassed the CI/CD pipeline and was manually deployed to the Staging environment by a senior engineer.

Root Cause Analysis (5 Whys)

Why did it reach staging? Because branch protections were temporarily disabled. Why? To push a hotfix during an outage. Why weren't they re-enabled? The engineer forgot, and there was no automated audit enforcing the setting.

Corrective Action Plan

1. Implemented a Terraform drift-detection cron job that resets GitHub branch protections to "Strict" every 15 minutes. 2. Engineering team retrained on emergency CAB procedures. Verified fixed by Internal Audit on 2026-03-12.

🤝 Artifact 17: Vendor Risk Assessment (A.5.19 Information security in supplier relationships)

›

Vendor: CloudHost IoT Metrics Ltd.

RISK: MEDIUM

Service Provided: Sub-contracted telemetry analytics processing for pump flow data.

ISO 27001 Certified? Yes (Certificate verified valid until 2027)

SOC 2 Type II Report Reviewed? Yes (No material exceptions)

Reviewer Decision: Conditional approval. While the vendor is certified, the data flow diagram shows they use shared tenant databases. Condition: Traffic must be encrypted via mTLS, and all data payloads must be pseudonymized before transmission.

🎯 Artifact 18: Penetration Test Report (A.8.8 Management of technical vulnerabilities)

›

NovaFlow Azure API Pentest - Exec Summary

Conducted by: SEC-Offensive Group • Date: Nov 2025

Scope: Grey-box assessment of `api.novaflow.com` production endpoints against the OWASP API Security Top 10 (2023).

Findings Summary: 0 Critical, 2 High, 4 Medium.

High (BOLA): Endpoint `/api/v1/pump/status` lacked proper authorization checks, allowing Tenant A to query Tenant B's pump IDs.
High (Rate Limiting): Authentication endpoint lacked strict rate limiting, permitting credential stuffing attacks.

Remediation: Findings imported to Jira. High vulnerabilities must meet the 14-Day SLA per Patch Management Procedure (Artifact 8).

⚡ Artifact 19: BCDR Tabletop Exercise (A.5.30 ICT readiness for business continuity)

›

Q2 2026 Tabletop: "Azure Region East-US Complete Outage"

Mandatory annual drill required by Clause 5.30 to prove the BCDR plan actually works.

Scenario: A catastrophic weather event takes down Azure East-US. Primary telemetry databases are offline.

Target Metrics: Recovery Time Objective (RTO) = 4 hours. Recovery Point Objective (RPO) = 1 hour.

Execution: Cloud team initiated Geo-Failover to Azure West-Europe using Azure Traffic Manager and Cosmos DB read-replicas.

Outcome: PASS. Failover successful within 2 hours (Beats RTO). Data loss was less than 5 minutes (Beats RPO). Action Item: The crisis communication matrix was outdated; PR agency phone numbers must be updated.

🇪🇺 Integrating the EU Cyber Resilience Act (CRA)

For manufacturers of "Products with Digital Elements" (like NovaFlow Systems' IoT controllers), maintaining two separate compliance tracks for ISO 27001 and the CRA (Regulation EU 2024/2847) guarantees organizational friction and audit fatigue.

The Paradigm Shift: ISO 27001 focuses on securing the Organization's information assets. The CRA focuses on securing the Product placed on the market. To survive, enterprises must merge these requirements into a single Unified Control Framework (UCF), extending the corporate ISMS directly into the product's Secure Development Lifecycle (SDLC).

Comprehensive Mapping: CRA vs. ISO 27001

The CRA's Essential Cybersecurity Requirements (Annex I) and manufacturer obligations (Articles 13 & 14) act as a highly prescriptive, product-centric version of ISO 27001's Annex A Clause 8 (Technological Controls). Here is how NovaFlow maps the legal mandates to their ISMS.

CRA Mandate (Reg EU 2024/2847)	ISO 27001:2022 Control	Integration Strategy for the ISMS
Article 13(2) & Annex VII: Product Cybersecurity Risk Assessment.	6.1.2 InfoSec Risk Assessment A.8.25 Secure Dev Lifecycle	Expand the ISMS risk methodology to explicitly include "Product threat modeling" (e.g., STRIDE) during the design phase. The product risk assessment must be retained in the CRA Technical Documentation. Tag product risks in the central GRC tool.
Annex I, Part I (2)(b): Secure by default configuration.	A.8.27 Secure System Architecture A.8.9 Configuration Mgmt	Update Tier 3 Engineering Runbooks to mandate the removal of default passwords, implementation of zero-trust defaults, and the closure of unused network ports prior to the release candidate (RC) build.
Annex I, Part I (2)(c): Automatic security updates (opt-out available).	A.8.8 Technical Vulnerabilities A.8.19 Software Installation	ISMS must dictate that product firmware includes OTA (Over-The-Air) update capabilities enabled by default. Tier 3 guides must detail the opt-out mechanism required for users.
Annex I, Part I (2)(e) & (f): Protect confidentiality and integrity (data at rest/in transit).	A.8.24 Use of Cryptography	Tier 1 Cryptographic Policy must enforce state-of-the-art encryption (e.g., AES-256, TLS 1.3) specifically for data processed by the product and its remote data processing solutions.
Annex I, Part I (2)(l): Security-related information recording and monitoring (logging).	A.8.15 Logging A.8.16 Monitoring activities	Products must be engineered to generate secure audit logs for relevant internal activity (access, modification of settings). Tier 2 procedures must detail how these logs are handled and protected.
Annex I, Part II (1): Software Bill of Materials (SBOM).	A.5.19 Supplier Relationships A.8.28 Secure Coding	The CI/CD pipeline must automatically generate a machine-readable SBOM (e.g., SPDX or CycloneDX) covering at least top-level dependencies on every build to track third-party/open-source vulnerabilities.
Article 13(8) & Annex I, Part II (2): Support Period and provision of security updates.	A.8.8 Technical Vulnerabilities	The ISMS Vulnerability Management Policy (Tier 1) must explicitly define the "Support Period" (minimum 5 years per CRA, or the expected product lifetime if shorter) and SLAs for pushing free OTA patches.
Article 14 (1) & (3): Severe Incident and Actively Exploited Vulnerability Reporting.	A.5.24 Incident Mgmt Planning A.5.26 Response to Incidents	Critical Conflict: While ISO 27001 requires timely response, corporate SLAs (often influenced by GDPR) typically target 72 hours. The Tier 2 Incident Response Playbook must have a "CRA Override" triggering ENISA/CSIRT early warning notifications within the strict legal mandate of 24 hours.
Annex I, Part II (5): Coordinated Vulnerability Disclosure (CVD) Policy.	A.5.7 Threat Intelligence A.6.8 Event Reporting	Publish a `security.txt` file on the corporate domain, provide a clear single point of contact (Article 13(17)), and implement a Tier 2 procedure for triaging external bug bounty or white-hat researcher reports.

Strategy 1: The Unified Pipeline

Do not rely on engineers reading the CRA legislation or the ISO 27001 standard. Encode compliance into the tools.

If the CRA requires an SBOM and ISO 27001 requires secure coding, configure GitLab/GitHub to fail the build if the Software Composition Analysis (SCA) tool fails to generate an SBOM. The pipeline log becomes your Tier 4 evidence for both audits.

Strategy 2: Navigating the 24h Rule

CRA Article 14 establishes aggressive reporting timelines via the ENISA single reporting platform. A 24-hour early warning is exceptionally tight for a hardware manufacturer.

The ISMS must formally separate Enterprise Incidents (e.g., phishing an HR rep) from Product Incidents (e.g., actively exploited firmware vulnerability). Tier 3 Work Instructions for the SOC must establish an immediate escalation path to Legal/Compliance exclusively for product exploits.

Strategy 3: CRA Technical Documentation

CRA Article 31 and Annex VII demand extensive Technical Documentation (architecture, risk assessment, SBOM, test reports) before placing a product on the market.

Leverage your ISMS Tier 4 Records. Threat models, SAST/DAST reports, and CAB approvals generated by ISO 27001 processes should seamlessly compile into the CRA Technical Documentation dossier to prove Conformity Assessment.

CRA Artifact Cookbook

📦 Artifact 20: Software Bill of Materials (SBOM) Generation (Art. 13)

›

Tier 3 Technical Work Instruction

# Generating CycloneDX SBOM during CI/CD build phase

syft packages dir:./src -o cyclonedx-json > ./build/nova-pump-sbom.json

[Analysis] Validating SBOM against known vulnerable dependencies...

✔ No critical CVEs detected in top-level dependencies.

[Analysis] Uploading manifest to CRA Technical Documentation Repository...

✔ SBOM artifact successfully stored for regulatory audit trail.

🤝 Artifact 21: Coordinated Vulnerability Disclosure Policy (Annex I, Part II)

›

Tier 2 Standard Operating Procedure

POL-SEC-012: Vulnerability Disclosure (CVD)

Policy Statement: NovaFlow commits to receiving, reviewing, and responding to vulnerability reports from external security researchers within 72 hours, in compliance with the CRA.

Implementation: The IT team must publish and maintain a `.well-known/security.txt` file on the root domain, directing researchers to our secure intake portal.

Contact: https://novaflow.com/security/report Contact: mailto:*protected email* Encryption: https://novaflow.com/security/pgp-key.txt Acknowledgments: https://novaflow.com/security/hall-of-fame Preferred-Languages: en, da Expires: 2026-12-31T23:59:59Z

🇪🇺 Integrating the NIS2 Directive

While ISO/IEC 27001 specifies the requirements to establish, implement, and maintain an ISMS, the NIS2 Directive establishes the strict legal minimums for critical infrastructure across Europe.

The Relationship: NIS2 defines the mandatory legal framework and reporting obligations. ISO/IEC 27001 delivers the precise, process-oriented structure needed to actually design, manage, and document compliance with the law. Note: The references below use the Danish transposition (Lov nr. 434) as a definitive national case study.

⚖️ 1. Legal Requirements BEYOND ISO 27001

Even with a mature ISO/IEC 27001:2022 certification, NIS2 introduces strict legal escalations that require immediate attention from the Board and Legal teams:

Personal Liability (§ 23)

Authorities can impose temporary bans prohibiting C-level executives from exercising managerial functions in cases of gross negligence. ISO 27001 merely asks for abstract "Leadership Commitment" (Clause 5.1).

Mandatory Training (§ 7)

Members of the management body MUST complete specific cybersecurity training to independently assess risks. This goes far beyond ISO's general competence requirements.

Rigid Reporting Windows (§ 13)

Incidents must be reported to the national CSIRT under an unforgiving timeline: an early warning within 24 hours, a full notification within 72 hours, and a final report in 1 month. ISO specifies reporting, but without hard external hours.

Customer Notification (§ 15)

A direct legal mandate forcing entities to notify the recipients of their services regarding significant cyber threats and the mitigation measures customers should take.

🗺️ 2. Mapping NIS2 Minimum Measures to Annex A

Article 21 of the Directive (transposed as § 6, stk. 1 i Lov nr. 434) dictates 10 mandatory technical and organizational measures. Disclaimer: The legal text of Lov nr. 434 is framework-neutral and does not explicitly reference ISO 27001. The table below represents a professional interpretive framework mapping the statutory Danish requirements to the ISO standard.

NIS2 Legal Requirement (§ 6, stk. 1)	Corresponding ISO/IEC 27001:2022 Annex A Controls
1) Risk & Sec Policies: Policies on risk analysis and information system security.	A.5.1 Policies for information security A.5.12 Classification of information (And Clause 6.1.2 InfoSec risk assessment)
2) Incident Handling: Incident handling.	A.5.24 Incident management planning and preparation A.5.25 Assessment and decision on events A.5.26 Response to information security incidents
3) BCP & Crisis: Business continuity, backup management, DR, and crisis management.	A.5.29 Information security during disruption A.5.30 ICT readiness for business continuity A.8.13 Information backup
4) Supply Chain: Supply chain security, including relationships with direct suppliers.	A.5.19 Information security in supplier relationships A.5.20 Addressing info sec in supplier agreements A.5.21 Managing info sec in the ICT supply chain
5) DevSecOps: Security in acquisition, development and maintenance, including vulnerability handling.	A.8.25 Secure development life cycle A.8.26 Application security requirements A.8.27 Secure system architecture A.8.8 Management of technical vulnerabilities
6) Effectiveness: Policies to assess the effectiveness of cybersecurity risk management measures.	A.5.35 Independent review of information security A.5.36 Compliance with policies and standards (And Clause 9.1 Monitoring and measurement)
7) Cyber Hygiene: Basic cyber hygiene practices and cybersecurity training.	A.6.3 Information security awareness, education and training
8) Cryptography: Policies regarding the use of cryptography and encryption.	A.8.24 Use of cryptography
9) HR & Assets: Human resources security, access control policies, and asset management.	Section 6 (People controls: A.6.1 - A.6.6) A.5.15 Access control A.5.9 Inventory of information and other associated assets
10) MFA: Use of multi-factor authentication or continuous authentication solutions.	A.8.5 Secure authentication

🛡️ 3. Pragmatic Focus in a Pure NIS2 Context

While Lov nr. 434 applies broadly to cybersecurity, from an auditor's strategic perspective, if a national authority is inspecting your organization purely for NIS2 compliance (rather than a formal ISO certification audit), certain elements of an ISMS shift in practical weighting:

Focus on Actual Measures over Formal Bureaucracy: The law (§ 21) authorizes authorities to audit the actual security measures and systems. While ISO 9.3 requires strict meeting minutes for "Management Review", NIS2 compliance pragmatically relies more on whether the Board has verifiably approved the measures and attended training (§ 7), rather than the formatting of the minutes.
Proactive Supervision vs. Formal Audit Programs: ISO 27001 requires a stringent, scheduled, and independent internal audit program (ISO 9.2). NIS2 focuses heavily on proactive supervision, continuous security scanning, and objective effectiveness testing (§ 6, stk. 1, nr. 6).
Physical Security Context: NIS2 is primarily a cyber law. While physical security remains vital, Annex A controls regarding "Clear desk" (A.7.7) or "Cabling security" (A.7.12) are typically secondary to network resilience, unless a physical breach directly causes a systemic IT collapse for the critical service.

Strategy 1: Executive Shielding

Because NIS2 (§ 23) introduces personal liability for management, and (§ 7) mandates cyber training, the ISMS must evolve from a technical tool into a legal shield.

Update your Tier 4 Management Review Records. It is no longer enough to show a PowerPoint. You must retain cryptographic or physically signed evidence of the Board's attendance at cyber training, and their explicit, recorded acceptance of residual risks.

Strategy 2: The "Red Button" Playbook

The rigid 24-hour early warning window (§ 13) cannot survive standard IT triage. Normal helpdesk escalation will cause you to miss the legal deadline.

Update your Tier 2 Incident Response Procedure to include a "NIS2 Fast-Track". If an incident meets the 'significant' threshold, it must bypass L1/L2 support and immediately trigger Legal and the CISO to initiate CSIRT and Customer (§ 15) notifications.

Strategy 3: Cascading Supply Chain SLAs

You cannot meet your 24-hour reporting deadline if your cloud provider takes 48 hours to inform you they were breached.

Leverage ISO Annex A 5.19 (Supplier Relationships) to aggressively renegotiate contracts. Your ISMS Vendor Management procedure must enforce strict contractual SLAs (e.g., 12-hour notification) for all critical Tier 1 suppliers to ensure you have the data needed to comply with the law.

NIS2 Artifact Cookbook

🎫 Artifact 22: Executive Management Cyber Training Record (§ 7 & § 23)

›

Tier 4 Evidence & Record

TRN-2026-001: Board of Directors Cyber Liability Training

Requirement: Mandatory § 7 training demonstrating that Top Management possesses sufficient knowledge to assess cybersecurity risk and approve the ISMS control framework.

Execution Date: 15-Jan-2026

Format: 4-Hour executive workshop conducted by External Legal Counsel & CISO.

Acknowledgment Signature: "I, CEO of NovaFlow Systems, hereby acknowledge the completion of the mandatory NIS2 cybersecurity training and accept accountability for the approval of the ISMS risk treatment plan (Ref: Clause 6.1.3f)."

Signed: [Cryptographic Hash / DocuSign Ref: 8A9B2C3D]

📋 Artifact 23: 24-Hour Incident Early Warning Playbook (§ 13)

›

Tier 3 Technical Work Instruction

SOP-INC-009: NIS2 24h CSIRT Escalation Fast-Track

Trigger: If an incident meets the definition of 'Significant' under § 12 (e.g., severe operational disruption to the IoT platform), the L2 SOC Analyst MUST immediately execute the following bypass protocol.

Immediate Action Items (T+0 to T+24 Hours)

Do NOT wait for full forensic confirmation. Certainty is not required for the early warning.
Page the CISO and General Counsel simultaneously using the "CRIT-REGULATORY" PagerDuty channel.
Legal Counsel to initiate the "Early Warning" notification to the National CSIRT (virksomhed.cert.dk) via the secure portal, establishing the timeline for the 72-hour comprehensive report.

🇪🇺 Integrating the EU AI Act

Regulation (EU) 2024/1689 (The AI Act) establishes the world's first comprehensive legal framework for Artificial Intelligence. For NovaFlow Systems, integrating predictive AI into their industrial controllers classifying it as a High-Risk AI System (Annex I - Machinery Safety Component).

The Paradigm Shift: Rather than building a separate "AI Compliance" silo, Article 17 of the AI Act explicitly allows the required AI Quality Management System (QMS) to be integrated into existing frameworks. By mapping the AI Act's rigorous data governance, transparency, and robustness mandates directly into our ISO 27001 ISMS, we maintain operational efficiency.

Comprehensive Mapping: EU AI Act vs. ISO 27001

The AI Act imposes strict obligations on providers of High-Risk AI Systems (Chapter III, Section 2). Here is how NovaFlow maps these legal mandates to their ISMS.

AI Act Mandate (Reg EU 2024/1689)	ISO 27001:2022 Control	Integration Strategy for the ISMS
Article 9: Risk Management System.	6.1.2 InfoSec Risk Assessment	Extend the core ISMS risk methodology to explicitly evaluate AI-specific hazards (e.g., algorithmic bias, model degradation, feedback loops) throughout the entire AI lifecycle.
Article 10: Data and data governance.	A.8.10 Information Deletion A.8.28 Secure Coding	Implement a Tier 1 Data Governance Policy specifically for training, validation, and testing datasets to ensure they are relevant, representative, and free of errors/bias.
Article 11 & Annex IV: Technical documentation.	7.5 Documented Information	Maintain comprehensive Tier 4 records detailing the model architecture, training methodologies, and computational resources used, ensuring availability for notified bodies.
Article 12: Record-keeping (Logs).	A.8.15 Logging A.8.16 Monitoring activities	Ensure the AI system automatically records events (logs) over its lifetime to facilitate post-market monitoring and identify risks to fundamental rights or safety.
Article 14: Human oversight.	A.5.1 Policies for infosec A.5.2 Infosec roles	Update Tier 2 Procedures to guarantee that High-Risk AI systems have built-in human-machine interface tools allowing human operators to override or stop the system (fail-safe).
Article 15: Accuracy, robustness and cybersecurity.	A.8.8 Vulnerabilities A.8.20 Networks security	Expand Tier 3 Runbooks to include mandatory adversarial testing (red-teaming) specifically targeting AI vulnerabilities like data poisoning, model evasion, and confidentiality attacks.
Article 17: Quality management system.	Clauses 4-10 (Entire ISMS)	Leverage Article 17(3), which allows the AI QMS to be part of the existing ISO 27001 ISMS, integrating AI lifecycle management into standard change control and compliance audits.
Article 72: Post-market monitoring.	9.1 Monitoring & Measurement A.5.36 Compliance	Implement a continuous, documented system to evaluate the AI's performance in the real world, ensuring feedback loops do not introduce new biases or security flaws.

Strategy 1: The Converged Risk Register

Avoid creating a separate silo for AI risks. Expand the ISO 27005 methodology.

Modify the Tier 2 Risk Assessment Methodology to explicitly evaluate AI-specific hazards—such as algorithmic bias, model inversion, and data poisoning—directly within the central enterprise GRC risk register alongside traditional cyber threats.

Strategy 2: Data Governance as Code

Article 10 demands rigorous data governance. Relying on manual policy checks will fail at scale.

Encode the policy. Modify your Tier 3 CI/CD Runbooks to integrate automated statistical checks that block model training pipelines if the ingested datasets fail tests for representativeness, completeness, or identified biases.

Strategy 3: Human-in-the-Loop Mappings

Article 14 requires "Human Oversight" to override AI decisions. This cannot just be a software feature.

Translate the interface tools into Tier 3 Work Instructions. Operators must have documented procedures detailing exactly when and how to press the "stop button" or discard an AI recommendation to prevent fundamental rights violations.

AI Act Artifact Cookbook

📜 Artifact 24: AI Data Governance Policy (Art. 10)

›

POL-AI-001: Training Data Governance Tier 1

Policy Statement: All datasets used for training, validating, and testing NovaFlow's Predictive Flow AI must undergo rigorous statistical analysis to ensure they are relevant, representative, and free from bias that could impact industrial safety.

Data Processing: In accordance with Article 10(5), special categories of data may only be processed within isolated, pseudonymized environments strictly for bias detection and correction, and must be deleted immediately after correction.

💻 Artifact 25: Adversarial AI Testing SOP (Art. 15)

›

Tier 3 Technical Work Instruction

# Running automated Model Evasion and Data Poisoning checks before release

mlsec-toolkit --target ./models/predictive_flow_v3.onnx --attack-type evasion --samples 10000

[Analysis] Evaluating robustness against gradient-based perturbations...

✔ Model confidence variance within acceptable threshold (< 2%).

[Analysis] Checking for data poisoning signatures in training weights...

✔ No backdoor triggers detected.

# Log results to Tier 4 Compliance Evidence

echo "Art 15 Robustness Test Passed" >> /var/compliance/ai_act_reports/release_v3.log

🎫 Artifact 26: AI Incident Report (Art. 73)

›

Tier 4 Evidence & Record

INC-2027-011: Predictive Flow Model Degradation

Description: Post-market monitoring (Art 72) detected an anomalous feedback loop causing the AI to aggressively throttle industrial pump pressure, risking hardware damage.

Human Oversight Triggered (Art 14): Tier 1 Operator utilized the required 'fail-safe' hardware override to manually halt the AI logic and return to static PID control.

Regulatory Action: Per Article 73, this qualifies as a "Serious Incident." The Market Surveillance Authority was notified within the mandatory 15-day window.

The ISO 27001 and 27002 Guides

Below are static front pages of my ISO 27001 and 27002 interactive Guides. Due to copyright restrictions, I cannot share a link to the guides. The guides are designed to quickly convey the big picture and to let you dive into relevant details.

NIS2

For your convenience, I’m providing my interactive NIS2 requirements navigator (in Danish – sorry to my non-Danish-speaking readers).

Lov om et højt cybersikkerhedsniveau (NIS2-loven)

Interaktiv guide til lov nr. 434 af 6. maj 2025 – Gældende fra 1. juli 2025.

Kapitel 1: Anvendelsesområde, Jurisdiktion & Definitioner

§ 1. Anvendelsesområde

Loven gælder for offentlige og private enheder i kritiske sektorer angivet i lovens Bilag 1 og 2.

Undtagelser: Gælder ikke for virksomheder dækket af særlove med samme sikkerhedskrav (f.eks. DORA i den finansielle sektor, tele- eller energiberedskabsloven).
Sikkerhed & Forsvar: Undtager offentlige instanser inden for national sikkerhed, forsvar, politi og efterforskning.
Kommuner: Ministeren kan beslutte at udvide lovens dækning til også at omfatte kommuner, regioner og uddannelsesinstitutioner.

§ 2. Jurisdiktion (Dansk ret)

Hovedreglen er, at loven gælder for enheder, der er etableret fysisk i Danmark.

Særligt for Digitale Udbydere (Cloud, DNS, datacentre, onlinemarkedspladser mv.):

Disse hører under dansk ret, hvis deres hovedforretningssted i EU er i Danmark (defineret ved stedet, hvor sikkerhedsbeslutninger træffes, operationer udføres, eller hvor flest medarbejdere er ansat).
Hvis de er etableret uden for EU, men leverer tjenester i Danmark, skal de udpege en fysisk/juridisk repræsentant i Danmark eller det EU-land, de opererer i.

§ 3. Definitioner

Oplister 35 afgørende definitioner for loven. De vigtigste er:

Hændelse:

En begivenhed, der bringer tilgængelighed, autenticitet, integritet eller fortrolighed i fare.

CSIRT:

Beredskabet, der håndterer it-hændelser og yder teknisk bistand.

Cybersikkerhed:

Aktiviteter for at protecte it-systemer og brugere mod cybertrusler.

Nærvedhændelse:

En potentiel hændelse, som dog blev forhindret eller ikke indtraf.

§ 4. Væsentlige enheder (Essential Entities)

Klassificerer de hårdest regulerede virksomheder. En enhed i Bilag 1 er "Væsentlig", hvis den enten:

Beskæftiger ≥ 250 ansatte, eller
Har en årlig omsætning over 50 mio. EUR og en balance over 43 mio. EUR.

Uanset størrelse (selv ved 1 ansat) anses følgende altid for Væsentlige: DNS-udbydere, topdomæneadministratorer, kvalificerede tillidstjenester, statslig centralforvaltning, kritiske CER-enheder, samt virksomheder, der er den eneste udbyder af en kritisk tjeneste i Danmark (Single Point of Failure).

§ 5. Vigtige enheder (Important Entities)

Enheder fra Bilag 1 eller 2, som ikke er store nok til at være Væsentlige, klassificeres som Vigtige, hvis de:

Beskæftiger ≥ 50 ansatte, eller
Har en årlig omsætning over 10 mio. EUR og en balance over 10 mio. EUR.

Myndighederne kan dog ved afgørelse tvinge en mindre virksomhed op som "Vigtig", hvis den udgør en særlig national betydning.

Kapitel 2: Sikkerhedsforanstaltninger

§ 6. Foranstaltninger til risikostyring

Væsentlige og Vigtige enheder skal indføre passende tekniske, operationelle og organisatoriske foranstaltninger, der er proportionale med deres risiko. Loven kræver, at minimum disse 10 foranstaltninger implementeres:

Politikker for it-sikkerhed og risikoanalyser.
Håndtering af hændelser (Incident response).
Driftskontinuitet (Backup, Disaster recovery og krisestyring).
Forsyningskædesikkerhed (Risikostyring af leverandører og tredjeparter).
Sikkerhed i it-udvikling og vedligehold (Sikker kodning og sårbarhedshåndtering).
Procedurer til at måle og vurdere effektiviteten af sikkerheden (Audits/Tests).
Cyberhygiejne og medarbejderuddannelse.
Politikker for brug af kryptering/kryptografi.
Personalesikkerhed, adgangskontrol (IAM) og forvaltning af it-aktiver.
Brug af Multifaktorautentificering (MFA) og sikret nødkommunikation.

§ 7. Ledelsesansvar og uddannelse

Den øverste ledelse (Direktion/Bestyrelse) bærer det fulde juridiske ansvar for it-sikkerheden.

Ledelsen skal godkende alle cybersikkerhedsforanstaltningerne og overvåge, at de efterleves.
Direktion og bestyrelse er lovmæssigt forpligtet til at deltage i specialkurser om cyberrisici for overhovedet at have kompetencerne til at vurdere it-sikkerheden. De skal tilskynde tilbud om tilsvarende kurser til personalet.

§ 8. Krav om Certificering

Ministeren har bemyndigelse til at udstede regler om, at virksomheder er tvunget til at benytte it-produkter, cloud-tjenester eller software, der er udtrykkeligt certificeret under den europæiske cybersikkerhedscertificeringsordning, som bevis på, at § 6 er overholdt.

Kapitel 3 & 4: Registrering, Databaser & Underretning

§ 9. & § 10. Registreringspligt

Virksomheder har pligt til at indmelde sig selv til myndighederne.

§ 9 (Digitale udbydere): DNS, Cloud, markedspladser, søgemaskiner mv. skal registrere sig senest 3 måneder efter lovens ikrafttræden, inklusiv info om hvilke EU-lande de dækker.
§ 10 (Alle andre enheder): Øvrige Væsentlige og Vigtige enheder skal registrere kontaktinfo, sektor og IP-adresser senest 2 uger efter de bliver omfattet af loven. Enhver stamdata-ændring skal meldes inden for 2 uger.

§ 11. Database over domænenavne (WHOIS-data)

Domæneadministratorer (f.eks. Punktum dk) skal indsamle, validere og vedligeholde nøjagtige ejerdata (navn, e-mail, tlf.) for alle domæner i Danmark.

Ikke-personoplysninger (firmadomæner) skal være offentligt tilgængelige.
Ved henvendelse fra "legitime adgangssøgende" (f.eks. politiet eller CSIRT) skal adgang til ellers skjulte personoplysninger udleveres inden for 72 timer.

§ 12. Definition af hændelsesunderretning

Der er pligt til at rapportere Væsentlige Hændelser til myndighederne. En hændelse er væsentlig, hvis den skaber alvorlig driftsforstyrrelse/økonomisk tab, eller forvolder skade på borgere eller andre virksomheder.

§ 13. Tidsfrister for underretning (3-trins-raketten)

Hvis uheldet er ude, starter uret for rapportering til CSIRT/myndighederne:

Inden 24 timer (Tidlig varsling): Den første heads-up. Mistænkes angrebet for at være ondsindet (hackerangreb), og kan det sprede sig til andre lande? (Tillidstjenester skal dog springe direkte til trin 2 inden for de 24 timer).
Inden 72 timer (Hændelsesunderretning): En teknisk dybdegående rapport. Vurdering af alvoren og indsendelse af IOC'er (Indicators of Compromise - fx hackernes IP'er eller virus-hashes).
Senest 1 måned (Endelig rapport): Detaljeret redegørelse for Root-cause (hvordan kom de ind?), skadens omfang, og hvilke løsninger der er implementeret for at sikre, det ikke sker igen.

§ 14. Frivillige underretninger

Virksomheder (f.eks. små underleverandører), der ikke falder ind under § 4 og § 5, kan frivilligt melde hackerangreb ind til CSIRT. Frivillige indberetninger er fredet og undtaget fra loven om aktindsigt, så virksomheden undgår dårlig PR.

§ 15. & § 16. Kommunikation med kunder & offentlighed

§ 15 (Til kunderne): Bliver din tjeneste ramt, og går det ud over dine kunder, skal du underrette dem uden unødigt ophold og rådgive dem i, hvordan de beskytter sig mod truslen.
§ 16 (Til pressen/offentligheden): Myndigheden kan, hvis det er for at forhindre et landsdækkende nedbrud, tvinge den ramte virksomhed til at gå til offentligheden/pressen med hændelsen - eller selv udsende en pressemeddelelse.

Kapitel 5: CSIRT'ens opgaver

§ 17. Bistand og Proaktive Scanninger

CSIRT fungerer som statens "it-brandvæsen". Udover at reagere på kriser, har de lovmæssig adgang til, på anmodning fra virksomheden, at yde bistand med realtids-monitorering, eller foretage proaktive sikkerhedsscanninger af virksomhedens ydre netværk for at finde sårbarheder, inden hackerne gør det.

§ 18. Anonym Sårbarhedsrapportering (Whistleblower)

CSIRT skal drive et fortroligt it-system, hvor it-forskere, etiske hackere, eller interne medarbejdere kan rapportere opdagede IT-sårbarheder i danske systemer - i fuld anonymitet.

§ 19. Cybersikkerhedsfællesskaber

Fremmer frivillig informationsdeling mellem virksomheder om cybertrusler (f.eks. sektorspecifikke ISACs). Væsentlige og Vigtige enheder har dog pligt til at informere myndighederne, hvis de melder sig ind eller ud af disse delings-netværk.

Kapitel 6 & 9: Tilsyn, Håndhævelse & Straf

§ 20. Kompetente myndigheder

Ministeren udpeger, hvem der fører tilsyn i de forskellige sektorer (f.eks. Finanstilsynet, Energistyrelsen). Lovteksten sikrer, at disse tilsyn kan agere uafhængigt, selv når de fører tilsyn med staten selv.

§ 21. Tilsyn med Væsentlige Enheder (Proaktivt)

Myndighederne har meget skrappe og indgribende beføjelser. De kan til enhver tid og uden retskendelse dukke uanmeldt op til kontrolbesøg, kræve it-systemer scannet, kræve eksterne audits på virksomhedens regning, og gennemtvinge udlevering af alle politikker og dokumenter.

§ 22. Håndhævelse mod Væsentlige Enheder

Myndigheden kan udstede påbud. F.eks. kan de tvinge virksomheden til at rette sårbarheder, advare kunder, offentliggøre lovbruddet, eller (i særlige tilfælde) tvinge virksomheden til at acceptere en ekstern, statsligt udpeget "tilsynsperson" siddende i virksomheden for en periode.

§ 23. Suspendering og Ledelsesforbud (Kun for Væsentlige Enheder)

Dette er lovens mest radikale værktøj. Hvis en Væsentlig Enhed ignorerer påbud efter § 22, kan tilsynet sætte hårdt ind: De kan suspendere virksomhedens it-certificeringer, hvilket reelt forbyder dem at levere deres tjenester. Derudover kan myndigheden udstede et direkte forbud mod, at virksomhedens administrerende direktør udøver ledelsesfunktioner i virksomheden, indtil cybersikkerheden er bragt i orden. (Kan dog bringes for domstolene, og gælder ikke for den offentlige forvaltning).

§ 24. & § 25. Tilsyn og Håndhævelse mod Vigtige Enheder

Tilsynet her er "reaktivt". Det betyder, at myndighederne kun aktiverer deres værktøjskasse, hvis der er sket en hændelse, eller hvis de modtager et tip om, at virksomheden slækker på sikkerheden. Når tilsynet aktiveres, har de dog samme beføjelser (audits, datakrav, påbud) som i § 21 og § 22. § 23 (Direktør-forbuddet) gælder dog ikke for Vigtige Enheder.

§ 26. Høringsret

Virksomheden har krav på at blive hørt og fremsætte et forsvar, inden myndigheden træffer afgørelse om en sanktion, medmindre tøven vil forværre krisen.

§ 32. Bødestraf (Kapitel 9)

Manglende risikostyring (§ 6), manglende registrering (§ 9-10) eller forsinket rapportering af et hackerangreb (§ 12, 13) straffes med bøde, og selskabet kan ifalde direkte strafansvar som juridisk person. Bestemmelsen tillader desuden, at ministerierne kan fastsætte yderligere bøder i særlovgivning.

Kapitel 7, 8, 10 & 11: EU-Samarbejde & Ikrafttrædelse

§ 27. Gensidig bistand på tværs af EU (Kapitel 7)

Hvis din virksomhed har servere i Tyskland, men ledelse i Danmark, skal de nationale tilsyn samarbejde. EU-lande kan anmode hinanden om at sanktionere virksomheden på deres vegne, eller de kan udføre fælles, tværnationale kontrolbesøg.

§ 28. Oplysningsdeling

Tillader danske myndigheder at dele data med andre EU-stater og EU-institutioner (som ENISA) for at opretholde unionens samlede cyberforsvar.

§ 29. Hemmeligholdelse & National Sikkerhed

Den danske stat har ret til at nægte at udlevere data til EU eller andre instanser, hvis det kompromitterer Danmarks nationale sikkerhed eller forsvarshemmeligheder.

§ 30. & § 31. IT-Systemer og EU-retsakter

§ 30 sikrer bemyndigelse til at inkorporere EU-Kommissionens fremtidige præciseringer direkte. § 31 giver ministeren lov til at fastsætte krav til, at virksomheder skal kommunikere med staten via krypterede kanaler og specifikke MitID/eBoks formater.

Kapitel 10 & 11: Ikrafttrædelse og Frister

§ 33: Loven træder officielt i kraft den 1. juli 2025.
§ 33, stk. 3: Deadlinen for virksomheder til at registrere sig hos myndighederne (som beskrevet i § 9 & § 10) er sat til den 1. oktober 2025.
§ 33, stk. 4-7: Loven ophæver og erstatter de fire gamle sektorspecifikke NIS1-love (Tele, energi, transport, sundhed).
§ 34 (Kapitel 11): Territorialbestemmelsen slår fast, at loven ikke automatisk gælder på Grønland og Færøerne, medmindre det vedtages ved kongelig anordning.

Bilag 1: Sektorer af særlig kritisk betydning

Enheder fra disse sektorer reguleres primært som Væsentlige Enheder, hvis de har over 250 ansatte (jf. § 4). Visse digitale udbydere er væsentlige uanset størrelse.

1. Energi

Elektricitet, varme m.v. +

Elektricitetsvirksomheder, distribution og transmission
Markedsdeltagere for aggregering/energilagring
Operatører af ladestationer for elbiler
Fjernvarme og fjernkøling

Olie, Gas & Brint +

Olierørledninger og -lagre
Gasdistribution, lager- og LNG-operatører
Brintproduktion og -lagring

2. Transport

Luft, Bane & Vand +

Luftfartsselskaber og lufthavne
Jernbaneinfrastruktur og -virksomheder
Rederier og havnedriftsorganer

Vej & Offentlig transport +

Vejmyndigheder med trafikledelse
Operatører af intelligente transportsystemer

3 & 4. Finansiel Sektor

Bank & Infrastruktur +

Kreditinstitutter
Operatører af markedspladser
Centrale modparter (CCP'er)

5. Sundhed

Sundhed & Forskning +

Sundhedstjenesteydere og EU-referencelaboratorier
Forskning i lægemidler og fremstilling heraf
Fremstilling af medicinsk udstyr, der er kritisk under kriser

6 & 7. Vandhåndtering

Drikke- og Spildevand +

Leverandører og distributører af drikkevand
Virksomheder der indsamler eller behandler spildevand

8. Digital Infrastruktur

Netværk & Cloud +

Internetudvekslingspunkter og DNS-udbydere
Topdomænenavneadministratorer
Cloudcomputingtjenester og datacentre
Indholdsleveringsnetværk (CDN)
Udbydere af elektroniske kommunikationsnet

Forvaltning, IT & Rummet

Flere sektorer +

(9) Udbydere af administrerede (sikkerheds)tjenester (B2B IT)
(10) Offentlige forvaltningsenheder (centralt og evt. regionalt)
(11) Operatører af jordbaseret ruminfrastruktur

Bilag 2: Andre kritiske sektorer

Enheder i disse sektorer reguleres primært som Vigtige Enheder, forudsat de har mindst 50 ansatte (jf. § 5).

Post & Affald

Logistik og Miljø +

1. Post- og kurertjenester: Postbefordrende virksomheder og kurerer.
2. Affaldshåndtering: Virksomheder, der primært varetager affaldshåndtering.

Kemi & Fødevarer

Produktion og Engros +

3. Kemikalier: Virksomheder der fremstiller eller distribuerer stoffer/blandinger (REACH).
4. Fødevarer: Fødevarevirksomheder inden for engrosdistribution samt industriel produktion.

5. Fremstilling

Specifik produktion +

Medicinsk udstyr og in vitro-diagnostik.
Computere, elektroniske og optiske produkter.
Elektrisk udstyr, maskiner og udstyr (generelt).
Motorkøretøjer, påhængsvogne og andre transportmidler.

Digitale platforme & Forskning

Tjenester & Udvikling +

6. Digitale udbydere: Onlinemarkedspladser, onlinesøgemaskiner og platforme for sociale netværk.
7. Forskning: Uafhængige forskningsorganisationer.

Cyber Resilience Act

For convenience, here is my CRA Executive Summary:

CRA-executive-summary_ProjektDK

EU AI Act

For your additional convenience, here is my interactive guide to the AI Act:

EU AI Act Explorer

Comprehensive Guide to Regulation (EU) 2024/1689

Sources:

Regulation (EU) 2024/1689 (EU AI Act - Official Journal)
Digital Omnibus on AI (COM(2025) 836 / Trilogue Agreement May 2026)

Scope & Risk Approach

The AI Act regulates the placing on the market, putting into service, and use of AI systems in the EU. It applies universally, protecting the fundamental rights enshrined in the EU Charter, democracy, the rule of law, and the environment. It does not apply to AI used exclusively for military, defence, national security, or sole scientific R&D purposes.

The framework follows a strict, proportionate risk-based approach, classifying systems into four categories. (Source: AI Act Recitals 1-12)

The AI Act Risk Pyramid

Unacceptable
Risk

High Risk

Limited Risk

Minimal Risk

Hover or click a tier to explore

Select a risk tier from the pyramid
to view its detailed definitions.

Prohibited AI Practices

Article 5 details systems posing unacceptable risks to fundamental rights. These are banned from being placed on the market or put into service in the EU. Click each section to expand details.

1. Cognitive & Subliminal Manipulation

Article 5(1)(a) & (b) • Recital 29

Deploying AI systems that use subliminal, manipulative, or deceptive techniques to distort human behaviour in a way that impairs informed decision-making, causing significant harm.

Exploitation of Vulnerabilities: This includes exploiting individuals or groups due to their age, disability, or specific social/economic situations.
Harm Requirement: The prohibition applies when the manipulation causes, or is reasonably likely to cause, significant physical, psychological, or financial harm.
Medical Exemption: Lawful practices in the context of medical treatment (e.g., psychological therapy or physical rehabilitation) with explicit consent are not considered prohibited manipulation, as clarified in Recital 29.

2. Social Scoring

Article 5(1)(c) • Recital 31

AI systems used by public or private actors for the evaluation or classification of natural persons based on their social behaviour over time or inferred personality traits.

Prohibited Outcomes: The scoring is banned if it leads to detrimental or unfavourable treatment in social contexts that are unrelated to where the data was originally generated, or if the treatment is unjustified or disproportionate.
Context: This prevents mass surveillance and citizen scoring systems that evaluate individuals' general "trustworthiness" or societal worth.

3. Real-Time Remote Biometrics (Law Enforcement)

Article 5(1)(h) • Recitals 32-35

The use of 'real-time' remote biometric identification systems in publicly accessible spaces for the purpose of law enforcement is heavily prohibited.

Strict Exceptions (Requires Prior Judicial Authorisation):

Targeted search for victims of abduction, trafficking, or missing persons.
Prevention of a specific, substantial, and imminent threat to life, physical safety, or a terrorist attack.
Localisation/identification of a suspect for specific serious criminal offences (e.g., murder, kidnapping, terrorism) punishable by a custodial sentence of at least four years.

4. Untargeted Scraping of Facial Images

Article 5(1)(e) • Recital 43

The use of AI systems that create or expand facial recognition databases through the untargeted scraping of facial images from the internet or from CCTV footage.

Privacy Protection: This ban is designed to prevent mass surveillance capabilities and protect the fundamental right to privacy from tools like Clearview AI.

5. Emotion Recognition at Work & School

Article 5(1)(f) • Recital 44

Using AI to infer the emotions of natural persons in the areas of the workplace and educational institutions is strictly prohibited due to the power imbalance in these environments.

Unscientific Basis: The regulation acknowledges that emotion recognition is often unscientific, unreliable, and prone to cultural bias.
Safety Exception: It is not prohibited if the system is intended to be put in place strictly for medical or safety reasons (e.g., systems detecting state of fatigue in professional pilots or truck drivers to prevent accidents).

6. Biometric Categorisation (Sensitive Traits)

Article 5(1)(g) • Recital 30

Categorising individuals based on biometric data to deduce or infer sensitive personal attributes.

Prohibited Traits: Inferring race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation.
Law Enforcement Exemption: This prohibition does not cover the lawful labelling or filtering of lawfully acquired biometric datasets by law enforcement (e.g., sorting suspects by hair or eye color from acquired footage).

7. CSAM & Illegal Sexual Content

Source: Digital Omnibus on AI (Trilogue Agreement)

Generating or disseminating Child Sexual Abuse Material (CSAM) and non-consensual illegal sexual content (deepfakes) via AI systems.

Strict Enforcement: Introduced via the Digital Omnibus, this dedicated ban takes effect in December 2026.
Severe Penalties: Violations fall under the Article 5 penalty structure, carrying the highest possible fines (up to €35M or 7% of global turnover).

High-Risk AI (Articles 6-49)

Systems that negatively affect safety or fundamental rights must comply with strict requirements.

Expert Panel Recommendations for Enterprise Implementation

Maintain Assessment Evidence for Art. 6(3) Derogations: While the Digital Omnibus removed the mandatory EU Database registration for systems deemed non-high-risk via narrow procedural derogations, technical documentation justifying this classification must still be retained internally for market surveillance authorities.
Track Technical Standards: Because the enforcement of High-Risk rules is directly tied to the publication of CEN/CENELEC harmonized standards, compliance officers should monitor the EU Commission's formal decisions confirming standard availability.
Establish Data Pseudonymisation Logs: When leveraging Article 4a for sensitive data bias testing, maintain explicit processing logs detailing why synthetic data was insufficient, as required by GDPR Art. 30 / AI Act Art. 4a(1)(f).

Exceptions (Art. 6.3 • Recital 53): An AI system listed in Annex III is not considered high-risk if it does not materially influence decision-making (e.g., performs a narrow procedural task, improves past human activity, or does purely preparatory work). However, if it performs profiling, it is always high-risk.

Compliance Warning (Digital Omnibus Update): Relying on the Art. 6.3 derogation requires maintaining robust technical documentation to defend the non-high-risk classification. The original mandatory registration in the EU Database for these systems was removed by the Digital Omnibus to reduce administrative burden.

Lifecycle Trigger: Substantial Modification (Art. 3(23) • Recitals 84, 128)

If a deployer modifies a high-risk system in a way that affects its compliance with the AI Act, or modifies the intended purpose of a system such that it becomes high-risk, this constitutes a "substantial modification".

The Consequence: The deployer legally assumes the role of the Provider, becomes subject to all 7 mandatory requirements below, and the system must undergo a new conformity assessment.

7 Mandatory Requirements for Providers

1. Risk Management System

Article 9 • Recital 65

A continuous, iterative process run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating.

Identify & Evaluate: Providers must identify known and reasonably foreseeable risks to health, safety, or fundamental rights when the system is used as intended or under conditions of reasonably foreseeable misuse.
Mitigation Measures: Providers must adopt targeted measures to eliminate or reduce risks as far as technically feasible. If risks cannot be eliminated, adequate mitigation and control measures must be implemented.
Pre-Market Testing: High-risk systems must be tested against prior defined metrics to ensure they perform consistently and comply with all requirements before being placed on the market.

2. Data and Data Governance

Articles 10 & 4a • Recitals 67, 68, 70

Models trained with data must be developed using training, validation, and testing datasets that meet strict quality criteria.

Quality Standards: Datasets must be relevant, sufficiently representative, and to the best extent possible, free of errors and complete.
Bias Mitigation: Data governance practices must include examination for possible biases that could affect health, safety, or lead to discrimination prohibited by EU law.
Sensitive Data Exception: Source: Digital Omnibus on AI: Article 4a was introduced to explicitly permit the processing of sensitive personal data (e.g., race, health) strictly for bias detection and correction across all AI systems, subject to state-of-the-art security (like pseudonymisation) and strict access controls.

3. Technical Documentation

Article 11 & Annex IV • Recital 71

Must be drawn up before the system is placed on the market to demonstrate compliance and provide authorities with the necessary information to assess the system.

Contents: Must include system architecture, algorithm logic, training methodologies, metrics used for accuracy/robustness, and the risk management system description.
SME & SMC Provisions: Source: Digital Omnibus on AI: Simplified documentation provisions and templates originally meant for SMEs and start-ups have been extended to Small Mid-Caps (SMCs).

4. Record-Keeping (Logs)

Article 12 • Recital 71

Systems must technically allow for the automatic recording of events ('logs') over their lifetime.

Traceability: Logging must be appropriate to the system's purpose and is crucial for identifying situations that present a risk, facilitating post-market monitoring, and investigating incidents.
Biometric Specifics: For remote biometric identification, logs must record the period of use, the reference database checked against, the input data that led to a match, and the identity of the personnel verifying the result.

5. Transparency & Instructions

Article 13 • Recital 72

Operation must be sufficiently transparent to enable deployers to understand how the system works and use it appropriately.

Instructions for Use: Must be concise, correct, clear, and accessible.
Required Disclosures: Instructions must detail the intended purpose, expected accuracy/robustness, known limitations, and circumstances where the system might pose risks to health, safety, or fundamental rights.

6. Human Oversight

Article 14 • Recital 73

Systems must be designed with appropriate human-machine interfaces allowing natural persons to effectively oversee their functioning and intervene if needed.

Intervention: Overseers must be able to understand the system's capacities, remain aware of automation bias, and be able to disregard output or interrupt the system safely (a "stop" button).
The "Four-Eyes" Principle: For high-risk biometric identification systems, no action or decision can be taken by the deployer based on an AI match unless that match has been separately verified and confirmed by at least two natural persons (except in certain law enforcement situations).

7. Accuracy, Robustness & Cybersecurity

Article 15 • Recitals 74-76

Systems must achieve an appropriate level of accuracy, robustness, and cybersecurity and perform consistently throughout their lifecycle.

Feedback Loops: Systems that continue to learn after deployment must eliminate or reduce the risk of biased outputs influencing future operations.
Cyber Resilience: Must be resilient against attempts by unauthorised third parties to alter their use, outputs, or performance.
AI-Specific Threats: Must include measures to prevent and control attacks trying to manipulate the training dataset (data poisoning), adversarial examples, or model evasion.

General-Purpose AI (Ch. V)

Rules for foundational models capable of competently performing a wide range of tasks.

Source: Digital Omnibus on AI: Centralized enforcement (Article 75) explicitly grants the AI Office exclusive supervisory powers over AI systems based on GPAI models where both are developed by the same provider, as well as AI systems embedded in Very Large Online Platforms (VLOPs).

All GPAI Models

Obligations apply universally to ensure downstream providers have necessary information. (Articles 53-54 • Recitals 97, 101, 105)

Tech Docs & Transparency: Keep up-to-date documentation; provide info to downstream providers integrating the model.
Copyright: Put in place a policy to respect EU copyright laws, honoring rights reservations (opt-outs).
Training Data: Publish a sufficiently detailed summary of the content used for training.

*Open-source models are exempt from tech doc transparency, but must still comply with Copyright and Training Data summary rules.

Systemic Risk

High-Impact GPAI

Models trained with computation > 10^25 FLOPs, presumed to have high-impact capabilities causing systemic risks to health, security, or rights. (Articles 51, 55 • Recitals 110, 111)

Added Obligations:

Perform model evaluations & adversarial testing (Red Teaming).
Assess and mitigate systemic risks at the Union level.
Keep track of and report serious incidents without undue delay.
Ensure adequate cybersecurity for the model and physical infrastructure.

Transparency Rules (Article 50)

Comprehensive obligations to prevent impersonation, manipulation, and deception by AI systems. Click each section to expand details.

1. Direct Interaction with AI (Chatbots)

Obligation for: Providers • Article 50(1) • Recital 132

Providers must design and develop AI systems intended to interact directly with natural persons in such a way that the individuals are notified that they are interacting with an AI system.

Exception: Notification is not required if it is obvious from the point of view of a reasonably well-informed, observant, and circumspect person, taking the context of use into account.
Vulnerable Groups: The notification design must appropriately consider the characteristics of vulnerable groups (e.g., age, disability) if the system is specifically intended to interact with them.
Law Enforcement Exemption: Does not apply to AI systems authorised by law to detect, prevent, investigate, or prosecute criminal offences (unless the system is available for the general public to report crimes).

2. Machine-Readable Marking (Generative AI)

Obligation for: Providers • Article 50(2) • Recital 133

Providers of AI systems that generate synthetic audio, image, video, or text content must ensure the outputs of the AI system are marked in a machine-readable format and are detectable as artificially generated or manipulated.

Source: Digital Omnibus on AI: Introduced a transitional period delaying enforcement of this specific obligation until December 2026 for systems already on the market.

Technical Requirements: Solutions must be effective, interoperable, robust, and reliable (e.g., using watermarks, cryptographic provenance, or metadata), reflecting the state of the art.
Exceptions: This marking is not required if the AI only performs an assistive function for standard editing, or if it does not substantially alter the original input data or its semantics.

3. Deepfakes Disclosure

Obligation for: Deployers • Article 50(4) • Recital 134

Deployers of an AI system that generates or manipulates image, audio, or video content constituting a "deep fake" (content resembling existing persons, objects, places, or events that would falsely appear to be authentic) must clearly and distinguishably disclose that the content has been artificially generated or manipulated.

Artistic & Satirical Exception: If the content is evidently part of a creative, satirical, or artistic work, the disclosure is still required, but it must be provided in an appropriate manner that does not hamper the display or enjoyment of the work.
Law Enforcement Exemption: Does not apply where use is authorised by law to detect, prevent, investigate, or prosecute criminal offences.

4. AI-Generated Text of Public Interest

Obligation for: Deployers • Article 50(4) • Recital 134

Deployers of an AI system that generates or manipulates text published with the purpose of informing the public on matters of public interest must disclose that the text has been artificially generated or manipulated.

Human Review Exception: Disclosure is not required if the AI-generated text has undergone a process of human review or editorial control, and a natural or legal person holds editorial responsibility for its publication.

5. Emotion & Biometric Categorisation

Obligation for: Deployers • Article 50(3) • Recital 132

Deployers of an emotion recognition system or a biometric categorisation system must inform the natural persons exposed thereto of the operation of the system.

Data Protection: Any personal data must be processed in strict accordance with the GDPR (Regulation (EU) 2016/679) and other relevant data protection laws.
Exceptions: This obligation does not apply to systems permitted by law to detect, prevent, or investigate criminal offences, subject to appropriate safeguards.

Governance & Fines

Enforcement structures and penalties for non-compliance.

Governance Bodies

AI Office (Commission)

Central Union expertise; exclusive powers to supervise and enforce rules specifically on General-Purpose AI models. (Digital Omnibus Update: AI Office's exclusive competence over GPAI and VLOPs formally centralized in Art 75).

European AI Board

Composed of Member State reps. Advises on consistent application, harmonisation, and guidelines.

Scientific Panel

Independent experts alerting the AI Office to systemic risks and advising on GPAI classifications.

National Competent Authorities

Notifying authorities and market surveillance authorities in each Member State enforcing rules on standard AI systems.

Penalties (Article 99 • Recital 168)

€35M / 7%
For non-compliance with the Prohibited AI Practices (whichever is higher, based on global turnover).
€15M / 3%
For failing to meet High-Risk obligations, GPAI rules, or transparency duties.
€7.5M / 1%
For supplying incorrect or misleading information to authorities.

* Source: Digital Omnibus on AI: Fines proportionality and privileges for SMEs extended to Small Mid-Caps (SMCs).

Presumption of Conformity

Allows providers of high-risk AI systems or general-purpose AI (GPAI) models to legally presume that their system satisfies specific mandatory requirements without needing to demonstrate compliance from scratch.

1. Compliance with Harmonised Standards (Article 40)

Standardization Deliverables: High-risk AI systems or GPAI models that conform to harmonised standards (or parts thereof) whose references have been published in the Official Journal of the European Union (OJEU) are automatically presumed to comply with the corresponding requirements in Chapter III (Section 2) or Chapter V.
Role of Standardisation Bodies: The European Commission issues standardisation requests to European standardisation organisations (such as CEN, CENELEC, and ETSI) covering risk management, data quality, transparency, human oversight, accuracy, and cybersecurity.

2. Compliance with Common Specifications (Article 41)

Fallback Technical Rules: Where harmonised standards do not exist, are delayed, or insufficiently address fundamental rights concerns, the Commission can adopt common specifications via implementing acts.
Presumption Mechanism: High-risk AI systems or GPAI models that comply with these common specifications (or parts of them) are presumed to satisfy the corresponding statutory requirements to the extent those specifications cover them.

3. Specific Presumptions for Contextual Data Governance (Article 42(1))

Context-Specific Data Training: High-risk AI systems trained and tested on data reflecting the specific geographical, behavioural, contextual, or functional setting in which they are intended to operate are presumed to comply with the data governance requirements of Article 10(4).

4. Cybersecurity Certification Schemes (Article 42(2))

Cybersecurity Act Alignment: High-risk AI systems certified (or issued a statement of conformity) under an approved EU cybersecurity scheme pursuant to Regulation (EU) 2019/881 (Cybersecurity Act) are presumed to fulfill the technical cybersecurity requirements under Article 15.

5. Presumption for Notified Bodies (Article 32)

Conformity Assessment Bodies: Third-party conformity assessment bodies that satisfy relevant harmonised standards published in the OJEU are presumed to meet the organizational, competence, and independence requirements for notified bodies under Article 31.

Key Operational Note

While relying on harmonised standards or common specifications grants a presumption of conformity, providers must still draw up the technical documentation (Article 11), establish a quality management system (Article 17), issue an EU Declaration of Conformity (Article 47), and affix the CE marking (Article 48) prior to placing the system on the market.

Timeline & Milestones

Article 113 mandates a phased rollout following publication in the Official Journal, including recent updates from the Digital Omnibus on AI.

August 1, 2024

Entry into Force

20 days after publication in the Official Journal (July 12, 2024).

February 2, 2025

+ 6 Months

Prohibited AI Practices (Chapters I & II) become strictly enforced.
Source: Digital Omnibus on AI: The original AI literacy obligation for businesses was replaced with a requirement for Member States and the Commission to foster AI literacy.

August 2, 2025

+ 12 Months

GPAI rules apply. Penalties apply. Governance structures (Board, Notifying authorities) must be operational. Codes of practice finalised.

December 2026

Digital Omnibus Prohibitions

Introduction of new strict prohibitions surrounding Child Sexual Abuse Material (CSAM) and non-consensual deepfakes.
Source: Digital Omnibus on AI

December 2027

High-Risk (Annex III)

Rules for High-Risk AI systems (Annex III stand-alone systems) now apply. Member States must have at least one AI regulatory sandbox operational.
Source: Digital Omnibus on AI: These dates were extended via the Omnibus to tie enforcement to the availability of harmonized standards, with a hard deadline set for Dec 2027.

August 2028

High-Risk (Annex I)

Rules apply for High-Risk AI embedded as safety components in regulated products (Annex I, e.g., machinery, medical devices, toys).
Source: Digital Omnibus on AI: These dates were similarly extended via the Omnibus with a hard deadline set for Aug 2028.

December 31, 2030

Long-Term Milestone

AI systems acting as components of large-scale EU IT systems (Annex X, e.g., Schengen Information System) must be brought into compliance.

Abbreviations

Common terminology used within the regulation.

Artificial Intelligence

GPAI

General-Purpose Artificial Intelligence

FLOPs

Floating-Point Operations

SME

Small and Medium-sized Enterprises

SMC

Small Mid-Cap Enterprises (Introduced via Omnibus)

API

Application Programming Interface

Conformité Européenne

HLEG

High-Level Expert Group (on AI)

ENISA

EU Agency for Cybersecurity

CEN

European Committee for Standardization

ETSI

European Telecommunications Standards Institute

Wrap-up

I guess it should be obvious by now that creating and maintaining a Unified Control Framework (UCF) as the operational engine is a complex task in today’s compliance landscape.

My core recommendation is not to try to do it all at once. Use an incremental approach, starting with a classic ISMS core and building from there.

NB – I haven’t even mentioned the tricky interplay between IT and OT. If you’d also like to explore that rabbit hole, read my article, Industrial Architecture and MES.

The Enterprise ISMS Cookbook

Welcome to the Cookbook

Glossary of Key Terms

T1 Policies

T2 Procedures

T3 Work Instructions

T4 Records & Evidence

🔗 Bridging the Frameworks: The Harmonized Structure & The 4 Tiers

🚀 Enterprise Case Study: NovaFlow Systems

POL-SEC-001: Information Security Policy

POL-SEC-004: Cryptographic Controls Policy

POL-SEC-005: Global Access Control Policy

POL-SEC-008: Asset Management & Classification

PROC-SEC-08: Master Incident Response

SOP-FW-005: Cryptographic Firmware Signing

Step 1: Pipeline Authentication (OIDC)

Step 2: Sign the Binary via Azure SignTool

IAM-01: Azure Identity Config Guide

Terraform Main.tf (Security Enforcements):

RISK-892: Hardware Constraints Prevent Crypto Signing on V1 Pumps

⚠️ Formal Risk Exception Request

Event Description

Root Cause Analysis (5 Whys)

Corrective Action Plan

NovaFlow Azure API Pentest - Exec Summary

Q2 2026 Tabletop: "Azure Region East-US Complete Outage"

🇪🇺 Integrating the EU Cyber Resilience Act (CRA)

Comprehensive Mapping: CRA vs. ISO 27001

Strategy 1: The Unified Pipeline

Strategy 2: Navigating the 24h Rule

Strategy 3: CRA Technical Documentation

CRA Artifact Cookbook

POL-SEC-012: Vulnerability Disclosure (CVD)

🇪🇺 Integrating the NIS2 Directive

⚖️ 1. Legal Requirements BEYOND ISO 27001

Personal Liability (§ 23)

Mandatory Training (§ 7)

Rigid Reporting Windows (§ 13)

Customer Notification (§ 15)

🗺️ 2. Mapping NIS2 Minimum Measures to Annex A

🛡️ 3. Pragmatic Focus in a Pure NIS2 Context

Strategy 1: Executive Shielding

Strategy 2: The "Red Button" Playbook

Strategy 3: Cascading Supply Chain SLAs

NIS2 Artifact Cookbook

TRN-2026-001: Board of Directors Cyber Liability Training

SOP-INC-009: NIS2 24h CSIRT Escalation Fast-Track

Immediate Action Items (T+0 to T+24 Hours)

🇪🇺 Integrating the EU AI Act

Comprehensive Mapping: EU AI Act vs. ISO 27001

Strategy 1: The Converged Risk Register

Strategy 2: Data Governance as Code

Strategy 3: Human-in-the-Loop Mappings

AI Act Artifact Cookbook

POL-AI-001: Training Data Governance Tier 1

INC-2027-011: Predictive Flow Model Degradation

The ISO 27001 and 27002 Guides

NIS2

Lov om et højt cybersikkerhedsniveau (NIS2-loven)

Cyber Resilience Act

EU AI Act

Scope & Risk Approach

The AI Act Risk Pyramid

Unacceptable Risk

High Risk

Limited Risk

Minimal Risk

Prohibited AI Practices

High-Risk AI (Articles 6-49)

7 Mandatory Requirements for Providers

General-Purpose AI (Ch. V)

All GPAI Models

High-Impact GPAI

Added Obligations:

Transparency Rules (Article 50)

Governance & Fines

Governance Bodies

Penalties (Article 99 • Recital 168)

Presumption of Conformity

1. Compliance with Harmonised Standards (Article 40)