Our managed service provider's remote monitoring and management vendor was reportedly breached, and our environment was hit with ransomware. The investigation is still underway, so we are currently waiting for more information. We have an onsite backup server and an offsite backup, and our provider says the backups are available, but we have not completed a full end-to-end restore test.
Assuming we can eventually restore everything, what should our next steps be? We are already reviewing which systems were affected, how they were affected, and where our documentation and understanding are incomplete. This has also exposed some opportunities to improve our data management and disaster recovery processes.
We are also unsure how to evaluate the MSP and its vendor after the incident. What questions should we ask about the breach, the timeline, the data involved, the RMM platform, credential exposure, backups, and their response?
4 Answers
Assume every credential shared with or accessible through the MSP is exposed until proven otherwise. Rotate privileged accounts, service accounts, VPN credentials, local administrator passwords, API keys, and any credentials stored or used by the RMM platform. Remove old accounts and persistent remote access, then monitor closely for unusual authentication and administrative activity.
Ask whether the RMM had access to domain controllers, other Tier 0 systems, credential stores, backup servers, or broad administrative accounts. The answer will determine how extensive the credential reset and rebuild need to be.
Contact your cyber insurance provider immediately, even if the MSP has already done so. They can direct the incident-response process and may require specific forensic work before restoration. Also consider legal counsel and applicable law-enforcement or government cybersecurity resources.
Do not restore just because backups exist. Confirm when the backups were created, whether the backup infrastructure was compromised, and whether complete systems can actually be restored. Ideally, rebuild or isolate the backup environment and restore systems into a clean, controlled network. Each recovered host should be checked for persistence and kept isolated until it has been cleared. A recent backup may already contain the attacker’s foothold, so you may need to use an older recovery point.
The waiting period can be especially frustrating, but forensic collection should happen before recovery if possible. Restoring without identifying the entry point and persistence mechanisms can just result in another compromise.
Get the MSP’s answers in writing. I would ask when the intrusion was first detected, when they believe it began, when your organization was notified, what systems and data were accessed or exfiltrated, whether the RMM stored or exposed credentials, and whether the backup environment was touched. Also ask for their containment and eradication plan, forensic findings, indicators of compromise, and an explanation of how they will prevent a repeat incident.
Review the contract, notification obligations, liability language, security requirements, and insurance coverage. Their transparency and level of detail over the next few weeks should factor heavily into whether you continue working with them.
Use the incident as a full disaster-recovery exercise, but document everything while the details are fresh. Build a current inventory of systems, dependencies, owners, recovery priorities, and minimum services needed to operate. Record which systems were unclear or undocumented and turn those gaps into specific remediation tasks.
Independently verify the backup strategy rather than relying on a provider’s statement that it worked. Maintain multiple backup copies with at least one isolated or immutable copy, and perform regular test restores—not just backup-success checks. A second backup method can help ensure recovery remains possible if the primary backup platform or provider is compromised.
We already have several backup copies, but this has made it clear that we need to verify the restores ourselves and document the recovery process instead of assuming the backups are usable.
Some providers run their own management tools on highly privileged infrastructure, which can create a path through the entire environment. Treat that possibility seriously even if the initial report says only endpoints were affected.