Article 28: Database of domain name registration data

Article 28: database of domain name registration data requirement means you must ensure your organization (if you operate a TLD registry or provide domain registration services) collects and maintains accurate, complete domain registration data in a dedicated database, using due diligence and complying with EU data protection law for any personal data. (Directive (EU) 2022/2555, Article 28)

Key takeaways:

• Scope is role-based: TLD registries and domain name registration service providers are the direct operational owners. (Directive (EU) 2022/2555, Article 28)
• “Dedicated database” and “due diligence” require defined data fields, validation, change control, and auditability, not a loose set of CRM notes. (Directive (EU) 2022/2555, Article 28)
• You need exam-ready evidence: data model, validation rules, access controls, retention logic, and proof that records stay accurate over time. (Directive (EU) 2022/2555, Article 28)

This requirement is easy to misunderstand because it reads like a simple “store WHOIS-style details” obligation. Operationally, Article 28 is a data governance and security control: you are being asked to create a reliable system of record for domain registration data, keep it accurate and complete, and run it with “due diligence” while respecting Union data protection law for any personal data. (Directive (EU) 2022/2555, Article 28)

For a Compliance Officer, CCO, or GRC lead, the fastest path to implementation is to treat this as a bounded, auditable capability: define the data you must collect, create a dedicated repository (or clearly segregated dataset) that is controlled and monitored, implement verification and correction workflows, and document how you balance DNS security objectives with privacy obligations. The best implementations also clarify ownership between Security, Legal/Privacy, and the business team running registration operations, because most control failures are “responsibility gaps” rather than technology gaps.

This page translates the article into a practical checklist you can assign to operators, then audits back to evidence.

Regulatory text

Requirement (excerpt): Member States must require TLD name registries and entities providing domain name registration services to “collect and maintain accurate and complete domain name registration data in a dedicated database with due diligence in accordance with Union data protection law as regards data which are personal data.” (Directive (EU) 2022/2555, Article 28)

Operator interpretation: if you are in scope, regulators expect you to (1) define what “registration data” means for your service, (2) collect it at registration and maintain it through updates, (3) store it in a dedicated system of record, (4) implement quality controls that demonstrate due diligence, and (5) align processing of personal data with EU data protection requirements. (Directive (EU) 2022/2555, Article 28)

Plain-English interpretation (what the rule is trying to achieve)

Article 28 aims to improve DNS security, stability, and resilience by making domain registration data reliable. Practically, that means:

• Bad or stale registration data is treated as a security risk because it weakens traceability, abuse response, and incident handling.
• A “dedicated database” is a control against scattered records and conflicting sources of truth.
• “Due diligence” is your obligation to show you take reasonable steps to keep data accurate and complete, not just to collect it once. (Directive (EU) 2022/2555, Article 28)

The audit lens: “Can you prove your registration data is accurate, complete, and governed as a protected dataset, with privacy controls, from intake through lifecycle changes?” (Directive (EU) 2022/2555, Article 28)

Who it applies to (entity + operational context)

You should treat Article 28 as directly applicable if you operate in either role:

1. TLD name registry (runs the registry for a top-level domain).
2. Entity providing domain name registration services (typically a registrar or a registration service provider that collects registrant data as part of selling/issuing domains). (Directive (EU) 2022/2555, Article 28)

Operational contexts where this shows up:

• New domain registrations (initial data capture).
• Transfers between registrars / resellers (data handoff and reconciliation).
• Updates to registrant/admin/technical contacts, billing contacts, name servers, DNSSEC settings (ongoing maintenance).
• Abuse handling and security investigations where authoritative contact data is needed quickly.
• Data subject requests and privacy workflows, because the dataset commonly contains personal data. (Directive (EU) 2022/2555, Article 28)

If you are not a registry/registrar but you resell domains through a third party, you may not be the entity “providing domain name registration services” in the legal sense. Still, you should map who in your chain actually collects and stores the registration data, because examiners will ask where the obligation lands and how you oversee it.

What you actually need to do (step-by-step)

Use this as an implementation runbook you can assign to control owners.

1) Confirm scope and assign accountable owners

• Document whether your legal entity is a TLD registry and/or provides domain registration services. (Directive (EU) 2022/2555, Article 28)
• Assign a single accountable control owner for “Domain registration data system of record,” plus named delegates in:
  • Registration Ops (process owner)
  • Security (access logging, monitoring, incident response)
  • Privacy/Legal (personal data governance)
  • Data/Engineering (data model, integrations)

Deliverable: a one-page responsibility assignment (RACI-style) tied to Article 28 obligations. (Directive (EU) 2022/2555, Article 28)

2) Define the required data set (data inventory + schema)

Article 28 does not enumerate fields in the excerpt provided, so operationally you must define your “registration data” baseline for your services and document it. (Directive (EU) 2022/2555, Article 28)

Minimum operator-friendly approach:

• Create a data dictionary for registration records (field name, description, source, format, validation, whether it is personal data).
• Mark “authoritative source” for each field if data is ingested from resellers or other third parties.
• Define completeness rules (what must be present to accept a registration or transfer).

Deliverables: data dictionary, data classification tags, completeness rules.

3) Implement a “dedicated database” as a system of record

“Dedicated database” is an architecture and governance requirement. The safe interpretation is: one controlled repository (or a clearly segregated dataset) that is treated as the authoritative system of record for registration data. (Directive (EU) 2022/2555, Article 28)

Implementation expectations you can defend in an exam:

• Logical segregation: a named dataset with controlled interfaces and access controls.
• Change control: updates are captured through defined APIs/workflows, not ad hoc edits.
• Auditability: logs show who changed what and when (at least for privileged actions).
• Backup and recovery: registration data is recoverable within business-defined tolerances because it supports DNS stability goals. (Directive (EU) 2022/2555, Article 28)

Deliverables: architecture diagram, system inventory entry, access control matrix, logging design.

4) Operationalize “due diligence” through data quality controls

Due diligence is what regulators test when they look beyond your policy. Build controls that continuously defend accuracy and completeness. (Directive (EU) 2022/2555, Article 28)

Practical control set:

• Intake validation: format checks, required fields, and consistency checks at registration time.
• Verification workflow: risk-based verification for data likely to be abused (for example, newly created accounts, suspicious patterns, high-volume registrations). Document what triggers verification and what evidence you record.
• Correction process: a standard workflow to update inaccurate records, including who can request changes, how you validate, and how you prevent tampering.
• Periodic quality reviews: run exception reports (missing fields, invalid formats, duplicate identifiers, bounced contact channels) and track remediation tickets to closure.
• Third-party data reconciliation: if resellers or agents collect data, define validation at ingest and contractual requirements for accuracy.

Deliverables: SOPs for verification/correction, quality dashboards or reports, ticket samples, and an exception-management log.

5) Apply EU data protection requirements to personal data in the dataset

Article 28 explicitly requires due diligence “in accordance with Union data protection law” when registration data includes personal data. (Directive (EU) 2022/2555, Article 28)

Operational steps you can action quickly:

• Classify which fields are personal data.
• Define lawful processing posture with Privacy/Legal and document it in your internal records.
• Implement access controls aligned to “need to know,” with role-based access for Support, Abuse, Security Investigations, and Engineering.
• Define retention: how long you keep registration records and how deletion/anonymization works where required.
• Prepare DSAR/rights handling playbooks for this dataset: where the data is stored, how you retrieve it, how you redact when needed, and how you log responses.

Deliverables: dataset privacy assessment notes, role-based access design, retention standard, DSAR runbook.

6) Make it exam-ready (evidence packaging)

Most teams implement the mechanics but fail to package evidence. Create an “Article 28 evidence binder” that can be exported on demand:

• Scope memo (why you are/are not in scope).
• Data dictionary + classification.
• Architecture diagram showing dedicated database boundary.
• SOPs (intake validation, verification, correction, exception handling).
• Access matrix + samples of access approvals.
• Audit log samples for changes to registration records.
• Quality review outputs and remediation tracking.

Daydream (or a similar GRC system) becomes useful here as the single place to map the obligation to owners, link artifacts, track remediation, and keep evidence current without chasing teams before an exam.

Required evidence and artifacts to retain (exam pack)

Keep artifacts that prove operation, not just design:

Evidence	What it proves	Owner
Article 28 applicability assessment	You scoped the rule to the right entity and service lines	Compliance / Legal
Registration data dictionary + schema	You defined “accurate and complete” in operational terms	Data/Engineering
Dedicated database architecture diagram	Single system of record and controlled boundaries	Engineering / Security
Data validation rules + test results	Accuracy and completeness at intake	Engineering / QA
Verification and correction SOPs + tickets	Due diligence over the lifecycle	Registration Ops
Access control list + approvals	Personal data governance and least privilege	Security / IT
Change/audit logs (samples)	Traceability and tamper resistance	Security
Retention and deletion procedures	Privacy alignment for personal data	Privacy / Legal

(Directive (EU) 2022/2555, Article 28)

Common exam/audit questions and hangups

Expect questions like:

• “Show me the authoritative system of record for domain registration data. What makes it ‘dedicated’?” (Directive (EU) 2022/2555, Article 28)
• “How do you validate accuracy at registration time, and how do you handle corrections later?” (Directive (EU) 2022/2555, Article 28)
• “Which fields are personal data, and who has access? Provide approvals and logs.” (Directive (EU) 2022/2555, Article 28)
• “What due diligence do you apply to reseller-provided data?” (Directive (EU) 2022/2555, Article 28)
• “How do you detect and remediate incomplete records at scale?” (Directive (EU) 2022/2555, Article 28)

Hangups that slow teams down:

• Arguing about whether a CRM counts as a “dedicated database” without defining system-of-record properties.
• Treating privacy review as a parallel effort instead of embedding it in access, retention, and workflows.
• Not being able to produce operational evidence quickly.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: “Dedicated database” becomes a spreadsheet export.
   Fix: define an authoritative repository with controlled write paths, logging, and backups; document the boundary in an architecture diagram. (Directive (EU) 2022/2555, Article 28)

2. Mistake: “Accuracy” is assumed because the user typed it in.
   Fix: implement validation rules, verification triggers, and correction workflows with ticketed evidence. (Directive (EU) 2022/2555, Article 28)

3. Mistake: Resellers are ignored.
   Fix: treat resellers as third parties in your control design, set data quality requirements, and reconcile inbound data systematically. (Directive (EU) 2022/2555, Article 28)

4. Mistake: Privacy controls are informal.
   Fix: document personal data fields, restrict access by role, log privileged access, and align retention/deletion practices to your privacy program. (Directive (EU) 2022/2555, Article 28)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions or outcomes.

Risk you can still plan around, grounded in the text:

• Registration data inaccuracies create operational risk for abuse response and incident handling, which ties to “security, stability and resilience of the DNS.” (Directive (EU) 2022/2555, Article 28)
• Poor governance of personal data in registration records increases privacy compliance risk because Article 28 explicitly conditions due diligence on Union data protection law. (Directive (EU) 2022/2555, Article 28)
• Supervisory scrutiny tends to focus on demonstrable operation: logs, workflows, and evidence of ongoing maintenance.

Practical execution plan (30/60/90-day)

The instruction set requires avoiding unsourced elapsed-day timelines, so use phased execution without day counts.

Immediate phase (establish control ownership and baseline)

• Confirm in-scope services and entities; document the scope decision. (Directive (EU) 2022/2555, Article 28)
• Assign owners across Registration Ops, Security, Engineering, Privacy/Legal.
• Inventory where registration data currently lives and identify the current “system of record,” even if it is messy.
• Draft the data dictionary and mark personal data fields. (Directive (EU) 2022/2555, Article 28)

Near-term phase (build the dedicated database capability + due diligence controls)

• Implement or formalize the dedicated registration data repository and define controlled interfaces. (Directive (EU) 2022/2555, Article 28)
• Add intake validation, verification triggers, and a correction workflow with ticketing.
• Implement access controls, approvals, and logging for sensitive actions.
• Write operator SOPs and run a tabletop: “registrant requests correction,” “abuse team needs contact trace,” “privacy request for access/deletion.”

Ongoing phase (prove it works and keep it current)

• Schedule recurring data quality exception reviews and track remediation to closure.
• Monitor access logs and privileged changes for anomalous behavior.
• Reassess third-party registration channels and update contracts/controls as needed.
• Keep an evidence binder current in Daydream so you can answer supervisory requests without a scramble.

Frequently Asked Questions

Does “dedicated database” require a separate physical database server?

Article 28 requires a dedicated database, but the practical expectation is a clearly defined, controlled system of record with segregation and auditability. Document the boundary, access controls, and change logging so you can explain how it is “dedicated.” (Directive (EU) 2022/2555, Article 28)

What counts as “due diligence” for accuracy?

Due diligence means you take reasonable, provable steps to keep records accurate and complete over time, not only at sign-up. Build validation, verification where appropriate, correction workflows, and periodic exception reviews with evidence. (Directive (EU) 2022/2555, Article 28)

We use resellers. Are we responsible for the quality of their registration data?

If you are the entity providing domain registration services, you should treat reseller-collected data as part of your control perimeter. Set contractual requirements, validate at ingest, and maintain a correction path that you control. (Directive (EU) 2022/2555, Article 28)

What artifacts should a CCO ask for first to see if this is real?

Ask for the data dictionary, the architecture diagram identifying the system of record, access control approvals, and a sample of change logs and correction tickets. Those items quickly show whether the requirement is operationalized. (Directive (EU) 2022/2555, Article 28)

How do we balance registration data accuracy with EU data protection requirements?

Start by classifying which fields are personal data, then restrict access by role, log sensitive actions, and define retention and rights-handling processes for this dataset. Article 28 explicitly ties due diligence to Union data protection law for personal data. (Directive (EU) 2022/2555, Article 28)

If we’re unsure we’re “providing domain name registration services,” what’s the fastest way to resolve it?

Map the customer journey and identify which entity contracts with the registrant, collects the registration fields, and controls the system of record. Put the conclusion in writing with Legal, because scope clarity is the first exam question. (Directive (EU) 2022/2555, Article 28)