Most organisations will face a bad day: a cyber event, a major outage, corrupted data, a failed supplier, or something physical that takes systems or people offline. In that moment, technology matters—but the incident is a business problem first. Who speaks to customers? Who can authorise taking email down while you investigate? Who decides it is safe to restore from backup? Those answers belong to your leadership, not to a help desk ticket. A written incident response plan exists so you are not inventing governance, comms, and priorities at 2am.
Your IT provider or managed service partner should be central to technical execution: containment, logging, recovery tooling, hardening, and getting systems back in a controlled way. They do not, however, run the response for the business. You name who is in charge, who approves external messages, and who accepts trade-offs such as downtime versus preserving evidence. Below is what to think through before you need it—whether you are in Perth, regional WA, or anywhere in Australia.
Why a written plan beats “we’ll call IT”
“Call IT” is a step, not a strategy. Incidents span more than desktops and servers: ransomware or account compromise, cloud or internet outages, accidental deletion, payroll or finance systems, third-party SaaS, and even situations where email or phones are the attack vector—so normal channels to reach staff or clients may be untrustworthy or offline. A plan should cover how you operate without those channels for a period, not only how to fix them.
Continuity thinking belongs in the same conversation. Backups and recovery objectives (how fast you need to be back, and how much data you can afford to lose) should be agreed before a crisis. Our backup and recovery work is about making restore paths real and tested; the business still decides what “good enough” recovery means for revenue, compliance, and reputation. Aligning that with cyber security and managed IT means fewer surprises when pressure is on.
Keep the document short enough to use: roles, contact trees, critical systems, escalation paths, and comms principles. Link out to detailed runbooks or vendor contacts rather than duplicating everything in one giant file you will never open.
Who is in charge
Name an incident lead (and a deputy) who coordinates the response on your side. That person does not need to be technical; they need authority to convene people, make time-bound decisions, and speak internally on behalf of leadership. Clarify who can declare that you are in incident mode—so the team stops debating whether it is “serious enough” and starts following the plan.
Spell out who can authorise sensitive actions: isolating systems, wiping endpoints, paying invoices to vendors, engaging legal or PR, notifying insurers, or communicating with regulators. For many SMBs, the owner or GM is the default; larger teams might separate “technical decisions” (recommended by IT) from “business decisions” (approved by leadership). HR may need a seat at the table if the incident involves people, insider risk, or workplace safety.
In practice this is RACI without the spreadsheet: for each major action type, know who is responsible (does the work), accountable (owns the outcome), consulted (must be in the loop), and informed (gets updates). Your MSP is often consulted or responsible for technical tasks—but accountable for the overall response remains with the business.
What must keep operating
List the few things that truly matter for the next 24–72 hours: taking orders, paying staff, serving existing clients, meeting regulatory deadlines, or keeping safety-critical processes running. Map them to systems (ERP, POS, practice management, M365, line-of-business apps) and to how customers reach you—website forms, main phone, email, SMS, social channels.
Assume email or identity systems may be compromised or offline. Maintain an out-of-band contact list: mobile numbers for key staff, your MSP’s escalation number, critical vendor contacts, and a way to reach clients if your usual broadcast tool is down. Store a copy offline or on paper someone can access without logging into corporate systems. If your website is the public face of “we are still here,” know who can change a banner or status page—and have a fallback (e.g. phone tree, Google Business Profile update) if the site itself is affected.
Dependencies matter: if you rely on one cloud app for bookings or payments, that vendor’s status page and support channel should be in your plan. Your IT partner can help inventory systems and dependencies; prioritisation is a business call.
Contacting clients and other stakeholders
Customers, partners, and staff need timely, consistent information—especially if their data or service is affected. Decide in advance who approves any external wording (usually leadership plus legal or insurance where relevant). Rushing a vague or inaccurate message can do more harm than the technical issue itself.
Prepare holding statements templates you can adapt: we are aware of an issue, we are investigating with specialist support, we will update by [time], here is how to reach us meanwhile. Avoid speculation. Be honest about known impact and next steps. Choose channels deliberately—email may be wrong if mail is the problem; your website status page, SMS, or phone may be better.
Some sectors have notification expectations or mandatory reporting; insurers often have timelines and evidence requirements. This article is not legal advice—your plan should name who calls counsel or your broker and when, so technical work does not accidentally destroy logs you need for a claim or inquiry.
Internal comms deserve the same discipline: staff should hear key facts from leadership, not the rumour mill. A single internal channel (even a simple call list) reduces confusion and stops well-meaning people from posting details publicly.
Working with your IT partner
Define a clear escalation path into your provider: who on your side opens the critical ticket, who is available after hours, and what “severity” means for your business. One primary contact on your side reduces conflicting instructions and helps preserve a clean timeline for later review.
Your IT team can guide containment (isolate hosts, reset sessions, block indicators), preservation of evidence, restore options, and safe return to operation. They should not be deciding whether you notify customers, what you say on your website, or whether to pay a ransom—that remains business and legal territory. Collaboration works best when leadership trusts technical recommendations but owns the risk acceptance.
During an incident, change control still matters: panic-driven “quick fixes” can break recovery or blur audit trails. Agree that material changes go through the incident lead and your IT partner together, with notes on what was done and why. Afterward, a structured review improves both technology and process—again led by the business, with IT feeding facts and options.
Testing and keeping the plan alive
A plan you have never walked through is a guess. Run a tabletop exercise once or twice a year: a scenario (e.g. ransomware, CEO account takeover, datacentre outage) and a timed discussion of who does what, who calls whom, and what you would tell clients in the first hour versus the first day. Note gaps—missing phone numbers, unclear sign-off, systems nobody owns—and fix them.
Test backups the same way: restoration drills prove RTO/RPO are real, not slide-deck fiction. Update the plan when you change systems, vendors, or key people; stale contact lists fail exactly when you need them.
After any real incident, hold a short post-incident review: what worked, what did not, what to document for insurance or compliance, and what to change in the plan before memory fades. Your MSP can supply technical timelines and recommendations; the business decides what to adopt and fund.
Summary
Incident response is leadership, communication, and prioritisation under pressure—not only IT work. Your organisation should own who leads, who speaks externally, what must keep running, and how you reach clients when usual channels fail. Your IT provider should be a capable partner for containment, recovery, and hardening, but not a substitute for business decisions. Write it down, keep contacts current, test restores and tabletops, and treat the plan as a living document. If you want help aligning technical readiness with your risk picture—backups, detection, access controls, and day-to-day managed IT—we are happy to talk. Contact us or request a quote for a practical conversation.
Want technical readiness that matches your plan?
We help Perth and Greater Metro businesses with security-first managed IT, cyber security, and backup and recovery—so when you run the response, the tooling and expertise are there to support you.
Contact Us Get Quote