Domain Governance Register: What to Track for Every Company Domain

Most teams have a domain inventory — a list of the domains they own. Far fewer have a domain governance register: a record of why each domain exists, who is accountable for it, whether it is active or a decommission candidate, and whether the team has decided to renew it or let it lapse. When a domain portfolio grows to dozens or hundreds of names across brands, campaigns, and business units, the inventory tells you what you have. The governance register tells you what to do about it.

This guide explains what to track per domain, why an inventory alone is not enough, and how to turn the register into management-ready evidence. CertPilot supports this with customer-entered governance metadata on each domain, alongside its automated SSL/DNS/RDAP checks. The owner field is customer-entered only — it is not derived from RDAP/WHOIS registrant data.

See how it fits on the External Footprint Monitoring page, paste a portfolio into Watchtower to get a fast view of SSL and expiry across domains, and review the sample reports to see how governance context appears in the Domain Health Report.

Inventory vs governance register

An inventory and a governance register answer different questions:

| | Domain inventory | Domain governance register | |---|---|---| | Core question | What domains do we own? | Why do we own each one, and what should happen to it? | | Typical contents | Hostname, registrar, expiry | Owner, purpose, lifecycle status, renewal decision, review date | | Failure mode | A domain is missing from the list | A domain is on the list but nobody knows what it is for | | Outcome | Visibility | Accountability and decisions |

A team can have a perfect inventory and still waste money auto-renewing dead domains, lose a wanted domain because nobody decided to renew it, or scramble during an incident because no owner is recorded. Governance closes that gap.

Why a domain inventory alone is not enough

Domain portfolios get messy in predictable ways:

• Sprawl with no record of purpose. Marketing buys campaign domains, a brand refresh leaves old names behind, an acquisition adds more. Nobody can say what half of them are for.
• No internal owner. When renewals or DNS changes need a decision, there is no named person, so the work stalls or falls through.
• Parked and inactive domains keep auto-renewing. Money goes to domains nobody uses because no deliberate "renew vs let expire" decision was ever captured.
• Wanted domains lapse by accident. The mirror image — a domain that mattered expires because no one decided, in writing, to keep it.
• No proof of review. When a manager or auditor asks "do you have your domains under control?", a list is not an answer. A reviewed register is.

What to track for every domain

A lean governance register does not need many fields. CertPilot records these as customer-entered metadata on the domain, surfaced in the dashboard and the Domain Health Report:

• Owner — the internal person or team accountable for the domain. (Customer-entered only; never pulled from registrant data.)
• Purpose — why the domain exists or what it is used for (primary site, redirect, campaign, email-only, brand protection, legacy).
• Lifecycle status — active, parked, redirect, decommission candidate, or retired.
• Renewal decision — undecided, renew, let expire, or review.
• Notes — free-text context a future colleague will need.
• Last reviewed date — when a human last looked at this record.

Field-by-field: what good looks like

• Owner should be a role or named person, not "IT" in the abstract. The test: if this domain had a problem today, who gets the ticket?
• Purpose should be specific enough that someone unfamiliar with the domain understands whether it can be dropped. "Old 2019 product launch microsite, no live content" is useful. "Marketing" is not.
• Lifecycle status is what drives clean-up. A domain marked decommission candidate is a prompt to confirm nothing depends on it before letting it go.
• Renewal decision turns auto-renew from a default into a choice. Undecided is itself a signal — it means a decision is owed.
• Last reviewed date is what makes the register trustworthy. A field that was filled in once and never revisited is not evidence of governance.

Handling parked and decommission candidates

The highest-value output of a domain governance register is a defensible answer to "which domains can we stop paying for?"

A safe path for a decommission candidate:

1. Mark lifecycle status = decommission candidate and renewal decision = review.
2. Confirm no live website, no active MX/email use, and no redirects or links depend on it. Check the public DNS records — CertPilot's checks show A/AAAA, MX, NS, TXT, and CAA so you can see what is still wired up.
3. Record the decision and the date in the register, then either set renewal decision = let expire or move it back to active/renew.
4. Keep the record after the domain lapses so there is a trail of why it was dropped.

The same discipline catches the opposite mistake: a domain marked renew with a clear owner will not quietly lapse.

Turning the register into management evidence

A governance register is most useful when it produces something a manager can read. CertPilot's Domain Health Report includes a Domain Governance Review section that summarises the governance metadata alongside the technical checks — so a single PDF shows both "are these domains technically healthy?" and "are they under deliberate management?". The dashboard also surfaces a review queue for the gaps that need attention: missing owner, missing purpose, undecided renewal, never reviewed, and decommission candidates.

This is evidence of operational control, not certification. CertPilot helps you show domains are managed; it does not certify compliance with any framework.

See the sample report gallery for the Domain Health Report format, and the External Footprint Monitoring page for how governance metadata sits beside the automated checks.

Domain governance register checklist

• List every domain — primary, redirect, campaign, country-code, email-only, and legacy.
• Assign a named owner to each (internal accountability, not registrant data).
• Record a specific purpose for each domain.
• Set a lifecycle status: active, parked, redirect, decommission candidate, or retired.
• Capture a renewal decision: renew, let expire, review, or explicitly undecided.
• Confirm dependencies (website, email/MX, redirects, DNS records) before marking anything for decommission.
• Stamp a last reviewed date and re-review on a regular cadence (quarterly is reasonable for active portfolios).
• Produce a Domain Health Report so the review is visible to management.

What CertPilot can help with

• Automated public checks — SSL, DNS, RDAP/domain expiry, and email-authentication records across every domain you add, daily.
• Customer-entered governance metadata — owner, purpose, lifecycle status, renewal decision, notes, and last reviewed date per domain.
• Governance review queue — operational counts for missing owner, missing purpose, undecided renewal, never reviewed, and decommission candidates.
• Domain Health Report — technical health plus a Domain Governance Review section, ready to share.
• Portfolio views — paste a list into Watchtower or use the audit tools to see SSL and expiry across many domains at once.

What CertPilot does not do

• The owner and governance fields are customer-entered metadata — they are not derived from RDAP/WHOIS registrant data, and they do not affect technical health scoring.
• CertPilot does not renew domains, log in to registrars, edit or restore DNS, or manage registrar accounts.
• No vulnerability scanning, penetration testing, employee monitoring, or compliance certification.
• It is a governance evidence tool, not a system of record for registrar credentials or payment details — keep those in a dedicated password manager.

Frequently Asked Questions

What is a domain governance register?

A domain governance register is a maintained record of why each domain exists, who internally owns it, its lifecycle status, whether the team has decided to renew or retire it, and when it was last reviewed. It sits on top of a basic domain inventory and turns a list of names into a set of deliberate decisions.

How is this different from a domain ownership audit?

A domain ownership audit focuses on control and access — registrar account holder, who can log in, billing and recovery. A governance register focuses on purpose, internal accountability, lifecycle, and the renew-or-retire decision. They complement each other; the ownership audit answers "who can act," and the governance register answers "what should we do."

Does CertPilot pull the domain owner from WHOIS?

No. The owner field is customer-entered only. CertPilot reads public RDAP/WHOIS data for expiry and registrar context where available, but it never populates the internal owner from registrant data. The owner is whatever your team types.

Does governance metadata change a domain's health score?

No. Governance fields are customer-entered and do not affect SSL, DNS, or domain-expiry scoring. Any "needs review" indicator (such as undecided renewal or a stale review date) is a neutral operational prompt, not a technical pass/fail.

Can CertPilot decide which domains to retire for me?

No. CertPilot surfaces the candidates and the public signals so you can make the call. The decommission decision — confirming nothing depends on a domain and choosing to let it expire — stays with your team and is recorded in the register.

Related resources

• Domain ownership audit — who controls and can act on a domain.
• Domain operations guide — expiry, registrar access, and handover.
• Domain expiry monitoring — tracking renewal windows.
• External Footprint Monitoring — checks plus governance metadata in one place.
• Sample reports — the Domain Health Report with its Domain Governance Review section.