How to Build an Incident Response Plan That Works

A suspicious email is opened. A staff member’s Microsoft 365 account begins sending invoices to customers. Or a critical system stops responding at 8:15 on a Monday morning. The first few minutes determine whether your team acts calmly or loses valuable time debating who should do what. When you build an incident response plan, you give people a practical way to contain the problem, protect customers and keep the business moving.

An incident response plan is not a lengthy policy written for an audit and forgotten in a shared folder. It is a set of agreed decisions, contacts and actions for handling cyber security events and major technology disruptions. It should be clear enough for a manager to use under pressure and detailed enough for your IT team or provider to act without delay.

What an incident response plan needs to achieve

The aim is not to prevent every incident. No business can promise that. The aim is to reduce the impact when something does go wrong: less downtime, less data exposure, clearer communication and faster recovery.

For a small or mid-sized business, the plan should answer four questions straight away: what has happened, who is in charge, what actions are authorised, and who needs to be told. If those answers are missing, well-meaning people can make matters worse by deleting evidence, resetting the wrong accounts or sending premature updates to customers.

Your plan should sit alongside, not replace, your business continuity and disaster recovery arrangements. Business continuity covers how you keep operating during a disruption. Disaster recovery focuses on restoring systems and data. Incident response deals with investigating, containing and managing the immediate security or technology event. They overlap, but they have different jobs.

Start with the incidents most likely to affect your business

A useful plan reflects how you actually work. A construction business relying on mobile access to job systems has different risks from a professional services firm holding sensitive client documents. Begin with a short risk workshop involving operations, finance, management and IT.

Consider the systems that would cause the greatest disruption if unavailable or compromised. This may include email, Microsoft 365, accounting software, customer relationship management systems, file storage, internet connectivity, phones, cloud applications and line-of-business software.

Then identify realistic incident scenarios. Common examples include phishing and account takeover, ransomware, fraudulent invoice changes, lost or stolen devices, unauthorised access to cloud data, supplier compromise and outage of a critical service. If your team uses AI tools, also consider accidental sharing of confidential information, overly broad access to internal knowledge, or an automated workflow taking the wrong action at scale.

You do not need a separate 40-page document for each scenario. A core plan supported by short playbooks is usually more practical. The core plan explains the overall process, responsibilities and communications. Each playbook gives the first actions for a specific event.

Assign roles before an incident happens

Titles matter less than clarity. In a smaller business, one person may hold several responsibilities, but every role needs a backup. Include personal mobile numbers or an accessible offline contact list in case email and collaboration platforms are unavailable.

Your plan should nominate an incident lead with authority to coordinate decisions and escalate issues. It should also identify the technical lead, usually your internal IT team or managed service provider, the business decision-maker, a communications contact and a finance contact for payment or fraud-related events.

Be explicit about authority. Can the technical lead disable an employee account immediately? Who can approve shutting down a system to stop an attack spreading? Who communicates with affected customers? Waiting for permission can be costly, but giving everyone unrestricted authority creates its own risks.

For organisations using an outsourced IT partner, define the handover clearly. Your provider can investigate, contain and recover systems, while your leadership team makes business decisions about operations, customer communication, legal advice and reputational issues. At OzeIT, we find this split helps businesses move quickly without losing control of the decisions that only they can make.

Build an incident response plan around clear phases

Most incidents move through the same broad stages, even if the technical details differ.

1. Identify and assess

Record what was observed, when it was first noticed, which systems or people may be affected, and who reported it. Avoid assumptions in the early stages. A failed login could be a forgotten password, or it could be the first sign of account compromise.

Assess severity based on business impact, data sensitivity, the number of users affected and whether the event is ongoing. A suspected ransomware infection on one device is different from confirmed access to a database containing customer information. Your plan should include simple severity levels so the team knows when to escalate.

2. Contain without destroying evidence

Containment limits further damage. It may mean isolating a computer from the network, disabling a compromised account, blocking a malicious email sender, revoking active sessions or pausing an automated workflow.

The trade-off is that containment can interrupt normal work. Disconnecting a server may affect a whole department, while leaving it online may allow an attacker to move further through the network. The incident lead should make this decision with technical advice and document why it was made.

Preserve useful evidence where possible. Save suspicious emails, timestamps, system alerts and relevant logs. Do not ask staff to investigate on their own or delete messages because they look suspicious. Evidence helps determine the scale of the incident and may be needed for insurers, legal advisers or regulatory reporting.

3. Eradicate and recover

Once contained, remove the cause. This could involve resetting credentials, removing malicious software, patching a vulnerability, correcting access permissions or rebuilding an affected device. Recovery means restoring systems safely, checking backups and monitoring for signs the issue returns.

Backups deserve particular attention. A backup that has never been tested is an assumption, not a recovery strategy. Confirm how often critical data is backed up, where copies are held, who can access them and how long a full restoration would take. Some businesses can tolerate a few hours without a system; others need a workaround within minutes. Your recovery objectives should match that reality.

4. Communicate and improve

Provide staff with short, accurate instructions. For example, tell them whether to change passwords, avoid a system, send customer enquiries elsewhere or report suspicious messages. They do not need technical detail, but they do need to know what to do next.

External communication depends on the incident. You may need to speak with customers, suppliers, cyber insurers, banks or legal advisers. If personal information may have been accessed, assess obligations under Australia’s Notifiable Data Breaches scheme. Not every incident requires notification, but delaying the assessment can make a difficult situation harder to manage.

After recovery, hold a review while details are fresh. Focus on what happened, what worked, where decisions slowed down and what controls need to change. This is about improving the system, not blaming the person who reported the issue.

Create short playbooks for high-risk events

A playbook turns the main plan into an immediate checklist. Keep it to one or two pages where possible and make it available offline. For a business email compromise playbook, the first steps may include disabling the affected account, revoking sessions, checking mailbox forwarding rules, alerting finance to payment fraud risks and reviewing recent sent emails.

For ransomware, the playbook may call for isolating affected devices, preserving evidence, checking whether shared drives or cloud storage are affected, confirming backup status and contacting your IT provider. Do not assume paying a ransom will restore operations or keep stolen information private. The right response depends on the facts, the business impact and advice from relevant specialists.

Include an AI and automation playbook if these tools connect to business systems. Pause the automation if it is making incorrect updates, identify what data or records were affected, review access logs and restore approved data where needed. Human review points are especially valuable when an automated process can send customer messages, approve documents or update financial records.

Test the plan when nothing is on fire

A plan only works if people can use it. Run a short tabletop exercise at least annually, and after major changes such as a new cloud platform, acquisition, office move or significant automation rollout. Give the group a realistic scenario and ask what happens in the first 15 minutes, first hour and first day.

Testing often exposes ordinary but serious gaps: an outdated contact number, unclear approval limits, missing access to backups or a key supplier who has not been included. Fix these issues and update the plan. A simple test that leads to improvements is far more useful than a perfect-looking document no one has rehearsed.

Keep the final plan accessible, current and proportionate to your business. The best time to build an incident response plan is before an incident forces your team to invent one under pressure.