On a normal Tuesday, your finance manager gets an email that looks like it came from a supplier. The branding is right. The tone is right. The bank account details are not. At almost the same time, one staff member rings IT because their screen has locked up and a strange message is asking for payment. Nobody in the business is asking for a textbook definition of a cyber incident at that point. They want to know who makes decisions, what gets shut down, what gets saved, and how the business keeps operating.
That's what security incident response really is. It's not a security team's private checklist. It's the practical system your business uses to make good decisions under pressure, contain damage, protect evidence, communicate clearly, and get back to work without making the problem worse.
For SMBs in New Zealand and Australia, this matters because response capacity is usually thin. The same person might handle IT, vendors, compliance, and half the operational firefighting in a given week. If your plan lives only in one person's head, you don't have a plan. You have a dependency.
When a Crisis Hits What Is Your Plan
A lot of owners still think of cyber incidents as the dramatic stuff. Ransomware on every screen. News headlines. Full business shutdown. In practice, the first sign is often smaller and messier. A mailbox starts sending messages the user never wrote. A payroll change request looks legitimate until someone double-checks it. A cloud file share suddenly has odd permission changes. By the time the business realises something is wrong, people are already improvising.
Security incident response is the organised process for handling that moment. It answers four business questions fast. What happened. What is affected. What do we do next. Who needs to know.
New Zealand has built a clearer national reporting path for this kind of event. CERT NZ was formally launched in April 2017, and in its first full year it handled over 1,300 incident reports, which shows how quickly a national channel for cyber incident coordination became part of the local response environment, according to CERT NZ. That matters because incident response isn't an abstract enterprise exercise anymore. It's part of how real businesses in this market detect, triage, and escalate problems.
Practical rule: If your first response step is “figure out who should lead this”, you're already behind.
For a smaller business, a useful plan doesn't need to be elegant. It needs to be usable. A one-page contact list, a decision tree for isolating devices, a simple communication template, and clear access to managed security support will beat a polished fifty-page document nobody can follow under stress.
The shift in mindset is simple. Stop asking whether an incident will happen. Start asking whether your business can stay calm and organised when it does.
The 7 Phases of Effective Incident Response
A good way to understand incident response is to think about a building fire. You don't start planning once the smoke alarm goes off. You prepare exits, assign wardens, run drills, check extinguishers, and decide who calls emergency services. Cyber response works the same way. The names are more technical, but the flow is familiar.
Preparation
Preparation is the fire drill before the fire. It involves deciding who's on point, what tools you trust, where logs are stored, how backups are verified, which systems are most critical, and when to escalate.
For SMBs, preparation often fails because it becomes too ambitious. You don't need an enterprise-grade command centre to start. You need working basics:
- Contact clarity for internal decision-makers, IT support, legal advisers, cyber insurer, and key vendors
- Asset priority so people know which systems matter most to revenue, operations, and customer service
- Access readiness including admin accounts, MFA recovery paths, and emergency device isolation procedures
- Evidence discipline so staff know not to wipe machines or “clean up” before the issue is assessed
Detection and Analysis
Detection is noticing smoke. Analysis is figuring out whether it's burnt toast or an electrical fire in the wall.
Public reporting from CERT NZ shows thousands of reports annually, with phishing and scams among the common incident types, which is why time to detect and time to contain matter so much for local SMBs handling both major incidents and high-volume disruptive events, as noted earlier from CERT NZ. In plain terms, speed matters because small incidents spread.
Analysis should answer a tight set of questions:
| Question | Why it matters |
|---|---|
| What triggered the alert | Helps separate noise from a genuine incident |
| Which users or systems are involved | Defines the scope |
| Is the threat still active | Drives urgency |
| What business process is exposed | Connects technical events to real-world impact |
A common mistake is over-investigating too early. If an account is actively compromised, containment usually matters more than perfect certainty.
A short explainer helps here:
Containment and Eradication
Containment is closing the fire door so flames don't spread. Eradication is removing the burning source.
Containment actions might include isolating a device, disabling a user session, revoking tokens, blocking a mailbox rule, or cutting off a third-party connection. Eradication comes after that. Remove malware. Reset compromised accounts. Clean persistence mechanisms. Patch the exploited weakness.
If you skip containment and jump straight to cleanup, you often give the attacker time to move elsewhere.
Recovery and Post-incident Activity
Recovery is reopening the building safely, not just turning the lights back on. Systems come back in a controlled order. Users regain access in stages. Monitoring stays heightened because some threats return through the same gap.
The final phase is where most SMBs lose value. They breathe out and move on. Don't. Post-incident review is where you tighten permissions, fix process weaknesses, improve detections, and update playbooks so the same failure doesn't happen twice.
The seven phases are simple on paper. Under pressure, they're only useful if your team can follow them without debate.
Creating Your Incident Response Playbooks
Frameworks are useful. Playbooks are what people use at 8:15 on a Friday morning when someone says, “My email is sending things by itself.”
A playbook is a short, incident-specific checklist. It shouldn't read like policy. It should read like instructions for a capable person who is stressed, interrupted, and short on time. If your team has to interpret every step, the playbook is too vague.
Start with the incidents you're most likely to face
New Zealand's NCSC says human interaction is a factor in most cyber incidents, which is why strong playbooks prioritise quick user and session isolation, identity checks, and response steps for phishing or credential theft, as referenced in this incident response guidance summary.
That has a practical implication. Your first playbooks shouldn't be built around exotic attack paths. Start with the everyday incidents:
- Compromised Microsoft 365 or Google Workspace account
- Malware or ransomware on a workstation
- Fraudulent payment or supplier email impersonation
If you want these to stick, treat them as operational documents and fold them into broader process improvement work, not just IT policy.
Playbook example for a compromised email account
Use this when a user reports suspicious mailbox activity, unknown sent items, MFA prompts they didn't initiate, or rules forwarding mail externally.
Confirm the report
Check with the user by phone or in person. Don't rely on email if the mailbox may be compromised.Contain the account
Disable sign-in or revoke active sessions. Reset credentials and enforce MFA re-registration if required.Preserve evidence
Record affected user, time first noticed, suspicious messages, mailbox rules, sign-in anomalies, and any related financial requests.Check blast radius
Review whether the account sent phishing emails internally, accessed shared files, or triggered password resets elsewhere.Notify key people
Inform the incident lead, IT support, finance if payment workflows are involved, and managers of impacted teams.Remediate
Remove malicious inbox or forwarding rules. Review delegated access, app consents, and recovery settings.Communicate internally
Tell staff what to watch for. Keep it factual. Don't speculate.
Playbook example for malware or ransomware on a device
This one needs discipline. People often panic and start clicking around. That can make things worse.
Field advice: If a device looks infected, isolate first and investigate second.
- Disconnect the device from network access if you can do so safely
- Tell the user to stop using it and avoid rebooting unless instructed by the response lead
- Identify business impact by checking what files, shares, or applications the device could reach
- Capture what you can such as screenshots, ransom notes, filenames, timestamps, and user observations
- Decide on spread risk before reconnecting anything or restoring from backup
- Rebuild or clean based on the severity and confidence of the investigation
- Reset related credentials if the device had privileged or saved access
What good playbooks include
The best playbooks are short enough to use and specific enough to reduce hesitation.
| Element | What it should contain |
|---|---|
| Trigger | The event that activates the playbook |
| Owner | The person responsible for leading the response |
| First 15 minutes | Immediate containment and reporting actions |
| Evidence list | What to preserve before changes are made |
| Escalation point | When to involve outside specialists |
| Comms notes | Who gets updated and how |
A playbook shouldn't impress an auditor. It should help your team do the next right thing.
Building Your Incident Response Team
Most SMBs don't have a formal cyber incident response team sitting around waiting for trouble. They have a handful of internal people, one or two external providers, and a lot of overlapping responsibilities. That's fine, as long as the overlap is deliberate.
The mistake is assuming “IT will handle it”. IT can handle technical triage. It usually can't also run executive decisions, customer communications, evidence handling, legal judgement, insurance coordination, and business continuity all at once.
Think in roles, not job titles
Outside advisers have warned organisations to plan for non-technical surge capacity, including legal and business continuity support. For NZ SMBs, where key staff often wear multiple hats, that means identifying backup people and external specialists before the incident happens, as discussed in this cyber incident readiness article.
A practical SMB response team often looks like this:
Incident commander
Usually an operations lead, owner, or senior manager. This person makes decisions, sets priorities, and breaks ties.Technical lead
Internal IT manager, MSP, or security provider. Owns investigation, containment, and recovery tasks.Business lead
Someone who understands which customers, staff, sites, or services are affected first.Communications lead
Handles internal updates and any customer, supplier, or partner messaging.External support
Legal counsel, insurer, forensic specialist, or cloud provider contact when needed.
Use a simple RACI so people don't trip over each other
RACI stands for Responsible, Accountable, Consulted, Informed. It's one of the easiest ways to remove ambiguity.
Here's a stripped-down example for a compromised email account:
| Task | Owner | IT lead | Finance lead | GM | External adviser |
|---|---|---|---|---|---|
| Disable account access | I | R | I | A | C |
| Assess payment fraud exposure | I | C | R | A | C |
| Approve staff communication | I | C | I | A | C |
| Preserve logs and evidence | I | R | I | I | C |
| Decide on external notification | I | C | C | A | C |
In a smaller business, one person may sit in two or three of those boxes. That's normal. What matters is that each action still has one accountable owner.
If two people think they're in charge during an incident, nobody is.
Build for absence, not ideal staffing
Assume your key person is on leave, offline, or directly affected by the incident. That changes how you staff your plan. Every critical role needs a deputy. Every outside specialist should already be named. Every playbook should state who steps in if the primary contact can't respond.
That's how a small team behaves like a larger, more resilient one.
Measuring and Improving Your Readiness
A plan you've never tested is just optimism in document form. The only useful question is whether your business can spot an incident, contain it, and recover without confusion.
That's where metrics help. Not because executives love dashboards, but because metrics answer blunt operational questions. How long did it take us to notice. How long did it take us to stop the bleeding. How long until people could work safely again.
Track the few metrics that change decisions
For SMBs, I'd keep the first scorecard tight:
Time to detect
How long the incident was active before someone recognised it as a real problem.Time to contain
How long it took to stop spread, cut access, or isolate the affected asset.Time to recover
How long before the business-critical service was safely usable again.Escalation delay
How long between first warning and involving the right decision-maker or outside support.
These aren't vanity metrics. If detection is slow, you need better visibility or staff reporting habits. If containment is slow, your authority model or access model is probably broken. If recovery drags on, backups, rebuild procedures, or vendor dependencies may be the weak point.
Run tabletop exercises before you need them
A tabletop exercise is a guided conversation around a realistic scenario. No production systems are touched. Nobody needs to “hack” anything. You walk the team through what they would do.
Use a scenario that matches your environment. For example:
A staff member reports repeated MFA prompts they didn't approve. Shortly after, finance receives a payment request from that same user's mailbox with updated bank details. The mailbox also appears to have created an external forwarding rule.
Now ask practical questions:
- Who declares this an incident
- Who has authority to disable the account immediately
- How do you confirm whether payment workflows were affected
- What evidence must be preserved before settings are changed
- Who communicates to staff, and what do they say
- When do you call external support
Look for friction, not perfection
The point of a tabletop isn't to prove the team is smart. It's to expose friction while the stakes are low.
Common failure points show up quickly:
| Friction point | What it usually means |
|---|---|
| Nobody knows who leads | Ownership is unclear |
| Access can't be changed quickly | Admin control is too fragmented |
| Vendors are hard to reach | Contact paths and contracts need work |
| Comms stall | Decision-making and templates are missing |
Review every exercise like a real incident. Update playbooks. Fix access gaps. Tighten contact lists. Then run the scenario again later and see if the same confusion appears. If it does, the plan didn't change enough.
Modernising Response with Integrated Workflows
Most incident response plans fail in the same boring way. The document exists. The team knows it exists. Nobody uses it because the actual work is happening in email, chat, phone calls, ticketing systems, spreadsheets, and people's heads.
That's why modern security incident response should live inside the tools your business already uses to coordinate work. If incidents are managed where tasks, approvals, owners, and status updates already happen, response gets faster and leadership gets visibility without endless check-in messages.
Put the response process where work already happens
A platform such as monday.com can act as the operational layer around an incident. Not the forensic engine, and not the SIEM, but the place where response becomes trackable work.
Used properly, a workflow platform can hold:
- Incident records with severity, owner, affected systems, and timestamps
- Automated notifications when a playbook is triggered or escalation criteria are met
- Task boards for containment, communication, legal review, recovery, and post-incident actions
- Leadership views showing status, blockers, and decisions pending
- Audit trails so you can reconstruct who did what and when
For teams working to tighten process control, workflow automation design becomes part of cyber readiness, not a separate operational project.
Cloud and vendor realities change the response model
As environments become more cloud-heavy, response isn't only about what's on your network. It's also about what your providers will let you see, export, preserve, and investigate. SANS highlights the importance of pre-negotiated forensic access, incident expectations, and vendor SLA terms in third-party environments in its incident response glossary and guidance.
That's the piece many SMBs miss. They assume they can “get the logs later” or ask a SaaS vendor for everything if something goes wrong. Often they can't. Or not quickly enough.
Your response speed in the cloud depends as much on contracts and logging rights as it does on technical skill.
This is also where a managed provider can help. Some businesses use internal IT plus a workflow tool. Others add external monitoring, SIEM management, and response support. Wisely, for example, provides managed IT, cybersecurity, and workflow implementation services that can connect operational response steps with broader business processes. That's useful when the challenge isn't just detection. It's getting technical, operational, and leadership actions moving in the same direction.
The practical shift
A binder-based plan assumes people will leave their normal systems to manage an emergency. Most won't. An integrated workflow assumes the opposite. It brings the emergency into the systems where work already gets assigned, tracked, escalated, and reviewed.
For an SMB, that's usually the difference between a plan that exists and a plan that operates.
Your Next Steps Towards Cyber Resilience
If your business has no formal incident response capability today, don't start by trying to write an enterprise manual. Start with a few decisions that reduce confusion immediately.
Do these first
Identify your crown jewels
List the systems and processes that would hurt most if unavailable or compromised. Payroll, email, finance approvals, customer files, line-of-business apps, remote access, and cloud identity are common starting points.Name a core response team
Assign an incident lead, a technical lead, and one business decision-maker. Then assign backups. Keep the list short and real.Write one high-probability playbook
Start with a compromised email account or payment fraud scenario. Those incidents are common, disruptive, and heavily tied to human behaviour.Run a tabletop within the next month
Don't wait for perfect documentation. Put the key people in a room and walk through a realistic incident. You'll find the gaps quickly.Move the plan into operational tooling
If your playbooks, owners, and approvals can be tracked in the same systems your team already uses, adoption improves. That matters more than polish.
Use outside references wisely
It also helps to look at adjacent service management practices. A useful example is this Freshservice incident management guide, which shows how structured incident handling benefits from clear ownership, workflow discipline, and consistent escalation paths. Those same habits strengthen cyber response.
Cyber resilience doesn't come from pretending incidents won't happen. It comes from making sure your people know what to do, your tools support them, and your business can keep making sensible decisions under pressure.
If you're an SMB in NZ or AU, that's the target. Not perfection. Readiness.
If you want help turning a paper plan into something your team can effectively run, Wisely can support the practical pieces: mapped response workflows, monday.com implementation, managed IT and cybersecurity coordination, and the process design needed to make incident response part of day-to-day operations rather than a document nobody opens.
