GDPR-compliant DNS providers — a 2026 buyer's checklist

If you're an EU-based business, a public-sector buyer, or an operator under NIS2 or sectoral compliance frameworks, "GDPR-compliant DNS" is part of your procurement checklist. This page walks through what that actually means in 2026, what to ask vendors in the RFP stage, and which DNS providers structurally fit.

What "GDPR-compliant DNS" actually means

GDPR doesn't certify products. There's no "GDPR-compliant" stamp. What there is:

1. Personal data definitions. DNS query data — IP addresses, queried names, timestamps — can be personal data under GDPR (Article 4(1), confirmed by the CJEU in Breyer v. Germany, 2016).
2. Controller / processor obligations. If your DNS provider processes personal data on your behalf, they are a processor and you are a controller (Article 28). That triggers requirements: a written DPA, restricted processing, subprocessor controls, breach notification, audit rights, and so on.
3. Lawful transfer mechanisms. If the processor is outside the EU/EEA, you need a lawful basis for the transfer: EU–US Data Privacy Framework (if certified), Standard Contractual Clauses (SCCs) with a Transfer Impact Assessment (TIA), or Binding Corporate Rules.
4. Data minimisation, purpose limitation, retention limits, and right-of-access. Apply to whatever query metadata the provider stores.

A "GDPR-compliant" DNS provider, in the practical sense, is one that:

• Has a published, executable DPA with SCCs / DPF as appropriate.
• Has clear data-handling, retention, and subprocessor disclosures.
• Operates with personal data minimisation by default (no advertising-driven query log monetisation).
• Has incident-reporting commitments aligned with GDPR Article 33's 72-hour requirement.
• Either is structurally EU-jurisdiction (simpler audit story) or has a credible cross-border transfer regime (extra audit work).

The 12-question procurement checklist

Drop these directly into your RFP. Ask vendors for written answers — verbal commitments don't survive an audit.

1. Where is your company headquartered, and under which legal regime do you operate?
2. Where are your operations team and primary ops infrastructure located?
3. Where is authoritative zone data stored? Is it ever processed outside the EU/EEA?
4. Do you have a publicly available Data Processing Agreement we can execute? (Send me the link.)
5. What is the lawful basis for any transfer of personal data outside the EU/EEA? (DPF certification? SCCs? Adequacy?)
6. What query metadata do you store? For how long? Who can access it? Is it ever used for advertising or monetisation?
7. What is your subprocessor list, and how do you notify customers of changes?
8. What is your breach-notification SLA, and is it aligned with GDPR Article 33?
9. Do you have ISO 27001 / SOC 2 Type II / other relevant certifications? Provide the latest reports.
10. Are you in scope for NIS2, and what is your status against its incident-reporting obligations?
11. Can I exercise data-subject rights (access, deletion, portability) for personal data in your query logs?
12. Can I cancel and have all my zone data and query metadata deleted within 30 days?

The answers tell you more than any marketing page.

How to score the responses

Not every question carries equal weight. Here's a suggested weighting framework you can adapt to your context. Score each provider 0–3 per question (0 = no answer / non-responsive, 1 = partial / weak, 2 = adequate, 3 = strong / documented).

Multiply score by weight for a weighted total (max possible: 72). Don't treat the number as absolute — it's a structured conversation starter. A US provider scoring 55 with strong DPF documentation might be a better operational fit than an EU provider scoring 40 with weak documentation.

Run this scoring exercise for each provider on your shortlist, attach the scores to your procurement record, and re-score at contract review. Changes in a provider's posture (new DPA, dropped certification, subprocessor addition) should trigger a re-score.

Procurement artefacts — what to collect and what to look for

Before you sign anything, collect these documents. Each one should be read — not filed unread — because the details in them are what a data-protection authority will ask about.

Collect these before the contract is signed. Once a provider is in production, replacing them is harder than qualifying them.

How major DNS providers stack up

Status legend: 🟢 structural fit · 🟡 satisfiable with extra audit work · 🔴 problematic.

EU-headquartered providers

US-headquartered providers

🔴 cases are providers without any DPA/SCC mechanism, or with documented data-handling practices that don't meet GDPR processor requirements. Not naming names — confirm with each vendor's published DPA.

NIS2 and GDPR — how the two frameworks interact for DNS procurement

GDPR and NIS2 are separate legal instruments, but for DNS procurement they overlap in practice. Understanding the interaction makes your procurement exercise once-and-done rather than twice-the-pain.

The takeaway: do the procurement once, collect the evidence once, and document it in a format that serves both regulatory regimes. The NIS2 supply-chain evidence and GDPR processor-selection evidence should live in the same procurement record.

For the full NIS2 context — which sectors are in scope, Article 21 measures in detail, incident-reporting timelines — see the NIS2 and DNS guide.

When "structural fit" matters more than "satisfiable"

For most workloads, a US-headquartered provider with DPF certification + SCCs + a TIA is fine — the legal regime is clear, the contractual mechanism exists, the audit overhead is bounded.

It matters more when:

• You're under NIS2 as an essential or important entity and supply-chain risk is part of your assessment. A structurally EU-jurisdiction provider materially simplifies that assessment.
• You're a public-sector buyer with explicit sovereignty mandates (e.g., French SecNumCloud, German BSI Cloud Computing Compliance Catalogue, EU CSIRT criteria).
• Your customers' procurement requires it. Increasingly common in EU-headquartered enterprises selling to other EU enterprises — DNS is in the supply-chain risk assessment.
• You handle high-sensitivity personal data (healthcare, financial, children's data) where DPAs default to extra scrutiny.
• You're in a sector with specific guidance (DORA for financial services, EHDS for health data) that effectively prefers EU-jurisdiction processors.

For everything else — early-stage SaaS, dev/test, non-regulated content sites — pick the provider that fits your stack. GDPR compliance is achievable on either side.

Buyer-scenario guide — which provider profile fits

Not every buyer needs the same level of due diligence. Here's how the decision maps to common scenarios.

DNScale's GDPR posture

For transparency, here's how DNScale specifically answers the 12-question checklist:

1. HQ / jurisdiction: EU.
2. Operations: EU (specific locations on the network page).
3. Zone data location: EU. Replicates to a global anycast edge for performance, but the source of truth is EU.
4. DPA: Yes, published; can be signed as part of onboarding.
5. Cross-border transfers: None for authoritative zone data. Edge query handling occurs at PoP locations worldwide; aggregated query metadata for billing returns to EU storage.
6. Query metadata: Aggregated. Retention bounded to billing and operational diagnostics. Not used for advertising. Not sold.
7. Subprocessors: Disclosed; notification on change.
8. Breach notification: Aligned with Article 33's 72-hour requirement.
9. Certifications: ISO 27001 certified. NIS2 in progress.
10. NIS2: Yes, in scope. Operational obligations met.
11. Data-subject rights: Yes, support is via the published DPO contact.
12. Cancellation: Zone data export and deletion within 30 days.

Specific contractual artefacts available on request via support. For the infrastructure details that underpin these claims — AS numbers, IXP peering, network architecture — see the DNScale infrastructure and EU operations page.

Audit-readiness — what your internal team needs to produce

If a data-protection authority or NIS2 regulator asks about your DNS provider selection, the response window is short. Have a processor selection record ready before they ask. Here's a template.

Processor selection record — template

Provider: [Name] Date of selection: [Date] Date of most recent review: [Date] Review cadence: [e.g., annually, or on contract renewal]

1. Selection criteria — Adapt the 12-question checklist above to your context. List the criteria you used and their weightings.

2. Shortlist and scores — Attach the weighted scoring table for each shortlisted provider. Include the rationale for the chosen provider.

3. Contractual artefacts on file — Check each one:

• Signed DPA
• Subprocessor register (date of last update: ___)
• Transfer Impact Assessment (if non-EU provider; date of assessment: ___)
• Certification reports (ISO 27001 expiry: ___, SOC 2 date: ___)
• Incident-response policy / last post-incident report (date: ___)
• Data-retention and deletion policy (retention period: ___)

4. Risk assessment — Note any risks identified and mitigated. Example: "Provider uses US-based subprocessor for CDN cache (Cloudflare); accepted because the subprocessor has DPF certification and our DPA includes subprocessor obligations. Risk: medium. Mitigation: monitored."

5. DPO / legal review — Name of reviewer and date of sign-off.

6. Next review date — Scheduled.

Store this record where your DPO can retrieve it within 48 hours. Don't create it during an audit — have it maintained as a living document. Update it when the provider changes their DPA, adds subprocessors, drops a certification, or announces a material change to their infrastructure.

Related comparisons

• Best EU DNS providers 2026 — the full round-up
• DNScale vs Cloudflare DNS
• DNScale vs AWS Route 53
• DNScale vs Google Cloud DNS
• Best DNS for multi-provider redundancy

References

• GDPR official text (EUR-Lex)
• EU–US Data Privacy Framework
• NIS2 Directive (EU 2022/2555)
• ENISA: guidance on GDPR for cloud and DNS providers
• Court of Justice of the European Union, Breyer v. Bundesrepublik Deutschland, C-582/14 (2016) — IP addresses as personal data
• DNScale NIS2 and DNS compliance guide
• DNScale infrastructure and EU operations