Enforcements such as NIS2 are no longer a future planning consideration. The European Union Agency for Cybersecurity's (ENISA) NIS360 report confirms that supervisory authorities are actively assessing cybersecurity maturity across critical sectors. The agency is moving from guidance and consultation into active oversight, scrutiny, and accountability. This is the regulatory environment European enterprises now operate in.

Multi-tenant cloud platforms remove operational overhead but place source code and pipelines on shared infrastructure regulators now scrutinize. Self-managed solutions provide isolation but transfer responsibility for upgrade cycles, security patches, and disaster recovery (DR) tests to an already stretched platform team. Both deployment options leave gaps in risk management, data sovereignty, and furnishing audit evidence.

In this article, you'll discover how GitLab Dedicated, a fully isolated, single-tenant SaaS solution deployed in your preferred Amazon Web Services (AWS) region and hosted and managed by GitLab, addresses these challenges and helps you keep pace with evolving compliance requirements.

"NatWest Group is adopting GitLab Dedicated SaaS to enable our engineers to use a common cloud engineering platform; delivering new customer and colleague outcomes rapidly, frequently, and securely with high quality, automated testing, on-demand infrastructure, and straight-through deployment."

— Adam Leggett, Platform Lead for Engineering Platforms, NatWest Group

Regulations are driving change

In the European Union, key regulations are driving the need for a different platform approach. These regulations converge on a decision most enterprises made before they existed: a platform their developers build on. That decision now carries audit consequences it didn't before.

1. Digital Operational Resilience Act (DORA), which came into force across EU financial services in January 2025, requires financial institutions to keep critical technology resilient, avoid over‑reliance on key providers, and strengthen incident reporting.
2. NIS2 Directive, adopted in December 2022, requires essential and important sectors to strengthen cybersecurity, secure technology supply chains, and rapidly report significant incidents to relevant authorities across the European Union.
3. General Data Protection Regulation (GDPR), applicable since May 2018, requires organizations to protect personal data, document where it is stored and who accesses it, and ensure a valid legal basis for every use.

On multi-tenant platforms, shared execution, runners, and storage mean a single CVE or misconfiguration can simultaneously expose multiple tenants. On self-managed deployments, risk concentrates internally: Secrets and credentials accumulate and aren’t regularly rotated, while manual, incident-driven changes cause drift from infrastructure-as-code baselines, obscuring the real attack surface from audits.

GitLab Dedicated codifies operations

Site reliability engineers (SREs) manage your GitLab Dedicated instance in an isolated AWS account without default direct access to customer environments. All operational changes use automated, approval-gated workflows via a defined control plane, not live system intervention. CI/CD variables and runner tokens can rotate on a cadence defined by you, reducing configuration drift and keeping the operational attack surface tightly controlled through codified processes.

Disaster recovery is built in by default for every GitLab Dedicated customer, with each Dedicated customer instance having a secondary region that maintains a backup. GitLab Geo provides asynchronous, continuous replication between the two sites. The deployment architecture aims to minimize the impact of regional cloud failures and maintain business continuity for our customers. GitLab Dedicated provides disaster recovery with these recovery objectives:

• Recovery Time Objective (RTO): Service is restored to your secondary region in eight hours or less.
• Recovery Point Objective (RPO): Data loss is limited to a maximum of four hours of the most recent changes, depending on when the disaster occurs relative to the last backup.

Data sovereignty and customer‑controlled security

Auditors need clarity for GDPR and data sovereignty: data location, access ownership, and whether runner traffic leaves approved regions. In multi-tenant platforms, the provider controls these and data may cross borders. In self-managed deployments, you have to define storage policies, key management, and network routing to keep everything within your chosen region.

GitLab Dedicated brings isolation with control

Region selection at provisioning pins object storage, artifacts, and compute data to your chosen AWS region. You also select a secondary failover region, so the only cross-region movement is the replication you explicitly enable between those two regions. Customers in the European Union can keep both regions in-jurisdiction. GitLab manages failover against defined Recovery Time Objective and Recovery Point Objective targets.

Bring-your-own-key (BYOK) provisions customer managed keys so GitLab cannot access encrypted data if you revoke the key. AWS PrivateLink creates a VPC endpoint in your account; traffic between your network, CI/CD jobs, and GitLab Dedicated stays on AWS’s private backbone.

One constraint applies across all major cloud providers and cannot be resolved at the infrastructure layer: As a U.S. corporation, Amazon Web Services remains subject to U.S. legal obligations, including the Clarifying Lawful Overseas Use of Data (CLOUD) Act, which can compel data disclosure regardless of where servers are physically located.

BYOK addresses the GitLab-layer exposure as GitLab holds no keys and cannot decrypt your data. But this does not alter AWS's obligations under U.S. law. Organizations with strict jurisdictional requirements should address the residual exposure through legal and contractual mechanisms: data processing agreements, transfer impact assessments, and documented legal basis for transfers alongside infrastructure controls.

Audit evidence gaps

On multi-tenant SaaS, logs and incident records live in shared infrastructure, so auditors need the provider’s help to extract tenant-specific evidence. For self-managed deployments, the primary audit risk is CVE exposure caused by upgrade delays. Falling behind on releases leaves known vulnerabilities in the environment where source code resides, which is more difficult to justify to auditors than straightforward capacity constraints.

GitLab streamlines compliance

GitLab Dedicated SREs keep your instance up to date on a pre-defined monthly upgrade cadence without a ticket in your platform team's backlog. Your instance runs the N-1 minor release and receives one minor and two patch releases each month inside a fixed weekly maintenance window, with emergency maintenance outside that window for S1 security issues.

Through the GitLab Trust Center self-service portal, you can access the latest GitLab Dedicated compliance documentation and assurance artifacts. For example, the latest DORA audit report by Schellman. With the out-of-the-box audit reports and centrally maintained evidence, your compliance and security teams no longer need to piece together years of self-managed configuration history or extract data from shared records for each regulatory submission or annual review. This builds a repeatable path to audit readiness with minimal operational overhead.

Check out this click-through demo to see how GitLab simplifies the management and operation of your Dedicated instance.

Moving to GitLab Dedicated

When you consider a move to GitLab Dedicated, you get more choice and more control delivered with a secure, compliant single-tenant SaaS. Infrastructure patching, availability evidence, and DR testing move into GitLab's audit scope, so your team documents and evidences the application layer rather than rebuilding infrastructure evidence for every submission.

Book a demo today to learn how GitLab Dedicated can meet your security and compliance needs.