Restoring the pulse: Lessons learned from a ransomware attack

When ransomware brings a healthcare organization to a standstill, recovery takes more than restoring servers. It requires teamwork and communication to rebuild a more resilient infrastructure that keeps patient care moving forward.

A few years ago, Mt. Graham Regional Medical Center experienced a ransomware attack that changed how we approach cybersecurity and disaster recovery. As our network collapsed and hundreds of servers became encrypted, we faced a complete disruption of the technology our organization relies on every day. We had to protect our environment, restore critical systems, and support clinicians and staff working under extreme circumstances.

While we eventually restored operations, the incident exposed gaps in our preparedness that we have worked hard to address. Here are several takeaways from our experience that you can apply to your own cybersecurity and disaster recovery strategies.

1. Assume an attack will happen and prepare accordingly

Our attack began well before we realized anything was wrong. Threat actors had been inside our network for approximately three months, using social engineering and credential harvesting to gain access.

We did not immediately recognize the situation as ransomware. Initially, it appeared to be a network issue. By the time the attack became clear, our virtual environment and hundreds of servers were being encrypted.

However, detecting suspicious activity is only part of the challenge. Organizations also need the ability to respond quickly, isolate compromised systems, and limit an attacker's ability to move through the network. Our immediate response included activating our security operations center, locking down systems, and using Velociraptor software to help investigate and identify compromised assets.

One principle has guided our thinking ever since: we need to slow attackers down so we have time to react. That means moving beyond a perimeter-based approach to security. Following the attack, we transitioned toward a zero-trust network architecture, strengthening how we validate access and protect systems. Cybersecurity can’t depend on the assumption that strong security measures will always prevent an intrusion. Preparation must also account for what happens when prevention fails.

2. Backups matter, but recovery speed matters too

One of the most important decisions we had made before the attack was to establish cloud backup services through BridgeHead approximately a year earlier. Our on-premises servers had been compromised, but we had a recovery path. Working with MEDITECH, our security partners, and other technical resources, we began retrieving backups and rebuilding our environment.

This process was intensive; we needed to restore approximately 100 terabytes of data, but our 1G internet — which is usually adequate in our small town — required an extended download time. Processing that volume of data took several days and became one of the biggest factors affecting our recovery timeline.

Our experience demonstrated that having backups is essential, but organizations must also evaluate whether they can restore those backups quickly enough to meet operational needs.

It is important to consider several questions when assessing recovery capabilities:

• How long would it take to restore the most critical systems?
• Can available network bandwidth support the recovery of large volumes of data?
• Are backups protected from the same threats that could compromise production systems?
• How will IT teams verify that restored systems are clean before reconnecting them?
• Which infrastructure and applications must be restored first?

For us, recovery involved moving systems through isolated environments, scanning them for threats, and progressing them into a clean environment before returning them to production. Security validation was a necessary part of recovery, not an optional step to accelerate the timeline. MEDITECH also required confirmation that the environment was clean before proceeding with reconnection. This reinforced that recovery speed and recovery security must go hand in hand.

3. Downtime procedures must be practiced, not just documented

When the network went down, our staff had to transition to downtime procedures. Some clinicians were comfortable returning to paper-based workflows, while others had become accustomed to digital charting and were concerned about working without the usual technology. This comparison became evident when seeing how our ED department was unfazed by downtime procedures due to their previous experience, while our daytime staff had more questions since it was unknown territory for them.

That difference highlighted the challenge that having a downtime process on paper does not mean every department is prepared to execute it under pressure. We also discovered communication gaps beyond the hospital itself when several of our fourteen external clinics closed. They assumed they needed to operate without access to the EHR because they did not have any communication from admin, and they had no practiced downtime procedures. This illustrates how a technology disruption can quickly become an organization-wide challenge.

The incident prompted us to rethink our business continuity planning. We needed clearer communication channels, better coordination between the hospital and external clinics, and a more consistent understanding of what each department should do when systems are unavailable.

One change we implemented was rolling downtime periods for individual departments. Rather than taking the entire organization offline at once, we gave departments opportunities to practice their procedures in manageable windows.

This approach helps staff become familiar with downtime workflows before a real emergency occurs. It also allows us to identify outdated documentation, inconsistent processes, and areas where additional training is needed. For example, we found some of our large downtime binders contained outdated forms (illustrated by the fact that the logos on them were 28 years old!). After making that observation, the quality department now manages binder updates on a monthly basis so there is a physical source of truth alongside our more recently implemented access e-forms.

4. Communication is as critical as the technology

During a cyber incident, IT teams focus on identifying the threat, securing the environment, and restoring systems. But technical recovery is only one part of the response.

Without reliable communication, even well-intentioned teams can make decisions that disrupt patient care or complicate recovery. We learned that our incident response structure needed to do more to connect technical teams with clinical and administrative leadership. Our updated business continuity planning places greater emphasis on incident command, communication responsibilities, and prioritizing which systems and services should return first. We also modernized aspects of our communication infrastructure, including phone routing and emergency call forwarding, so that critical communications can continue when normal systems are disrupted.

Another important lesson involved the security of the tools staff turns to during downtime. During the incident, we encountered an improvised emergency department dashboard built using a Google Sheet. The initiative reflected a need for accessible information, but it also raised questions about standardization and the protection of sensitive information.

We used that example as an opportunity to pursue a standardized, secure dashboard solution for departmental use during downtime. Providing approved alternatives before an incident can reduce the need for improvised solutions during a crisis.

5. Recovery depends on people, not just infrastructure

A ransomware incident creates uncertainty across an organization. Clinicians are trying to care for patients without familiar tools. IT teams are working long hours to investigate the attack and rebuild systems. Executives are managing operational decisions while trying to answer difficult questions from staff and the community.

For IT staff, the pressure can be especially intense. Teams must work methodically through a complex recovery process while facing understandable frustration from people who need systems restored immediately.

At Mt. Graham, we established rotating 12-hour IT shifts and coordinated work through a bridge line to support a sustained response, while protecting technical staff from unrelated interruptions. With AI-driven phishing attacks on the rise, we also deployed Darktrace human defense modules to simulate realistic phishing email attempts among staff, requiring individuals who fail multiple tests to complete a weeklong security defense course before returning to duties.

The psychological effects of a major cyberattack can last well beyond the restoration of systems. It reinforced the importance of recognizing stress, supporting employees, and making room for recovery after the immediate crisis has passed. Cyber resilience is not just about servers, backups, and security controls. It is also about building a culture in which people can respond effectively, communicate openly, and support one another under pressure.

Moving from recovery to readiness

Looking back, our ransomware attack exposed weaknesses we could not fully appreciate until we had to operate without our normal technology. It also gave us a clearer understanding of where to focus our efforts.

We have strengthened our security posture, moved toward a zero-trust architecture, improved our business continuity planning, and introduced regular departmental downtime exercises. We have also worked to improve secure communication and standardize the tools available to staff when systems are unavailable.

For healthcare organizations evaluating their own readiness, IT staff and clinical leaders can work together on three priorities:

• Validate your recovery capabilities. Confirm that backups are immutable and protected, restoration timelines are realistic, and systems can be brought back online securely.
  
• Practice organization-wide downtime. Test clinical workflows, communications, departmental responsibilities, and external-site coordination rather than relying on a written plan alone.
  
• Invest in people and processes. Establish clear incident command, define communication responsibilities, and ensure employees have the training and support they need.

At Mt. Graham, we learned that restoring the EHR is only one milestone in a much larger recovery effort. The goal is to restore safe, reliable operations while protecting the people, information, and services that make patient care possible.

We cannot predict every scenario, but we can prepare for disruption. The more thoroughly we practice, test our assumptions, and learn from experience, the better positioned we will be when the unexpected happens.