A cyber tabletop exercise is a facilitated, discussion-based walkthrough of a realistic cyber incident — your team talks through how they’d respond, step by step, while a facilitator throws in complications. No real systems are touched, no production data is at risk. For the price of a couple of hours in a room, it’s the cheapest, highest-value security exercise an SME can run.
Most businesses buy controls and assume they’d cope on the day. A tabletop tests the assumption before an actual attacker does. It exposes the awkward gaps — who decides whether to pay a ransom, where the offline contacts list lives, whether anyone has actually read the cyber insurance policy — while the cost of finding out is a meeting, not a disaster.
What a tabletop exercise actually is
The format is deliberately low-tech. You gather the right people in a room, present a plausible incident, and walk through the response as a guided conversation. The facilitator describes the scenario, reveals new information at intervals (“injects”), and asks decision questions at each turn: What do we do now? Who makes that call? Who do we have to notify, and by when?
Nothing is simulated technically. You’re not unplugging servers or launching a fake phishing campaign — that’s a live or red-team exercise, a different and more expensive thing. A tabletop tests your decisions, your roles, your communications and your documentation. It answers the question that controls alone never do: when something goes wrong at 4:45pm on a Friday, does this team actually know what to do?
That’s why it sits at the top of the value-for-money list. A penetration test tells you whether attackers can get in. A tabletop tells you whether you can respond once they have. We cover the testing side in our piece on penetration testing; this is the other half of the picture.
Why it’s the best-value exercise you can run
Three reasons. First, cost: the only real input is people’s time, usually 90 minutes once or twice a year. No tooling, no consultants required for a first pass. Second, breadth: in one session you stress-test your incident plan, your decision-making, your notification obligations and your backups all at once. Third, it surfaces the failures that genuinely sink SMEs — not technical zero-days, but the human and process gaps. Nobody knew who could authorise a payment hold. The disaster recovery plan referenced a staff member who left in 2022. The “current” backup hadn’t been test-restored in eighteen months.
Those are the things that turn a manageable incident into a week of chaos, and a tabletop finds them in an afternoon.
Who should be in the room
The single biggest mistake is treating a cyber incident as an IT problem and inviting only IT. A real incident is a business event with legal, financial, operational and reputational consequences. The people who’ll actually make the decisions on the day need to be the people in the exercise.
- Owner or managing director — the person who ultimately decides whether to pay, to go public, to pull systems offline. Their absence is the most common reason a tabletop is toothless.
- Operations — they understand what the business can and can’t run without, and what “down for a day” actually costs.
- Finance — for ransom and fraud scenarios especially. They hold the payment controls and know the bank relationships.
- IT or your MSP — to speak to containment, recovery, what’s logged and what can realistically be restored, and how fast.
- Communications or whoever fronts customers — staff, clients, suppliers and possibly media all need handling, and silence is its own decision.
For a small business these might be five people wearing seven hats, and that’s fine. The point is to have every function represented, not to fill seats.
How to run one
1. Pick a realistic scenario
Choose something that could plausibly happen to your business, not a Hollywood cyber-war. The four that matter most for Australian SMEs:
- Ransomware — files encrypted, a ransom note, operations halted.
- Business email compromise (BEC) payment fraud — a supplier’s “updated bank details” email that diverts a real payment.
- A stolen or lost laptop — a device with mailbox and file access gone from a cafe or car.
- Microsoft 365 account takeover — a phished login giving an attacker access to mail, files and Teams.
Rotate the scenario each time. Don’t run ransomware every year and call it covered.
2. Inject complications
The scenario shouldn’t unfold cleanly. Part-way through, the facilitator reveals a twist: the backups are also encrypted; the one person who knows the firewall is on a plane; a journalist has already called. Injects are where comfortable plans fall apart and the real learning happens.
3. Ask decision questions and capture gaps
At each stage, push for specifics. Who makes this call? Who do we legally have to notify, and within what window? Where’s our offline list of contacts if email and Teams are down? The facilitator’s job is to record every “we’re not sure” and “we’d have to check” — those uncertainties are the output. A scribe writing down each gap and unanswered question is what turns the session into something actionable.
A sample 90-minute agenda
| Time | Segment | What happens |
|---|
| 0–10 min | Set-up and ground rules | No blame, no “right” answers, phones down. Confirm everyone’s role for the day. |
| 10–25 min | Scenario reveal | Facilitator presents the incident. Initial reactions and first moves discussed. |
| 25–55 min | Injects and decisions | Two or three complications introduced. Group works through containment, notification, recovery and communications. |
| 55–75 min | Recovery and aftermath | How do we get back to normal? Notifications, insurer, customers, lessons. |
| 75–90 min | Debrief and gaps | Walk the captured list. Agree owners and dates for each fix. |
A sample scenario you can run
Here’s one a real Melbourne SME could use verbatim. A manufacturing business in Dandenong arrives Monday to find production-planning files won’t open and a ransom note demanding payment in cryptocurrency sits on the shared drive. Staff can’t process orders.
Work through it: Who’s leading the response? Do we shut down the network to contain it? Inject one — IT reports the most recent backup ran successfully but has never been test-restored, so nobody can confirm it works. Inject two — a production supervisor mentions they reused their work password on a personal site that was breached last year. Inject three — a key customer rings asking why their order is late, and a second emails asking if their data is safe.
Now the hard questions. Do we engage our cyber insurer before doing anything, given the policy may require it? Does this trigger the Notifiable Data Breaches scheme, and who assesses that? Who tells staff what they can and can’t say? You’ll likely find at least three things nobody had a confident answer for — which is exactly the point.
Turning findings into actions
A tabletop that ends with a nice discussion and no follow-up was a waste of an afternoon. Before everyone leaves, every gap on the list needs an owner and a date. “Build an offline contact sheet — Ops, two weeks.” “Test-restore the backups quarterly — MSP, ongoing.” “Add a verbal-confirmation rule for any bank-detail change over $5,000 — Finance, this week.” We feed these straight into a remediation plan, and the most valuable ones usually point at controls: multi-factor authentication everywhere, conditional access, tested backups. Those tie into the work we describe in our guides on conditional access in Microsoft 365 and recovery time and recovery point objectives.
The second run, six to twelve months later, should open by checking off the previous list. That closed loop — find, fix, verify — is what separates a business that’s genuinely ready from one that merely owns an incident response plan.
How often to run one
Annually as a baseline, and again after any major change: a new core system, a merger or acquisition, a shift to a new cloud platform, or significant staff turnover in the key roles. A plan written around last year’s team and last year’s systems quietly goes stale. An annual rhythm keeps it current and keeps the muscle memory warm.
How it satisfies insurers and Essential Eight expectations
This isn’t only good practice — it increasingly maps to what insurers and frameworks expect. Cyber insurance applications and renewals now routinely ask whether you have an incident response plan and whether you test it. “Yes, and we run a tabletop annually” is a materially stronger answer than a dusty document, and it can shape both whether you’re covered and what you pay. We unpack this in our cyber insurance guide for Australian SMEs.
On the framework side, the Australian Cyber Security Centre (ACSC) builds the Essential Eight around technical mitigations, but the higher maturity levels and the broader ACSC guidance assume you can actually respond to and recover from an incident — tested backups, a workable plan, and people who know their roles. A tabletop is how you prove the human side of that holds together, not just the technical controls. It’s the rehearsal that makes the documentation real.
Frequently asked questions
How long should a tabletop exercise take?
90 minutes to two hours is the sweet spot for an SME. Long enough to work through a scenario and a few injects properly, short enough that busy decision-makers will actually commit the time. Anything under an hour rarely gets past the obvious; anything over half a day usually means too many people or too broad a scope.
Do we need an external facilitator?
Not for your first one. A capable internal lead or your MSP can run it from a prepared scenario. An independent facilitator earns their keep later, because they ask the uncomfortable questions an internal person might smooth over, and they can play injects without the group seeing them coming.
What’s the difference between a tabletop and a real simulation?
A tabletop is a discussion — you talk through decisions, nothing technical happens. A live simulation or red-team exercise actually executes attacks or recovery steps against real systems. Tabletops are cheaper, lower-risk and where every business should start; simulations come later, once the basics are solid.
Who should facilitate if the MD needs to be a participant?
Whoever facilitates should stay neutral and not be a decision-maker in the scenario, so the MD participates rather than runs the session. That’s a common reason businesses bring in their MSP or an external facilitator — it frees the leadership team to actually make the calls.
Where to start
You don’t need a budget or a consultant to begin. Pick one scenario from this post, block 90 minutes, get the right five people in a room, and walk it through. Capture every gap and assign an owner before you leave. That single session will tell you more about your real readiness than any amount of policy documentation.
If you’d rather have it facilitated properly — a tailored scenario, sharp injects, and a remediation plan you can actually action — that’s part of what we do. TechAssist is a Melbourne-based MSP founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma, and we run tabletop exercises as part of our cybersecurity services. Get in touch and we’ll help you rehearse the bad day before it arrives.
A good incident response plan answers the questions you won’t be able to think clearly about at 2am: who’s in charge, who they call, what they do in the first half hour, and who’s allowed to pull a server offline. If your plan doesn’t fit on one page, nobody will read it when it matters.
That’s the gap most SMEs have. They’ve got a document — usually written to pass an audit — and it’s useless under pressure. Here’s how to build an incident response plan your team can actually follow when something goes wrong.
Why most SME incident response plans fail
The plans we’re handed when we take on a new client usually fail for one of three reasons, and often all three.
They’re too long. A 35-page document with a glossary, a RACI matrix and four appendices is not a plan — it’s a compliance artefact. When a finance manager in Hawthorn notices their mailbox sending invoices they didn’t write, they won’t page through a PDF. They need to know who to ring and what to touch, in seconds.
They’ve never been tested. A plan that has only ever been read is a guess. You don’t find out that the listed “incident lead” left eight months ago, or that nobody knows the after-hours number for your IT provider, until you’re already in a live event.
They were written for auditors, not for 2am. A document that satisfies an ISO 27001 control reads very differently from one a stressed staff member can act on. The first describes a process in the passive voice; the second tells a named human to do a specific thing right now. You need both, but if you only have time for one, write the one for 2am.
The six phases, in plain English
Every credible incident response framework — the ACSC’s guidance and the international NIST model both land in the same place — breaks a response into six phases. You don’t need to memorise the jargon, but you do need to understand what each phase is for.
- Prepare. Everything you do before an incident: the plan, the contact list, logging, backups, and training so people recognise an incident when they see one. This phase decides how the other five go.
- Detect. Noticing something is wrong and confirming it’s real. The faster you detect, the less damage gets done. Detection that relies on a customer phoning to say their data is on a forum isn’t detection — it’s notification.
- Contain. Stopping the spread: isolating the affected machine, disabling the compromised account, blocking the malicious sender. Stop the bleeding before you worry about the cure.
- Eradicate. Removing the cause — the malware, the foothold, the dodgy mail rule the attacker created. Containment buys time; eradication makes it safe to come back.
- Recover. Bringing systems back in a controlled way, restoring from clean backups, and watching closely in case the attacker is still around.
- Lessons learned. The bit everyone skips. A short, blameless review of what happened and what you’d change. Skip it and you’ll relive the same incident next quarter.
The mistake is treating these as neat, sequential stages. In a real event you’ll be detecting, containing and notifying at once. The phases are a checklist of what must happen, not a timeline.
What a usable one-page plan contains
The plan people actually follow is short, specific and pinned somewhere everyone can reach. Here’s what earns a place on the single page.
Roles and a call tree
Name an incident lead — one person who owns the response and can make decisions — and a deputy for when they’re on a plane. Then a call tree: who rings whom, in what order. The staff member who spots the problem rings the lead, who decides whether to escalate and who else gets pulled in. Names and mobile numbers, not job titles. “Notify the CISO” is no use to a business that doesn’t have one.
Severity levels
Three is plenty. A simple severity scale stops people either panicking over spam or shrugging at ransomware. Something like:
| Severity | Example | Response |
|---|
| P1 — Critical | Ransomware, active data exfiltration, business-wide outage | Invoke the plan immediately, all hands, ring the MSP now |
| P2 — Major | Single compromised mailbox, one infected machine, suspected breach | Lead engaged within the hour, contain and assess |
| P3 — Minor | Isolated phishing click with no confirmed compromise | Investigate during business hours, log it |
First-30-minutes actions
The single most valuable part of the page. A short, ordered checklist for before anyone has worked out exactly what’s happening: don’t turn the machine off (you’ll lose evidence in memory), disconnect it from the network instead, change the affected user’s password, ring the incident lead, and start a timestamped log of who did what and when. That log matters later — for your insurer, for the OAIC, and for the lessons-learned review.
Who can authorise disconnecting systems
Spell out, by name, who has the authority to pull production systems offline. In the heat of an incident, the worst outcome is a staff member who can see the problem but is too afraid to act because they’re not sure they’re allowed to take the line-of-business server down. Pre-authorise it. The incident lead, or a named director, can make that call without waiting for a meeting.
Communications
Decide in advance who says what to whom. Internally: how you tell staff without tipping off an attacker who may be reading the same mailboxes (use a phone tree or an out-of-band channel, not the compromised email). Externally, you may have legal duties:
- The OAIC. If personal information is breached and serious harm is likely, the notifiable data breaches scheme requires you to notify the Office of the Australian Information Commissioner and affected individuals. We’ve covered the timing and thresholds in our piece on the OAIC obligations for Melbourne businesses. Build the assessment trigger straight into your plan.
- ReportCyber and the ACSC. Cybercrime should be reported to the Australian Cyber Security Centre (ACSC) through ReportCyber. It doesn’t replace your other obligations, but it’s the right channel.
- Customers. A pre-agreed holding statement saves you drafting one while the phones are ringing. Honest, brief, no speculation.
Recovery priorities tied to RTO and RPO
Not everything comes back at once, so the plan should rank what comes back first. That ranking comes straight from your recovery time objective (how long you can be down) and recovery point objective (how much data you can afford to lose). If you haven’t set those, our guide on RTO versus RPO walks through how. The short version: the systems with the tightest RTO get restored first, and your backup design has to actually meet the RPO you’ve promised — tested, not assumed.
An IR plan is not a BCP or DR plan
People use these terms interchangeably, then wonder why the documents contradict each other. They answer different questions.
| Plan | Answers | Triggered by |
|---|
| Incident response (IR) | How do we stop and clean up a security incident? | A cyber attack, breach or compromise |
| Disaster recovery (DR) | How do we get IT systems back up? | Any outage — attack, hardware failure, flood |
| Business continuity (BCP) | How does the business keep operating while IT is down? | Any major disruption to operations |
They overlap. A ransomware event might trigger all three: the IR plan handles containment and eradication, the DR plan handles restoring systems from backup, and the BCP keeps invoices going out and staff paid while it happens. Keep them as separate, linked documents rather than one giant file, and make sure the recovery steps in your IR plan point at the same RTO/RPO targets your DR plan uses.
Test it before it’s real
An untested plan is a hypothesis. The cheapest, most effective test is a tabletop exercise: get the people named in the plan around a table for 90 minutes and walk through a realistic scenario. “It’s 7am Monday, finance can’t open any files and there’s a ransom note on the desktop. Go.” Then watch what breaks.
Every tabletop we run surfaces the same gaps: the after-hours number is wrong, two people both think they’re the lead, nobody knows where the offline backups are, or the plan assumes a tool the business doesn’t have. None of those are failures — finding them in a meeting room beats finding them in a real breach. Run one at least annually, and again whenever something significant changes. It’s a core part of being Essential Eight aligned, not a nice-to-have.
Decide who you’re calling before you need them
When a P1 hits, you do not want to be googling “incident response Melbourne” at 2am. The contact list — current numbers, on the page — should include the people you’ll genuinely need:
- Your MSP. The team that knows your environment and can contain the incident technically. Response time is the whole game here.
- Your cyber insurer. Most cyber policies require you to notify them early, often within hours, and many provide a breach-response hotline and panel of specialists. Notify late and you risk the claim.
- Your lawyer. For anything involving personal data, regulatory notification or potential liability, get legal advice early. It also helps protect privilege over the investigation.
A manufacturing business in Dandenong we work with learned this the practical way. A staff member clicked a convincing invoice link, credentials were phished, and within an hour the attacker was setting up forwarding rules to skim payment redirections. Because their plan named us as first call and pre-authorised us to disable accounts, we killed the session, reset the credentials and locked the mailbox down before money moved. The plan didn’t prevent the click — nothing does entirely — but it turned a potential six-figure fraud into a contained, two-hour incident.
TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers and no offshore helpdesk. We target sub-15-minute response on critical incidents from our 24/7 NOC in Tecoma — which is exactly when an incident response plan stops being a document and starts being a clock. If you want a plan that holds up under pressure, our security and SOC services and broader cybersecurity services are built around detection and response, not just policy. Happy to pressure-test your current plan with a tabletop before something forces the issue.
Frequently asked questions
How long should an incident response plan be?
The part people act on should fit on one page: roles, call tree, severity levels, first-30-minutes actions and the key contacts. You can keep longer supporting detail — runbooks, notification templates, the OAIC assessment process — in a separate document, but the action page has to be short enough to use under pressure.
What’s the difference between an incident response plan and a disaster recovery plan?
The incident response plan covers how you detect, contain and clean up a security incident. The disaster recovery plan covers how you get IT systems back online after any outage, including non-security ones like hardware failure. A serious cyber attack usually triggers both, plus your business continuity plan, so keep them linked but separate.
How often should we test our incident response plan?
At least once a year with a tabletop exercise, and again after any significant change — a new core system, a major staffing change, or a merger. Testing is where you find the broken phone numbers and unclear roles before a real incident does.
Who do we have to notify after a breach in Australia?
If personal information is involved and serious harm is likely, you must notify the OAIC and affected individuals under the notifiable data breaches scheme. Cybercrime should also be reported to the ACSC through ReportCyber. Notify your cyber insurer early too — most policies require prompt notification.
Can our staff disconnect a server during an incident?
Only if your plan says so, by name. Pre-authorise specific people to take systems offline, because the worst outcome is a staff member who can see the problem but hesitates because they’re not sure they’re allowed to act. Spell out who has that authority before you need it.
Why IT Security Matters for Your Business
Businesses today face an array of cyber threats, making IT security crucial to protect sensitive information and maintain operations. TechAssist understands the importance of IT security and offers expert solutions tailored to your needs, ensuring comprehensive protection and compliance with industry standards. Emphasizing our commitment to customer satisfaction, we deliver reliable technology to secure your business and safeguard your digital assets.
Understanding IT Security
IT security, also known as cybersecurity, encompasses the measures taken to safeguard digital information and systems from unauthorized access, theft, or damage. With the rapid growth of technology and increased dependence on digital systems, IT security has become a crucial aspect of modern business operations.
As businesses continue to rely heavily on digital platforms for communication, data storage, and transactions, the importance of IT security cannot be overstated. Failing to prioritize IT security can have severe consequences, including financial loss, damage to reputation, and legal repercussions. In today’s digital world, a robust IT security strategy is essential for businesses to protect their sensitive data, maintain customer trust, and ensure compliance with industry regulations.
Common threats faced by businesses in the realm of IT security include malware attacks, phishing attempts, ransomware, and data breaches. These cyber threats can lead to significant financial and reputational damage, emphasizing the need for comprehensive protection. By understanding the potential risks and taking proactive measures to safeguard your digital assets, you can ensure the security and success of your business.
Reasons Why IT Security Should Be a Top Priority for Your Business
Making IT security a top priority for your business is vital for several reasons. First and foremost, it ensures the protection of sensitive data, both your own and that of your customers. Safeguarding this information is crucial to prevent data breaches, which can result in severe financial and reputational damage. A proactive approach to IT security also helps maintain customer trust and demonstrates your commitment to their privacy.
Compliance with industry regulations and standards, such as the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act (HIPAA), is another critical reason to prioritize IT security. Failure to comply with these regulations can lead to substantial fines and penalties, further emphasizing the importance of a robust IT security strategy.
Additionally, a strong IT security foundation is crucial for maintaining your business’s reputation. Security breaches can severely impact customer trust and tarnish your image in the market. By proactively addressing IT security risks, you can protect your business’s reputation and ensure continued customer confidence.
Finally, prioritizing IT security is essential for business continuity. Cyber attacks and breaches can disrupt operations, causing significant downtime and financial losses. A solid IT security strategy plays a vital role in disaster recovery planning, helping to minimise downtime and maintain smooth operations in the face of potential threats.
Best Practices for IT Security
To ensure the highest level of IT security for your business, start by developing a comprehensive strategy. This involves identifying potential risks and vulnerabilities, followed by establishing protocols and procedures to address these threats. By having a robust plan in place, you can better navigate the complex landscape of cybersecurity.
Implementing strong security measures is a crucial aspect of maintaining IT security. This includes regular software updates and patches, which help prevent potential vulnerabilities from being exploited. Network monitoring and intrusion detection systems also provide an additional layer of protection by detecting and responding to any unauthorized access or suspicious activity.
Training employees on IT security best practices is essential to maintain a secure environment. Staff members should be educated on potential threats, such as phishing attempts and malware, to minimise the risk of breaches. Ongoing training and awareness programs ensure that employees remain vigilant and informed about emerging threats and security measures.
Regularly reviewing and updating IT security policies and procedures is vital to stay current with evolving threats and technologies. As the cyber landscape changes, adapting security measures accordingly is crucial to ensure continued protection. By following these best practices, you can safeguard your business against cyber threats and maintain a robust IT security posture.
How TechAssist Can Help Secure Your Business
TechAssist brings extensive expertise and experience in IT security, offering comprehensive solutions tailored to the unique needs of your business. Our team of knowledgeable professionals is dedicated to providing the highest level of security and customer satisfaction.
Our IT security solutions encompass a wide range of services, including risk assessment, policy development, network monitoring, and incident response. These services are designed to identify and address potential vulnerabilities, ensuring that your business remains protected from evolving cyber threats.
By partnering with TechAssist for your IT security needs, you can benefit from our commitment to customer satisfaction, advanced technology solutions, and industry best practices. Together, we can safeguard your business’s digital assets and help maintain a secure and successful operation.
Secure Your Business with TechAssist
In this digital age, prioritizing IT security is essential for businesses to protect sensitive data, maintain customer trust, ensure compliance with industry regulations, and promote business continuity. Investing in a comprehensive IT security strategy can help safeguard your business against evolving cyber threats and minimise the impact of security breaches.
TechAssist is here to support you with expert IT security solutions tailored to your needs. Our team of experienced professionals is dedicated to providing reliable technology and exceptional customer satisfaction. Don’t wait to secure your business – take action today. To learn more about how TechAssist can help protect your digital assets and keep your business running smoothly, please visit our website or contact us for assistance.