| An incident response plan records who leads a suspected cyber incident, how staff report it, which actions are authorised and how the business keeps operating. It brings technical response, communication, privacy decisions and recovery together, and it should be available even if your usual email or network cannot be trusted. |
A changed supplier bank account, a mailbox sending messages nobody wrote, or files that suddenly will not open can all be the first sign of a cyber incident. The hours that follow go better when an incident response plan already tells the people involved who to call, what they may do and where to record it.
This guide is for owners and managers rather than security engineers. It covers the first actions on a suspicion, what an incident response plan should contain, who belongs on the team, how response, recovery and notification fit together, and how to test the plan before it is needed.
What should you do when you suspect a cyber incident?
Report the concern immediately to the incident lead and IT response contact through the route in your plan. Use a separate, trusted channel if email or an account may be compromised. Record what happened and when, without continuing the affected transaction or opening suspicious material again.
The response team assesses the available information and takes proportionate containment. That may include isolating affected devices or blocking a compromised account under agreed authority. Investigation continues alongside those actions; staff do not need to prove a breach before raising the alarm.
The right first containment depends on the incident. With ransomware, prompt isolation of affected devices can limit the spread. With a compromised Microsoft 365 account, Microsoft’s guidance on responding to a compromised email account recommends disabling the account while the investigation runs, revoking active sessions and checking forwarding and inbox rules. A password change on its own is not a complete response.
Avoid wiping, rebuilding or making uncoordinated changes. Keep relevant messages and records, and log the actions taken. Your technical lead balances preserving evidence with stopping harm, because power-offs, reboots, isolation and rebuilds have different effects. If a fraudulent payment may have been sent, contact your bank immediately through a trusted route; recovery of the money is not guaranteed.
What should your incident response plan contain?
Each line of the plan records a decision made in advance, so nobody has to work it out under pressure. Use the table as a checklist for your own version.
| Item | Decision to record |
|---|---|
| Lead and deputy | Who coordinates, approves spending and acts if the usual lead is unavailable. |
| Reporting route | How staff raise a suspicion, including outside agreed support hours. |
| Trusted contacts | IT, providers, insurer or broker, legal and privacy help, and bank contacts. |
| Containment authority | Who may isolate devices, suspend accounts or stop affected transactions. |
| Incident record | Where facts, times, actions, decisions and evidence locations are recorded. |
| Communication | A trusted alternative channel, the update owner, and staff and customer messages. |
| Notification | The privacy assessment owner, contractual duties, insurer terms and NCSC reporting. |
| Continuity and recovery | Essential workarounds, restoration checks and who approves the return to service. |
The government’s Own Your Online service publishes an editable incident response plan template that makes a practical starting point. Filling in a template does not establish readiness on its own, so check the contacts, permissions and alternative communication route actually work.
Keep a protected copy of the incident response plan available offline and another accessible to the deputy. Store credentials separately in your approved password manager rather than in the plan itself.
Length is not the measure. A one-page incident response plan summary can point to detailed contact lists and technical procedures, as long as the people named can find both when normal systems are unavailable. Write it for the realistic incidents your business faces, such as a compromised mailbox, ransomware or a supplier breach that reaches you, and use the real names of your systems and suppliers rather than generic placeholders.
Which mistakes slow down a response?
The costly errors in the first hours can come from good staff making reasonable-sounding decisions without a plan. Each of these can be prevented by writing the decision down in advance.
- Waiting for certainty. Holding back a report until someone is sure lets harm continue. Report the suspicion and let the response team assess it.
- Warning everyone through a compromised channel. An all-staff email from a mailbox an attacker can read may alert the attacker. Use the trusted alternative channel in the plan.
- Wiping or rebuilding too early. A well-meant rebuild can remove the records an investigation needs. Coordinate changes through the technical lead.
- Treating a password reset as the fix. Active sessions, forwarding rules and connected apps can keep access open after a password change.
- Restoring before agreed checks. Bringing a service back from backup before containment and access are checked can let the problem return.
- Leaving notification until the end. The privacy assessment belongs early in the response, not after recovery is finished.
A short incident response plan that names who decides each of these points removes much of the hesitation. Each item is also a useful prompt in a tabletop exercise.
Who should be on your incident response team?
A cyber incident is not only a technical problem, so the team combines technical, decision-making and communication roles. In a small business one person may hold several roles, but each role still needs a named owner who knows it is theirs.
- Response lead and deputy. Coordinates the response, keeps the incident record moving and acts as the single point of contact.
- Technical contact. Carries out or directs containment and investigation, whether that is an internal person or your IT provider.
- Senior decision-maker. Approves spending, operational changes and, where needed, pausing parts of the business.
- Communication owner. Prepares and sends messages to staff, customers and suppliers through trusted channels.
- Privacy assessment owner. Decides whether personal information is affected and whether the breach is notifiable.
- Continuity owner. Keeps essential work going through agreed workarounds while affected services are dealt with.
Where the technical contact is an outside provider, the incident response plan needs their after-hours route and a clear agreement on what they may do without waiting for sign-off. Staff are the earliest warning system, which is why training staff to spot and report attacks belongs in your response capability alongside the named roles.
How do response, recovery and notification fit together?
The familiar labels of preparation, detection and analysis, containment, eradication, recovery and review remain useful headings. They are not a fixed queue. Analysis and containment can repeat, while communication, records, legal assessment and continuity run alongside the technical work. NIST’s incident response guidance, revised in 2025, treats reporting during the response and the decision to start recovery in the same risk-based way.
Keep essential work operating through agreed fallbacks while the affected services are dealt with. Begin the privacy assessment and required communications during the response. Restore each service when the response lead and technical team judge the containment, the integrity of the source, access and monitoring adequate for that service. Do not reconnect untrusted systems simply because a backup exists, and continue investigating and monitoring as required.
A post-incident review records what happened, what worked and what did not, then assigns improvements to owners and dates. The aim is to close the gaps, not to find someone to blame.
How is incident response different from disaster recovery?
Incident response manages the security event and its impact: who acts, what is contained, what is recorded and who is told. A disaster recovery plan restores systems and data against agreed recovery priorities and tested arrangements, whatever caused the disruption.
During a cyber incident the two overlap. Continuity work and restoration can start for a service once agreed conditions are met, while investigation, monitoring and notification continue. Disaster recovery is not a separate process that waits until the entire threat has gone, so your incident response plan and disaster recovery plan need to name the same people and agree how a service is approved for return.
When do you need to notify a privacy breach?
Under the Privacy Act 2020, a privacy breach is notifiable when it has caused, or is likely to cause, serious harm. The duty follows awareness of a notifiable breach, not every suspicious email. Notify the Privacy Commissioner and affected people as soon as practicable, considering any exceptions or permitted delay for notifying individuals. Do not wait for complete facts or finished recovery.
The Privacy Commissioner expects notification within 72 hours of becoming aware that a breach is notifiable. Its statement on how long 72 hours is describes that timeframe as a guide rather than a statutory deadline, and notifications can be updated as facts develop.
- Owner and deputy. Name who makes the privacy assessment and who acts if that person is unavailable.
- Recorded decision. Record the assessment, the reasons and the time, including a decision not to notify.
- Other duties. Contractual notice to customers, insurer notice under the policy and sector requirements are separate from the privacy duty.
- NCSC reporting. The National Cyber Security Centre accepts incident reports and requests for support, which serve a different purpose from privacy notification.
Our guide to NZ Privacy Act compliance covers the wider privacy duties your systems need to support.
How does cyber insurance fit with the plan?
The plan coordinates action, while cyber insurance responds according to the terms of the policy. Check the actual conditions rather than assuming what insurers require across the market. Some policies provide access to a specialist response panel that coordinates forensic, legal and communication help, and the policy may set who can be engaged for insured work.
Record the insurer or broker contact route, the notice requirements, any panel arrangements and any approval conditions in the incident response plan before an incident. Whether a policy responds depends on its wording and the circumstances, so keep the policy contact separate from the technical and privacy decisions.
How do you test an incident response plan?
A tabletop exercise, where the team talks through a realistic scenario step by step, shows quickly whether the plan works. Review the plan after an incident or a significant change to people, systems or providers, and schedule exercises that match the risk to the business.
Choose a realistic scenario
Pick an incident the business could plausibly face, such as a compromised mailbox combined with changed supplier payment details, or a day when email and the shared files are unavailable.
Run it with the deputy
Assume the usual lead is unavailable. Can the deputy reach IT support through a trusted channel, stop a questioned payment, authorise account containment and start the privacy assessment?
Check contacts, access and authority
Call the numbers, test the alternative channel and confirm that the people named can take the actions the plan gives them, at the hours the plan assumes.
Assign the gaps
Record what did not work, give each gap an owner and a due date, and update the plan. Track the gaps to completion rather than filing the exercise notes.
A second scenario where email and the shared files are unavailable tests the alternative channel and the offline copy. Contacts, access and authority are the gaps an exercise can expose first.
What can an IT provider or MDR service cover?
An outsourced IT provider can carry out agreed technical work and coordinate with specialists. Agree the support hours, escalation route, the actions it may take without sign-off and the specialist help available before an incident, rather than relying on someone being reachable when it matters.
Managed detection and response monitors connected sources, investigates alerts and takes approved technical response. It does not automatically include full forensics, legal advice, notification or business recovery. The business keeps its decisions about operations, spending, privacy and communication, with advisers involved where needed. Record which services the provider covers, and which it does not, in the incident response plan.
Incident response planning support from Exodesk
Exodesk can help you set out the roles, escalation routes and containment authority in your incident response plan, connect it to your monitoring and recovery arrangements, and rehearse it with the people who will use it. Response hours and scope are agreed in advance, so everyone knows what support is available and when.
Exodesk has supported New Zealand businesses since 1989. Today, our Christchurch and Dunedin teams support businesses nationwide.
NEXT STEP
Want your response roles agreed before an incident?
Tell us who would lead today, which systems the business depends on and what support hours you need, and we can discuss the plan and a rehearsal. Please keep passwords and incident details out of the enquiry form.
Or see our managed detection and response service.
Frequently Asked Questions
What is an incident response plan?
It records how a business handles a suspected or confirmed cyber incident: who leads, how staff report it, what containment is authorised, and how communication, notification and recovery are coordinated. Keep it accessible outside the affected systems and rehearse the decisions before it is needed.
What is the difference between incident response and disaster recovery?
Incident response manages the security event and its impact. Disaster recovery restores affected systems and data after a disruption. They overlap during a cyber incident, because continuity and restoration can start when agreed conditions are met while investigation, monitoring and notification continue.
What are the main stages of incident response?
Preparation, detection and analysis, containment, eradication, recovery and review are useful headings, but they are not a fixed queue. Communication, records and notification run alongside the technical work, and the team may revisit earlier decisions as the incident becomes clearer.
Who should be on an incident response team?
Name a response lead and deputy, a technical contact, a senior decision-maker, a communication owner and a privacy assessment owner, plus someone responsible for keeping essential work going. Small businesses may combine roles, but authorisation, availability and the route to specialist help still need to be clear.
Do small businesses need an incident response plan?
A short, tailored plan helps a small team avoid working out contacts and authority during an incident. Include the real systems, suppliers, reporting routes, notification decisions and recovery arrangements. A one-page summary can point to detailed contacts and procedures, but its length alone does not make it effective.
How frequently should an incident response plan be tested?
Review it after an incident or a significant change to people, systems or providers, and schedule exercises that match the risk to the business. Each exercise should check contacts, deputies, permissions and actions. Assign the gaps it finds to owners with due dates.
What legal obligations follow a data breach in New Zealand?
A notifiable privacy breach must be notified to the Privacy Commissioner and affected people as soon as practicable, subject to the exceptions and permitted delays in the Privacy Act. The threshold is serious harm that has occurred or is likely. Assess promptly, record the decision and update notifications as facts develop, without waiting for every detail.
What is the first thing to do when you suspect a breach?
Report it immediately through your agreed incident route and record what you noticed, using a trusted alternative channel if normal email may be compromised. Authorised responders then assess the risk and contain it proportionately while they investigate. Do not wait for certainty before raising the alarm, and avoid uncoordinated changes.
How is an incident response plan different from cyber insurance?
The plan coordinates action, while insurance responds according to the terms of the policy. Record the insurer contact route, notice requirements, panel arrangements and any approval conditions before an incident. Do not assume every policy requires the same plan, covers every cost or lets any provider carry out insured work.
Can an outsourced IT provider run incident response for us?
It can carry out agreed technical work and coordinate with specialists. Confirm the hours, connected systems, authorisation, escalation and recovery scope in advance. The business keeps its decisions about operations, spending, privacy and communication, and monitoring or ordinary IT support does not automatically include every response service.
Contact us or call 0800 396 337 to discuss your plan, its roles and a rehearsal.
