Chapter 3 — Regulatory Drivers and Operational Governance

Summary

This chapter traces the shift from periodic compliance projects to continuous, demonstrable operational control. It begins with the obligations that DORA, NIS2, GDPR, the EU AI Act and supervisory guidance from the EBA, FCA and PRA impose on organisations in regulated and critical sectors, then broadens the survey to cover the wider regulatory landscape that any multi-sector, multinational organisation must navigate: healthcare frameworks such as HIPAA and the EU Medical Device Regulation; manufacturing and cyber-physical system standards including the EU Cyber Resilience Act and IEC 62443; transport and critical mobility directives; sustainability and ESG reporting obligations under the CSRD, ISSB and SEC climate rules; telecommunications security under the EECC and UK TSA; government and defence accreditation schemes such as FedRAMP and EUCS; and cross-cutting instruments ranging from eIDAS 2.0 and the EU Data Act to PCI DSS and SOX. The chapter shows how these diverse obligations converge on a common set of operational expectations and distils them into stable design criteria — continuous topology visibility, governed automation, sovereign telemetry and bounded, explainable AI — that, if genuinely met, make compliance a by-product of well-designed operational architecture.

3.1 From compliance projects to operational obligations

For much of the cloud adoption era, regulatory work has been organised as a sequence of projects. A new law appears, a programme spins up, consultants are engaged, gap analyses are performed, policies are rewritten, some systems are modified, and a collection of slide decks and attestations is produced. For a time, the organisation can say with a straight face that it is “compliant”, at least in the narrow sense that a particular regulatory requirement has been mapped to a set of controls.

This model has always had its limits, but it is especially brittle in a world where the production environment itself is constantly changing. Infrastructure as code, continuous delivery, multi‑cloud deployments and SaaS adoption mean that the technical state of the organisation may evolve several times per day. A control that was accurately documented six months ago may no longer exist in that form. A policy that makes sense in a static on‑premises world may be honoured in the breach in a dynamic, distributed architecture, not because anyone has consciously decided to violate it, but because the systems that should enforce it have quietly drifted out of alignment.

The current generation of regulation makes this gap explicit. Frameworks like the Digital Operational Resilience Act (DORA) [1] in financial services, NIS2 [2] for essential and important entities in the EU, and sector‑specific guidance from data protection authorities and supervisors do not merely ask, “Do you have a policy?” They ask, “How do you actually behave during an incident? How do you design for resilience? How do you test your ability to withstand and recover from disruption? How do you ensure that third‑party providers and AI‑driven components do not undermine your obligations?”

These questions cannot be answered once and filed away. They demand continuous, operational answers. They demand visibility into how the organisation’s systems behave in production, how automation is designed and controlled, how incidents are managed and learned from, and how AI participates in those processes. Compliance becomes not a static state but a property of the way the organisation operates day to day.

The practical consequence is that operations—and by extension, operations architecture—moves from the periphery of regulatory thinking to the centre. The safest place for a policy is no longer a PDF on a file share; it is an enforced behaviour embedded in the tools and platforms that run the enterprise. Standards such as ISO/IEC 27001:2022 [3] and ISO 22301:2019 [4] have long expressed this expectation in the language of management systems; what is new is that legislative instruments now embed the same expectation directly into binding law, with material penalties attached.

The thread that runs through DORA, NIS2, GDPR [5], the EU AI Act [6] and the guidance of national supervisors—whether the EBA [7], the FCA [8] or the PRA [9]—is this: demonstrable, continuous operational control. The NIST Cybersecurity Framework 2.0 [10] and the annual ENISA Threat Landscape reports [11] reinforce the same principle from a technical risk perspective. A one‑time gap analysis, however thorough, cannot satisfy a requirement that is, by its nature, live and ongoing. The architecture must.

3.2 The evolving concept of digital sovereignty

“Digital sovereignty” began as a relatively simple story about geography. Legislators and policymakers, particularly in Europe, worried about personal data leaving the jurisdiction in which it was collected without adequate protection. Cloud providers responded with regions, availability zones and sometimes “sovereign cloud” offerings, promising that data would reside within certain borders and be subject to local law.

Over time, regulators and courts recognised that geography alone is not enough. If a dataset is stored in a compliant region but administered entirely by staff in another jurisdiction, under another legal regime, can it really be considered sovereign? If sensitive logs or telemetry are streamed to a global monitoring service without controls, is the organisation’s sovereignty promise intact? If encryption keys are managed by a foreign provider, does the location of the encrypted bits still matter? The GDPR’s requirement under Article 32 [5] for appropriate technical and organisational measures to ensure a level of security appropriate to the risk applies equally to processing operations that involve telemetry, keys and operational metadata—not merely to the primary records most organisations think of first.

In parallel, the definition of what counts as “data” in this context has expanded. It is no longer only about records in databases. Models trained on those records, embeddings derived from them, and inferences drawn by AI systems may all, in various ways, reveal information about the underlying data subjects. A model deployed in a different jurisdiction, or accessed by an operator outside the original legal context, raises sovereignty questions even if the raw data never moves. The EU AI Act [6] introduces an additional dimension here: AI systems that process personal data or that are deployed in high‑risk contexts carry obligations that extend to how the model is managed, who oversees it, and what records are kept—all of which have operational implications.

This broader view of sovereignty introduces new operational constraints. It is no longer enough to configure the right region and assume the rest will follow. Operational engineers must be aware of:

Where administrative access originates: which humans and which automated systems can connect to which components, from which locations, using which credentials.
Where telemetry and logs are sent: whether observability pipelines inadvertently export sensitive data outside allowed boundaries.
Where AI inference runs: whether models that have seen sensitive data are being invoked from contexts that are consistent with the commitments made to data subjects and regulators.
Who controls the control plane: whether the provider of a platform can, in principle, exercise unilateral power over the systems that store or process sensitive data.

A sovereign cloud operations architecture has to manage these concerns in a way that does not require every engineer, in every incident, to hold the entire regulatory landscape in their head. It must bake sovereignty into the default behaviour of the system, so that the easiest way to operate is also the compliant way.

3.3 DORA and the codification of operational resilience

Regulation (EU) 2022/2554—the Digital Operational Resilience Act [1]—entered into application on 17 January 2025 after a two‑year transition period. It applies to a wide range of financial entities regulated at the European level, including credit institutions, payment institutions, investment firms, insurance undertakings, crypto‑asset service providers and, critically, the critical ICT third‑party service providers that serve them. The ambition of DORA is to replace a fragmented patchwork of national guidance with a single, binding, prescriptive framework for digital operational resilience across the EU financial sector.

What makes DORA structurally different from its predecessors is its specificity. It does not request that firms be “robust” or maintain “appropriate resilience”. It codifies five mandatory pillars of ICT risk management and attaches concrete requirements to each.

The five ICT risk management pillars. The first pillar is an ICT risk management framework: firms must maintain, document and regularly review a comprehensive framework that identifies sources of ICT risk, maps exposure to those sources, and establishes protection, detection, response and recovery mechanisms [1, Art. 6]. This is not a one‑time exercise; the framework must be reviewed at least annually and after major ICT incidents or significant changes to the estate. The second pillar covers ICT‑related incident management: firms must define processes to identify, classify, manage and notify incidents, with clear criteria for determining whether an incident is “major” and therefore subject to the mandatory reporting timeline [1, Art. 17–19]. The third pillar is digital operational resilience testing: firms must test their ICT systems regularly, with basic testing for all in‑scope entities and advanced Threat‑Led Penetration Testing (TLPT) for the most significant [1, Art. 24–26]. The fourth pillar addresses ICT third‑party risk management, requiring a detailed framework for managing dependencies on external service providers [1, Art. 28–44]. The fifth pillar mandates information sharing: firms are encouraged to exchange cyber threat intelligence with peers and competent authorities in a structured and confidential way [1, Art. 45].

Impact tolerance and TLPT. DORA’s approach to testing is deliberately borrowed from the operational resilience frameworks developed in the UK [8, 9]: the concept of impact tolerances. Firms must identify their critical or important business services, determine the maximum tolerable level of disruption for each, and test whether they can remain within those tolerances under severe but plausible scenarios. For significant institutions, DORA requires TLPT at least every three years [1, Art. 26]. TLPT—a structured methodology aligned with the TIBER‑EU framework published by the European Central Bank—involves red‑team exercises led by authorised external testers who simulate sophisticated, intelligence‑led attacks against live production systems, not merely sandboxed environments. The scope of a TLPT engagement is agreed with the competent authority and must cover critical ICT systems and functions. The results are shared with the supervisor and must feed into remediation plans with defined timelines.

ICT third‑party risk and the register of contractual arrangements. Chapter V of DORA is concerned entirely with third‑party risk, reflecting regulatory concern about concentration risk in the cloud and managed services market. Financial entities must maintain a complete and up‑to‑date register of all contractual arrangements with ICT third‑party service providers [1, Art. 28(3)]. This register is not merely a list of contracts; it must capture the nature and criticality of the services provided, the jurisdictions in which data is processed, exit strategies, and the dependencies between providers and business services. The European Supervisory Authorities are empowered to request this register at any time. Critically, where a financial entity relies on a provider for a critical or important function, it must assess concentration risk—the danger that the failure or unavailability of a single provider could have a systemic impact—and must maintain documented plans for transitioning away from that provider if necessary [1, Art. 30].

How Concert directly addresses DORA’s dependency mapping obligation. The dependency mapping obligation is perhaps the most challenging operational requirement in DORA for any organisation operating in a modern, dynamic cloud environment. A static diagram produced in a workshop satisfies neither the letter nor the spirit of the requirement: the diagram will be out of date within weeks, and the organisation will have no reliable way to assess the impact of provider incidents or disruptions on specific business services in real time.

IBM Concert addresses this directly through its continuous topology discovery capability. Rather than relying on manual documentation or periodic discovery scans, Concert maintains a continuously updated graph of the relationships between business services, applications, infrastructure components, APIs, and the ICT third‑party services on which they depend. When a cloud provider reports an incident, Concert can immediately surface which business services are potentially affected, what the dependency chain looks like, and what the estimated business impact is. This is precisely the evidence DORA requires: not a historical chart, but a live, queryable map of the operational estate that can be used to demonstrate impact tolerance assessments, inform TLPT scoping, and populate the register of contractual arrangements with accurate dependency data. The instrument of compliance here is not a policy document; it is an operational capability embedded in the architecture.

3.4 NIS2, cybersecurity, and the fusion of security and operations

Directive (EU) 2022/2555—the Network and Information Security Directive 2 [2], which repealed and replaced the original NIS Directive from 2016—entered into force in January 2023 with a transposition deadline of October 2024. Where the original directive applied to a relatively narrow set of operators of essential services and digital service providers, NIS2 substantially widens the scope and hardens the obligations.

Expanded scope: essential versus important entities. NIS2 introduces a two‑tier classification. “Essential entities” are drawn from eleven critical sectors: energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, ICT service management (business‑to‑business), public administration, and space [2, Art. 3(1)]. “Important entities” cover eight additional sectors: postal and courier services, waste management, manufacture of critical products (chemicals, food, medical devices, electronics, machinery, motor vehicles), digital providers including online marketplaces and search engines, and research organisations [2, Art. 3(2)]. The practical significance of the distinction lies in the supervisory regime: essential entities are subject to proactive ex‑ante supervision and more extensive audit powers, while important entities face primarily ex‑post supervision triggered by evidence of non‑compliance. Both categories are, however, subject to identical substantive obligations, including the ten minimum security measures and the incident notification requirements.

The ten minimum security measures. Article 21 of NIS2 [2] specifies the minimum measures that all in‑scope entities must implement. These are worth enumerating in full because they translate directly into operational design requirements. Entities must implement: (i) risk analysis and information system security policies; (ii) incident handling procedures, including detection, response and recovery; (iii) business continuity and crisis management measures, including backup management and disaster recovery; (iv) supply chain security, addressing the security of relationships with direct suppliers and service providers; (v) security in network and information systems acquisition, development and maintenance, covering vulnerability handling and disclosure; (vi) policies and procedures to assess the effectiveness of cybersecurity risk management measures; (vii) basic cyber hygiene practices and cybersecurity training; (viii) policies on the use of cryptography and, where appropriate, encryption; (ix) human resources security, access control policies and asset management; and (x) the use of multi‑factor authentication or continuous authentication solutions, secured voice, video and text communications, and secured emergency communication systems [2, Art. 21(2)]. For organisations already aligned to ISO/IEC 27001:2022 [3], most of these measures will be familiar; NIS2 translates them into binding law with supervisory teeth.

The incident notification timeline. The notification timeline under NIS2 is one of its most operationally demanding provisions, and it directly shapes the tooling and process requirements for any in‑scope organisation. Upon becoming aware of a significant incident, an entity must submit an early warning to its national Computer Security Incident Response Team (CSIRT) or competent authority within 24 hours [2, Art. 23(4)(a)]. This early warning need not be complete, but it must indicate whether the incident is suspected to have been caused by unlawful or malicious acts, and whether it has or may have cross‑border impact. Within 72 hours of awareness, the entity must provide a full incident notification that includes an initial assessment of the incident—severity, impact, and indicators of compromise [2, Art. 23(4)(b)]. A final report must follow within one month, covering a detailed description, likely root cause, applied mitigation measures, and the cross‑border impact where applicable [2, Art. 23(4)(c)].

The 24‑hour early warning threshold is, in practice, a very short window in which to characterise an incident with any confidence, particularly for distributed, multi‑cloud environments where the blast radius may not be immediately apparent. This has direct implications for operational tooling. To meet the early warning requirement reliably, organisations need the ability to detect, correlate and assess incidents across hybrid and multi‑cloud estates automatically and in near‑real time. A siloed security operations centre that lacks integration with cloud operations tooling will struggle; the two functions must work from a common operational picture.

Implications for operational tooling and audit trails. NIS2 also introduces personal accountability at senior management level that has no direct equivalent in most earlier frameworks [2, Art. 20]. Management bodies of essential and important entities are required to approve the cybersecurity risk management measures, oversee implementation, and may be held personally liable for infringements. This sharpens the need for clear, auditable evidence of what decisions were made, by whom, on what basis, and with what effect. Logging not just the fact that a change was made, but the authorisation chain, the AI‑assisted recommendation if one was involved, the human approval, and the post‑change verification, becomes not just good practice but a regulatory expectation. The governance and audit plane described elsewhere in this book is the architectural mechanism for satisfying this expectation.

3.5 Data protection, telemetry, and the invisible flows

Data protection regulation, led by GDPR [5] but echoed in many jurisdictions, was an early driver of the sovereignty conversation. It forced organisations to think seriously about where personal data was stored, who had access to it, and under what conditions it could be processed or transferred. In the operational realm, however, some of the most significant data flows remained under‑examined.

Observability is a prime example. To understand and operate complex systems, engineers need logs, metrics, traces and events. These often contain or imply information about users and their behaviour. A request log may include identifiers or payloads; a trace may reveal user journeys; a metric may correlate with the activity of specific cohorts. When these artefacts are shipped en masse to centralised logging or monitoring platforms, especially when those platforms are operated as cloud services, the organisation may inadvertently create new data protection and sovereignty issues.

Regulators are increasingly aware of this. They do not distinguish, in any meaningful way, between “business data” and “operational data” if both can reveal information about individuals. Nor do they see a difference between a database and a log store if personal data is present in each. GDPR Article 32 [5] requires that the controller and processor implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk; this obligation applies to the security of operational data flows just as much as to the security of primary application data. For operations architecture, this implies that observability must be designed with data protection in mind. Questions that once seemed purely technical—which logs are collected? how long are they retained? where are they stored? who can query them?—take on a regulatory dimension.

In a zero‑copy, sovereign architecture, this tension is heightened. On the one hand, having rich telemetry is essential to demonstrate control, diagnose issues, and support forensic analysis. On the other hand, unconstrained telemetry flows risk undermining the very sovereignty story the organisation is trying to tell. A balance must be struck.

Practically, that means being deliberate about what is logged and traced, avoiding unnecessary capture of personal data. It means partitioning observability pipelines by jurisdiction or sensitivity, so that sensitive telemetry stays within the same sovereign boundaries as the systems it describes. It means ensuring that tools like Instana and logging backends can operate in federated modes, giving central teams visibility into patterns and aggregates without exfiltrating raw data from regulated zones. It means treating access to observability data as a governed privilege, not an unmonitored convenience.

These are not tasks that can be left to individual teams to interpret inconsistently. They must be part of the operational governance framework, subject to the same policy‑as‑code discipline as other aspects of the estate.

3.6 AI governance in the context of operations

AI governance is often introduced with examples from customer‑facing or decision‑centric domains: credit scoring, hiring, medical diagnosis, criminal justice. In those contexts, the focus is on fairness, bias, explainability and responsibility toward individuals affected by model outputs. When AI is applied to operations, the ethical stakes are different but no less real.

An AI‑driven anomaly detector that fails to recognise a pattern could miss a brewing outage. An AI‑suggested remediation that misjudges context could take down a service unnecessarily or route traffic through a non‑compliant path. An agent that overestimates its own confidence might apply a security change too broadly, disrupting legitimate activity. These are not abstract possibilities; they are the kinds of failure modes that any experienced operator can imagine.

Governing AI in this domain involves several layers. At the model level, organisations must ensure that the data used to train and fine‑tune operational models is representative of their estate and does not embed outdated or biased assumptions. At the deployment level, they must define clear boundaries for what agents are allowed to do autonomously, what requires explicit human approval, and what is prohibited. At the monitoring level, they must track the behaviour of AI components over time: how often they are right, how often they are overridden, how they respond to novel conditions.

Watsonx.governance provides tooling for many of these tasks: model registration, lineage, metrics, policy application and audit. But as with other regulations, the existence of a governance platform is not enough. The organisation must integrate it into the operational flow. That means ensuring that when Orchestrate agents call models to make recommendations or decisions, those invocations are tied back to registered, governed artefacts, not to ad‑hoc, untracked endpoints. It means logging not only the fact that an action was taken, but the reasoning and model outputs that led to it, so incidents can be analysed after the fact. It means designing user interfaces that make it clear when a suggestion comes from an AI component and what its confidence and basis are, so humans can make informed judgements. It means establishing processes for updating, retraining, or retiring models and agents as the estate and regulatory environment evolve.

In short, AI governance in operations must be treated with the same seriousness as any other safety‑critical automation. The fact that it is “only” about infrastructure and applications does not make the consequences of failure any less real, especially when those systems support critical business services.

3.7 Operational governance as the convergence point

When we look across digital sovereignty, operational resilience, cybersecurity, data protection and AI governance, a pattern emerges. The specific vocabulary varies by domain and regulator, but many of the requirements converge on a simple expectation: the organisation must be able to demonstrate that it operates its systems consciously and consistently, in line with explicit principles, and that it learns from experience.

Operational governance is the discipline that translates that expectation into practice. It is broader than configuration management and narrower than corporate governance. It sits at the intersection of technology, process, and people. It is concerned with questions such as: how is the state of the estate known at any given moment? How are changes proposed, reviewed, and implemented? How are incidents detected, triaged, resolved, and learned from? How are responsibilities divided between humans and automation, and how are those responsibilities adjusted over time? How is evidence of all this activity captured, retained, and presented to those who need to see it?

In a sovereign cloud context, operational governance must be provider‑agnostic but policy‑aware. It cannot depend on any single cloud’s native console or toolset; otherwise, multi‑cloud becomes an exercise in duplication. At the same time, it must understand and enforce the organisation’s own commitments: which jurisdictions matter, which data classes require special treatment, which business services are critical, which agents may act where.

The EBA Guidelines on ICT and Security Risk Management [7] offer a useful illustration of where this convergence leads in practice. They require that ICT risk management form an integral part of the overall risk management framework, that the management body maintains a sufficiently detailed overview of ICT risk, and that there are adequate arrangements for the continuity of critical or important functions. The PRA supervisory statement SS2/21 [9] and the FCA policy statement PS21/3 [8] make essentially the same demand in the UK operational resilience context: what is the maximum tolerable level of disruption, can you demonstrate you can stay within it, and can you show us the evidence? These questions require operational governance infrastructure—not just operational activity—to answer reliably.

The architectural patterns described in this book—zero‑copy integration, multi‑cloud topology with sovereign zones, full‑stack and network‑aware observability, infrastructure and policy as code, agentic operations with governed AI—are all, in different ways, instruments of operational governance. IBM’s platforms provide concrete ways to instantiate them, but the deeper point is that governance is no longer only a matter of writing rules; it is a matter of building systems and practices in which the rules are the default behaviour.

3.8 Healthcare regulatory obligations

Healthcare is among the most intensely regulated domains for data handling and system operation. Patient data carries legal protections that, in practice, extend deep into the operational stack — from the databases that store electronic health records to the observability pipelines that capture request logs and the AI models that ingest clinical signals. Any organisation hosting, processing or transmitting health data in the cloud must treat the operational architecture as part of the regulated surface, not merely the application layer above it.

HIPAA and the operational perimeter of protected health information. In the United States, the Health Insurance Portability and Accountability Act (HIPAA) [12] establishes the baseline for protecting electronic protected health information (ePHI). The Security Rule requires covered entities and their business associates to implement administrative, physical and technical safeguards — including access controls, audit controls, transmission security and integrity mechanisms — for all electronic systems that create, receive, maintain or transmit ePHI [12]. Business Associate Agreements (BAAs) extend these obligations contractually to cloud providers and managed service operators. The Privacy Rule’s minimum necessary standard demands that access to ePHI be limited to the minimum amount required for a given purpose, a principle with direct implications for observability: if a log stream contains patient identifiers or clinical data, every consumer of that stream must be justified and documented.

Proposed updates to the HIPAA Security Rule, published in late 2024 and expected to be finalised in 2025, would strengthen several operational requirements [13]. These include mandatory encryption of ePHI at rest and in transit without exception, a 72-hour notification window for breaches, continuous and documented risk analysis rather than periodic assessments, and more prescriptive requirements for network segmentation and vulnerability management. For cloud operations teams, the direction of travel is clear: continuous compliance monitoring, automated evidence collection and zone-scoped data handling are moving from best practice to legal mandate.

EU Medical Device Regulation and software as a medical device. Regulation (EU) 2017/745 — the Medical Device Regulation (MDR) [14] — governs the placing on the market and ongoing surveillance of medical devices across the EU, including software that qualifies as a medical device in its own right (Software as a Medical Device, or SaMD). Where cloud-hosted SaMD is concerned, the MDR’s post-market surveillance obligations require that the manufacturer maintain a systematic process for collecting and reviewing experience from devices placed on the market, including performance data, complaint logs and field safety reports [14, Art. 83–86]. In operational terms this translates to a requirement for continuous telemetry: uptime records, error rates, latency distributions and user-reported anomalies must be captured, retained and analysable over the device’s expected lifetime. Traceability through the European Database on Medical Devices (EUDAMED) adds a further dimension — every version of the software, every update deployed to production and every Clinical Evaluation Report must be linkable to the operational evidence that supports it. The audit trail is not a compliance add-on; it is the backbone of the device’s regulatory file.

FDA 21 CFR Part 11 and electronic records. In the United States, FDA 21 CFR Part 11 [15] sets the requirements for electronic records and electronic signatures in industries regulated by the Food and Drug Administration, including pharmaceuticals, biotechnology and medical device manufacturing. Any cloud system that produces, stores or transmits records subject to FDA regulation — batch records, laboratory results, quality events, adverse event reports — must maintain tamper-evident audit trails recording who created, modified or deleted each record and when [15, §11.10(e)]. Systems must be validated to ensure accuracy, reliability and consistent intended performance, and access must be limited to authorised individuals with controls proportionate to the record’s sensitivity. For cloud operations, Part 11 means that infrastructure-as-code pipelines, configuration management systems and even monitoring dashboards that display regulated data must be designed with audit trail integrity and system validation in mind.

France HDS certification and sovereign health data hosting. France has taken a notably prescriptive approach to health data sovereignty through its Hébergeur de Données de Santé (HDS) certification [16]. Any organisation hosting personal health data on behalf of a French healthcare entity must hold HDS certification, which requires ISO 27001 certification plus a set of additional controls specific to health data — covering data localisation, incident management, personnel screening and contractual transparency. The practical effect is a mandatory sovereign hosting requirement for French health data, one that cannot be satisfied merely by deploying in an EU region operated by a non-certified provider. For multinational healthcare organisations, HDS illustrates how national-level requirements can layer on top of EU-wide frameworks, demanding zone-scoped architectures in which French health data is processed exclusively within certified infrastructure.

Implications for sovereign operations architecture. Taken together, these healthcare frameworks reinforce a consistent set of operational design requirements. Observability pipelines must be capable of ePHI scrubbing — stripping or pseudonymising patient identifiers before telemetry leaves a health-data sovereign zone — while still preserving enough operational signal to support diagnosis and performance management. AI governance must account for model access to patient data: any model trained on or inferring from clinical records must be registered, governed and subject to the same access audit trails as the data itself. Federated observability, in which aggregated metrics and anonymised patterns flow to central teams while raw ePHI remains within the zone, is not merely architecturally convenient; it is the operational expression of the minimum necessary principle under HIPAA and the data minimisation principle under GDPR [5].

Healthcare regulatory framework mapping to sovereign zone controls

3.9 Manufacturing, industrial, and cyber-physical systems

The convergence of information technology and operational technology in manufacturing and industrial environments introduces regulatory obligations that extend beyond data protection into the domains of product safety, supply chain integrity and physical-world consequence. A vulnerability in a connected industrial controller is not merely an IT incident; it is a potential safety event. Regulators have responded accordingly, and cloud platforms that host or support industrial operations must now account for frameworks that treat cybersecurity as a product attribute, not merely an enterprise hygiene practice.

EU Cyber Resilience Act. Regulation (EU) 2024/2847 — the Cyber Resilience Act (CRA) [17] — entered into force in late 2024 and establishes mandatory cybersecurity requirements for products with digital elements placed on the EU market, including standalone software. The CRA requires manufacturers to design products with security by default, to conduct and document conformity assessments, and to handle vulnerabilities throughout the product’s supported lifetime [17, Art. 13]. Critically, it mandates that manufacturers maintain and make available a Software Bill of Materials (SBOM) identifying the components and dependencies of their products [17, Annex I, Part II]. For organisations operating CI/CD pipelines that produce software destined for the EU market, this means that build systems must generate, sign and retain SBOMs as first-class artefacts, and that vulnerability management processes must be capable of tracing a newly disclosed CVE to every affected product version and deployment. The CRA also imposes incident reporting obligations: actively exploited vulnerabilities must be reported to ENISA within 24 hours [17, Art. 14], a timeline that closely mirrors NIS2 and demands the same kind of automated detection and correlation capability.

IEC 62443 and industrial automation security. The IEC 62443 family of standards [18] provides the most widely adopted framework for securing industrial automation and control systems (IACS). Its architecture is built around the concepts of zones and conduits — logical groupings of assets with common security requirements connected by controlled communication paths — and defines four security levels representing progressively greater capability to withstand attack. The parallels with the sovereign zone model described in this book are direct and deliberate: both approaches segment the estate into bounded regions with defined trust levels and controlled interfaces. For organisations managing hybrid IT/OT environments, IEC 62443 provides the vocabulary and assessment methodology that regulators and auditors in the industrial sector expect. Operational tooling must be capable of discovering and mapping OT assets alongside IT assets, monitoring network flows across zone boundaries, and enforcing conduit policies that prevent unauthorised lateral movement between the enterprise IT network and the process control network.

EU Machinery Regulation. Regulation (EU) 2023/1230 — the new Machinery Regulation [19] — replaces the Machinery Directive 2006/42/EC and adds, for the first time, explicit cybersecurity and AI requirements for machinery with digital components. Machinery that incorporates safety functions implemented in software, or that uses AI to influence its behaviour, must demonstrate that these digital elements do not compromise the essential health and safety requirements [19, Art. 5 and Annex III]. For manufacturing operations platforms that manage fleets of connected machinery, this means that software updates, configuration changes and AI model deployments affecting machine behaviour must be traceable, reversible and subject to the same change governance as safety-critical modifications.

Implications for sovereign operations architecture. The operational consequence of these frameworks is that OT/IT convergence cannot be treated as a networking exercise alone. Observability must extend into the industrial domain — capturing not only traditional IT metrics but also controller states, safety instrumented system (SIS) status and process variable trends. ICS-aware monitoring must distinguish between benign operational changes and anomalous behaviours that could indicate compromise or misconfiguration. Supply chain security, enforced through SBOM management and continuous vulnerability correlation, must be embedded in the CI/CD pipeline as a default rather than a periodic audit activity. The sovereign zone model provides a natural architectural home for these requirements: OT zones with strict ingress and egress controls, dedicated observability pipelines that never co-mingle process telemetry with enterprise data, and governed change workflows that require explicit safety review before any modification reaches the control layer.

IEC 62443 zone and conduit model mapped to sovereign zone architecture

3.10 Transport and critical mobility infrastructure

Transport systems — aviation, rail, maritime, pipeline and road — are among the most safety-critical environments in which cloud-hosted operations platforms now play a role. The regulatory landscape reflects this criticality, combining traditional safety regulation with a growing body of cybersecurity-specific requirements that emerged, in many cases, from high-profile incidents demonstrating how a digital compromise can cascade into physical-world disruption.

TSA Security Directives. In the United States, the Transportation Security Administration (TSA) issued a series of Security Directives in 2021 and 2022 following the Colonial Pipeline ransomware attack, initially targeting pipeline operators and subsequently extended to rail and aviation [20]. These directives require owner-operators of critical transportation infrastructure to designate a cybersecurity coordinator, report cybersecurity incidents to CISA within 24 hours, conduct vulnerability assessments, and develop and implement cybersecurity implementation plans covering network segmentation, access controls, continuous monitoring and patching [20]. The monitoring requirements are prescriptive: covered entities must have the capability to detect anomalous activity in IT and OT networks and must maintain logs sufficient to support incident investigation. For organisations providing cloud-hosted operational platforms to transport operators, these directives translate into requirements for air-gapped or tightly segmented deployment models, real-time telemetry with local retention, and incident response automation that can function even when connectivity to external services is degraded.

EASA Part-IS and aviation cybersecurity. The European Union Aviation Safety Agency (EASA) has introduced information security requirements through its Part-IS regulation [21], which applies to organisations within the aviation ecosystem — airlines, airports, air navigation service providers, aircraft manufacturers and their supply chains. Part-IS requires that these organisations establish and maintain an information security management system (ISMS), conduct continuous risk assessment, and implement protective measures commensurate with the threats to aviation safety. Continuous monitoring is an explicit obligation: organisations must be able to detect, assess and respond to information security events that could affect the safety of civil aviation [21]. For cloud operations, this means that aviation-sector deployments require observability architectures that can correlate IT events with safety implications, maintain separation between safety-critical and non-safety-critical systems, and produce audit trails that satisfy both cybersecurity regulators and aviation safety authorities.

IMO maritime cyber risk management. The International Maritime Organization (IMO) has incorporated cyber risk management into the International Safety Management (ISM) Code through Resolution MSC.428(98) [22], requiring that cyber risks are appropriately addressed in existing safety management systems from January 2021. Port state control inspections may now include review of an organisation’s cyber risk management procedures, covering both IT systems and the OT systems that control navigation, propulsion and cargo management. For cloud platforms supporting maritime operations, this means that the operational architecture must account for connectivity constraints — vessels may have limited or intermittent satellite bandwidth — and must support local autonomy with periodic synchronisation, a pattern that the sovereign zone concept accommodates naturally through edge-capable deployments with store-and-forward telemetry.

EU PNR Directive. Directive (EU) 2016/681 on the use of Passenger Name Record data [23] imposes strict controls on the handling of PNR data by air carriers and Passenger Information Units. PNR data must be retained for no more than five years, with depersonalisation after six months, and may be processed only for the specific purposes defined in the Directive [23, Art. 12]. For airline and transport operators hosting PNR processing in the cloud, these requirements mandate data residency controls, automated retention and depersonalisation workflows, and purpose-limitation enforcement in access control policies — all of which must be verifiable through operational audit trails.

Implications for sovereign operations architecture. Transport regulation converges on a set of operational requirements that align closely with the sovereign zone model: safety-critical systems must be isolated from general-purpose IT, monitoring must be continuous and locally resilient, incident detection must be fast enough to support 24-hour reporting obligations, and data handling must respect strict residency and retention rules. Cross-border data flow constraints — a vessel’s operational data may be subject to the laws of its flag state, the port state and the coastal states through which it transits — make jurisdiction-aware telemetry routing an operational necessity rather than an architectural nicety.

3.11 Sustainability, ESG, and environmental reporting

A newer but rapidly hardening set of regulatory obligations concerns the environmental and sustainability performance of organisations, including the energy consumption and carbon footprint of their digital infrastructure. These frameworks do not regulate cybersecurity or data protection directly, but they impose data collection, auditability and reporting requirements that fall squarely on the operations function — because it is operations teams who have access to the telemetry needed to measure and report what regulators and investors now demand.

EU Corporate Sustainability Reporting Directive. Directive (EU) 2022/2464 — the Corporate Sustainability Reporting Directive (CSRD) [24] — requires approximately 50,000 EU companies to report on sustainability matters according to the European Sustainability Reporting Standards (ESRS), with the first reports due for financial years beginning in 2024. The CSRD introduces the principle of double materiality: companies must report both on how sustainability matters affect their business and on how their business affects the environment and society [24]. For technology and financial services companies, this means reporting on energy consumption, greenhouse gas emissions across Scopes 1, 2 and 3, and the environmental impact of their digital infrastructure — including cloud data centres. The data underlying these reports must be auditable to a level of assurance comparable to financial reporting, which means that operational telemetry — power consumption metrics, workload placement data, cooling efficiency measurements — must be collected systematically, retained with provenance, and reconcilable to the published figures.

EU Taxonomy Regulation. Regulation (EU) 2020/852 — the Taxonomy Regulation [25] — establishes a classification system for determining whether an economic activity qualifies as environmentally sustainable. Technology companies must assess and disclose the proportion of their revenue, capital expenditure and operating expenditure aligned with the taxonomy’s technical screening criteria. For data centre operators and cloud consumers, relevant criteria include power usage effectiveness (PUE) thresholds, water usage effectiveness, renewable energy sourcing, and circular economy practices for hardware. Operational platforms must be capable of collecting and reporting these metrics at sufficient granularity to support taxonomy alignment assessments — not as a periodic manual exercise, but as a continuous data feed integrated into sustainability reporting workflows.

ISSB/IFRS sustainability disclosure standards. The International Sustainability Standards Board (ISSB) has published IFRS S1 (General Requirements for Disclosure of Sustainability-related Financial Information) and IFRS S2 (Climate-related Disclosures) [26], which are being adopted or referenced by jurisdictions worldwide. IFRS S2 requires disclosure of Scope 1, 2 and 3 greenhouse gas emissions, climate-related scenario analysis and transition planning. For organisations whose cloud infrastructure constitutes a material source of emissions — either directly through owned data centres or indirectly through cloud provider consumption — IFRS S2 demands operational data that many organisations currently lack: granular energy consumption by workload, location-based and market-based emission factors, and the methodology used to estimate Scope 3 emissions from supply chain providers.

SEC climate disclosure rules. In the United States, the Securities and Exchange Commission (SEC) adopted climate-related disclosure rules in 2024 [27] requiring material climate risk disclosure and, for larger registrants, Scope 1 and 2 greenhouse gas emissions reporting with phased-in attestation requirements. Although implementation has been subject to legal challenge and stays, the direction of travel is consistent with international standards: organisations will need auditable, system-generated emissions data, not estimates produced in spreadsheets.

Implications for sovereign operations architecture. The operational architecture implications of sustainability regulation are distinctive. Data centre energy observability — real-time power consumption per rack, per zone, per workload — must be a first-class telemetry stream alongside the traditional metrics of CPU, memory and network utilisation. Carbon-aware workload placement, in which the automation layer considers the carbon intensity of available regions when scheduling batch jobs or scaling services, becomes a governance-driven capability. Automated ESG evidence collection — aggregating energy, water and waste data from infrastructure providers, reconciling it against reported figures and producing audit-ready datasets — is an emerging requirement that integrates naturally with the governance and audit plane described in this book. Sustainability dashboards, fed by the same operational telemetry infrastructure that supports reliability and security monitoring, complete the picture: a single observability architecture serving multiple regulatory masters.

Sustainability telemetry flows from data centre to ESG report

3.12 Telecommunications and digital infrastructure

Telecommunications providers occupy a unique position in the regulatory landscape. They are simultaneously operators of critical national infrastructure, processors of vast quantities of personal and traffic data, and the connectivity substrate on which every other sector depends. The regulatory obligations that apply to them are correspondingly extensive, and increasingly prescriptive about the security of the network infrastructure itself — not merely the data that traverses it.

European Electronic Communications Code. Directive (EU) 2018/1972 — the European Electronic Communications Code (EECC) [28] — establishes security obligations for providers of electronic communications networks and services across the EU. Article 40 requires that providers take appropriate and proportionate technical and organisational measures to manage the risks posed to the security of networks and services, and that they report significant incidents to national authorities [28, Art. 40]. The EECC’s security framework aligns with and is complemented by NIS2 [2], which brings telecoms providers explicitly within its scope as essential entities. In practice this means that telecoms operators must maintain continuous monitoring of network infrastructure, implement supply chain security measures covering equipment vendors and managed service providers, and have incident detection and reporting capabilities that satisfy both the EECC’s sector-specific requirements and NIS2’s cross-sectoral obligations.

UK Telecommunications (Security) Act 2021. The United Kingdom has taken a particularly prescriptive approach through the Telecommunications (Security) Act 2021 [29] and its associated regulations and code of practice. The Act grants OFCOM powers to set and enforce specific security requirements for public telecoms providers, and the accompanying code of practice specifies detailed measures covering network architecture, monitoring, access control, supply chain management and data handling. Notably, the Act’s supply chain provisions were shaped by the policy decision to restrict and ultimately remove high-risk vendors from UK telecoms networks — a decision with direct implications for vendor diversification and the operational complexity of managing multi-vendor environments. For cloud platforms supporting telecoms operations, the Act’s requirements translate into demands for deep network function observability, configuration compliance monitoring across a heterogeneous vendor estate, and audit trails that demonstrate adherence to the code of practice.

Implications for sovereign operations architecture. Telecoms-specific regulation reinforces the broader themes of this chapter but adds distinctive requirements. Network function virtualisation (NFV) and 5G core network elements, increasingly deployed on cloud infrastructure, require observability that understands telecoms-specific protocols, service-level constructs and fault propagation patterns — not merely generic container metrics. Multi-vendor supply chain governance, driven both by security policy and by diversification mandates, requires the operational platform to track, audit and enforce vendor-specific deployment rules across the estate. The sovereign zone concept maps naturally to telecoms use cases: different network functions may be subject to different jurisdictional controls depending on the data they process, the customers they serve and the national security considerations that apply.

3.13 Government, defence, and public sector frameworks

Government and defence organisations impose some of the most stringent cloud security and sovereignty requirements, often formalised through accreditation and certification schemes that must be satisfied before any workload can be deployed. These frameworks are significant not only for the public sector itself but for any commercial organisation that wishes to serve government customers or that operates in industries where government-grade security is a contractual expectation.

FedRAMP. The Federal Risk and Authorization Management Program (FedRAMP) [30] is the United States government’s standardised approach to security authorisation for cloud products and services. FedRAMP defines three impact levels — Low, Moderate and High — each with a corresponding set of security controls derived from NIST SP 800-53 [31]. The programme’s distinguishing operational characteristic is its emphasis on continuous monitoring (ConMon): once authorised, a cloud service provider must submit monthly vulnerability scans, annual penetration test results, and regular Plan of Action and Milestones (POA&M) updates to the authorising agency and the FedRAMP Programme Management Office [30]. Significant changes to the system — new services, architectural modifications, boundary changes — require a reassessment. For operations teams, FedRAMP ConMon is not a periodic reporting exercise; it is a continuous obligation that requires automated scanning, real-time configuration drift detection, and a disciplined change management process that classifies every modification against the authorisation boundary.

EUCS — EU Cloud Certification Scheme. ENISA’s developing European Union Cloud Services Certification Scheme (EUCS) [32] aims to establish a harmonised EU-wide framework for cloud security certification at three assurance levels: basic, substantial and high. At the highest assurance level, the scheme is expected to include sovereignty requirements — restrictions on where data is processed, who can access it, and under which legal jurisdiction the provider operates [32]. The exact requirements remain under negotiation, but the direction is clear: for the most sensitive government and critical infrastructure workloads, EU cloud certification will demand not only technical security controls but also legal and organisational sovereignty measures. Organisations designing cloud operations architectures for European public sector customers should anticipate EUCS high-level requirements as a design constraint and ensure that their sovereign zone model can accommodate jurisdiction-specific isolation, personnel screening and legal entity separation.

National data localisation laws. Beyond the EU, a growing number of countries have enacted or strengthened data localisation requirements that mandate that certain categories of data be stored and processed within their national borders. Russia’s Federal Law No. 242-FZ requires that personal data of Russian citizens be stored on servers physically located within Russia [33]. China’s Personal Information Protection Law (PIPL) and the Data Security Law impose cross-border data transfer restrictions and require security assessments for transfers of important data [34]. India’s Digital Personal Data Protection Act 2023 empowers the government to restrict transfers to specific jurisdictions [35]. Saudi Arabia, Indonesia, Vietnam and others have similar provisions at various stages of implementation. For multinational organisations, this patchwork of localisation mandates means that the operational architecture must support per-jurisdiction sovereign zones — each with its own data residency guarantees, access controls and audit trails — managed through a common operational framework that provides consistent governance without requiring that data or telemetry cross the boundaries that local law prohibits.

Common Criteria. ISO/IEC 15408 — the Common Criteria for Information Technology Security Evaluation [36] — provides an internationally recognised framework for evaluating the security properties of IT products. While Common Criteria certification applies to products rather than to operational architectures, it is relevant to the selection of cloud platform components: evaluated products carry an assurance level that can simplify the risk assessment process in government and defence contexts. Operations teams should ensure that the products they rely upon — hypervisors, key management systems, identity providers — carry appropriate Common Criteria evaluations where the deployment context requires it.

Implications for sovereign operations architecture. Government and defence frameworks push the sovereign zone concept to its logical extreme: multi-classification hosting, in which workloads at different classification levels coexist on shared infrastructure with cryptographic and logical separation; air-gapped operations, where the most sensitive environments have no connectivity to the public internet and must be managed through physically isolated control planes; and per-jurisdiction sovereign zones that satisfy the localisation requirements of every country in which the organisation operates. The operational architecture must support all of these deployment models without fragmenting into a collection of bespoke, unmanageable environments. A common governance framework — with policy-as-code definitions that adapt to the classification, jurisdiction and accreditation requirements of each zone — is the mechanism that makes this tractable.

3.14 Cross-cutting and emerging frameworks

Beyond the sector-specific instruments surveyed above, several cross-cutting regulatory frameworks impose obligations that affect cloud operations irrespective of the industry in which the organisation operates. These frameworks address identity, data portability, payment security, financial controls and digital asset regulation — domains that, at first glance, may seem distant from the operations function but that, on closer inspection, impose requirements squarely on the operational architecture.

eIDAS 2.0 and the EU Digital Identity Wallet. Regulation (EU) 2024/1183, amending the original eIDAS Regulation [37], introduces the European Digital Identity Wallet — a government-issued digital identity that EU member states must make available to all citizens and residents. For sovereign cloud operations, the implications centre on identity federation: the wallet framework establishes qualified trust services, cross-border identity verification and cryptographic attestation mechanisms that operational access control systems will need to support. An engineer authenticating to a sovereign zone management plane using a wallet-based credential must trigger the same governed audit trail as any other form of authentication, but the underlying trust chain and credential format will be different from traditional enterprise identity providers. Operations architectures must be prepared to integrate wallet-based authentication alongside existing SAML, OIDC and certificate-based mechanisms.

EU Data Act. Regulation (EU) 2023/2854 — the EU Data Act [38] — addresses fair access to and use of data, including provisions on cloud switching and interoperability. Articles 23 to 31 require cloud service providers to remove barriers to switching, support data portability in structured and machine-readable formats, and provide sufficient information to enable customers to migrate their workloads [38, Art. 23–31]. For operational tooling, this has a direct implication: vendor lock-in in monitoring, logging and automation platforms becomes a regulatory risk, not merely a commercial one. Organisations should ensure that their observability data is exportable, that their automation logic is expressed in portable formats, and that their operational workflows do not create dependencies that would make switching prohibitively expensive or technically infeasible. The Data Act reinforces the architectural preference for open standards and API-driven integration that runs throughout this book.

PCI DSS v4.0. The Payment Card Industry Data Security Standard version 4.0 [39], effective from March 2024 with a transition period for new requirements through March 2025, represents the most significant update to the payment card security framework in a decade. PCI DSS v4.0 introduces requirements for targeted risk analysis to justify control implementation, continuous monitoring of security controls, and enhanced requirements for multi-factor authentication and automated log review [39]. For any organisation handling cardholder data in a cloud environment, PCI DSS v4.0’s emphasis on continuous monitoring and automated detection aligns with the broader regulatory trend described in this chapter: point-in-time assessments are insufficient; the security posture must be demonstrably maintained at all times. Network segmentation testing, penetration testing, and automated evidence collection are all areas where the operational platform can either support or undermine PCI compliance.

SOX and IT general controls. The Sarbanes-Oxley Act (SOX) [40] does not prescribe specific IT requirements, but its Section 404 — requiring management assessment and external audit of internal controls over financial reporting — has, through decades of practice, established a set of IT General Controls (ITGCs) that auditors expect. These cover change management (all changes to financially significant systems must be authorised, tested and documented), logical access controls (access to systems and data must be appropriate and reviewed periodically), and computer operations (batch processing, backups and incident management must be controlled and monitored) [40]. For cloud operations, SOX ITGCs mean that the infrastructure-as-code pipelines, deployment automation and access management processes described elsewhere in this book are not merely operational conveniences; for publicly traded US companies, they are the mechanisms through which SOX compliance is demonstrated.

PSD2/PSD3 and payment services regulation. Directive (EU) 2015/2366 — the Second Payment Services Directive (PSD2) [41] — and its anticipated successor PSD3 impose security requirements on payment service providers including strong customer authentication, secure communication standards for open banking APIs, and incident reporting obligations. Operational monitoring of payment APIs — latency, error rates, authentication failures, fraud indicators — is a regulatory expectation, and the observability architecture must be capable of providing this monitoring with the granularity and timeliness that supervisors require.

MiCA and crypto-asset regulation. Regulation (EU) 2023/1114 — the Markets in Crypto-Assets Regulation (MiCA) [42] — brings crypto-asset service providers within a regulatory framework that echoes DORA’s operational resilience requirements. MiCA mandates that crypto-asset service providers maintain sound ICT risk management, business continuity arrangements and incident response procedures [42, Art. 65–66]. For organisations operating crypto-asset platforms on cloud infrastructure, MiCA means that the same operational discipline — continuous monitoring, governed change management, incident detection and reporting — that DORA demands of traditional financial entities now extends to the digital asset domain.

Implications for sovereign operations architecture. The cross-cutting frameworks reinforce a central thesis of this chapter: operational architecture is the convergence point for regulatory compliance. Identity federation must accommodate new credential types without sacrificing auditability. Data portability and switching rights must be reflected in tooling choices and data formats. Payment and financial reporting controls must be embedded in automation pipelines. The sovereign operations model — with its emphasis on policy-as-code, governed automation, immutable audit trails and zone-scoped data handling — provides the structural foundation on which all of these obligations can be met without requiring a separate compliance programme for each framework.

3.15 From regulatory text to design criteria

It is easy to be overwhelmed by the alphabet soup of regulations and guidelines. Each sector, jurisdiction and regulator has its own language and emphases. Trying to optimise directly for every clause is both exhausting and brittle. A more practical approach is to extract from the regulatory landscape a set of design criteria that, if met, will make compliance easier now and more adaptable in the future.

From the discussion above — spanning financial services, cybersecurity, data protection, AI governance, healthcare, manufacturing, transport, sustainability, telecommunications, government and cross-cutting frameworks — we can derive at least the following. The architecture must make it possible to know, at any time, what supports a given business service and how it would be affected by various failures — a requirement driven directly by DORA [1], the operational resilience frameworks of the FCA [8] and PRA [9], and echoed by TSA Security Directives [20] and EASA Part-IS [21] in the transport sector. The organisation must be able to demonstrate that it can respond to disruptions, both technical and security‑related, in a controlled and tested way, satisfying the incident management and testing pillars of DORA, the minimum security measures of NIS2 [2], and the continuous monitoring obligations of FedRAMP [30] and PCI DSS v4.0 [39]. Sovereignty commitments must be implementable as technical constraints on where data and telemetry live, where inference happens, and who can act where, reflecting the obligations of GDPR Article 32 [5], HIPAA [12], France HDS [16], national data localisation laws [33–35] and the anticipated EUCS high-level requirements [32]. Operational data flows — logs, metrics, traces, model outputs — must be treated as part of the regulated data landscape, not as an unregulated by‑product, consistent with the interpretations of data protection authorities across the EU and the ePHI protections required by HIPAA. AI involvement in operations must be bounded, monitored and explainable, with clear accountability and an auditable sovereign record, as the EU AI Act [6] now requires for high‑risk operational deployments and the EU Machinery Regulation [19] demands for AI-influenced safety functions. Supply chain security must be embedded in build and deployment pipelines, with SBOM generation and vulnerability tracking as first-class operational concerns, reflecting the EU Cyber Resilience Act [17], NIS2’s supply chain provisions [2] and the UK Telecommunications (Security) Act [29]. Sustainability and environmental data — energy consumption, carbon emissions, resource efficiency — must be collected with the same rigour as security telemetry, as the CSRD [24], ISSB standards [26] and SEC climate rules [27] now require auditable operational evidence for ESG reporting.

The NIST Cybersecurity Framework 2.0 [10], with its updated “Govern” function sitting alongside Identify, Protect, Detect, Respond and Recover, provides a useful non‑legislative reference that many organisations already use to structure their risk management thinking. ENISA Threat Landscape reports [11] complement this by cataloguing the threat categories — ransomware, supply chain attacks, DDoS, data breaches — that resilience testing programmes, including DORA TLPT, must address credibly. ISO/IEC 27001:2022 [3] and ISO 22301:2019 [4] remain the workhorses of certification, providing independently auditable management system frameworks that demonstrate to regulators and clients alike that the organisation’s governance is systematic rather than ad hoc. IEC 62443 [18] provides the equivalent for industrial environments, and Common Criteria [36] supports product-level assurance in government and defence contexts.

The remaining parts of this book use these criteria as a lens. When we discuss the architectural reference model in the next part, we will ask how each plane — the observability plane, the automation plane, the agentic intelligence plane, the governance plane — contributes to meeting them. When we explore specific technologies and patterns, we will consider not only whether they are technically elegant, but whether they make it easier to answer the kinds of questions regulators, boards, safety authorities and sustainability auditors are now trained to ask.

In this sense, regulation is not just a constraint; it is a source of clarity. It forces organisations to articulate what they are trying to achieve operationally and to build architectures that make those goals demonstrably true. Sovereign cloud operations, as described in this book, are one attempt to rise to that challenge.

Regulatory obligations mapped to operational design criteria

3.16 The EU AI Act and operational AI

Regulation (EU) 2024/1689—the EU Artificial Intelligence Act [6]—entered into force on 2 August 2024 and establishes the world’s first comprehensive legislative framework for AI systems placed on the EU market or affecting persons within it. For organisations operating AI‑driven components within their cloud estates, the Act introduces obligations that sit squarely within the operational domain, not merely the product development domain. Understanding where operational AI systems fall within the Act’s classification structure, and what obligations follow from that classification, is now an architectural concern of the first order.

Classification of operational AI systems. The Act establishes four risk tiers. Prohibited AI practices represent an absolute ceiling [6, Art. 5]; no operational AI system in scope of this book approaches that category. Unacceptable and limited risk systems carry disclosure obligations but not the full management system requirements. High‑risk AI systems, defined in Annex III of the Act [6], are subject to the most demanding obligations, and it is here that many operational AI deployments will find themselves classified. Annex III includes AI systems used in the management and operation of critical infrastructure, specifically the management of road traffic, the supply of water, gas, heating and electricity [6, Annex III, para. 2]. By reasonable extension, supervisory authorities are likely to regard AI systems that make or recommend operational decisions affecting the continuity of critical business services—automated change execution, anomaly‑driven incident escalation, capacity rebalancing across sovereign zones—as falling within or proximate to this category. Organisations should take a conservative approach to classification and obtain legal advice specific to their deployments rather than assuming a general‑purpose operational agent sits outside high‑risk scope.

Transparency and logging requirements (Article 13). For high‑risk AI systems, the Act requires that the system be designed and developed in such a way as to ensure that its operation is sufficiently transparent that deployers can interpret the system’s output and use it appropriately [6, Art. 13(1)]. This transparency obligation extends to the information that must accompany a high‑risk system: its intended purpose, the level of accuracy and robustness on which it has been validated, any known or foreseeable circumstances that may lead to risks, and, critically, a description of the data on which the system has been trained [6, Art. 13(3)]. In the operational AI context, this translates into a requirement that every agent action recommendation be traceable to a specific model version, a defined intent, and a documented confidence profile. The “sovereign AI record” concept developed in this book—the persistent, immutable log of AI‑assisted operational decisions—is the architectural mechanism for satisfying Article 13 in practice.

Human oversight obligations (Article 14). Article 14 of the Act mandates that high‑risk AI systems be designed and developed in such a way, including with appropriate human–machine interface tools, that they can be effectively overseen by natural persons during the period in which the AI system is in use [6, Art. 14(1)]. The human oversight obligation is not merely procedural; it requires that the system itself be designed so that a human can fully understand its capabilities and limitations, monitor its operation for anomalies, and intervene, halt, or override the system’s output when necessary [6, Art. 14(4)]. For agentic operations architectures, this is a design constraint, not a policy aspiration. The approval gate patterns, confidence thresholds, and human‑in‑the‑loop escalation paths that characterise well‑designed Orchestrate agent workflows are not optional niceties; under Article 14, they are legally mandated features for high‑risk deployments. Any operational AI system designed to execute changes autonomously without a meaningful opportunity for human interception will face legal challenge if it touches critical infrastructure.

Risk management system requirements (Article 9). Providers of high‑risk AI systems must establish, implement, document and maintain a risk management system for the life of the AI system [6, Art. 9(1)]. This system must be an iterative process that runs throughout the entire life cycle of a high‑risk AI system, updated and revised continuously as new risks emerge from operational experience. It must include identification and analysis of known and foreseeable risks, estimation and evaluation of risks, and the adoption of risk management measures [6, Art. 9(2)]. For operational AI—systems whose risk profile may change as the infrastructure they manage changes, as new threat actors emerge, or as the model drifts from its original training distribution—this is a demanding obligation. It requires that model performance metrics, override rates, and incident attributions be tracked systematically over time, and that the results feed into a documented review and update cycle. Watsonx.governance provides exactly this instrumentation: model lineage, drift detection, fairness metrics, and policy enforcement can all be tied to a structured risk management programme that satisfies Article 9’s iterative requirement.

Implications for watsonx.governance and the sovereign AI record. Taking Articles 9, 13 and 14 together, the architectural implication for sovereign operations is clear: every AI‑assisted operational decision must be anchored to a governed artefact—a registered model with documented lineage, training data provenance, validation results and a current risk assessment—and every invocation of that model in an operational context must be logged in a form that supports post‑hoc review by a human, an auditor, or a supervisory authority. The sovereign AI record is not an optional feature of a mature AI operations programme; it is the operational evidence base required by the Act. Watsonx.governance provides the platform for maintaining this record. The agentic architecture described in subsequent chapters provides the integration points that ensure the record is populated automatically, without requiring individual teams to maintain it manually. The combination of governed AI tooling and governed operational workflows is, in this sense, the technical answer to the EU AI Act’s most demanding operational requirements.

Key Takeaways

Regulation has shifted from demanding static compliance artefacts to demanding continuous, demonstrable operational control. Architecture, not documentation, is now the primary compliance instrument.
DORA’s five ICT risk management pillars—framework, incident management, resilience testing, third‑party risk, and information sharing—collectively require that financial entities maintain a live, queryable understanding of their operational estate and its dependencies. Static diagrams and annual workshops are structurally insufficient.
NIS2’s expanded scope, ten mandatory security measures, and 24‑hour early warning requirement mean that security operations and IT operations can no longer function as separate disciplines with separate tooling. A shared operational picture is a regulatory expectation, not merely a best practice.
GDPR Article 32 applies to operational data flows—logs, metrics, traces—with the same force it applies to primary application data. Observability architectures must be designed with data residency and access governance in mind from the outset.
The EU AI Act classifies AI systems used in critical infrastructure operations as likely high‑risk, triggering binding obligations for transparency (Art. 13), human oversight (Art. 14), and iterative risk management (Art. 9). These are design constraints that must be reflected in the agentic operations architecture.
ISO/IEC 27001:2022, ISO 22301:2019, the NIST Cybersecurity Framework 2.0 and the ENISA Threat Landscape series provide the technical risk management vocabulary that translates legislative obligations into implementable controls and independently auditable management systems.
Healthcare frameworks — HIPAA, EU MDR, FDA 21 CFR Part 11 and France HDS — extend regulatory scrutiny to operational telemetry (ePHI in logs), AI governance (model access to patient data) and sovereign hosting certification. Observability pipelines in healthcare environments must implement ePHI scrubbing and zone-scoped retention by default.
Manufacturing and cyber-physical system regulations — the EU Cyber Resilience Act, IEC 62443 and the EU Machinery Regulation — embed cybersecurity and supply chain security into product compliance. CI/CD pipelines must generate SBOMs as first-class artefacts, and OT/IT convergence monitoring must extend observability into industrial control networks.
Sustainability reporting obligations under the CSRD, ISSB standards and SEC climate rules require that data centre energy consumption, carbon emissions and resource efficiency data be collected with the same auditability as financial data. Operational telemetry is the source of truth for ESG reporting.
Cross-cutting frameworks — eIDAS 2.0, the EU Data Act, PCI DSS v4.0, SOX, PSD2 and MiCA — collectively reinforce that operational architecture is the convergence point for compliance. Identity federation, data portability, payment monitoring, financial controls and digital asset resilience all depend on the same governed automation, immutable audit trails and zone-scoped data handling that the sovereign operations model provides.
The practical path through regulatory complexity is not to optimise for every clause but to derive a set of stable operational design criteria — continuous topology visibility, governed automation, sovereign telemetry, bounded and explainable AI, supply chain integrity and auditable sustainability data — that, if genuinely met, make compliance a by‑product of good operational architecture.

Bridge to Chapter 4 — Architecture Reference Model

This chapter has traced the arc from compliance as a periodic project to compliance as a continuous operational property, examining the obligations that DORA, NIS2, GDPR, the EU AI Act, supervisory guidance from the EBA, FCA and PRA, and a broad sweep of sector-specific and cross-cutting frameworks — from HIPAA and the EU Medical Device Regulation in healthcare, through the Cyber Resilience Act and IEC 62443 in manufacturing, to the CSRD and ISSB standards in sustainability reporting, and FedRAMP and EUCS in government — now impose on organisations operating across regulated and critical sectors. The central argument is that these obligations, despite their diversity of origin and vocabulary, cannot be satisfied by policies, attestations or point-in-time assessments alone. They require architectures that make continuous visibility, controlled automation, sovereign data handling, supply chain integrity, sustainability evidence collection and governed AI the default way the organisation operates — not an additional layer applied in response to audit findings.

The design criteria derived from this regulatory survey — live dependency mapping, tested impact tolerance, governed change execution, sovereign observability, bounded and explainable operational AI, supply chain traceability, auditable sustainability telemetry and an immutable audit record — are not abstract desiderata. They are the translation of regulatory text into architectural requirements that an operations platform must satisfy. Chapter 4 takes these criteria as its starting point, proposing a reference model organised around four operational planes — observability, automation and orchestration, agentic intelligence, and governance and audit — and showing how the components of IBM’s sovereign stack instantiate each plane in a way that is coherent, auditable, and designed to evolve alongside both the regulatory landscape and the operational estate it governs.

References

[1] European Parliament and Council of the European Union, “Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector and amending Regulations (EC) No 1060/2009, (EU) No 648/2012, (EU) No 600/2014, (EU) No 909/2014 and (EU) 2016/1011,” Official Journal of the European Union, vol. L 333, pp. 1–79, Dec. 2022. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554

[2] European Parliament and Council of the European Union, “Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS2 Directive),” Official Journal of the European Union, vol. L 333, pp. 80–152, Dec. 2022. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2555

[3] International Organization for Standardization and International Electrotechnical Commission, “ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements,” ISO/IEC, Geneva, Switzerland, Oct. 2022. [Online]. Available: https://www.iso.org/standard/27001

[4] International Organization for Standardization, “ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements,” ISO, Geneva, Switzerland, Oct. 2019. [Online]. Available: https://www.iso.org/standard/75106.html

[5] European Parliament and Council of the European Union, “Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation),” Official Journal of the European Union, vol. L 119, pp. 1–88, Apr. 2016. [Art. 32: “Security of processing.”] [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679

[6] European Parliament and Council of the European Union, “Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence and amending Regulations (EC) No 300/2008, (EU) No 167/2013, (EU) No 168/2013, (EU) 2018/858, (EU) 2018/1139 and (EU) 2019/2144 and Directives 2014/90/EU, (EU) 2016/797 and (EU) 2020/667 (Artificial Intelligence Act),” Official Journal of the European Union, vol. L 2024/1689, Jun. 2024. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689

[7] European Banking Authority, “EBA Guidelines on ICT and Security Risk Management,” EBA/GL/2019/04, European Banking Authority, Paris, France, Nov. 2019. [Online]. Available: https://www.eba.europa.eu/regulation-and-policy/internal-governance/guidelines-on-ict-and-security-risk-management

[8] Financial Conduct Authority, “Building operational resilience: impact tolerances for important business services — Policy Statement PS21/3,” Financial Conduct Authority, London, UK, Mar. 2021. [Online]. Available: https://www.fca.org.uk/publications/policy-statements/ps21-3-building-operational-resilience

[9] Prudential Regulation Authority, “Supervisory Statement SS2/21 — Operational Resilience: Impact tolerances for important business services,” Bank of England, London, UK, Mar. 2021. [Online]. Available: https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/operational-resilience-ss

[10] National Institute of Standards and Technology, “The NIST Cybersecurity Framework (CSF) 2.0,” NIST, Gaithersburg, MD, USA, Feb. 2024. [Online]. Available: https://doi.org/10.6028/NIST.CSWP.29

[11] European Union Agency for Cybersecurity (ENISA), “ENISA Threat Landscape 2024,” ENISA, Athens, Greece, 2024. [Online]. Available: https://www.enisa.europa.eu/topics/cyber-threats/enisa-threat-landscape

[12] U.S. Department of Health and Human Services, “Health Insurance Portability and Accountability Act of 1996 (HIPAA) — Security Rule,” 45 CFR Parts 160, 162 and 164, Feb. 2003. [Online]. Available: https://www.hhs.gov/hipaa/for-professionals/security/index.html

[13] U.S. Department of Health and Human Services, “HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information — Notice of Proposed Rulemaking,” 89 FR 101202, Dec. 2024.

[14] European Parliament and Council of the European Union, “Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC,” Official Journal of the European Union, vol. L 117, pp. 1–175, May 2017. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32017R0745

[15] U.S. Food and Drug Administration, “21 CFR Part 11 — Electronic Records; Electronic Signatures,” Code of Federal Regulations, Title 21, Part 11, Mar. 1997. [Online]. Available: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11

[16] Agence du Numérique en Santé (ANS), “Hébergeur de Données de Santé (HDS) — Référentiel de certification,” Ministère des Solidarités et de la Santé, Paris, France, 2018. [Online]. Available: https://esante.gouv.fr/produits-services/hds

[17] European Parliament and Council of the European Union, “Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) No 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act),” Official Journal of the European Union, vol. L 2024/2847, Nov. 2024. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847

[18] International Electrotechnical Commission, “IEC 62443 — Industrial communication networks — Network and system security,” IEC, Geneva, Switzerland, 2018–2024. [Series comprising IEC 62443-1-1 through IEC 62443-4-2.] [Online]. Available: https://www.iec.ch/cyber-security

[19] European Parliament and Council of the European Union, “Regulation (EU) 2023/1230 of the European Parliament and of the Council of 14 June 2023 on machinery and repealing Directive 2006/42/EC of the European Parliament and of the Council and Council Directive 73/361/EEC,” Official Journal of the European Union, vol. L 165, pp. 1–102, Jun. 2023. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32023R1230

[20] Transportation Security Administration, “Security Directives Pipeline-2021-01 (series) and SD 1580/82-2022-01 (rail),” U.S. Department of Homeland Security, Washington, DC, USA, 2021–2022.

[21] European Union Aviation Safety Agency, “Commission Implementing Regulation (EU) 2023/203 laying down rules for the application of Regulation (EU) 2018/1139 as regards information security risks (Part-IS),” Official Journal of the European Union, vol. L 31, Feb. 2023.

[22] International Maritime Organization, “Resolution MSC.428(98) — Maritime Cyber Risk Management in Safety Management Systems,” IMO, London, UK, Jun. 2017.

[23] European Parliament and Council of the European Union, “Directive (EU) 2016/681 of the European Parliament and of the Council of 27 April 2016 on the use of passenger name record (PNR) data for the prevention, detection, investigation and prosecution of terrorist offences and serious crime,” Official Journal of the European Union, vol. L 119, pp. 132–149, Apr. 2016. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016L0681

[24] European Parliament and Council of the European Union, “Directive (EU) 2022/2464 of the European Parliament and of the Council of 14 December 2022 amending Regulation (EU) No 537/2014, Directive 2004/109/EC, Directive 2006/43/EC and Directive 2013/34/EU, as regards corporate sustainability reporting,” Official Journal of the European Union, vol. L 322, pp. 15–80, Dec. 2022. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2464

[25] European Parliament and Council of the European Union, “Regulation (EU) 2020/852 of the European Parliament and of the Council of 18 June 2020 on the establishment of a framework to facilitate sustainable investment, and amending Regulation (EU) 2019/2088 (Taxonomy Regulation),” Official Journal of the European Union, vol. L 198, pp. 13–43, Jun. 2020. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32020R0852

[26] International Sustainability Standards Board, “IFRS S1 — General Requirements for Disclosure of Sustainability-related Financial Information” and “IFRS S2 — Climate-related Disclosures,” IFRS Foundation, London, UK, Jun. 2023. [Online]. Available: https://www.ifrs.org/issued-standards/ifrs-sustainability-standards-navigator/

[27] U.S. Securities and Exchange Commission, “The Enhancement and Standardization of Climate-Related Disclosures for Investors — Final Rule,” 17 CFR 210, 229, 230, 232, 239, and 249, Release Nos. 33-11275; 34-99678, Mar. 2024.

[28] European Parliament and Council of the European Union, “Directive (EU) 2018/1972 of the European Parliament and of the Council of 11 December 2018 establishing the European Electronic Communications Code,” Official Journal of the European Union, vol. L 321, pp. 36–214, Dec. 2018. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32018L1972

[29] United Kingdom Parliament, “Telecommunications (Security) Act 2021,” c. 31, London, UK, Nov. 2021. [Online]. Available: https://www.legislation.gov.uk/ukpga/2021/31

[30] Federal Risk and Authorization Management Program (FedRAMP), “FedRAMP Authorization Process,” General Services Administration, Washington, DC, USA, 2024. [Online]. Available: https://www.fedramp.gov

[31] National Institute of Standards and Technology, “NIST Special Publication 800-53 Revision 5 — Security and Privacy Controls for Information Systems and Organizations,” NIST, Gaithersburg, MD, USA, Sep. 2020 (updated Dec. 2024). [Online]. Available: https://doi.org/10.6028/NIST.SP.800-53r5

[32] European Union Agency for Cybersecurity (ENISA), “European Union Cloud Services Certification Scheme (EUCS) — Candidate Scheme,” ENISA, Athens, Greece, 2024. [Online]. Available: https://www.enisa.europa.eu/topics/certification/enisa-candidate-schemes/cloud-services

[33] Russian Federation, “Federal Law No. 242-FZ on Amending Certain Legislative Acts of the Russian Federation in as Much as it Concerns Updating the Procedure for Personal Data Processing in Information and Telecommunications Networks,” Jul. 2014.

[34] Standing Committee of the National People’s Congress, “Personal Information Protection Law of the People’s Republic of China (PIPL),” Aug. 2021; “Data Security Law of the People’s Republic of China,” Jun. 2021.

[35] Parliament of India, “Digital Personal Data Protection Act, 2023,” Act No. 22 of 2023, New Delhi, India, Aug. 2023.

[36] International Organization for Standardization and International Electrotechnical Commission, “ISO/IEC 15408:2022 — Information security, cybersecurity and privacy protection — Evaluation criteria for IT security (Common Criteria),” ISO/IEC, Geneva, Switzerland, 2022. [Online]. Available: https://www.iso.org/standard/72891.html

[37] European Parliament and Council of the European Union, “Regulation (EU) 2024/1183 of the European Parliament and of the Council of 11 April 2024 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework,” Official Journal of the European Union, vol. L 2024/1183, Apr. 2024. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1183

[38] European Parliament and Council of the European Union, “Regulation (EU) 2023/2854 of the European Parliament and of the Council of 13 December 2023 on harmonised rules on fair access to and use of data and amending Regulation (EU) 2017/2394 and Directive (EU) 2020/1828 (Data Act),” Official Journal of the European Union, vol. L 2023/2854, Dec. 2023. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32023R2854

[39] PCI Security Standards Council, “Payment Card Industry Data Security Standard (PCI DSS) Version 4.0,” PCI SSC, Wakefield, MA, USA, Mar. 2022 (effective Mar. 2024). [Online]. Available: https://www.pcisecuritystandards.org/document_library/

[40] U.S. Congress, “Sarbanes-Oxley Act of 2002,” Pub. L. 107-204, 116 Stat. 745, Jul. 2002. [Section 404: Management Assessment of Internal Controls.]

[41] European Parliament and Council of the European Union, “Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) No 1093/2010, and repealing Directive 2007/64/EC (PSD2),” Official Journal of the European Union, vol. L 337, pp. 35–127, Dec. 2015. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015L2366

[42] European Parliament and Council of the European Union, “Regulation (EU) 2023/1114 of the European Parliament and of the Council of 31 May 2023 on markets in crypto-assets, and amending Regulations (EU) No 1093/2010 and (EU) No 1095/2010 and Directives 2013/36/EU and (EU) 2019/1937 (MiCA),” Official Journal of the European Union, vol. L 150, pp. 40–205, Jun. 2023. [Online]. Available: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32023R1114