NIS2, DORA, CISA, SAMA: Why Zero Trust Became the Security Standard Regulators Agree On

Why global regulations converge on Zero Trust Architecture

The convergence is striking precisely because it was not coordinated. European, American, Middle Eastern, and Asia‑Pacific regulators worked independently, responding to local risk environments and sector priorities. Despite this, they arrived at the same technical requirements.

Across frameworks, the emphasis consistently falls on:

• Identity‑centric access control
• Continuous monitoring and verification
• Network segmentation and containment
• Encryption and cryptographic protection
• Incident detection, response, and recovery
• Supply chain and third‑party risk management
• Data protection by design

These are not product requirements. They are architectural ones.

The shared architectural requirements behind major regulations

NIS2 and systemic cyber resilience

NIS2 applies to essential and important entities across the European Union. Article 21 mandates a set of minimum cybersecurity risk management measures, including risk analysis, incident handling, business continuity, supply chain security, vulnerability management, cryptography, access control, and continuous or multi‑factor authentication.

While expressed in regulatory language, these requirements assume an architecture capable of enforcing least privilege, segmenting systems, continuously monitoring activity, and containing incidents when compromise occurs. This is the operating model Zero Trust Architecture was designed to support.

DORA and continuous operational resilience

DORA establishes a comprehensive digital operational resilience framework for the financial sector. It requires continuous ICT risk monitoring, anomaly detection, incident classification and reporting, business continuity testing, and third‑party ICT oversight.

To meet these obligations, financial entities must map their ICT environments, monitor access and system behaviour continuously, and maintain tested containment and recovery mechanisms. These expectations align directly with Zero Trust principles around continuous verification, segmentation, and observability.

GDPR and data protection by design

GDPR’s principle of data protection by design and by default requires that technical controls are embedded into systems from the outset. Access limitation, encryption, and auditable data access are not optional enhancements. They are assumed foundations.

Zero Trust Architecture directly supports these requirements by enforcing identity‑based access decisions and producing comprehensive audit trails for every data interaction. Data minimisation and pseudonymisation decisions sit above this architectural layer, but the architecture itself is what makes those decisions enforceable and observable.

The EU AI Act and emerging trust boundaries

With high‑risk AI obligations taking effect from August 2026, the EU AI Act introduces explicit requirements for risk management systems, data governance, human oversight, and transparency in AI deployments.

Organizations deploying AI in regulated contexts must now extend trust boundaries to AI systems themselves. This requires architectural controls that govern identity, access, data flows, and monitoring across AI workflows. Once again, Zero Trust provides the structural model regulators implicitly assume.

Beyond Europe: the same pattern worldwide

The alignment does not stop at the EU’s borders.

In the United States, federal agencies are mandated to adopt Zero Trust Architecture aligned with CISA’s Zero Trust Maturity Model, spanning identity, devices, networks, applications, and data. This is one of the few cases where Zero Trust is named explicitly in a regulatory mandate and tied to a maturity framework.

In the Gulf region, enforcement‑backed requirements are equally explicit. Saudi Arabia’s National Cybersecurity Authority and SAMA require financial institutions to demonstrate identity‑centric access controls and segmentation. In the UAE, updated cybersecurity regulations mandate Zero Trust access controls for entities handling personal data, with significant financial penalties for non‑compliance.

The United Kingdom’s Cyber Security and Resilience Bill aligns closely with NIS2. Across Asia‑Pacific, countries including Singapore, Australia, India, Malaysia, and Vietnam are strengthening cybersecurity requirements around continuous verification, least privilege, monitoring, and incident detection.

Independent regulators, across four continents, have converged on the same architectural model.

One architecture instead of parallel compliance programs

Faced with overlapping regulations, many organizations default to parallel compliance programs. Separate gap analyses. Separate control mappings. Separate evidence collection exercises.

This approach is expensive, slow, and fragile.

Zero Trust Architecture offers an alternative. A single architectural foundation can satisfy the technical expectations of multiple regulatory frameworks simultaneously.

One identity governance model supports NIS2 authentication requirements, DORA access control mandates, and GDPR data access accountability. One segmentation strategy meets NIS2 network security expectations and DORA containment requirements. One monitoring and detection capability feeds incident reporting across all applicable regulations.

The overlooked benefit: compliance evidence by design

A mature Zero Trust Architecture produces much of the technical evidence regulators require as a byproduct of normal operation.

Access logs with identity context. Authentication events tied to device posture. Segmentation enforcement records. Incident detection timestamps with full audit trails. Data access decisions recorded at every request.

These are not special reports assembled for auditors. They are the natural output of an architecture built on continuous verification and monitoring.

Organizations with mature Zero Trust implementations consistently spend less time assembling technical compliance evidence because the data already exists. It simply needs to be mapped to the relevant regulatory framework.

Architecture and governance are not interchangeable

Zero Trust Architecture does not replace governance obligations.

Board‑level accountability under NIS2 and DORA, management training, business continuity planning, third‑party contractual clauses, GDPR data subject rights processes, and data minimisation decisions all sit above the architectural layer.

Both are necessary. But while governance requirements vary by jurisdiction, the architectural layer can be designed once to support them all.

Regulators did not set out to standardise on Zero Trust. They responded to the same reality: identity‑driven attacks, lateral movement, supply chain exposure, and the collapse of perimeter assumptions. The result is clear. Different regulations. Different enforcement models. One architectural foundation.

Zero Trust has become the security standard regulators agree on because it reflects how modern systems fail, and how resilient systems must be designed.

Learn how Atos views the architectural foundations behind global cybersecurity regulation.