Backups and restore testing for small SaaS teams, after Astrana's 8-K

In its Item 1.05 8-K signed on 23 September 2026, Astrana Health listed its remediation steps: resetting affected credentials, restricting remote access tools, restoring some systems from clean backups and improving monitoring. The order is worth noticing. Credentials come first, and the word "clean" does a lot of work.

Most small teams have backups. Fewer have tested a restore, and fewer still know how they would pick a restore point after an intrusion.

What's affected

Anything you cannot rebuild from code: databases, object storage, secrets stores, identity provider configuration, CI/CD settings, and the data you hold in SaaS tools. Backups of these fail in four common ways. They are encrypted or deleted along with production, they were never restored in a test, they contain the attacker's changes, or nobody remembers the steps.

How to check if you're exposed

Answer these in a meeting, not from memory.

1. Which systems are backed up, how often and where? Include SaaS data.
2. Can the credentials that run production also delete the backups?
3. When did we last restore each one, and how long did it take?
4. What is the maximum data loss we can accept (RPO) and the longest downtime (RTO) for each system?
5. How would we choose a restore point if the intrusion began weeks ago?

If question 2 is "yes" or question 3 is "never", you do not have recoverability yet.

What to do now

1. Put backups in a separate account or tenant, with separate credentials and MFA, and make deletion require a second person or a delay.
2. Turn on immutability or object lock where your provider supports it, with a retention window longer than your longest expected dwell time.
3. Write an RPO and RTO for each system, and a restore order. Authentication and secrets come before applications.
4. Schedule restore tests: monthly for the database that holds customer data, quarterly for the rest, and once a year a full rebuild exercise.
5. Record each test in a log, as in the template below.
6. Define "clean". Keep several restore points, and before using one, check it against your logs for unauthorized changes such as new users, keys, scheduled jobs or modified code.
7. Reset credentials and tokens before or during restore, otherwise you may bring the attacker's access back with the data.

RESTORE TEST LOG
System: ___            Date: ___        Tester: ___
Backup used (date/id): ___
Start: ___  Data usable at: ___  Elapsed (RTO actual): ___
Data age at restore (RPO actual): ___
Integrity check run and result: ___
Problems found: ___
Fixes and owner: ___  Next test due: ___

How this could have been avoided

The filing does not explain how the attack began beyond social engineering calls that spoofed the main phone number. These controls fit the facts it does give.

• Make backups unreachable from stolen staff credentials, so social engineering cannot delete them.
• Practice restores so that "restoring some systems" is a routine step, and the team already knows which ones matter.
• Keep clean restore points with known dates, so "clean" is a fact you have checked, not a hope.
• Prepare the credential reset runbook, because the company's own list put credential resets first.

Why it matters

Recovery is also evidence. Restoring quickly can overwrite the logs that show what was taken, which you may need for notification. Take disk or snapshot copies for investigators before you rebuild, and keep the restore log with the incident file.

A tested restore also changes insurance and customer conversations. You can say when you last restored, how long it took and what you fixed, instead of saying you have backups.

Try it yourself

This week, restore your customer database to a scratch environment from last night's backup. Time it, run a row count and a few spot checks, and fill in the log above. Do not stop until you have written down what surprised you.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Astrana Health Form 8-K, September 2026