Scope
Prepare for failures of authority, routing and public trust
A domain incident may begin as an access problem, configuration error, supplier outage or suspicious public signal.
The response should focus on the authority and services at risk rather than waiting for a perfect incident label.
Expiry or renewal failure
A domain expires, enters a grace state or is at risk because notices, payment or ownership failed.
Registrar or account compromise
Unauthorised access, transfer, contact change, unlock or recovery activity affects registration authority.
Delegation or DNS failure
Nameservers or records are changed, deleted, unavailable or route users and systems incorrectly.
Email-control incident
Authorised sending breaks, unexpected authority appears, authentication fails or impersonation activity requires action.
Supplier or platform loss
A registrar, DNS, email, hosting or identity provider becomes unavailable or cannot support recovery.
Unexplained public change
External observation reveals an unexpected registration, DNS, certificate or mail-posture change requiring internal verification.
Do not wait for a domain-specific incident process.
Use the organisation's existing incident framework and add the domain-layer evidence, provider authority and recovery steps it otherwise lacks.
Method
Establish readiness in eight practical steps
1
Define triggers and escalation thresholds
Name the events that require incident activation: expiry risk, unexpected registrar or nameserver change, DNS outage, loss of administrative access, material mail-authentication failure or provider compromise. Use service impact, authority loss and public harm to guide severity.
2
Name roles and decision authority
Identify the incident lead, accountable business owner, registrar and DNS operators, messaging specialist, service owners, cyber or risk lead and communications contact. State who may approve emergency changes, transfers, lock changes and public communication.
3
Assemble provider and recovery information
Record provider account identifiers, emergency support paths, monitored contacts, recovery identities, vault locations and escalation references. Keep enough information accessible if email, identity or the primary provider console is unavailable.
4
Map impact and recovery priorities
Use the domain register to identify websites, email, identity, APIs, integrations and suppliers that depend on the affected domain. Prioritise public safety, essential service, identity and communication dependencies rather than restoring records without context.
5
Define containment and recovery actions
Document the first safe actions for each material scenario: preserve access, apply locks, suspend compromised credentials, restore known-good DNS, reduce TTL only when useful, withdraw obsolete email authority and engage provider escalation.
6
Preserve evidence and a decision trail
Capture timestamps, screenshots or exports, observed records, audit logs, provider case numbers, approvals and changes. Record what was known at each decision point without delaying urgent containment.
7
Plan communications and external obligations
Identify who must be informed internally and externally, what public trust or service impact must be explained, and whether legal, privacy, regulatory, insurer, supplier or law-enforcement obligations apply.
8
Exercise and maintain the path
Run at least one scenario annually and after material provider, ownership or platform change. Test contactability, access recovery, known-good evidence, decision authority and the ability to implement and validate a safe change.
Operational record
Keep the runbook short enough to use during the incident
The starter runbook is intended to sit inside an approved incident, continuity or knowledge system.
It links to authoritative records instead of copying passwords, complete zone files or fragile contact lists into another document.
- Activation and severity
- Triggers, initial impact questions and escalation thresholds.
- Roles and authority
- Incident lead, accountable owner, technical roles and emergency decision rights.
- Provider escalation
- Account identifiers, support paths, case references and recovery prerequisites.
- Dependencies
- Critical services, audiences, suppliers and communication channels affected.
- Known-good evidence
- Approved locations for zone state, access records, sender records and recovery materials.
- Scenario actions
- Containment, recovery, validation and rollback prompts for common incident types.
- Evidence log
- Observation times, public signals, audit events, provider responses and decisions.
- Communications
- Internal, customer, stakeholder, regulatory and public communication responsibilities.
- Completion
- Recovery confirmation, residual risk, follow-up actions and record updates.
- Exercise history
- Last scenario tested, outcome, lessons and next exercise date.
Portable incident record
Domain incident runbook template
A plain Markdown runbook that can be pasted into an incident platform, continuity plan, wiki or controlled knowledge repository.
Exercise and learning
Test the path, not only the document
A short tabletop or controlled recovery exercise should prove that people can find the records, reach providers,
recover access, make decisions and validate changes. The exercise record captures evidence and follow-up without becoming a separate assurance programme.
Portable exercise record
Domain incident exercise template
Use it for a registrar lockout, DNS misrouting, domain expiry or email-authority scenario, then transfer actions into the organisation's existing action system.
Evidence and cadence
Know when readiness genuinely exists
Evidence of practice
- A current runbook is stored in an approved, accessible location.
- Incident and provider roles can be reached through monitored organisational channels.
- Provider account identifiers and recovery paths are current.
- Critical domain dependencies and recovery priorities are documented.
- Known-good DNS, authority and sender evidence can be retrieved.
- A recent exercise demonstrated access, decision and recovery capability.
- Exercise and incident actions were assigned and closed or accepted.
Review it when
- The annual exercise or scheduled review falls due.
- A registrar, DNS, email, identity or hosting provider changes.
- An accountable owner, administrator or emergency contact changes.
- A material domain, service or supplier is launched or retired.
- A domain-layer incident or near miss occurs.
- Recovery evidence, vault arrangements or support paths change.
Common failure modes
A runbook can exist and still fail during the incident
Contacts live in the failed mailbox
The response depends on email or identity services that the domain incident has already disrupted.
The provider account cannot be identified
Support cannot verify or escalate the case because customer, reseller, registry or zone identifiers are missing.
One specialist holds the recovery knowledge
The organisation has a document but cannot act when the usual administrator is unavailable.
Records are restored without service context
DNS is changed quickly but identity, email, application and supplier dependencies are not validated in sequence.
Evidence is overwritten during containment
Urgent changes remove the state needed to understand compromise, support investigation or explain decisions.
Emergency authority is unclear
People know the technical action but not who can approve a transfer, lock change, rollback or public statement.
The runbook is never exercised
Stale contacts, inaccessible vaults and provider limitations are discovered only during a real incident.
Post-incident actions disappear
The service is restored, but registers, access controls, sender records and recurring governance are not corrected.
Return to the baseline
Readiness should make the incident-path answer demonstrable
Revisit the question about what happens when a domain, DNS record or email control fails. The organisation should now be able to name who leads, who can act, what services matter, how authority is recovered and when the path was last tested.