# Domain incident exercise record

Use this record for a short tabletop or controlled recovery exercise. Transfer resulting actions into the organisation's existing action, risk or improvement system.

## Exercise details

- Exercise date:
- Facilitator:
- Accountable owner:
- Participants and roles:
- Scenario selected:
- Domains, zones and services in scope:
- Exercise type: tabletop / access recovery / controlled technical validation / other
- Related incident, continuity or assurance record:

## 1. Objective

What capability is being tested?

- [ ] Recognise and escalate a domain-layer incident.
- [ ] Identify the affected authority and dependencies.
- [ ] Reach registrar, DNS, email or other provider support.
- [ ] Recover privileged access through a secondary path.
- [ ] Retrieve known-good DNS or authority evidence.
- [ ] Approve and implement an emergency change.
- [ ] Validate public and service recovery.
- [ ] Communicate through an independent channel.
- [ ] Other:

## 2. Scenario

Describe the initial event and what participants are told.

- Initial observation:
- Assumed service impact:
- Assumed authority or access impact:
- Public or customer impact:
- Information deliberately withheld until requested:

Suggested scenarios:

- the primary domain is approaching expiry and the renewal account cannot be accessed;
- nameserver delegation changes unexpectedly and public services fail;
- the DNS provider account is locked while a material record is misrouting traffic;
- an unauthorised email provider appears in public SPF or DMARC evidence;
- the usual registrar or DNS administrator is unavailable during an incident;
- the primary email and identity domain is impaired, affecting response communications.

## 3. Evidence and records located

| Required item | Located | Accessible to more than one person | Current | Notes |
| --- | --- | --- | --- | --- |
| Domain register |  |  |  |  |
| Registrar / DNS authority record |  |  |  |  |
| Authorised-sender register |  |  |  |  |
| Provider account identifiers |  |  |  |  |
| Emergency contacts and support paths |  |  |  |  |
| Recovery codes or approved vault references |  |  |  |  |
| Known-good DNS or zone evidence |  |  |  |  |
| Incident and communications plans |  |  |  |  |

## 4. Exercise timeline

| Time | Inject, observation or decision | Participant response | Evidence used | Outcome |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |
|  |  |  |  |  |
|  |  |  |  |  |

## 5. Capability assessment

### Recognition and escalation

- What worked:
- What was unclear:
- Was severity proportionate:

### Roles and decision authority

- Could participants identify the incident lead and accountable owner:
- Could emergency changes or provider escalation be approved:
- Conflicts or ambiguity:

### Provider and access recovery

- Were account identifiers and support paths usable:
- Was a secondary administrator or recovery path viable:
- Provider or platform limitation discovered:

### Dependencies and recovery

- Were affected services and recovery priorities clear:
- Could known-good state be retrieved:
- Were validation and rollback steps sufficient:

### Evidence and communication

- Was evidence preserved without blocking containment:
- Could the team communicate independently of the affected domain:
- Were external communication and obligations considered:

## 6. Findings and actions

| Finding or action | Owner | Due date | Priority | Destination record | Evidence of completion |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |

## 7. Completion

- Exercise objective achieved:
- Material capability gap requiring escalation:
- Temporary workaround or accepted risk:
- Runbook updated:
- Domain register updated:
- Authority record updated:
- Authorised-sender register updated:
- Actions transferred to existing systems:
- Next exercise scenario:
- Next exercise date:
- Accountable owner acceptance:

## Boundary

An exercise provides evidence that a defined path was tested under controlled conditions. It is not assurance that every scenario, provider or recovery action will succeed during a real incident.
