Ransomware Recovery Tabletop and Technical Restore Drill
Ransomware Recovery Tabletop and Technical Restore Drill is a one-week, $3,950 fixed-price exercise that answers the two questions an insurer, an auditor or your own board will eventually ask about the incident plan sitting in your document library: has anyone ever run it, and do the backups actually restore? Half of the week is a facilitated ransomware tabletop for leadership and IT — a scenario built from your real environment and delivered in timed injects: initial encryption, the backup repository targeted, the extortion note, insurer and counsel engagement, customer and staff communication, the pay-or-restore decision, and the criteria for declaring return to operations. Every decision, hesitation and missing phone number is written down as it happens. The other half is a controlled technical restore drill: an agreed server or virtual machine, mailbox, SharePoint site or file set, restored from whatever backup you already run — Azure Backup, Microsoft 365 Backup or a third-party product — to an isolated target, on a stopwatch, verified rather than assumed. You get a written report: the decision gaps the tabletop exposed, the measured time-to-restore per asset against the recovery targets your plan claims, and a prioritized remediation list. Remote delivery, one week elapsed; on-site delivery is quoted separately with travel. We exercise the plan you already have — if you do not have one yet, [BC/DR plan development](/services/business-continuity-disaster-recovery-plan) writes it first, and this drill is the natural follow-up a year later.
What this engagement is
Most organizations between 50 and 1,000 seats now have an incident response or business continuity plan. Far fewer have ever run it, and fewer still have watched somebody restore a real system from a real backup while a clock ran. That gap is where ransomware recoveries go wrong — not in the plan's table of contents, but in the ninety minutes nobody has rehearsed: who is allowed to declare an incident at 2am, who can authorize disconnecting a site or isolating devices in Microsoft Defender XDR, whether the one person who holds the backup console credentials is reachable, whether the backup was inside the blast radius, and whether anyone knows which phone call has to happen first. Insurance applications and renewal questionnaires now routinely ask whether the incident plan has been exercised in the past twelve months and whether backups have been restore-tested; security frameworks ask the same thing in their own vocabulary. This engagement produces the dated evidence those questions want — and, far more usefully, the list of things you did not know were broken. The tabletop is designed rather than downloaded. We build the scenario from your actual environment — your hypervisor or cloud, your identity provider, your endpoint protection, your backup product, the two or three applications whose absence stops invoicing — and deliver it as timed injects to leadership and IT sitting in the same session, because the failures worth finding live in the seam between them. The injects walk the room from the first odd alert to the decision to resume trading: encryption spreading faster than the on-call engineer can escalate, the backup repository showing failed jobs, an extortion note with a countdown, a journalist's email, staff asking on WhatsApp whether they should come in, the broker asking for a notification the policy may require within hours, counsel asking what data was in the encrypted share, and finally the pay-or-restore conversation nobody wants to have for the first time on the day. Method comes from the public practice literature — CISA's Tabletop Exercise Packages for scenario and discussion structure, the joint #StopRansomware Guide from CISA, the FBI, the NSA and the MS-ISAC (last substantially revised in 2023) for the response checklist, NIST SP 800-61r3 (published April 2025) for incident-response lifecycle vocabulary, and NIST SP 800-84 for exercise design and evaluation. The content, though, is entirely yours. We facilitate, keep time and scribe; your people decide. Nothing in the tabletop touches production. The restore drill is where opinions become numbers. You nominate the assets — typically one server or virtual machine, one mailbox and one SharePoint site or file set — and we restore them from the backup you already run, into a target you approve, never over the top of production. For an Azure VM protected by Azure Backup that means a 'Create new VM' or 'Restore disks' operation into a separate resource group and an isolated virtual network, never 'Replace existing', which swaps the disks on the live machine. We record which recovery-point tier the restore came from, because a snapshot-tier restore and a vault-tier restore are not the same wall-clock event, and because Microsoft documents that cross-region restore into the paired secondary region works only from vault-tier recovery points, and that restoring a vault-tier point into another subscription requires the cross-subscription restore property to have been enabled on the vault beforehand. Where the asset is a file set rather than a machine, we use item-level file recovery — the downloadable script that mounts the recovery point over iSCSI — and we plan around Microsoft's own published guidance that the feature is intended for recoveries of roughly 10 GB or less at expected transfer speeds of about 1 GB per hour. That number surprises people who assumed "we can just get the folder back" meant minutes, and finding it out during a drill is a great deal cheaper than finding it out on the day. Microsoft 365 Backup has its own shape, and it decides what a mailbox or site drill can honestly prove. Per Microsoft's published feature table, restore points are taken every 10 minutes for the previous two weeks and weekly from two to fifty-two weeks for SharePoint sites and OneDrive accounts, while Exchange Online mailboxes keep 10-minute granularity for the full year — so the truthful recovery point for a SharePoint site you discover was corrupted three months ago is a week, not ten minutes, no matter what the plan says. A site or OneDrive account restores either to the same URL, which rolls the whole thing back and overwrites everything created since, or to a new URL; a drill always uses a new URL. Exchange behaves differently again: a mailbox restore lands in the same or a new folder inside that user's own mailbox and returns only items modified or deleted since the restore point, so a mailbox drill is scheduled with that person or run against a test mailbox we populate first. Granular file and folder restore for SharePoint and OneDrive is generally available and needs the SharePoint Backup Admin role assigned before the window rather than during it. If you run Veeam, Acronis, Datto, Rubrik, Barracuda or anything else, we drive your console alongside your administrator, to your vendor's documented restore procedure, into the target you approved — we do not have to like your backup product to time it honestly. What we measure is deliberately unglamorous: when the restore was requested, when the job actually started (there is almost always a gap, and it is almost always a credential, a missing role or an approval nobody could give), when the data became available, when a human verified it was the right data rather than a corrupted or already-encrypted copy, and what could not be restored at all. Those timestamps sit in the report next to the recovery time and recovery point objectives your plan states, and the difference between the two columns is the finding. Remediation is prioritized by how much recovery time or data each gap costs you: immutability and multi-user authorization on the backup vault so an attacker with admin rights cannot delete recovery points, break-glass identity that survives the loss of your directory, an offline copy of the plan and the contact list, named deputies for every role that had exactly one holder, an out-of-band communication channel that does not depend on the Microsoft 365 tenant you are trying to recover, and the assets that turned out not to be backed up at all. Implementing those is separate work, separately quoted — Azure Backup for servers, Microsoft 365 Backup, Azure Site Recovery, or a managed restore-testing cadence so the next test is not another twelve months away — and the report is written so your own team, or another provider, can do all of it without us.
Success criteria
What you receive
How the work unfolds
We agree in writing what the exercise must prove and for whom (a board, an insurer's questionnaire, an auditor, or your own peace of mind), who attends, which assets go into the restore drill, which backup platform each one comes from, where the isolated restore target will be, when the restore window opens, and the safety rules: no in-place restore, no production change, stop at the first sign of risk. Access is least-privilege and time-bound — read access to the backup console for reconnaissance, and for the window itself either your administrator drives with us guiding or you grant a restore role that is revoked the same day.
The scenario and its injects are written against your real topology and sent for approval. In parallel we check what the drill can honestly prove: which of the nominated assets are actually protected, under which policy and retention, what recovery-point granularity exists at the data age the scenario uses, whether the vault has soft delete, immutability or multi-user authorization turned on, which roles the restore will need (the SharePoint Backup Admin role for granular Microsoft 365 restores, for example), and whether the restore target exists yet. If reconnaissance shows an asset cannot be restored at all, that is a finding we give you immediately, not a surprise on drill day.
A facilitated half-day session on Microsoft Teams. Injects are released on a clock; the room works the problem; the scribe records decisions, timings, assumptions and the moments where the conversation stops. We keep it honest and blameless — the aim is to find the gap, not the culprit — and close with a hot-wash while impressions are fresh, so participants hear the initial findings from their own mouths rather than from a document two weeks later.
Go/no-go confirmed in writing, then the agreed assets are restored to the isolated target with timestamps recorded at every step: request, job start, data available, verification complete. Each restore is verified against the test agreed at kickoff — the database mounts and the application connects, the mailbox items are present and readable, the site opens with the expected content and permissions, the file set opens and matches a known-good hash or spot check. Where something fails or stalls, we diagnose it far enough to write down why, and then move on rather than turning the drill into an unplanned repair project.
The decision-gap register, the measured restore results, the RTO and RPO comparison, the prioritized remediation plan and the dated evidence pack are written up and sent for review before the readout, so the leadership session discusses conclusions rather than hearing raw findings for the first time.
A 60-minute executive readout, then teardown: we tell you exactly which restored resources, staging storage blobs, disks, sites or test mailboxes to delete so they stop costing you money, hand over every working artifact, and remove our access. What you do next — internally, with us, or with another provider — is entirely your call; the report is written to serve all three.
Prerequisites
Who does what
IT Partner
- Design the scenario and its injects from your real environment, and send the exercise design pack for your approval before the session.
- Facilitate the tabletop neutrally, keep the clock, and scribe every decision, assumption and gap without editorializing or scoring individuals.
- Verify the backup configuration for the nominated assets before drill day, and tell you in advance if the drill cannot prove what you were hoping it would prove.
- Run or supervise every restore into the isolated target strictly to the approved plan, with timestamps at each step, and stop at the first sign of risk to production.
- Verify the restored data against the agreed test and say plainly when a restore succeeded as a job but failed as a recovery — a green tick in a console is not a recovery.
- Write the report, the measured results and the prioritized remediation plan, deliver the executive readout, and keep every claim in it traceable to something we observed.
- Remove our access at the end, name the restored resources you should delete so they stop billing, and treat everything seen during the exercise — including what went badly — as confidential.
Your team
- Name the executive sponsor and get the real decision-makers into the half-day session; a tabletop attended only by IT finds only IT's gaps.
- Provide the current plan, your stated recovery targets, and the backup configuration details for the nominated assets.
- Approve the scenario, the asset list, the restore target and the written go/no-go, and confirm that the target is not production.
- Grant the reconnaissance and restore-window access, and revoke it when the window closes.
- Make the decisions during the tabletop. We facilitate and record; we do not decide for you, and a decision we made for you would prove nothing about your organization.
- Own all communication with your insurer, broker, counsel, customers and any regulator — before, during and after the exercise.
- Delete the restored resources once we confirm they are no longer needed, and own the Microsoft or vendor charges they incurred.
What's not included
Limitations & technical notes
Frequently asked questions
How is this different from the BC/DR plan development engagement?
That one writes the plan; this one tries to break it. Business Continuity and Disaster Recovery Plan Development inventories workloads, sets recovery targets with your leadership, authors the procedures and closes with a plan-validation tabletop — the exercise there proves the document is coherent. This engagement assumes you already have a plan, puts it under a specific ransomware scenario with the people who would really run it, and then does the thing a plan-validation tabletop deliberately does not do: restores real data from your real backup and times it. Many customers buy the plan first and this a year later; a few buy this first because an insurer asked, and discover the plan needs rewriting.
We have never written a plan. Can we still book this?
Not usefully. An exercise needs something to exercise: named roles, an escalation path, some statement of what has to be back first. Without that, a facilitated session becomes a workshop about writing a plan, which is a different engagement and a worse use of your money. Start with BC/DR plan development. If you are unsure which side of that line you are on, the free 30-minute session will tell you in half an hour, at no charge.
Will anything you do touch production?
No. The tabletop is a conversation — no system is touched at all. The restore drill runs into an isolated target you approve in advance: a separate resource group and virtual network for a restored VM, a new SharePoint site URL, a test mailbox or a folder inside the mailbox owner's own mailbox where Microsoft's design requires it. We never use Azure Backup's 'Replace existing' option, never perform an in-place SharePoint or OneDrive rollback, and do not start any restore until you have signed the written go/no-go. The safety rules are agreed at kickoff and printed in the drill plan.
What exactly gets restored?
Whatever you nominate and we can verify is protected — typically three assets, for example one server or virtual machine, one mailbox and one SharePoint site or file set. Good candidates are the things your plan claims will come back first: the file share finance cannot invoice without, the line-of-business application server, the mailbox of somebody whose absence stops approvals. We check during reconnaissance that each nominated asset really is covered by a policy with a usable recovery point, and if it is not, we tell you before drill day and offer to swap it — after recording the fact, because an asset everyone assumed was backed up and is not is the single most valuable finding this engagement produces.
How long does a restore actually take?
That is the question the drill exists to answer for your environment, and honest ranges vary enormously with the platform, the size of the data, the recovery-point tier and the target. Microsoft publishes indicative figures for its own services — for example, guidance that Azure Backup's item-level file recovery suits recoveries of about 10 GB or less at roughly 1 GB per hour, and performance expectations for Microsoft 365 Backup measured in protection units rather than gigabytes. We will not quote you a number for your environment before we have measured it, because the interesting delay is usually not the data transfer at all: it is the twenty minutes spent finding who can approve the restore, or the role that was never assigned.
What happens if a restore fails during the drill?
It gets written down, with the reason, and the drill continues. A failed restore is a successful exercise: you have found, in a controlled window with nothing at stake, something that would have cost you days in a real event. We diagnose far enough to explain the cause and put a concrete fix in the remediation plan — we do not turn the drill into an unbudgeted repair project, and we do not quietly drop the asset from the report to make the numbers look better.
Who should be in the tabletop?
The people who would really be there: the owner or an executive who can authorize spending and downtime, the IT lead and whoever runs backup, whoever speaks to customers, and — if you have them — legal, HR and finance representation. Eight to twelve participants works well; more than that and the quiet people stop speaking. A session attended only by IT finds only IT's gaps, and in our experience the expensive gaps sit between IT and the business: who declares, who authorizes, who talks.
Our insurer asks whether our incident response plan has been tested in the last twelve months. Does this answer that?
It produces exactly the artifacts that question is looking for: a dated exercise record naming the scenario, the date, participants by role, the objectives and the findings, plus a dated restore-test record with measured recovery times. What we cannot do is tell you whether a particular carrier will accept it, or advise on your policy — we are engineers, not brokers or counsel, and that boundary is deliberate. If the wider questionnaire is the real problem, the Cyber Insurance Readiness Assessment maps your Microsoft 365 and Azure controls to the questions carriers ask and produces the evidence pack for them.
Do you need administrator rights to our backup system?
For reconnaissance, read access is enough — we need to see policies, protected items, retention and recovery points. For the restore window itself you choose: either your administrator drives the console while we guide and time it, which many customers prefer and which has the side benefit of proving your own team can do it, or you grant an account holding only the restore role for that day and revoke it when the window closes. We do not need Domain Admin or Global Administrator, and we will say so if either is offered.
What will this cost us in Microsoft charges?
Usually very little, but it is not nothing and it is yours. A restored virtual machine consumes compute and managed disks for as long as it exists; a vault-tier restore can leave VHD files in a staging storage account that Microsoft explicitly recommends deleting to avoid extra charges; Microsoft 365 Backup bills per gigabyte of protected data per month to your Azure subscription at Microsoft's current published rate, although restores themselves are free under that model; cross-region restore moves data between regions. We size the drill to keep these trivial, list every resource created, and tell you exactly what to delete at teardown. Microsoft bills you directly; we neither resell nor absorb those charges.
Can you run it on-site?
Yes, but not at this price. This service is delivered remotely on Microsoft Teams, which is what makes a one-week, $3,950 fixed fee possible. An on-site exercise is quoted separately with travel and expenses; the on-site format we already run is the Rapid Cyberattack Assessment Workshop, a longer engagement built around a two-day workshop. Tell us your location and dates and we will quote the on-site variant in writing before you commit.
We use Veeam, Datto or Acronis rather than Microsoft backup. Is that a problem?
No. The drill measures whatever protects your data. We work in your console alongside your administrator, follow your vendor's documented restore procedure, and time the result exactly as we would with Azure Backup or Microsoft 365 Backup. We are not neutral about backup design in general, but we are entirely neutral inside this engagement: the report measures what you have, and any recommendation to change products would be a finding with reasoning attached, not a sales pitch attached to a drill you paid for.
Does the tabletop cover whether to pay the ransom?
It covers the decision, not the answer. The scenario forces the room to confront the question with a countdown running, and the exercise records who owns that decision, what information they would need to make it (is the data recoverable, was it exfiltrated, what does counsel say, what does the policy require, who must be notified), and how long the organization took to even identify the decision-maker. We do not advise on paying, do not negotiate with threat actors and take no part in executing a payment. The value is that the question gets its first airing in a room where nothing is actually encrypted.
How is this different from your Rapid Cyberattack Assessment Workshop?
The workshop is Microsoft-style assessment and education: it looks at your posture and shows which Microsoft technologies reduce the risk of a rapidly spreading attack, and it exists in remote and on-site formats. This engagement assumes prevention has already failed and asks a narrower, harsher question: when it happens, what do your people do, and does your data come back? Buy the workshop to improve defences; buy this to test recovery. Several customers eventually do both, in that order.
How is this different from Managed Backup and Backup-Restore?
Managed Backup and Backup-Restore is a monthly service: we watch backup jobs, chase failures, keep retention honest and perform periodic test restores as routine hygiene. This is a one-off exercise with a different purpose — a scenario-driven test of decision-making combined with a measured, evidenced restore that produces a report you can hand to a board or an insurer. They complement each other neatly: the drill finds the gaps, the managed service stops them reopening, and the next annual exercise has far less to find.
You find things. Do you fix them?
Only under a separate, separately quoted engagement, and never automatically. The remediation plan is written so your own team or another provider can act on it — that is deliberate, and it is why the report explains reasoning rather than just naming products. Where you would like us to do the work, common follow-ons are immutability and multi-user authorization on the backup vault, Azure Backup for servers, Microsoft 365 Backup, Azure Site Recovery where replication is the right answer, and a managed restore-testing cadence. Every one of those is a fixed written quote you approve before work starts, and none of them is a condition of this engagement.
How often should we repeat the exercise?
Annually is the cadence most insurance questionnaires and security frameworks imply, and it is what the remediation plan assumes. Repeat sooner if something material changes: a new backup product, a new plan owner, an acquisition, a significant change to your Microsoft 365 tenant, or a near miss. The second exercise is always cheaper in effort than the first because the scenario design, the target and the ground rules already exist — and the most useful measurement in a repeat drill is the delta: did the times improve, and did the gaps you owned actually close?