Share
Author
In this article
Picture your team, in the middle of a mock tabletop exercise. Your IT lead (acting as the facilitator) reads out that the attacker wants an answer within the next 48 hours, and even this early on, that’s where the problems begin to emerge. No one in the room knows who has the authority to even discuss a ransom payment.
Despite the fear and anxiety such a situation can create, objectively speaking, everyone should be relieved. Better that moment happen during a Tuesday exercise, than a Friday night incident. That’s the purpose of a tabletop exercise, to test and improve the organisation’s decision making during active cyber security incidents.
Here, we’ll cover not only how to conduct one, but also how to measure and improve from them, including measuring response time, how to test them against real Australia based notification deadlines, fix any issues found, then test and measure again next quarter to provide evidence of improvement to the board.
We’ll also go over a complete ransomware tabletop exercise scenario that you could use this quarter without any form to complete. That’s based on AU scenarios, as opposed to the US or UK tabletops you’d typically find on the web.
But let’s start with the basics, what is a cyber incident tabletop?
A cyber incident tabletop exercise is a simulation of one or more cyber incidents which are run as a discussion based exercise to test the response of an organisation to a real cyber incident(s). It allows those that would manage the incident(s) to go through a realistic scenario in a structured manner where they can make all the decisions with time pressure.
Tabletop exercises are typically assessed based on the time it takes to make the decisions and the effectiveness of the response. A good exercise will culminate in a prioritised list of actions to fix any problems that were exposed during the exercise.
As the saying goes, failing to effectively plan, is planning to fail.
Key Takeaways
- Measure decision time, not attendance. The measurement of decision time in declaring an incident, in escalating to experts and in determining a ransom position in exercise one needs to be recorded in three numbers which then will be the basis for measuring improvement in subsequent exercises.
- Use Australia’s Notification Timelines. The 30 day assessment window of the OAIC and the 72 hour ransomware payment report to the ASD as the basis for your scenario deadlines.
- Keep the Executive and Technical Sessions Separate. We strongly recommend that all tabletop exercises run the Executive and Technical Sessions separately (as you do during an incident). Mixed rooms deliver polite but ineffectual simulations that hide all the issues.
- All findings need to have a named owner and a date for them. An after action list with no action taken proves that you were aware of a problem with no action taken.
The First Rehearsal Shouldn’t Be the Real Thing
Recently in a 2022 case, the Federal Court found the business RI Advice had contravened its obligations as an AFS licensee by failing to have adequate cyber risk management in place (ASIC v RI Advice Group [2022] FCA 496). That precedent has been the foundation to ASIC’s guidance ever since. Incident response plans need to be reviewed and tested. And your directors are going to be expected to ask what was found.
In 2026 the same court imposed a $2.5 million penalty on FIIG Securities for failing to have adequate cyber security measures in place as an AFS licensee.
These examples should act as a wake up call for businesses Australia wide. For licensed and APRA regulated entities this is now hard law. For others with no obligations at all, the courts and ASIC have provided useful guidance on what is required for adequate cyber risk management. So the real question directors need to be asking themselves isn’t “do I have a cyber incident response plan” but “when did we last test the plan and what did we find”.
Those examples might make the hair on your neck stand up, but we can assure you, a focused and diligent approach can close the risk gap. Three timelines matter here.
First, under the Privacy Act, an organisation has 30 days to determine whether a data breach is “notifiable” under the Act. You’ll need to take note, the 30 day clock commences on the date that the organisation first suspects a breach (i.e. has “reasonable grounds” to suspect an eligible data breach has occurred) even if the organisation is not 100% sure that a breach has actually occurred.
The other two timelines are the 72 hour report to the ASD (Australian Signals Directorate) under the Cyber Security Act 2024 if a ransom or extortion payment is ever made (for businesses with over $3 million in annual turnover), and the 72 hour notification period to APRA (Australian Prudential Regulation Authority) for a cyber security incident affecting an APRA regulated organisation (as contemplated by CPS 234).
In our July article, we created a cyber incident response plan template. If your business is looking for a starting point this is a great place to start, with all four of Australia’s cyber notification clocks mapped. Naturally, here we’ll be testing that plan.
Tabletop, simulation or red team?
The tabletop is the best place to start for an organisation to test an untested plan, whilst a red-team will be far more detailed (and far more expensive test), we recommend you walk before you run when it comes to testing, all a red team is likely to do to an untested plan is confirm the predictable chaos.
Table 1: choosing the right exercise
| Tabletop exercise | Simulation drill | Red team engagement | |
|---|---|---|---|
| What it tests | Decisions, authority, communications | A specific control or runbook, live | Detection and response against a real adversary |
| Touches live systems | No | Yes, in a controlled scope | Yes, adversarially |
| Business disruption | A meeting room for 1 to 3 hours | Hours to days for the teams involved | Weeks, mostly invisible until the readout |
| Effort and cost | Low | Medium | High |
| Maturity stage | Start here | Plan tested, controls in place | Mature programme with a SOC to test |
| Output | Decision baseline and findings list | Pass or fail on the control | Attack path report |
Treat It as a Measurement, Not a Meeting
As a brief explainer before we go deeper, ‘response time’ will be a measurement of the time to make a decision to address a breach.
We’ll aim to focus on the major delays (or costs) caused by human decision making errors in dealing with incidents, including for example, detection failure, non-escalation of incidents, and a failure of authority when it comes to dealing with a ransomware demand.
Have a silent scribe take notes of any tracking decisions, NIST calls this position the role of ‘data collector’ in its guidance (SP 800-84). It’s an essential part of the exercise, you shouldn’t skip.
- Time to declare. The time latency in declaring an incident. Including time to activate the response plan and commence assessment of the breach. (this should be minutes)
- Escalation latency. Communicating to approved stakeholders such as the board of directors, in-house legal and the insurer.
- Ransom posture decision time. The time it takes to achieve a reasonable defensible position, in respect to the demand. For some organisations this posture will be codified in the organisation’s constitution or cyber policy.
The decision log. Targets are indicative heuristics for a first exercise, not statutory deadlines; the clock in brackets is the obligation each target protects.
It’s important to take a no fault approach to tabletop exercises. This is the exact time when gaps need to be surfaced. Present a culture of openness and willingness to work through issues that arise so they can be closed before they really count.
In IBM’s 2026 Cost of a Data Breach study, Australian breaches identified and contained inside 200 days cost about AUD $3.26m, against $5.17m for those that ran longer, a gap of roughly $1.9m.
Write indicative targets into the log before you start, as heuristics rather than standards. Declare within 60 minutes, notify board, insurer, legal counsel within 2 hours, open up data breach assessment on the same day as the simulated incident, reach a defensible posture on ransom demands prior to the exercise (and not within the exercise itself).
Build the Exercise: Two Tracks, Five Injects, Real Clocks
The exercise can be run in two sessions, an executive tabletop and a technical tabletop. The executive tabletop will consist of the CEO, CFO, lawyer, communications expert and the person dealing with the insurer.
This session will test how the CEO and the executive team would respond to a ransomware attack, including the ransom posture and communicating with clients, staff and the press. The technical tabletop will consist of the IT expert or MSP, SOC team members and system owners. In this session the technical team will respond to the attack from a technical perspective including containing the attack, gathering evidence of the attack and recovering systems.
Run the exercise at the right scale for your organisation. Once there is real role separation, run the two tracks as separate sessions.
But for the smaller end of town a single table is fine as long as the owner is wearing their executive hat and your MSP is acting as the technical lead for you. The real discipline here is to ensure that you are separating out the decision making conversations from each other, not the people.
Two critical roles are required to run an effective exercise, a facilitator to present a scenario as a story within a time frame and force decisions, and a scribe to record all decisions made by participants within the exercise time frame and log them with corresponding time stamps.
External facilitation is strongly recommended for the first run and for the annual board exercise. Thereafter internal repeats are realistic once someone can facilitate without also being a participant, which in most mid-market organisations means your MSP or security partner.
Injects
These are the various scripted events that force key decisions within the exercise. These should be run against the statutory timeframes within the exercise to test how the organisation reacts under pressure.
- Discovery and triage. An EDR alert is triggered, and a help desk call is placed. Who is the incident owner for this scenario, and what criteria would they use to declare an incident?
- The exfiltration claim. The attacker asserts that data has been taken from the systems. Does anyone recognise that this starts the 30 day OAIC assessment window?
- The ransom demand with a deadline. Posture, authority, and the 72 hour ASD report that would apply if any payment were ever made.
- Media or major-client contact. The media or a major client contact the CEO before an appropriate statement has been finalised. Who speaks, and what are the holding lines?
- Insurer notification. Who contacts the insurer and when? Do the people participating in the exercise have full knowledge of the policy conditions including any consent requirements as well as the requirements of the insurer’s panel of lawyers?
💡 Expert Insight: Ashish Srivastava, Head of Cyber Security & Strategy
“The longest decision in almost every first-run ransomware exercise isn’t containment, it’s ransom posture. Technical teams can usually isolate affected systems within minutes. What delays the response is uncertainty over who has the authority to make the call on how the organisation responds to a ransom demand. That’s not a technology problem, it’s a governance problem.
At TechBrain, we’re confident in the technical response. Our greatest value is helping organisations answer the governance questions before an incident, rather than trying to answer them during one.”
There are a number of free tools to assist with the planning and delivery of tabletops, including CISA’s Tabletop Exercise Packages which contain over 100 scenarios for a variety of industries, as well as the ASD’s Exercise in a Box which includes a number of free, discussion based exercises that can be run in 30 to 120 minutes, including scribe sheets and reports.
However, none of these tools contain scenario injects that map to the various legislative notification obligations in Australian legislation. The following scenario addresses this shortfall and can be used as part of your organisation’s tabletop exercise.
Table 2: the clocks your injects should start
| Clock | Starts when | Deadline | Who it applies to |
|---|---|---|---|
| OAIC assessment (Privacy Act) | You become aware of reasonable grounds to suspect an eligible data breach | Assess within 30 days; notify as soon as practicable once confirmed | Organisations covered by the Privacy Act |
| ASD ransomware payment report (Cyber Security Act 2024) | A payment is made, or you learn one was made on your behalf | 72 hours | Businesses over $3 million turnover and critical infrastructure entities |
| APRA notification (CPS 234) | You become aware of a material information security incident | 72 hours | APRA-regulated entities |
| Cyber insurer notification | Per policy | Clauses commonly require notice immediately or within 24 to 72 hours of discovery, with consent conditions on response costs | Any insured business |
A Ransomware Scenario You Can Run This Quarter
Use the following ransomware scenario for your exercise. Run the 2 tracks separately and reconvene for the After Action Review (AAR) at the end.
The scenario commences at 1:47pm on a Friday, with a Finance Officer reporting that files are renaming themselves whilst in mid-processing for record updates. 10 minutes later the Help Desk receives 3 further calls of similar nature to the Finance Officer’s initial report.
The EDR system alerted at 11:20am but that alert was never opened or reviewed by anyone. At 2:30pm a text file is located on all affected shares. The text file outlines that a total of 400GB of data has been exfiltrated. Contact details are provided for the exfiltration event and a 48 hour ultimatum is given for any response regarding the ransom demand before it is published to the dark web.
It is important to note that the attacker’s 48 hour ultimatum is separate from the 72 hour ASD report that would be produced if any payment was made. The questions below test your ability to keep these two clocks apart.
Executive track questions, with what a good answer looks like:
- Who has declared an incident, and did they do it before the 2:30pm text file appeared? Good: one named role, backed by the plan’s activation criteria, declared on the first report.
- Do we have a position on payment and is it okay for someone to change this position? Good: a position on payment has been established by the board prior to this incident and is documented. A group of people have been authorised to change this position as required.
- What do we tell the client who called at 4pm today? Good: Holding statement (pre-approved) delivered by nominated spokesperson with an update time and not facts.
- Has the OAIC assessment formally started? If so, who is managing this? Good: This should formally start at 2:30pm and be owned by the privacy officer and/or the organisation’s counsel. The 30-day assessment period should also be recorded in the log.
- Have we spoken to the insurer, and do we know the consent conditions for payment? Good: the broker or insurer contacted on Friday and the policy conditions for notification and consent to payment outlined.
Technical track questions:
- Observe or Isolate? Good: isolate the affected segment now, preserve the EDR telemetry, and record the time.
- What should we preserve prior to re-imaging the hosts? Good: Host images of the patient zero machines, sign-in & audit logs and current OAuth grants. Our cyber forensics guide outlines the order to follow.
- What is the restore order and who verifies that the backups are good? Good: a written list of items to restore in order, restore to an isolated test environment first and then have the individual who did the verification sign off on the items to bring online.
- What do we need to prove left the environment? Good: firewall and proxy logs for the time frame of the exfiltration event. This may be difficult to find out though.
The Key Guardrails of the Scenario
The advice of the Australian Government, through the ASD, is not to pay.
A payment does not guarantee a working decryptor, and by paying, an organisation may mark itself to other attackers as one willing to pay. Some of the ransomware operators are sanctioned by the Australian Government and therefore making payment to them would be against the Autonomous Sanctions Act 2011 even though the attacker may not be known to the payer.
Most cyber policies require insurer consent before any payment, and if a payment is made by an entity (including by an insurer on its behalf) a report must be made to the ASD within 72 hours of the payment, or of learning it was made on your behalf.
The report must contain details of the demand, the payment made and all subsequent communications with the attackers. Information in that report has limited use protections, it generally cannot be used as evidence against the reporting entity in civil or regulatory proceedings, with narrow exceptions (including proceedings about the reporting obligation itself).
However, information reported to the ASD can be obtained by a regulator by other means.
Sector variants. We change one detail, and the whole scenario changes.
- Mining and mining services: Isolating IT does not isolate OT: add a remote site on satellite comms that must continue to operate. Notification of the Tier 1 supplier needs to occur within 24 to 48 hours of the incident having occurred.
- Medical: A paper fallback would be an inject in itself and there are specific obligations under My Health Record (in addition to the Privacy Act) that would also need to be considered in this scenario.
- Legal and accounting: Have external counsel involved prior to documenting any information by incident response team members, check integrity of trust accounts early in the containment phase.
- Real estate: Business Email Compromise (BEC) of a settlement. This type of loss is more typical of the real estate sector than any other.
- Wealth and insurance: CPS 234 and AFSL obligations apply, and after the FIIG Securities penalty a tested response is part of the licence baseline.
The After-Action Review Is Where Response Time Improves
The real value of an exercise is the After-Action Review (AAR) held within 2 weeks of the actual exercise.
Ensure that the AAR is held ‘without blame’. In turn, the AAR should follow the following structure: what the plan said would happen, what actually happened, the reasons for the differences, and the actions required to address these findings.
Each finding must have a named owner (not a role) and actions with associated timeframes (30, 60 or 90 days) and measurable criteria to determine success for each of these actions.
Table 3: the findings pipeline, with example rows
| Finding | Severity | Plan section affected | Named owner | Action (30/60/90 days) | Success criterion |
|---|---|---|---|---|---|
| Nobody could state the ransom position | High | Decision authority | CFO | 30 days: board resolution on payment posture | Position minuted and written into the plan |
| EDR alert unreviewed for 2 hours | High | Detection and activation | IT manager | 60 days: 24/7 alert routing in place | Alert reaches a human within 15 minutes |
| Insurer called on Monday | Medium | Escalation | Finance lead | 30 days: policy notification clause on the contact card | Insurer in the first-hour call list |
A simple test to distinguish between cosmetic changes to improve your cyber incident response and real changes to minimise decision time in a real incident is to test whether the 5 areas of the July template have been updated for each exercise. These are the incident response plan, the printed contact card for your phone, the full tabletop scenario, the communication templates before, during and after an incident, and the pre-authorised decision list.
It is also important to note that an unactioned list of findings (even with no action required) is evidence of known deficiency not remediated and could surface in later proceedings, as the RI Advice case showed with deficiencies left unactioned over an extended period.
Report findings to the Board, the original baselines, current numbers, delta and percentage of findings closed. APRA’s Prudential Practice Guide CPG 234 envisages testing results being reported to the board of a regulated entity, this should be a document a director could ask for by name.
💡 Expert Insight: Ashish Srivastava, Head of Cyber Security & Strategy
“The most common reason exercise findings never close is that they’re assigned to a role, not a named person. Once the exercise excitement fades, ownership tends to fade with it.
The exercise itself doesn’t close findings; accountability does. The organisations that see real improvement assign every action to a named owner, set clear due dates, and require progress to be reported back to the board or risk committee.”
One Exercise Is a Data Point, Four Are a Trend
As a benchmark, run 4 tabletops within the first year and then hold an annual exercise for subsequent years.
For sectors such as medical, legal and financial services, hold a quarterly exercise. Keep the 3 core decisions constant across the 4 tabletops and vary the scenario, level of complexity and the people participating, so the improvement chart is a fair comparison and the 4th exercise is still a test. You’d ideally want to see decision time falling across quarters.
It also has the potential of becoming a commercial document, because insurers are going to be asking for evidence of exercises conducted at the time of policy underwriting and renewal.
One important point to close on, don’t overclaim the value of your exercises.
Table 4: a first-year programme
| Quarter | Scenario focus | Inject complexity | Metric target | Board milestone |
|---|---|---|---|---|
| Q1 | Ransomware with exfiltration (the scenario above) | Baseline, 5 injects | Establish the three baselines | Baseline report |
| Q2 | Business email compromise on a payment | Add a bank recall window | Declare within 60 minutes | Payment posture minuted |
| Q3 | Supplier or MSP compromise | Add a contractual notification clock | Escalate within 2 hours | Contact card and comms templates re-issued |
| Q4 | Executive session with the full board | Rotate the facilitator, add a regulator inject | All three targets met | Annual attestation and insurer evidence pack |
How TechBrain Helps
We help to design and run tabletop cyber security incident response exercises for medium and large Australian businesses.
These are run with separate runsheets for executive and technical teams, and the set of injects are aligned with relevant Australian cyber security notification obligations. We use the decision-log created during the exercise to help measure response times in subsequent exercises. The results of each exercise are distributed in a timely manner and organised into a board-ready document used to track closure of findings over time.
We have a team of Australian based staff who are experienced in designing and facilitating a range of cyber security training exercises and are also the staff of the TechBrain 24×7 SOC.
All of our exercise design, facilitation and support is run out of our ISO 27001 certified management system.
- Facilitated tabletop exercises: the exercise, decision log baseline, after action review and findings pipeline described above.
- Incident response plan design and refresh: Use the findings from your exercises to enhance your incident response plan.
- Managed SOC and managed SIEM: the detection and log retention the exercise assumes you have.
- TechSure cyber risk assessment and Essential Eight assessment: the pre-exercise gap analysis to be covered off prior to running your first tabletop exercise.
Your first exercise should be a baseline, not a performance. Book a facilitated tabletop and leave with your numbers and a fix list.
Sources
- ASIC v RI Advice Group Pty Ltd [2022] FCA 496; ASIC media release 22-104MR. asic.gov.au
- Cyber risk: be prepared, ASIC. asic.gov.au
- ASIC v FIIG Securities Limited [2026] FCA 92 (judgment 13 February 2026); ASIC media release 26-021MR. asic.gov.au
- Ransomware and cyber extortion payment reporting factsheet, Department of Home Affairs (Cyber Security Act 2024, Part 3). homeaffairs.gov.au
- Notifiable Data Breaches scheme, Part 4, OAIC. oaic.gov.au
- Prudential Standard CPS 234 Information Security, APRA. apra.gov.au
- Cost of a Data Breach Report 2026, IBM (Australian figures as reported by SecurityBrief Australia, 31 July 2026). securitybrief.com.au
- Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, NIST SP 800-84. csrc.nist.gov
- CISA Tabletop Exercise Packages. cisa.gov
- Exercise in a Box, Australian Signals Directorate. cyber.gov.au
- Essential Eight Maturity Model, Australian Signals Directorate. cyber.gov.au
- Prudential Practice Guide CPG 234 Information Security, APRA. apra.gov.au
- Autonomous Sanctions Act 2011 (Cth). legislation.gov.au
This scenario and guidance are general in nature and current as at September 2026. They are not legal advice. Incident response remains each organisation’s responsibility; seek advice specific to your circumstances.
