A cloud outage rarely announces itself as a neat technology category. At 9:00 am, staff may be unable to sign in, a key SaaS application may be slow, a payments screen may be unavailable, a provider status page may still look normal, or customers may start asking why a promised service is not responding. For an Australian SME, the first pressure is usually operational: who decides what to do, how does the team stay in touch, and which work must continue while the facts are checked?

A short tabletop can answer those questions before an event demands instant decisions. This 90-minute format is a rehearsal for critical systems, decision owners, fallback communications and a useful incident record. It is not a claim that every outage can be diagnosed, repaired or recovered in 90 minutes. The clock gives the team a practical way to expose missing contacts, unclear authority, fragile dependencies and untested workarounds without changing production systems.

Use the scenario that best reflects the way your business works: the primary cloud/SaaS environment becomes unavailable at the start of the working day; email and multifactor sign-in are inconsistent; and one important customer deadline is approaching. A facilitator can pause at each time block, introduce a new fact and ask the people in the room what they would do next. The value comes from making decisions visible, not from pretending the answer will be the same for every business.

A 90-minute drill is not a 90-minute recovery promise

The distinction matters. A tabletop is a discussion-based exercise: it tests whether people can recognise the impact, use the right escalation path, choose a safe interim action and communicate with enough clarity to keep the business coordinated. A controlled technical test has a different job. It checks whether a restore, failover or recovery sequence actually works in the organisation’s environment. Both are valuable, but neither one automatically proves that future disruption will be brief or straightforward.

For this exercise, decide in advance that no one will fail over a live workload, reset credentials, delete data or make an unapproved configuration change. The team is practising the operating layer: how it confirms the scope, protects the business from speculative action and chooses the next owner. If the exercise reveals that a technical drill is needed, record that as a controlled follow-up with an agreed scope and change authority.

The facilitator should also make room for three possibilities. The issue could be a provider-side availability fault. It could be a local internet, identity, DNS or device problem that looks like a cloud outage. Or it could be a security or data-integrity concern that requires evidence preservation and a different escalation route. Treating those possibilities as distinct is safer than assuming the provider is at fault or that an availability event must be a cyber attack.

Before the timer starts: set up a safe exercise

Bring together the people who would actually make the first operational decisions: a business or operations lead, a technical recovery lead, a person responsible for customer or staff communications, and a scribe. A small SME can combine those roles, but it should still name a backup contact for each essential decision. Clear primary and secondary contacts, communication processes and record keeping are practical parts of an incident plan.

Write the scenario on one sheet. Include the starting time, the affected service, the first observable symptom and the condition that normal email or phone contact may also be unreliable. Give the scribe a simple decision log with five headings: time, observed fact, decision, owner and dependency. This prevents the discussion from drifting into a general debate about technology purchases.

Set a clear boundary for the exercise: it is a conversation, not a technical change window. Participants may consult approved runbooks or provider contacts, but they should not test a real restore, change a tenant setting or disclose a customer issue. That makes it easier to involve the people responsible for business operations without creating a new incident.

Prepare a small set of prompts as well. What would confirm whether the problem is local, identity-related or provider-side? Which provider portal, phone number or support agreement would the technical lead use? Where is the current contact list if the shared drive is unavailable? Which leader can authorise a customer update? By agreeing the questions before the exercise, you make missing information visible without having to improvise during an outage.

0–15 minutes: protect people, establish facts and assign ownership

Begin the clock with the business impact, not the dashboard. Confirm whether anyone’s safety or urgent customer obligation is affected. Then nominate an incident lead and a scribe, note the time, record the observed symptoms and list the first affected functions. A useful first check is deliberately modest: can a different user, network or device reproduce the problem, and does the provider offer any current information through a known channel?

Do not let the team turn an inconclusive status page into a diagnosis. A service can appear available while sign-in, DNS, payments, email delivery or a particular application workflow is failing. Conversely, a local connection problem can look like a provider outage from one office. The drill should require the technical lead to say what is known, what is assumed and what evidence would change the current decision.

At the end of this first block, the facilitator should expect a small but useful outcome: one incident owner, one communication owner, one log, a stated scope and a next check. If compromise, data loss or suspicious access is plausible, the team should also know who can activate the relevant security path. It does not need to decide the root cause yet. It needs to avoid actions that destroy evidence or make recovery harder.

15–30 minutes: coordinate away from the affected path

When the normal channel is part of the problem, the business needs a second route. That might be an agreed mobile call tree, a separate messaging channel, a status page, a catch-all contact method or a pre-approved customer service process. The right option depends on the business, but relying on one form of communication is a recognised outage risk.

Draft a holding update as part of the drill. It can be short: explain the customer-visible impact, say the team is checking the issue, provide a contact route and state the next update time. It should not guess the cause, promise a restoration time or name a supplier before the facts are clear.

Give staff equally practical guidance. Tell them which workaround, if any, is approved; who can answer questions; and what not to do. For example, staff should not move customer data into a personal account or create an unapproved communication channel simply because the normal platform is unavailable.

The scribe should record each update, recipient group and source of information. That record helps the next person taking over, gives the business a reliable timeline and makes the debrief more useful. It also stops several well-intentioned people from sending conflicting messages to customers, staff or providers.

30–60 minutes: prioritise the work, not the applications

A cloud outage can make every alert feel urgent. The exercise should instead ask which business function has to continue first. The best answer is rarely “the most visible app”. It may be the process that keeps customers informed, permits safe work, honours a time-sensitive commitment, protects a critical record or allows the team to take payment manually. Critical functions can be assessed by downtime impact, operating importance, obligations and protection of irreplaceable assets.

Ask the business lead to choose one function and describe the minimum service level needed for the next few hours. A professional-services firm may need a way to identify urgent client matters and contact people. A trade business may need job details, supplier contacts and a safe method of receiving changes. A retailer may need a manual path for payments, stock checks or customer advice.

Then map the dependencies behind that function. Does it rely on identity or multifactor authentication, DNS, an internet path, a data store, a payment service, a provider console, a licence, a named administrator or a specific customer contact? The list shows why “restore the app” is rarely a complete recovery decision.

Classify the function as high, medium or low priority for the scenario, then record the next safe action. That may be a documented manual workaround, a provider escalation, an approved alternate access route or a decision to pause non-essential work. A tabletop does not prove that the workaround is ready; it identifies what the business needs to test separately.

60–90 minutes: decide the next action and record the gaps

The last block is where the drill becomes more than a conversation. Ask the incident lead to summarise what the team now knows, the priority function, the current workaround, the provider escalation reference and the next customer or staff update. Then ask what evidence would show that the business has reached a usable state: a completed customer transaction, current data, a successful sign-in, a validated manual process or a service health check from the people actually using it.

Capture the gaps while they are fresh. Perhaps the backup contact did not have the right provider portal access. Perhaps the only copy of a runbook was in the unavailable platform. Perhaps staff were unsure who could approve a client update, or the technical lead could not verify whether multifactor access would work from a different device.

Every gap should finish with an owner and a due date. “Improve communications” is not yet an action. “Operations manager validates the hard-copy contact list by 30 November” gives the business something it can check at the next review.

Close the tabletop by naming the next controlled test. That might be a provider-contact rehearsal, a safe check of an alternate communications route, a review of privileged recovery access or a scoped technical restore exercise. A planning drill can reveal what must be tested; it should not be represented as evidence that a restoration target has been achieved.

Use realistic injects without making the exercise dangerous

A good tabletop needs a little pressure, not a destructive surprise. Introduce new information every 10 or 15 minutes and ask the team to update its plan. Keep the prompts plausible for the business and avoid testing systems, credentials or data in the live environment.

These injects are not a scorecard. They are a way to see whether the plan makes it easier for people to make aligned decisions. The Australian Government’s business-continuity guidance similarly treats workplace simulations as a way to reveal whether staff can find the plan, use incident checklists and put recovery actions in place.

Turn one exercise into an operating habit

After the exercise, hold a short debrief. What helped the team decide? What information arrived too late? Which contact, dependency, role or workaround was uncertain? Keep the answer practical: update the role sheet, correct the escalation contact, store a runbook in an accessible place, schedule a controlled technical test or clarify the customer communication template.

This article deliberately focuses on people and operational decisions. Recovery copies and tested restores still matter, but they belong to a related discipline. For a practical explanation of backup-copy separation, restore testing and the 3-2-1 rule, read vCloud Group’s business continuity and 3-2-1 backup guide. The useful connection is simple: a technical recovery arrangement is stronger when the business also knows who can use it, which work comes first and how the team will communicate while it is being checked.

When a business is ready to make the exercise more specific to its systems, vCloud Group’s Business Continuity+ service information outlines a continuity-planning approach that considers interruption processes, systems and scenarios. The right scope depends on the business. A conversation should clarify current responsibilities, dependencies and possible next tests—not promise that every interruption can be prevented or resolved on the same timetable.