Write a first-hour cyber incident contact plan before you need it

Prepare the first-hour contact and authority plan before an incident. The goal is to know who can decide, how they can be reached and which qualified help is available when normal systems may be unreliable.

Name decisions, then assign roles

A contact list is useful only if people understand why they are being called. Identify who can assess business impact, authorise technical action, approve external specialist help and coordinate communications. Include a backup for each essential role.

Keep this as preparedness work. During a real incident, follow the organisation’s authorised response procedure and obtain appropriate qualified assistance. A public planning article cannot determine whether a particular device should be disconnected, rebuilt or preserved in its current state.

Build a compact contact record

Role	Information to keep available
Business decision maker	Authority, primary and backup contact route.
Technical lead	Systems responsibility and approved escalation.
Service providers	Support references and the actual contracted response route.
Communications owner	Who approves staff, customer or public updates.
Privacy or legal adviser	How relevant obligations will be assessed for the incident.
Recovery owner	Who can access the approved recovery plan and authorise restoration.

Prepare a route outside the affected system

If the organisation relies entirely on its email tenant to contact the people responsible for an email compromise, the plan has an obvious dependency. Agree an alternative route and make the necessary details accessible to authorised people.

Do not solve this by placing sensitive credentials in an uncontrolled shared file. Keep contact information and authority clear while using the approved secure method for recovery access. Check that the backup contact knows their role and can reach the relevant providers.

Rehearse a fictional scenario

Use a short tabletop exercise: staff report unexpected account prompts while a critical application becomes unavailable. Ask who receives the report, who establishes what is known and who can approve next actions. Separate confirmed facts from assumptions throughout the exercise.

Record missing contacts, unclear authority and dependencies discovered. Avoid turning the exercise into an unapproved live disruption. Its immediate purpose is to improve decision readiness and communications, not to prove that every technical recovery path works.

Define a factual initial status note

• What was observed and when.
• Which operations appear affected.
• What is confirmed, uncertain or still being assessed.
• Who is coordinating and how authorised staff can reach them.
• The next update point and decisions required.

Avoid speculative attribution, promises of complete recovery or disclosure of sensitive technical detail. Regulatory, contractual and customer-notification decisions depend on the actual facts and appropriate advice. Maintain the plan as people, providers and systems change.