Prepare an incident-response plan
Create a practical incident plan with decision authority, escalation, service dependencies, alternative communications and a worked responsibility table.
A usable incident plan answers immediate questions: who is coordinating, how serious is the situation, who can approve an action and how will people communicate? Long descriptions of possible attacks do not compensate for missing answers to those questions.
Build the plan with the people who operate and own the services. The NCSC's planning guidance calls for clear contacts, escalation and coordination, linked to continuity, recovery and communications arrangements. The example below turns those needs into an original working outline.
Define the plan's job
The response plan coordinates the incident. A technical playbook supplies more detailed steps for a particular situation. Business-continuity arrangements describe how essential work can continue during disruption, while recovery arrangements describe how services return safely. Link these documents and give each an owner.
State which organisation, services and hours the plan covers. If support is available only during business hours, document what happens outside them. An on-call phone number does not establish a response capability unless someone has accepted that responsibility.
Worked outline: Harbour Workshop
Fictional organisation: a workshop with a customer portal, cloud email, a booking service and an outsourced IT supplier. This outline is a planning example, not a claim about a real business.
| Plan section | What the fictional team records |
|---|---|
| Activation | Staff report suspected incidents through the service desk; urgent service or data concerns trigger the incident lead's escalation route |
| Coordination | An incident lead opens a numbered record, assigns roles and sets the next update time |
| Authority | The service owner can approve portal interruption within agreed limits; wider business disruption escalates to the duty director |
| Technical response | The IT supplier investigates within its agreed remit; the internal platform owner coordinates access and dependencies |
| Business continuity | The operations manager considers the documented manual booking procedure if the portal is unavailable |
| Data assessment | The relevant data owner identifies what records may be affected and works with appropriate specialist advisers |
| Communications | A nominated contact drafts internal and customer updates using confirmed facts and recorded uncertainties |
| Recovery | Technical checks and business acceptance criteria are agreed before restoring normal operation |
| Review | The incident lead records outstanding actions, evidence locations and the review owner |
The actual plan needs named people, verified contact methods, contractual arrangements and service-specific decisions. Keep that information in an appropriately restricted location with a usable alternative if normal systems fail.
Assign responsibilities and deputies
| Role | Owns | Decision boundary to agree |
|---|---|---|
| Incident lead | Shared situation record, priorities, coordination and update rhythm | What the lead may authorise without further approval |
| Technical lead | Investigation, technical options and verification evidence | Which changes require a service owner or supplier's approval |
| Service owner | Operational consequence and acceptance of service restrictions | Permitted disruption and conditions for returning to service |
| Communications contact | Consistent, audience-appropriate messages | Who approves public or customer statements |
| Data owner or adviser | Information about affected records and relevant obligations | When specialist legal, privacy or sector advice is needed |
| Deputy for each critical role | Continuity when the main person is unavailable | How responsibility is transferred and announced |
One person may fill several roles in a small organisation. Record the conflict if that person must investigate while also approving their own disruptive actions, and identify available support.
Make escalation criteria observable
Agree examples that fit your organisation: suspected access to sensitive records, interruption of an essential service, loss of an administrator account, evidence of activity across several systems, or uncertainty exceeding the responding team's capability.
Describe both the trigger and destination. “Escalate if serious” leaves two decisions unanswered. “Notify the incident lead when customer-record access is suspected; the lead engages the data owner and service owner” gives people a route even before the full extent is known.
Avoid a universal legal reporting timetable in the operational checklist. Identify who assesses applicable duties and where they obtain current advice. Different facts and obligations can require different actions.
Map dependencies before they are unavailable
For each essential service, record its identity provider, network connection, hosting, data store, key supplier and recovery dependencies. Identify who can access relevant logs and how long the organisation actually retains them. Check whether recovery credentials depend on the same system that may be unavailable.
NIST's current response publication connects incident handling with asset knowledge, suppliers, communications and recovery. Use that wider view when checking the plan; a list of technical steps alone cannot resolve missing authority or access.
Expose the gaps in the worked example
Before Harbour Workshop can rely on its plan, it discovers three gaps. The supplier's weekend contact has never been tested. The alternate meeting channel uses the ordinary identity provider. The manual booking procedure has no process for reconciling records after recovery.
Each becomes a preparation action with an owner and evidence of completion. “Plan approved” would conceal these operational gaps; an action register makes them visible.
Maintain and rehearse it
Review the plan after a meaningful service, supplier or responsibility change and after an incident or exercise. Confirm contacts and access through an agreed process. Keep a dated revision record so responders know which version they are using.
Run the tabletop exercise once the basic arrangements exist. Use the exercise planner to choose the decisions to observe, then feed the resulting actions into the plan.
Sources and further reading
- NCSC: Plan your cyber incident response processes — checked 2 November 2026
- NIST SP 800-61r3: full publication — checked 2 November 2026
- NCSC Board Toolkit: Planning your response to cyber incidents — checked 2 November 2026