Cloud Region Governance for GDPR, NIS2 and DORA

At 08:17 on a Tuesday morning, Maria, the CISO of a fast-growing European fintech, receives the message every regulated cloud customer eventually fears.

The procurement team forwards a short supplier notice:

“Our cloud analytics provider is moving EU customer telemetry to a new region for performance reasons. They say there is no security impact. Can we approve?”

Before Maria can respond, a second notification arrives from the primary cloud service provider. Effective in 90 days, the provider will “optimize its global support model” by routing Tier 2 support tickets through a new subprocessor. A quick review shows that the subprocessor is headquartered in a country without a GDPR adequacy decision.

By 09:00, legal, privacy, resilience, procurement, cloud engineering and finance compliance have joined the thread. The DPO asks whether a Transfer Impact Assessment is needed. The resilience manager asks whether the new region affects the recovery plan for a critical service. The finance compliance lead asks whether the provider appears in the DORA ICT third-party register. The cloud team checks the production data plane and realizes the issue is broader than analytics. Backups, operational logs, support tickets, data lake exports, break-glass access and subcontractor access may all be in scope.

This is the real 2026 cloud governance problem.

Most organizations have a cloud policy. Many have a supplier register. Some have a GDPR transfer assessment. Fewer can answer, with evidence, the harder audit question:

Where exactly does regulated data and critical ICT processing reside, who can access it from where, what happens during failover, and what contractual control prevents the provider from changing the answer without approval?

That is cloud region governance. It is not a single legal checkbox. It is a living control system across ISO/IEC 27001:2022, ISO/IEC 27002:2022 cloud and supplier controls, GDPR accountability, NIS2 service resilience and DORA ICT third-party oversight.

Data residency is now an operational control

For years, “EU-only hosting” was treated as a clause in a data processing agreement. That is no longer enough. A modern cloud data residency and region governance program must cover at least six operational layers:

1. Primary production storage and compute regions.
2. Backup, archive and disaster recovery regions.
3. Logging, monitoring, SIEM and observability data locations.
4. Support access, including remote administration and break-glass access.
5. Subprocessors and subcontractors, including managed services and marketplace components.
6. Data transfer paths between environments, APIs, analytics platforms and customer support tools.

GDPR makes this unavoidable because personal data can include online identifiers, IP addresses, customer account IDs, user records, device identifiers, operational metadata and support records. Processing is also defined broadly, including storage, access, use, disclosure, erasure and destruction. “We only send logs” is not a safe exception if those logs contain identifiers.

GDPR Article 5 also includes the accountability principle. Controllers must not only comply with the principles of lawfulness, fairness, transparency, purpose limitation, data minimisation, storage limitation, integrity and confidentiality. They must also be able to demonstrate compliance. Cloud region governance is one of the ways that demonstration becomes real.

NIS2 extends the issue from privacy into resilience. Under Article 21, essential and important entities must implement appropriate technical, operational and organizational measures to manage risks to network and information systems used for operations or service delivery. The listed measures include supply-chain security, business continuity, backup management, disaster recovery, crisis management, access control, asset management, encryption and assessment of effectiveness. If a cloud region decision affects the availability or recovery of a service in scope, it is not only a data protection matter. It is a resilience matter.

For financial entities, DORA raises the standard further. DORA applies from 17 January 2025 and establishes requirements for ICT risk management, incident reporting, digital operational resilience testing, ICT third-party risk management and contractual arrangements. Article 28 requires financial entities to manage ICT third-party risk as an integral part of the ICT risk management framework, maintain registers of contractual arrangements, assess concentration risk and plan exits for critical or important functions. Article 30 expects contractual clarity on service and data processing locations, audit and access rights, incident support, subcontracting, recovery, return and exit transition.

DORA acts as the sector-specific regime for financial entities, while NIS2 still matters across the wider supply chain, especially for cloud computing providers, data centre providers and managed service providers. A single unvetted subprocessor can therefore create a domino effect across financial resilience, supply-chain security and privacy obligations.

In simple terms, if a regulated business cannot govern where its cloud processing occurs, it cannot credibly govern ICT third-party risk.

Use ISO 27001 as the management system anchor

ISO/IEC 27001:2022 provides the structure for turning residency confusion into a controlled management system.

Clauses 4.1 to 4.4 require the organization to define the ISMS in context, including internal and external issues, interested-party requirements, legal, regulatory and contractual obligations, interfaces and dependencies with other organizations. For cloud region governance, the ISMS scope should explicitly include cloud services, outsourced ICT processing, critical service dependencies and regulated data flows.

Clauses 5.1 to 5.3 make leadership accountable. Top management must align the information security policy and objectives with strategic direction, provide resources, assign responsibilities and ensure ISMS performance is reported. This is where cloud residency becomes a management and board topic, especially for NIS2 entities where management bodies must approve and oversee cybersecurity risk-management measures, and for DORA financial entities where the management body is responsible for ICT risk governance.

Clauses 6.1.1 to 6.1.3 provide the risk engine. The organization needs a repeatable risk assessment process, risk owners, impact and likelihood criteria, treatment options, selected controls, a Statement of Applicability and residual-risk acceptance. A cloud region change should not be approved through an informal email. It should trigger a risk assessment or change review when it affects regulated data, critical functions, suppliers or continuity assumptions.

Clause 8.1 turns planning into operational control. Processes must be implemented, controlled, documented, changed in a managed way and extended to externally provided products and services relevant to the ISMS. Clauses 8.2 and 8.3 require reassessment and treatment at planned intervals or when significant changes occur. Cloud region migration, backup replication, a new logging platform or a support subprocessor change are all candidates for reassessment.

The ISO/IEC 27002:2022 control set then provides the practical control family. The most relevant controls include:

• 5.9 Inventory of information and other associated assets.
• 5.14 Information transfer.
• 5.15 Access control.
• 5.19 Information security in supplier relationships.
• 5.20 Addressing information security within supplier agreements.
• 5.22 Monitoring, review and change management of supplier services.
• 5.23 Information security for use of cloud services.
• 5.29 Information security during disruption.
• 5.30 ICT readiness for business continuity.
• 5.31 Legal, statutory, regulatory and contractual requirements.
• 5.34 Privacy and protection of PII.
• 5.36 Compliance with policies, rules and standards for information security.
• 8.11 Data masking.
• 8.12 Data leakage prevention.
• 8.13 Information backup.
• 8.15 Logging.
• 8.16 Monitoring activities.
• 8.20 Networks security.
• 8.24 Use of cryptography.
• 8.25 Secure development life cycle.
• 8.27 Secure system architecture and engineering principles.
• 8.32 Change management.

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls treats ISO/IEC 27002:2022 control 5.23, Information security for use of cloud services, as a preventive control supporting confidentiality, integrity and availability, with operational capability in supplier relationship security and security domains across governance, ecosystem and protection. The guide links 5.23 to 5.19 supplier relationships, 5.14 information transfer, 5.9 asset inventory, 8.11 and 8.12 data masking and data leakage prevention, 8.20 network security and 8.25 secure development lifecycle.

A key observation from Zenith Controls is:

“Cloud service providers (CSPs) function as critical suppliers, and thus all controls regarding supplier selection, contracting, and risk management under 5.19 apply. However, 5.23 goes further by addressing cloud-specific risks, such as multi-tenancy, data location transparency, and shared responsibility models.”

That sentence captures the governance shift. A cloud provider is not just another supplier. It is often the place where regulated processing lives.

The hidden residency traps: backups, logs, support and subprocessors

Most data residency failures do not start with the production database. They begin with supporting systems that were never properly included in the data flow review.

Backups are the classic example. A SaaS platform may run in Frankfurt or Dublin, while automated backups replicate elsewhere for resilience or cost reasons. If the backup contains personal data, customer records, authentication logs or regulated transaction history, the backup region matters. Under NIS2 Article 21, backup management and disaster recovery are part of the security baseline. Under DORA, continuity of critical or important functions and tested exit strategies require knowledge of recovery locations and recovery dependencies.

Logs are another weak point. Security teams centralize telemetry into SIEM, observability and data lake services. Those logs may include IP addresses, user identifiers, administrator actions, payment metadata, failed authentication attempts, customer account IDs or support trace data. If logs move into a global monitoring service, the organization may have created a cross-border transfer without realizing it.

Clarysec’s Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME directly addresses supplier evidence:

“Contracts must require providers to retain logs for at least 12 months and provide access upon request”

This quote comes from section “Governance Requirements”, policy clause 5.5.1.3. For data residency governance, the same contract review should confirm where those logs are retained, who can access them and whether log evidence is available during an incident investigation or regulatory inquiry.

Support access is more subtle. A provider may host data in the EU, while support engineers outside the EU can access customer environments, database snapshots, diagnostic packages or ticket attachments. Whether this is acceptable depends on the data involved, transfer mechanism, role, contractual safeguards, access controls and logging. The architecture may be regional, while the human access model is global.

Subprocessors create the final blind spot. Your direct supplier may rely on cloud infrastructure, content delivery networks, managed databases, ticketing platforms, analytics services, offshore support teams or security vendors. DORA Article 29 requires assessment of subcontracting risks, third-country providers, data recovery constraints, data protection compliance and complex subcontracting chains. NIS2 Article 21 requires entities to consider the cybersecurity practices of direct suppliers and service providers. GDPR requires processors to manage subprocessors in a way that preserves the controller’s ability to comply.

Clarysec’s Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME makes this practical:

“Where suppliers are required to store data off-site, the company must obtain assurance regarding data protection, physical security, and the geographic storage location (e.g., EU-only hosting where required by GDPR).”

This is from section “Policy Implementation Requirements”, policy clause 6.2.4. The same policy also requires:

“Restrictions on further subcontracting without approval”

This quote comes from section “Governance Requirements”, policy clause 5.3.5. Together, these clauses turn residency into a supplier management workflow, not a procurement preference.

Turn policy into enforceable cloud region governance

Cloud region governance must be enforceable, reviewable and auditable.

For SMEs, the Cloud Usage Policy-sme Cloud Usage Policy - SME sets the baseline:

“Data residency and privacy practices comply with applicable legal requirements (e.g., GDPR)”

This is from section “Governance Requirements”, policy clause 5.2.3. The same policy requires cloud governance records to include:

“The country or region where data is stored”

This quote comes from section “Governance Requirements”, policy clause 5.3.4.

For larger organizations, the Cloud Usage Policy Cloud Usage Policy is more explicit about contractual enforcement:

“Data residency requirements must be enforced contractually (e.g., EU-only storage for GDPR-regulated data).”

This is from section “Policy Implementation Requirements”, policy clause 6.6.2. It also states:

“Cross-border data transfers must comply with GDPR Chapter V and, where applicable, DORA Article 28.”

This is from section “Policy Implementation Requirements”, policy clause 6.6.3.

The enterprise version also assigns attention to:

“Data residency and data ownership guarantees”

This quote comes from section “Roles and Responsibilities”, policy clause 4.5.1.2.

The Third party and supplier security policy Third party and supplier security policy adds the contracting layer by requiring:

“Data handling requirements, including storage location, access controls, and return or destruction clauses”

This quote comes from section “Governance Requirements”, policy clause 5.3.2.

Finally, the Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy identifies changes that should trigger compliance review, including:

“Changes to data transfer mechanisms, subprocessors, or cross-border data flows”

This is from section “Governance Requirements”, policy clause 5.3.1.1.

These documents should not operate as separate files. In a mature ISMS, they become one operating model: cloud inventory, data flow register, supplier register, contract matrix, risk assessment, transfer review, change approval and audit evidence pack.

Build a Cloud Region Governance Register

A practical register turns cloud residency from assumption into evidence. Start with one critical customer-facing service, especially one likely to be in scope for NIS2, DORA customer due diligence or GDPR scrutiny.

Now connect the register to implementation.

In Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, the Controls in Action phase, Step 23, focuses on organizational controls 5.19 to 5.37, including supplier agreements and cloud service governance. The Blueprint warns that supplier agreements must cover more than generic confidentiality:

“In many industries, supplier agreements also define data ownership and jurisdiction. Where is data processed? Who retains control? Are there transfer restrictions? Are there cloud-specific controls (like data segmentation, key ownership, or geographic limitations)? These elements aren’t just legal, they are operational security issues, especially in regulated sectors.”

The same phase and step addresses supplier change management:

“Most supplier relationships begin with good intentions. A thorough review, clear expectations, signed agreements (see 5.20), maybe even a security checklist. But what happens a year later, when the supplier proposes moving your data to a new cloud region?”

That is Maria’s Tuesday morning problem. The register gives the CISO a way to answer before approving the move.

The Zenith Blueprint also clarifies the governance meaning of cloud control 5.23:

“A misconfigured storage bucket, a publicly exposed dashboard, or excessive permissions in a cloud IAM setup, these aren’t cloud failures. They are failures of governance.”

In the Controls in Action phase, Step 22, the Blueprint addresses information transfer and states:

“If personal data is being transferred across borders, the method must comply with privacy and legal obligations, not just internal preferences.”

That line matters for cloud teams. Encryption, secure APIs and private connectivity are necessary, but they do not replace legal and regulatory transfer governance.

Run the first 90-minute evidence workshop

Do not begin by mapping the entire enterprise. Start with one critical service and run a focused workshop with cloud engineering, procurement, legal, privacy, resilience and security operations.

First, list every cloud or supplier component that stores, processes, transmits, backs up, monitors or supports the service. Include minor systems such as uptime monitoring, ticket attachments, error tracking, support screen-sharing tools and diagnostic exports.

Second, mark each data category. If the team says “metadata only”, challenge the assumption. Metadata can still be personal data or confidential customer data.

Third, verify the region from evidence. Use cloud console configuration, backup policies, SIEM tenancy settings, DPA exhibits, subprocessor lists, contractual terms, support access documentation and CSP audit reports. Do not rely only on sales assurances.

Fourth, flag gaps into the ISMS risk register. Examples include “backup replication region not contractually restricted”, “support access from third country lacks documented approval workflow”, “SIEM logs retained globally”, “subprocessor list does not identify hosting region”, or “DORA register does not distinguish critical or important function dependency”.

Fifth, decide treatment. Treatments may include contract amendment, region lock, customer notification, encryption with customer-managed keys, tokenization, log minimization, new supplier approval, exit strategy update or residual-risk acceptance by the risk owner.

Sixth, preserve evidence. Auditors will not only ask what you decided. They will ask how you know it was implemented.

Map one evidence set to ISO, GDPR, NIS2, DORA and NIST CSF 2.0

A strong cloud region governance program avoids duplicate compliance work. The same evidence can support multiple obligations if it is structured correctly.

NIST CSF 2.0 is useful as an integrating layer. Its GOVERN function aligns with legal, regulatory, contractual and privacy obligations, risk appetite, accountability, policies and oversight. Its GV.SC supply chain category maps well to DORA ICT third-party expectations, NIS2 supply-chain requirements and ISO supplier controls.

COBIT 2019 and an ISACA audit lens often test the same facts through governance objectives: ownership, decision rights, risk optimization, supplier performance, benefits realization and assurance. A COBIT-style reviewer may not begin with “which cloud region is configured?” They may begin with “who has authority to approve a region change, how is risk escalated, and how does management know cloud suppliers remain within tolerance?”

That is why the Clarysec model captures owners, approval points, contractual evidence and management reporting, not only technical settings.

Prepare for the auditor’s questions

Cloud region governance is a perfect example of how different auditors look at the same control from different angles.

An ISO/IEC 27001:2022 auditor will begin with scope, interested-party requirements, risk assessment and the Statement of Applicability. They will ask whether legal, regulatory and contractual requirements are identified, whether cloud and supplier controls are included, whether risks were assessed, whether controls are implemented and whether evidence is retained. They may sample one cloud service and ask for onboarding review, contractual clauses, region configuration, monitoring review and change approval.

A data protection authority or GDPR reviewer will focus on personal data. They will ask what personal data is processed, where it is stored, where it is accessed from, which processors and subprocessors are involved, whether transfer mechanisms are documented, whether a Transfer Impact Assessment is needed and whether appropriate technical and organizational measures are in place. Logs, support data and backups often receive attention because organizations underestimate them.

A NIS2 auditor or competent authority will focus on services in scope. They will look at management accountability under Article 20, risk-management measures under Article 21, continuity, backup management, disaster recovery, incident handling, supply-chain security, access control, asset management and assessment of effectiveness.

A DORA supervisor or internal audit team will look for ICT risk governance, management-body oversight, the register of information for ICT third-party arrangements, critical or important function mapping, concentration risk, subcontracting risk, data processing locations, audit rights, incident reporting support, continuity testing and exit plans. DORA is clear that outsourcing does not transfer accountability.

Zenith Controls helps security leaders prepare for these audit styles because it cross-references control relationships. For ISO/IEC 27002:2022 control 5.20, Addressing information security within supplier agreements, Zenith Controls ties it to 5.19 supplier relationships, 5.14 information transfer, 5.22 supplier monitoring, 5.11 return of assets and 5.36 compliance with policies, rules and standards. For control 5.22, Monitoring, review and change management of supplier services, it ties ongoing supplier oversight to 5.29 security during disruption, 8.8 management of technical vulnerabilities, 5.15 access control, 8.27 secure system architecture and engineering principles and 5.36 compliance.

That cross-control view matters because a region change is never just a region change. It may alter supplier risk, transfer risk, access risk, continuity risk, incident response evidence and contractual compliance.

Use this 2026 CISO checklist before approving a cloud change

Use this checklist before approving any new cloud region, cross-border processing path, backup location, logging platform, support model or critical ICT supplier change.

If the answer to any question is “we assume”, the control is not mature enough for regulated operations.

The remediation roadmap

The remediation path is practical when it is anchored in the ISMS.

1. Confirm that ISMS scope includes cloud services, critical ICT dependencies and regulated data processing.
2. Build the Cloud Region Governance Register for priority services.
3. Map each service to data categories, regions, backup locations, support access and subprocessors.
4. Review supplier agreements for storage location, transfer, audit, incident, subcontracting, return and destruction clauses.
5. Update the risk register for gaps, concentration risks and undocumented transfers.
6. Align the DORA ICT third-party register and NIS2 service dependency mapping where applicable.
7. Validate technical enforcement, including region locks, backup policies, logging settings, encryption, access controls and key management.
8. Prepare an audit evidence pack with screenshots, contracts, risk records, approvals, review minutes and test results.
9. Establish a change trigger for new regions, subprocessors, transfer mechanisms or critical supplier service changes.
10. Report cloud residency risk, exceptions and residual-risk decisions to management.

This is not theoretical compliance. It is the difference between a cloud estate that can survive audit scrutiny and one that depends on verbal assurances.

The business case: sovereignty, resilience and trust

Executives sometimes view data residency governance as a constraint on cloud agility. In practice, mature region governance improves agility because teams know the rules before they buy, build or migrate.

A product team can launch faster when approved regions are clear. Procurement can negotiate faster when mandatory clauses are already defined. Legal can assess transfers faster when data flows are documented. Security operations can investigate faster when log locations and access rights are known. The board can make risk decisions faster when concentration risk, continuity impact and residual-risk acceptance are visible.

For customers, especially regulated customers, this becomes a trust signal. A SaaS provider that can explain where data resides, how backups are governed, how support access is controlled, how subprocessors are approved and how region changes are reviewed will outperform a provider that only says “we use a leading cloud provider”.

In 2026, that distinction matters. NIS2 has brought cybersecurity governance to essential and important entities across the EU. DORA has made ICT third-party oversight a formal financial-sector discipline. GDPR accountability remains central. ISO/IEC 27001:2022 provides the management system that holds it together.

Next steps with Clarysec

If your organization cannot answer where regulated data and critical ICT processing reside across production, backups, logs, support access and subcontractors, now is the time to close the gap.

Clarysec can help you build a cloud region governance evidence pack using:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint for phased ISO implementation and audit readiness.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls for mapping ISO/IEC 27002:2022 cloud and supplier controls to operational evidence and cross-framework expectations.
• Cloud Usage Policy Cloud Usage Policy and Cloud Usage Policy-sme Cloud Usage Policy - SME for cloud data residency requirements.
• Third party and supplier security policy Third party and supplier security policy and Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME for supplier contracts, subcontracting and geographic storage assurance.
• Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME for log retention and provider evidence.
• Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy for compliance review triggers around transfer mechanisms, subprocessors and cross-border data flows.

Start with one critical service, one cloud provider and one register. Within a few workshops, you can move from assumptions to evidence, and from fragmented compliance to governed cloud resilience.

Download the Clarysec toolkit, request a demo or book a cloud region governance assessment to turn your cloud residency commitments into audit-ready proof.