Domain Governance Baseline Practice guide 01 · Establish a domain register
From baseline to practice · Guide 01

The foundational record behind ownership, renewal, DNS, email and incident readiness.

Establish a domain register.

Build a dependable governance view of the domains that matter to the organisation: why they exist, who is accountable, who operates them, how they renew and which services depend on them.

For technology and risk generalists Eight practical steps Blank CSV included No specialist tooling required
Download blank CSV Download worked example Open the baseline
Outcome

A register the organisation can actually govern from

At the end of this exercise, each material domain should have a stated purpose, an accountable owner, a technical operator, known registrar and DNS arrangements, named renewal responsibility, recorded email use, visible service dependencies and an explicit next action where information remains incomplete.

Scope

Register governance boundaries, not every hostname

The default unit is the registrable domain - the name the organisation registers or controls through a registrar, such as example.org or example.com.au. A complete list of technical hostnames is a different artefact.

Include by default

  • Active public and internal-facing registered domains.
  • Defensive, redirect, campaign and legacy domains.
  • Domains held through subsidiaries, agencies or suppliers.
  • Domains used only for email or identity.
  • Domains marked for retirement but not yet allowed to lapse.

Add a subdomain only when it matters as a boundary

  • It is separately delegated.
  • A different supplier or team operates it.
  • It represents a distinct public identity or critical service.
  • It has separate access, recovery or lifecycle arrangements.
Avoid the hostname trap. Trying to register every web, mail, application and infrastructure hostname produces an unmaintainable technical inventory. Record subdomains only where they change accountability, operation, supplier dependency or recovery.
Method

Establish the register in eight practical steps

  1. 1

    Collect the obvious sources

    Start with registrar and reseller accounts, authoritative DNS providers, existing asset records and known brand or campaign lists. Export rather than retype where possible.

  2. 2

    Look beyond the registrar

    Check Microsoft 365 or Google Workspace verified domains, cloud and CDN platforms, web hosting, email services, certificate-transparency evidence, procurement records and supplier contracts. No single source should be treated as complete.

  3. 3

    State why each domain exists

    Describe the business purpose in plain language. “Website” is rarely enough. Name the service, audience, brand, identity or defensive purpose that justifies continued control.

  4. 4

    Name accountability and operation separately

    Assign an accountable business owner or function and record the technical operator. They may be the same in a small organisation, but the distinction should remain visible.

  5. 5

    Confirm registrar, DNS and renewal responsibility

    Record where the domain is registered, who provides authoritative DNS, who receives renewal notices and who is accountable if payment, access or recovery fails.

  6. 6

    Record email use and critical dependencies

    State whether the domain sends, receives, does both or should do neither. Identify critical websites, identity services, APIs, suppliers and customer-facing services that depend on it.

  7. 7

    Keep unknowns explicit

    Do not invent certainty to complete the spreadsheet. Use “unknown” and write the next action needed to resolve the gap, including who should investigate it.

  8. 8

    Set a review cadence and change triggers

    Review the register at least annually, and after acquisitions, divestments, brand changes, supplier transitions, major incidents, platform migrations or material staff changes.

Starter record

Use only the fields needed to create governance visibility

The CSV deliberately avoids risk scores, control ratings and detailed technical metadata. It is a starting register that can be imported into the organisation's existing spreadsheet, CMDB, asset register or governance system.

Domain
The registered domain or material subdomain being governed.
Purpose
The business, service, identity, campaign, defensive or legacy reason it exists.
Lifecycle status
Active, defensive, redirect, campaign, legacy, retirement candidate or unknown.
Accountable owner
The business role or function answerable for continued use and governance.
Technical operator
The internal team or supplier that performs technical administration.
Registrar or reseller
The organisation through which the domain is registered and renewed.
Authoritative DNS provider
The provider hosting the authoritative DNS zone.
Renewal owner
The person or function accountable for renewal continuity.
Renewal date
The known expiry or renewal date, or “unknown” where it needs confirmation.
Email use
Sends, receives, both, none or unknown.
Critical services or supplier dependencies
The important services, platforms and suppliers that rely on the domain.
Last reviewed
The date the record was last confirmed by an appropriate owner or operator.
Next action or unresolved question
The specific work needed to close a gap or make a decision.
Portable starter files

Take the register into the system you already use

The files contain no macros, formulas, scoring or external connections. The worked example uses reserved example domains and illustrates a registered domain, defensive holding and material subdomain.

Blank CSV Worked example CSV
Evidence and cadence

Know when the practice genuinely exists

Evidence of practice

  • A current register exists in an approved organisational location.
  • Material domains have accountable owners and technical operators.
  • Registrar, DNS and renewal responsibilities are recorded.
  • Email use and critical dependencies are visible.
  • Unknowns have owners or explicit next actions.
  • A review date and change-trigger process are documented.

Review it when

  • The scheduled annual or more frequent review falls due.
  • A domain, DNS or email incident occurs.
  • A supplier, registrar, DNS or email platform changes.
  • A brand, campaign, service or product is launched or retired.
  • The organisation acquires, divests or restructures a business area.
  • An accountable owner or privileged operator leaves or changes role.
Common failure modes

A register can exist and still fail as governance

Using one registrar as the inventory

Domains may be distributed across resellers, suppliers, subsidiaries and legacy accounts. Treat registrar exports as evidence, not the whole answer.

Naming only the technical contact

A person who can edit DNS is not automatically accountable for the business purpose, renewal decision or risk acceptance.

Recording domains without purpose

A list of names cannot support lifecycle decisions if no one can explain why each domain remains necessary.

Ignoring defensive and redirect domains

Domains that host little content may still protect identity, traffic, email or public trust and require deliberate renewal decisions.

Capturing renewal dates without ownership

A calendar date does not prevent expiry when notices go to an inactive mailbox or no one is accountable for payment and escalation.

Attempting to catalogue every hostname

Unbounded technical discovery overwhelms the governance objective and makes the register difficult to maintain.

Hiding unknowns to complete the sheet

Unknown ownership or provider information is itself a governance finding. Make it visible and assign the next action.

Creating the register once

A static spreadsheet becomes misleading. Link updates to procurement, change, incident, project closure and supplier-transition processes.

Return to the baseline

The register should improve the answers, not replace the questions

Once the initial register exists, work through the baseline again. The organisation should be better able to answer which domains it controls, why they exist, who is accountable, who renews them and which services depend on them.

Return to the baseline Back to practical guidance