Read the advisory's scope before borrowing its urgency
The Cybersecurity and Infrastructure Security Agency published joint advisory AA26-222A on August 10 with the FBI and other U.S. and international partners. It describes tactics associated with Gunra ransomware and says organizations named on the group's data-leak site span several sectors, including healthcare and public health. The advisory does not say how many healthcare organizations were affected, name a consultant pharmacy practice, or identify an MRR software product.
One detail is specific enough to test. At one victim, the actors deleted backup and archived data at both the primary and disaster-recovery centers before and after deploying ransomware. That is a report about one incident, not proof that every second site or cloud copy is vulnerable. The advisory does not explain how the actors reached both environments; the practical lesson is to test whether the same identities, network paths, or administrative controls can reach every copy.
Two sites can still share one failure boundary
The practical inference is about control, not geography. A second copy may sit in another building or region and still be exposed through the same administrator account, management console, retention rule, or connected network. Ask four separate questions: who can delete the copy, who can change its retention, what route can reach it, and what credentials are required to restore it. Offline, immutable, physically separate, and securely segmented describe different safeguards; one word should not stand in for the others.
Map the recovery owners before arranging a test
A consultant pharmacy workflow may cross a laptop, local file store, MRR platform, facility source system, identity provider, and managed IT service. No single party necessarily backs up or restores the whole chain. Put that recovery map on one page before asking for evidence:
- Production data and configuration: identify the owner, backup method, retention period, and restore authority for each system in scope.
- Identity and access: identify the accounts or recovery credentials needed if the normal administrator account is unavailable.
- Dependencies: record the network, integration, encryption-key, device, and vendor-service dependencies required to make restored data usable.
- Decision and communication: name who can declare the primary route unavailable, authorize recovery, contact each provider, and accept the restored result.
Test one restore path without putting production data at risk
Use a synthetic dataset in an approved test environment; do not copy resident information into an improvised exercise. Choose a small, entirely synthetic bundle: a facility list, review records, attachments, recommendation statuses, and an export. Assume the live service and its normal administrator are unavailable. Then ask the responsible party to restore the bundle through the documented recovery route.
Keep a short evidence record: test date, system and dataset, backup date, recovery point, recovery environment, elapsed time, people involved, dependencies used, records and attachments checked, errors found, exclusions, and the owner and due date for each unresolved gap. If a vendor performs its own recovery test, request the same scoped facts rather than a broad assurance that testing occurs. A successful test is evidence for that scope and date; it is not a certification that every system or scenario will recover.
Recovery evidence does not replace patching and access controls
The advisory also describes exploitation of known vulnerabilities in internet-facing systems, including firewall and VPN infrastructure. It reports credential compromise and, for one victim, exploitation of default credentials where account-lockout controls were absent. Its recommended actions include prioritizing patches for known exploited vulnerabilities in internet-facing systems, including VPN gateways and RDP-exposed infrastructure, using multifactor authentication and least privilege, and segmenting networks.
Apply that list to the systems the practice actually uses. Which internet-facing assets are in scope? Who tracks their versions and patch deadlines? Where is multifactor authentication enforced? Which account can alter backups? A restore exercise tests recovery. It does not compensate for an unknown asset inventory, a shared administrator account, or an exposed service that remains unpatched.
Ask for one restore result, not a security verdict
AA26-222A is not a new HIPAA rule, a breach determination, or evidence that a particular product is secure or insecure. The agencies also warn that legitimate tools named in the advisory are not, by themselves, proof of malicious activity.
On the next systems call, ask for the most recent restore result covering one data set the practice depends on. Confirm what was restored, when and where the test ran, what was excluded, which customer actions were required, what failed, and whether the remediation was retested. If nobody can produce that record, assign the test rather than filling the gap with a questionnaire answer. The aim is concrete: show that one critical dataset can be restored through the documented route.