Datadog's UK Data Residency Options

Datadog has historically operated two primary site regions: the US site and the EU1 site, with EU1 storing data in Frankfurt. For many UK organisations with data-governance requirements, Frankfurt has been the default option — it keeps data within the EU, which satisfies a large proportion of UK GDPR and sector-specific data-handling requirements.

Datadog has been actively expanding its data residency options to include UK-based storage, a development that matters most to organisations with explicit UK data residency mandates — notably in regulated financial services, healthcare, and parts of the public sector where data cannot leave UK jurisdiction even for an EU destination.

The practical implication for a business evaluating Datadog: the data residency question is now answerable in a way it was not always a straightforward conversation two or three years ago. But the answer depends on which Datadog site you are configured on, and whether that configuration is being actively managed to reflect your data-governance requirements. A default deployment, without considered configuration, may not land your data where it needs to be.

This is one area where working with a UK Datadog managed service partner makes a concrete difference. Configuring Datadog's site and data pipeline correctly for residency requirements is not the sort of thing that gets revisited once the platform is live — it gets established at deployment and maintained from there. Getting it right from the start is significantly easier than remediating it later.

DORA and UK Operational Resilience — Understanding the Jurisdictional Picture

The Digital Operational Resilience Act (DORA) is an EU regulation that came into full effect in January 2025. It applies to financial entities operating within the EU — banks, insurers, investment firms, payment providers, and their critical ICT third-party service providers. If your business operates EU-regulated entities, or if you provide ICT services to EU financial institutions, DORA is likely in scope for you.

UK firms operating solely under UK regulation are not directly subject to DORA. The UK has its own operational resilience framework, developed by the FCA and PRA, which requires regulated firms to identify important business services, set impact tolerances, and demonstrate that they can stay within those tolerances for a sustained period of disruption. The UK framework pre-dates DORA and covers broadly similar ground — identification of critical services, structured incident management, recovery testing, and documented operational controls.

What this means practically: if you are a UK financial services firm with EU operations or EU institutional clients, you may have DORA obligations running in parallel with your FCA/PRA requirements. If you are UK-only, DORA does not apply directly, but the FCA/PRA operational resilience rules create very similar operational obligations. The documentation requirements, incident evidence standards, and third-party risk management expectations are substantively comparable.

The most common gap we see is not that firms lack monitoring — it is that the monitoring they have does not produce evidence in a form that a regulator or internal audit function can actually use.

For third-party ICT providers — including managed service providers and cloud platforms — DORA introduces specific obligations around ICT concentration risk and third-party oversight. Regulated firms must maintain registers of ICT third-party dependencies, conduct due diligence on providers, and have contractual rights of access and audit. As a Powered by Datadog accredited MSP, Critical Cloud supports customers' third-party risk management obligations: ISO 27001 certification, Cyber Essentials Plus, documented access controls, and the contractual transparency that DORA-adjacent due diligence requires.

NIS2 and UK NIS — Resilience for Operators of Essential Services

The EU's NIS2 Directive applies to EU-operating entities in sectors classified as essential or important — energy, transport, financial infrastructure, healthcare, digital infrastructure, and others. Like DORA, NIS2 is an EU instrument and does not apply directly to UK-only businesses.

The UK has its own equivalent: the UK NIS Regulations (2018), covering operators of essential services and relevant digital service providers in Great Britain and Northern Ireland. The UK government has been strengthening this framework, and the direction of travel is toward more explicit resilience requirements, incident reporting obligations, and supply-chain security expectations — broadly consistent with NIS2 but through domestic legislation.

For UK businesses in transport, digital infrastructure, healthcare, and financial market infrastructure, the UK NIS Regulations already impose incident reporting requirements and an expectation of appropriate and proportionate security measures. In practice that means the ability to detect incidents quickly, document them accurately, and report to the competent authority within the required timeframe.

What These Frameworks Require from Your Observability Stack

Both the FCA/PRA operational resilience framework and the NIS/NIS2 family of requirements converge on a similar set of operational expectations, even if the specific wording differs by regime. From an observability and log management perspective, regulated firms need to be able to demonstrate:

  • Incident detection and response times. Regulators want to see that you can detect a disruption promptly and respond within defined parameters. Alert quality matters — an environment where alerts are noisy and engineers ignore dashboards does not produce the detection times a regulator expects.
  • Structured incident records. Every significant incident needs a documented timeline: when it was detected, when engineers engaged, what was investigated, what corrective actions were taken, and when service was restored. Post-incident reviews for high-severity events are increasingly expected, not optional.
  • Log retention and integrity. Audit logs — access events, change records, security signals — must be retained for defined periods and must be tamper-evident. Where data residency requirements apply, those logs must be stored in the correct jurisdiction. Datadog's log retention and archive features support this; they need to be configured and maintained correctly.
  • Continuous improvement evidence. The FCA/PRA framework explicitly expects firms to demonstrate that they are improving resilience over time, not just maintaining a static posture. A managed improvement programme — working through reliability, security, and governance backlogs — generates exactly this kind of evidence.

How a Managed Datadog Deployment Helps

The gap between "we have Datadog configured" and "we have Datadog configured in a way that supports our regulatory obligations" is wider than most firms realise when they first deploy the platform. Alert quality degrades without active maintenance. Log pipelines accumulate technical debt. Retention policies are set once and then forgotten. Incident records exist in Slack threads rather than structured management systems.

What a managed Datadog service provides is ongoing operational discipline. At Critical Cloud, every customer environment is managed through Datadog — not just monitored, but actively operated. Incident management uses Datadog's structured incident workflow, producing the timestamped records and post-incident reviews that regulatory evidence requirements ask for. Log pipelines are configured and maintained with retention and residency requirements in mind from the start. Monthly improvement engineering works through reliability, security, and governance improvements that regulators expect to see evidenced over time.

For firms with DORA or FCA/PRA obligations, we support the third-party risk management process directly. Our ISO 27001 certification and Cyber Essentials Plus provide the external assurance regulated firms need when adding a managed service provider to their ICT third-party register, with documented access controls and the contractual transparency that DORA-style due diligence requires.

The Practical Starting Point

If you are a regulated UK business evaluating whether your current Datadog deployment is fit for your regulatory obligations, the most useful starting point is an honest assessment of what you have. Our HealthScan service provides an independent read-only review of your Datadog environment: alert coverage, log configuration, retention policies, signal quality, and cost. For regulated businesses, we include a specific review of whether the configuration supports the kind of incident evidence and audit trail that operational resilience frameworks ask for.

If you are starting from scratch — evaluating Datadog as part of a compliance programme or building out observability ahead of a regulatory examination — the configuration decisions made at deployment determine how much remediation work you face later. Working with a managed Datadog partner that understands UK regulatory context from the start is substantially less expensive than fixing a deployment that was built without it in mind.

The regulatory landscape for UK tech businesses is not getting simpler. DORA's reach, the strengthening of UK NIS, and the FCA/PRA's increasingly explicit expectations around operational resilience mean that observability is no longer just an engineering concern. It is a compliance asset — or a compliance liability, depending on how it is managed.