Cyber Incident Response Plan: What to Do in the First 24 Hours

A cyber incident creates pressure to act immediately. People reset passwords, switch off devices, delete suspicious files and message customers before the organisation knows what happened. Some action is necessary, but uncoordinated action can destroy evidence, spread confusion or allow the attacker to remain in another account.

The first 24 hours should have four goals: protect people and essential operations, stop further harm, preserve enough evidence to understand the event, and establish reliable communication. This guide is an operational starting point, not legal advice or a replacement for a qualified incident responder.

Before an incident: prepare one page

A small organisation does not need a fifty-page plan to begin. Create a one-page response sheet containing:

• Primary and backup incident lead
• IT, management, legal, communications and vendor contacts
• Cloud, email, domain, hosting, backup and telecom support channels
• Critical systems and their business owners
• Offline access to recovery keys and vendor contracts
• A separate communication channel if email is compromised
• Decision authority for isolation, shutdown and public communication

CISA notes that smaller organisations can start with a simple response plan and improve it over time. Practise it through a short tabletop scenario at least annually.

First 15 minutes: establish control

1. Name the incident lead. One person coordinates actions and records decisions.
2. Start an incident log. Record time, reporter, observed behaviour, affected user or device and every action taken.
3. Use a safe communication channel. If email may be affected, move the response team to an approved alternative.
4. Preserve the original report. Keep screenshots, messages, URLs and alert details. Do not forward malicious attachments.
5. Assess immediate safety and business impact. Determine whether money is moving, patient or citizen services are affected, privileged access is active or data is being destroyed.

First hour: contain without guessing

Containment should reduce harm while preserving the ability to investigate. Appropriate actions depend on the incident:

• Compromised account: disable or secure the account, revoke sessions and tokens, enforce a new unique password and multi-factor authentication, then review sign-ins and forwarding rules.
• Suspected infected device: isolate it from wired, wireless and VPN networks. Do not automatically wipe or reimage it.
• Phishing email: block the sender and indicators, search mailboxes for related messages, identify who clicked and secure affected accounts.
• Cloud or server compromise: restrict malicious access, preserve logs and snapshots, rotate affected secrets through a controlled process and check for persistence.
• Ransomware: isolate affected segments, protect backups from further access and check whether essential operations can continue safely.

Evidence to preserve

Collecting everything is unrealistic. Preserve what is most likely to answer who, what, when and how:

• Authentication, email, VPN, firewall, endpoint and cloud audit logs
• Alert details, file names, hashes, URLs, domains and IP addresses
• Relevant device or server snapshots where feasible
• Account changes, forwarding rules, tokens and privileged actions
• Affected data types and approximate records
• The incident timeline and actions performed by responders

Restrict access and note who collected each item. If legal proceedings, insurance or regulatory review may follow, obtain specialist advice on evidence handling.

Hours 2–4: define the incident

Move from symptoms to a working scope. Ask:

• What was the earliest confirmed malicious activity?
• Which identities, devices, systems and locations are affected?
• Does the attacker still have access?
• Was data viewed, copied, changed or destroyed?
• Which business services are unsafe or unavailable?
• Could a supplier or connected customer also be affected?
• What facts are confirmed, suspected or unknown?

Use those answers to set a severity level and a review time. A fixed review rhythm, such as every 60 minutes during an active event, keeps decisions aligned.

Communication without creating more risk

Prepare separate updates for responders, leadership, staff, customers, partners and authorities. Each audience needs different detail. State what is known, what is not yet known, what action the recipient should take and when the next update will arrive.

Do not speculate about attribution or promise that “no data was affected” before investigation supports it. Do not use marketing language. Accurate, calm updates preserve more trust than premature certainty.

Notification duties may arise from contracts, regulators, sector rules, insurance terms or the type of data involved. Organisations should review their specific obligations with appropriate legal and regulatory advisers and keep the relevant reporting contacts inside the response plan.

Hours 4–24: eradicate carefully and plan recovery

1. Identify the likely entry path and persistence mechanisms.
2. Patch or mitigate the exploited weakness.
3. Rotate affected credentials, keys and tokens in a planned order.
4. Validate backups before restoring.
5. Restore the highest-priority service into a known-good environment.
6. Increase monitoring for repeated access or related indicators.
7. Document residual risk and the decision to return each service.

Recovery is not simply turning systems back on. Business owners, IT and the incident lead should agree that the restored service is sufficiently trusted, monitored and supported.

Seven mistakes to avoid

• Allowing many people to make independent changes
• Wiping affected devices before evidence is captured
• Resetting only one password when sessions or tokens remain active
• Restoring from a backup without fixing the original entry path
• Communicating certainty before the facts are established
• Keeping the only response plan inside an unavailable system
• Closing the incident without lessons, owners and deadlines

After the incident

NIST SP 800-61 Revision 3 treats incident response as part of ongoing cybersecurity risk management across Govern, Identify, Protect, Detect, Respond and Recover. That is the right lesson for a smaller organisation too: the incident should update asset records, access controls, monitoring, supplier decisions, training and leadership priorities.

A useful post-incident review asks which control, decision or assumption allowed the impact rather than which individual can be blamed.

Turn this guide into your plan

Assign names to the roles, replace generic systems with your actual services, add vendor contacts, define severity levels and rehearse one scenario. A two-hour exercise will reveal gaps that a document review cannot.

Explore Cybersecurity Advisory and Training or request an incident-response planning session.