At 8:12 a.m. on a Monday, a 42-person professional services firm could not open its shared client files. Staff saw a ransom note instead. Phones still worked, but email, accounting records, schedules, and the file server were unavailable. This ransomware recovery example shows what separates a disruptive incident from a business-ending one: quick decisions, protected backups, and accountable technical support.
The goal of recovery is not simply to make computers work again. It is to restore safe business operations, protect confidential information, preserve evidence, meet any reporting obligations, and keep employees and customers informed without making promises the business cannot keep.
The ransomware recovery example: what happened
In this scenario, an employee received what appeared to be a legitimate shared-document notification. The employee entered Microsoft 365 credentials on a fraudulent sign-in page. The attacker used those credentials to access email, identify a remote access tool, and move through the network over several days.
The attacker eventually encrypted the primary file server and several workstations. They also attempted to access the backup system. That detail matters. Ransomware groups increasingly target backups first because they know a business with clean, accessible backups has a practical alternative to paying a ransom.
The firm had a managed backup platform with encrypted off-site copies, separate administrator credentials, and retention points that could not be altered from an everyday user account. Its IT provider also monitored backup jobs and received alerts when unusual file activity began. The attack still created a serious interruption, but the organization had a workable path forward.
The first hour: contain the damage before restoring anything
A rushed restoration can reinfect the environment or destroy useful evidence. The first hour should focus on containment and communication, not on getting every employee back online immediately.
The IT team isolated affected servers and computers from the network. They disabled the compromised user account, reset privileged credentials, ended active remote sessions, and temporarily restricted remote access. They preserved the ransom note, security alerts, and relevant logs for investigation.
Leadership designated one incident coordinator to make decisions and one point of contact for employees. That avoided conflicting instructions and reduced the chance that a well-meaning employee would reconnect an infected device. Staff received a direct message: do not restart, connect, or troubleshoot affected systems; use phones or approved personal devices only for essential communications.
For organizations in healthcare, legal services, finance, government, or any field holding sensitive information, the containment phase may also involve legal counsel, cyber insurance contacts, a forensic specialist, and compliance advisors. Whether notification is required depends on what data was accessed or removed, not merely on whether systems were encrypted. Encryption can be a disruption event. Confirmed data theft can create additional legal and client obligations.
Recovery begins with a business priority list
Not every system should return at the same time. In this example, the firm listed the services it needed to operate at a basic level: secure email, phones, internet access, identity services, client documents, accounting, and line-of-business applications.
That order was not based on which server was easiest to rebuild. It was based on business impact. The firm needed a clean way to communicate with clients first. Next, it needed staff to access current case and engagement documents. Accounting could wait briefly, but only if payroll and vendor payments had a documented workaround.
This is why recovery planning needs input from operations, finance, department leaders, and IT. A technology inventory tells a team what exists. A business impact review tells them what must come back first.
Verify backup integrity
Before restoring files, the IT team reviewed backup timestamps and checked whether the copies were created before the encryption event. They scanned recovery points, reviewed logs for suspicious activity, and tested a small set of restored files in an isolated environment.
A backup that completed successfully is not automatically a clean backup. If attackers had access for days or weeks, an older recovery point may be safer than the most recent one. That creates a trade-off: restoring an older version can mean losing some recent work, but restoring a compromised version can extend the outage.
In this case, the team selected a recovery point from the previous evening for the file server and a slightly older point for a workstation with signs of earlier attacker activity. Department leaders helped identify recent documents that employees could recreate from email attachments, paper records, or client portals if needed.
Rebuild the environment, not just the files
The affected server was rebuilt on clean infrastructure rather than simply being restarted. The team applied security updates, changed service account passwords, reviewed administrative access, enabled stronger sign-in protections, and removed unused remote access tools.
The firm restored data in stages. First came identity and core communications, then essential shared files, then specialized applications and less time-sensitive archives. Each restored system was tested by both IT and the business users who relied on it. A server can appear healthy while a critical workflow, scanner integration, accounting plug-in, or permission structure is still broken.
By late afternoon, employees had secure email and access to priority documents. By the following day, the firm had restored its main application and accounting functions. The full cleanup took longer because the team continued reviewing endpoints, logs, and accounts for signs of persistence. That extra time was not wasted. It helped ensure the attacker did not regain access after operations resumed.
Should a business pay the ransom?
There is no universal answer, and no responsible provider should treat payment as an easy solution. Paying does not guarantee a decryption key will work, that stolen information will be deleted, or that attackers will not target the business again. It can also introduce legal, insurance, and reputational considerations.
In this ransomware recovery example, the firm did not pay because it had usable backups, could restore its most important functions within its acceptable downtime window, and did not have evidence that payment would improve the outcome. A different organization might face a more difficult decision if backups are unavailable, a critical system cannot be rebuilt quickly, or an extended outage creates immediate safety risks.
The right approach is to make that decision with legal, insurance, executive, and cybersecurity guidance. It should never be left to one employee under pressure from a ransom note.
What this business changed after recovery
The incident exposed gaps that were manageable before the attack but unacceptable afterward. The firm required multifactor authentication for email, remote access, and administrator accounts. It tightened access permissions so employees could reach only the files and systems needed for their roles. It also separated backup administration from normal network administration.
The team added ongoing security awareness training with realistic phishing tests. Training was not used to blame the employee who entered credentials. Attackers design messages to create urgency and exploit trust. The objective was to make reporting suspicious messages fast and judgment-free.
The firm also documented a recovery runbook. It included emergency contacts, insurance information, system priorities, backup locations, vendor escalation procedures, communication templates, and decision authority. A plan stored only in an inaccessible network folder is not a recovery plan. Key contacts and procedures need to be available offline or through a separately secured service.
Finally, leadership scheduled recovery tests. Backups are only valuable when they can be restored within the time the business can afford to be down. Testing reveals whether file permissions restore correctly, whether applications depend on overlooked servers, and whether employees know their role during an outage.
The practical lesson for New Jersey businesses
Small and midsize organizations are often targeted because attackers expect limited internal IT resources and inconsistent security controls. A ransomware event does not require a large enterprise budget to manage well, but it does require preparation. Protected backups, monitored systems, layered security, clear response roles, and tested recovery steps reduce uncertainty when time matters most.
AComp NJ helps businesses build that preparation into daily IT operations through managed support, cybersecurity, backup and recovery, and strategic planning. The focus is practical: protect the systems your team relies on, shorten downtime, and give leadership a clear path when an incident occurs.
The most useful question to ask before an attack is not, “Do we have backups?” Ask, “Could we restore the systems that keep us serving customers by tomorrow morning?” If the answer is uncertain, a recovery review now can prevent a far more expensive decision later.