Incident Response Plan: What to Do in the First Hours of a Cyber Attack

It is a Friday afternoon. An accounts staffer notices invoices going to a supplier that has suddenly changed its bank details, and a second person mentions their mailbox is sending emails they never wrote. Is this a mistake, a scam, or a live breach? Who decides? Who do you call first, and what do you touch before you touch anything else?

Most South Island businesses cannot answer those questions on the day it matters, because the answers were never written down. The staffer keeps processing invoices while they wait for someone to decide. The compromised mailbox keeps sending. The hours that decide how bad this gets tick past while the business works out who is in charge.

An incident response plan is what removes that hesitation. This guide walks through what one covers, the order the steps run in, and why having it ready before an attack lands can turn a business-ending week into a bad afternoon. It is written for the South Island owners and managers who carry this risk, not for security engineers, so the focus stays on decisions and people, not on tools and configuration. By the end you will know what your own plan should contain and how to keep it useful.

What Is an Incident Response Plan?

An incident response plan is a documented playbook for handling a suspected or confirmed security breach from the moment it is spotted to the moment normal operations resume. It names the people involved, the order of actions, the thresholds that trigger escalation, and the outside parties who must be contacted, so nobody has to improvise while an attacker is still inside the network.

The plan answers the practical questions a business freezes on during a real event. Who has the authority to disconnect a compromised machine? Which systems can be isolated without stopping the whole company from working? At what point does a suspicious email become a reportable privacy breach? A good plan has these decisions made in advance and written where the right people can reach them, including on paper, because the network you need the plan on may be the network under attack.

Incident response sits alongside your other resilience work instead of replacing it. It assumes you already have backups, monitoring, and staff who know how to raise the alarm, and it gives those pieces a sequence to follow when something goes wrong.

Incident response versus disaster recovery

These two are often confused, and the difference decides which plan you reach for. Incident response is what you run while an attack is live: detecting it, containing it, removing the attacker, and handling the legal and communication fallout. It is the security playbook for the event itself.

A disaster recovery plan covers a wider set of scenarios and focuses on getting systems and data back online after any disruption, whether that is a flood, a hardware failure, or the aftermath of a breach. Put simply, incident response handles the attack in progress, and disaster recovery handles the return to service once the threat is gone. The two hand off to each other: the recovery step in an incident response plan often hands the restore work to the disaster recovery plan, so both need to exist and both need to be tested.

Why Does Your Business Need One?

Your business needs an incident response plan because the first hours of a breach are when the most damage is done and the fewest people are thinking clearly. An attacker who gains a foothold on Friday can spend the weekend moving through systems. A business that spends that same weekend arguing about who is in charge loses ground it cannot get back.

Improvising is expensive in ways that are easy to picture. Someone wipes a compromised laptop to be safe, and destroys the evidence a forensic investigator needed to trace the attack. Someone emails the whole company a warning, and tips off an attacker who is reading that mailbox in real time. Someone decides to keep the breach quiet, and sails past the point where the Privacy Act required them to notify. Each of those is a reasonable-sounding decision made by a good employee under pressure, and each one turns a contained problem into a much larger and more costly one.

There is also a simple readiness gap. New Zealand businesses have invested heavily in prevention over the last few years, adding multi-factor authentication, endpoint protection, and staff training. Far fewer have written down what happens when prevention fails, which it eventually does. Meanwhile the people who write the cheques are starting to ask: cyber insurers want to see a plan before they quote, and clients in regulated sectors ask about it in vendor questionnaires. A written, rehearsed plan is quickly becoming a baseline expectation, not an optional extra.

What Are the Stages of Incident Response?

The stages of incident response are preparation, detection, containment, eradication, recovery, and review. Preparation happens before anything goes wrong; the other five run in order once a cyber incident is suspected, each with its own goal, so a business moves from confusion to control without skipping steps that matter later. You do not need to memorise the labels, but you do need someone who owns each one.

Detect and confirm

The first job is to work out whether you actually have an incident. Alerts, staff reports, and unusual behaviour all point to something, but not every strange email is an attack. This stage confirms the threat is real, records when and how it was spotted, and starts a timeline that will matter for both the investigation and any notification duty. Confirmation should be fast but deliberate, because both overreacting and underreacting carry cost.

Contain

Once confirmed, the priority shifts to stopping the spread. Containment means isolating affected accounts and devices so the attacker cannot reach further, without destroying the evidence needed later. This is where advance decisions earn their keep. Knowing which systems can be pulled offline, and who is allowed to make that call at nine on a Saturday night, saves the minutes that decide how far an attack travels.

Eradicate and recover

Eradication removes the attacker’s access for good, closing the door they came through and any others they opened. Only then does recovery begin, restoring systems and data from clean sources and confirming everything is working before staff return to normal. Rushing recovery before eradication is complete is a common and costly mistake, because it lets the attacker straight back in. The restore work itself often follows your disaster recovery plan, which is why the two documents need to line up.

Review and improve

After the event, a calm review captures what happened, what worked, and what did not. The point is not to find someone to blame. It is to close the gaps the incident exposed so the next one is handled better or avoided entirely. The review feeds directly back into preparation, and a plan that is never reviewed slowly drifts out of date as staff, systems, and threats change.

Who Should Be on Your Incident Response Team?

An incident response team should combine technical, decision-making, and communication roles, because a breach is never only a technical problem. In a small business these roles may sit with a handful of people wearing several hats, but each role still needs a named owner who knows it is theirs.

The core roles are a response lead who runs the process and makes the call on containment; a technical lead, often your IT provider, who does the hands-on isolation and investigation; a communications owner who handles messages to staff, clients, and the public; and a decision-maker with the authority to approve costs, notify authorities, and if necessary shut down trading. For many South Island firms the technical lead is an outside partner, so the plan needs their after-hours number and a clear agreement on what they are authorised to do without waiting for sign-off.

Your people are your earliest warning system. Staff who can recognise something wrong and know exactly how to report it often catch an incident hours before any monitoring tool does, which is why security awareness training and a clear reporting route belong inside your response capability, alongside the technical roles.

What Are Your Legal Obligations After a Breach?

A cyber attack is not only an IT problem; it is a legal one, and the clock starts the moment you know. Under the Privacy Act 2020, a New Zealand business must notify the Office of the Privacy Commissioner and the affected people as soon as practicable if a privacy breach has caused, or is likely to cause, serious harm. Get this wrong, by notifying late or not at all, and the consequences land on the business regardless of how well the technical side was handled.

Deciding whether a given incident crosses the serious-harm threshold, and handling the notification correctly, sits within the wider set of privacy duties your IT setup has to support. Rather than repeat that ground here, the detail on what the law requires and how your systems should be set up to meet it is covered in our guide to NZ Privacy Act compliance. What matters for the response plan is that the notification decision is built into the sequence, with a named owner and a clear trigger, so it is not forgotten in the rush to fix the technical problem.

Alongside the privacy duty, your plan should account for contractual obligations to clients, any sector-specific rules that apply to your industry, and the terms of your cyber insurance policy, which usually require prompt notification to the insurer as a condition of cover. Missing an insurer deadline can void a claim at the worst possible moment.

How Do You Build and Test a Plan?

You build an incident response plan by writing down the decisions and contacts your business would otherwise have to work out mid-crisis, then rehearsing it until the steps feel familiar. A plan that exists only as a document nobody has read is barely better than no plan at all, because the value is in the practice as much as the paper.

Start by listing your most likely and most damaging scenarios — the kinds of cyber attacks most likely to hit your business — such as a compromised email account, ransomware, or a supplier breach that reaches you. For each, write the first three actions, the person who owns them, and who they escalate to. Keep the contact list current, store a copy offline, and make sure more than one person can reach it. The plan should be short enough that a stressed person can follow it, not a fifty-page manual that sits unread.

Testing turns the document into a capability. A tabletop exercise, where the team talks through a realistic scenario step by step, exposes the gaps quickly and cheaply: the phone number that is out of date, the decision nobody is sure they can make, the system that cannot actually be isolated the way the plan assumes. Running one once or twice a year, and after any major change to your systems or team, keeps the plan honest.

Early detection makes every later stage easier, which is why many businesses pair a response plan with managed detection and response, so that threats are caught and contained in their early stages rather than discovered days later. The plan and the monitoring work together: the monitoring surfaces the incident, and the plan governs what happens next.

What Goes Wrong Without a Plan?

Without a plan, businesses lose time, evidence, and trust in the exact order that does the most harm. Time is lost while people work out who is in charge. Evidence is lost when a well-meaning staffer wipes a machine or resets an account before it can be examined. Trust is lost when clients hear about a breach from someone other than you, or when a required notification arrives late.

The financial picture compounds these. Downtime has a daily cost, an uninsured or under-notified claim can be declined, and the reputational hit of a badly handled breach outlasts the technical recovery by months. A well-run response, by contrast, is often invisible to customers, because the business contained the problem, met its duties, and recovered before the damage spread. Whether a breach becomes a footnote or a headline usually comes down to one thing: whether the plan existed before the attack. A modest business with a rehearsed one-page plan routinely handles an incident better than a well-equipped one that has never practised, because the plan puts the right decisions in the right hands at the moment they are needed.

Get Your Incident Response Plan in Place Before You Need It

Exodesk helps Christchurch, Dunedin, and South Island businesses build and rehearse incident response plans that fit how they actually work, so the first hours of an attack are governed by a clear sequence rather than guesswork. We combine the plan with the monitoring and recovery capability that make it effective, and we are on the end of the phone when it matters.

Contact us today to discuss how we can help your business or connect with us on LinkedIn to stay updated with more insights.

Frequently Asked Questions

What is an incident response plan?

An incident response plan documents how a business reacts to a suspected or confirmed cyber attack, covering everything from the moment it is noticed to the return of normal service. The document assigns clear responsibilities, sets the order in which actions are taken, and lists the authorities, insurers, and clients who need to be told. Its purpose is to give staff a calm, tested sequence to work through when an emergency would otherwise cause chaos.

What is the difference between incident response and disaster recovery?

Incident response deals with a security attack while it is happening, covering detection, containment, and removing the threat. Disaster recovery focuses on restoring systems and data after any disruption, including the aftermath of a breach. A business needs both, and the recovery stage of an incident response plan usually hands over to the disaster recovery plan.

What are the main stages of incident response?

The main stages are preparation, detection, containment, eradication, recovery, and a review afterward. Preparation happens before any incident, and the remaining stages run in order once a threat is suspected. Each stage has a clear goal, which keeps the response organised instead of reactive.

Who should be on an incident response team?

An incident response team needs a response lead, a technical lead, a communications owner, and a senior decision-maker with the authority to approve costs and notify authorities. In a small business one person may hold several of these roles, but each role should have a named owner. For many firms the technical lead is their outsourced IT provider.

Do small businesses really need an incident response plan?

Small businesses need an incident response plan as much as large ones, because they are frequently targeted and usually have fewer resources to absorb a poorly handled breach. A short, practical plan that fits the size of the business is enough. The point is to have the key decisions made in advance rather than during the crisis.

How often should an incident response plan be tested?

An incident response plan should be tested at least once or twice a year, and again after any major change to systems, staff, or suppliers. A tabletop exercise, where the team talks through a realistic scenario, is the most practical way for most businesses. Testing reveals out-of-date contacts and unclear decisions before a real event does.

What legal obligations follow a data breach in New Zealand?

Under the Privacy Act 2020, a business must notify the Office of the Privacy Commissioner and affected individuals as soon as practicable when a privacy breach is likely to cause serious harm. There may also be contractual and insurance notification duties. Building the notification decision into the response plan ensures it is not overlooked during a technical emergency.

What is the first thing to do when you suspect a breach?

The first step in any breach response is to confirm whether the incident is real and start recording what you find, including the time it was noticed. Avoid deleting anything or resetting affected accounts before the threat is understood, because that can destroy evidence an investigator needs. Once confirmed, follow your plan to contain the affected systems and alert the response lead.

How is an incident response plan different from cyber insurance?

Cyber insurance covers some of the financial cost after an incident, while an incident response plan governs the actions your business takes during one. Insurers increasingly require a plan as a condition of cover and expect prompt notification when an incident occurs. The two work together: the plan reduces the damage, and the insurance helps meet the cost that remains.

Can an outsourced IT provider run incident response for us?

An outsourced IT provider can lead the technical side of incident response and often does, handling detection, containment, and recovery. The business still needs to own the decisions that are not technical, such as notifying authorities, communicating with clients, and approving costs. The strongest arrangement is a shared plan that spells out who does what before an incident occurs.