On 23 September 2026 Astrana Health signed an Item 1.05 8-K saying it had determined a cybersecurity incident was material as of 22 September. Threat actors had impersonated staff and spoofed the company's main phone number to contact employees. The company said it reset affected credentials, restricted remote access tools and restored some systems from clean backups.
That is a good tabletop scenario because it starts with a phone call, not an exploit. Below are three scripts you can run in 45 minutes each with five to eight people. One comes from the Astrana filing, one from Amgen's July filing about data in third-party cloud environments, and one from Boston Scientific's August outage.
What's affected
Tabletops fail when they test the plan nobody uses. These three scripts exercise the people and decisions that decide small-company outcomes: the service desk, the cloud vendor relationship and the recovery order. Each one is a conversation, so no systems are touched.
You need a facilitator who does not play a role, a scribe, and your real incident one-pager on the table.
How to check if you're exposed
Before you run anything, test the plan with three questions:
- If someone calls IT claiming to be a manager who lost their phone, what exactly does the desk do?
- If a provider tells you data was taken from your tenant, who reads that email and within what time?
- If your identity provider is down, how do you reach the people who can fix it?
If the answer to any is "it depends", pick the matching script below.
What to do now
Run one script a month. Keep each to 45 minutes: 5 to set up, 30 for injects, 10 for gaps and owners. Use this structure.
Script 1: The call from the main number
Based on the Astrana filing, where attackers spoofed the company's main phone number to reach employees.
- Setup: It is Tuesday 3 p.m. The service desk gets a call that shows your main office number. The caller says they are a regional director locked out before a client demo and needs MFA reset and remote access installed.
- Inject at 10 minutes: The caller knows the director's employee ID and manager name from LinkedIn. They push: "I will lose the deal."
- Inject at 20 minutes: The reset is done. Ten minutes later your identity logs show a login from a new country and a remote support tool session.
- Inject at 30 minutes: A second employee reports a similar call yesterday that they ignored.
- Questions: What does the desk verify and how? Who can approve an MFA reset without the user's current device? What do we revoke first? When is this a Sev 1? Who decides whether customer data was involved?
- Good output: A written callback procedure that uses a number from the HR directory, never the caller ID, plus a named approver for resets.
Script 2: The provider's email
Based on the Amgen filing. Amgen found unauthorized activity in cloud environments hosted by third-party providers, determined on 29 July 2026 that the incident was material because of the volume and sensitivity of affected files, and signed its filing on 31 July.
- Setup: Your hosting provider emails to say it found unauthorized access to storage that holds your customer exports. It cannot yet say which files.
- Inject at 10 minutes: The provider confirms that some of your files were copied. Counsel asks what personal data they contain.
- Inject at 20 minutes: A customer asks on the support line whether their data is affected.
- Inject at 30 minutes: Your insurer asks for notice "promptly" and the forensics firm asks for log access.
- Questions: Who owns the provider relationship? What do we know about what we stored there? Which notification clocks have started and from when? Who answers the customer today, and what do they say?
- Good output: A data map for that storage, a draft holding statement and a list of the contractual notice clocks.
Script 3: The Monday outage
Based on Boston Scientific, which identified an incident on 25 August 2026, reported a network outage affecting operating systems and business applications, and said full recovery was uncertain.
- Setup: On Monday morning staff cannot sign in, CI is down and the status page cannot be updated.
- Inject at 10 minutes: Backups exist, but nobody knows if the last good one pre-dates the intrusion.
- Inject at 20 minutes: The biggest customer asks for an ETA in writing.
- Inject at 30 minutes: Investors or your board ask whether this is material.
- Questions: What do we restore first and why? How do we know a backup is clean? Who approves the customer ETA? Where do we communicate if chat is down?
- Good output: A ranked restore list, a rule for choosing a restore point and an off-platform contact path.
How this could have been avoided
The Astrana filing is short, so these are controls that match the facts it gives.
- Never trust caller ID. A spoofed main number is useless against a callback to a directory number.
- Require a second factor or a manager approval before any MFA reset, and log who approved it.
- Allow only approved remote access tools, and block the rest. The company itself listed restricting remote access tools as a remediation step.
- Keep clean backups that an attacker with stolen credentials cannot reach, since the company restored some systems from them.
- Train the desk with a script like the first one above. Employees who get a suspicious call should report it the same day.
Why it matters
Tabletop value is in the gaps you write down. After each script, list three gaps with an owner and a date. Re-run the same script in 90 days and see which gaps closed.
Do not grade people. Grade the plan. If the desk could not verify a caller, the process failed, not the person who answered.
Try it yourself
Pick Script 1 and run it with only the service desk and one manager. Time how long it takes them to find the real verification procedure. If it takes more than two minutes, shorten and relocate the procedure.
Quick check
Why use a number from the HR directory to call back?
Caller ID can be spoofed, as the Astrana filing describes. A number you looked up yourself is not controlled by the caller.
What should every tabletop produce?
A short list of gaps, each with an owner and a due date, and a date to repeat the exercise.
