6 Incidents that Prove DevOps in Healthcare Needs a Recovery Plan

Healthcare cybersecurity is usually discussed in terms of patient data and regulations like HIPAA. But software teams in healthcare need to protect the development layer with the same rigor.

After an incident, teams need a trusted record of the codebase and the project context around it. Without this safeguard, they’re guessing at what changed and what’s safe to restore.

The six real-world examples below show how DevOps-related data gets compromised, and what incident response teams can learn from them.

Novo Nordisk: a $25 million extortion demand following the theft of source code (June 11, 2026)

A few weeks ago, the cybercriminal group FulcrumSec announced that it had breached the Danish manufacturer of Ozempic. The attackers claimed to have stolen 1.3 TB of data and demanded a $25 million ransom in exchange for not disclosing what they’d obtained. After Novo Nordisk refused to pay, FulcrumSec said it would seek private buyers instead.

The alleged scope in the DevOps and research areas was extensive: over 700,000 files and more than 1,000 private repositories, spanning source code and internal AI models on one side, and drug development and manufacturing data (including over 41,000 experimental drug compounds) on the other. Novo Nordisk confirmed the incident but not the attackers’ full technical scope.

FulcrumSec acknowledged that a personal GitHub access token let it move across Azure DevOps, GitHub, AWS, and Hugging Face for over two months. If the attacker had that much access for that long, you can’t assume the environment is lean.

💡Recovery lesson: Better token security and access controls would help here, obviously. So would backups. Clean restore points and repository history let teams compare changes, verify integrity, and restore critical DevOps resources from a trusted point if attackers damage or encrypt the environment on top of stealing data.

AstraZeneca: leaked code can become a map of internal systems (March 26, 2026)

In March 2026, LAPSUS$ claimed it had stolen about 3 GB of AstraZeneca data. The company hasn’t publicly confirmed the full scope, but reports described a dataset that went beyond source code. 

It allegedly included Java project data, cloud infrastructure references, GitHub Enterprise user information, internal identifiers, configuration files, and access-linked records.

That kind of leak gives attackers more than files to sell. They may access a working map of how software, identities, cloud services, and supply-chain workflows fit together. If the data is later shared more widely, the risk spreads beyond the first attacker.

💡Recovery lesson: A code and configuration leak hands attackers a map of your environment. Keep a trusted restore point and enough history to trace exposed secrets, rotate access, and rebuild from a known-good state.

Ascom: attackers went through the ticketing system (March 16, 2025)

Ascom provides communication and collaboration technologies for hospitals, long-term care facilities, and corporate teams. In 2025, the Hellcat group hacked into the company’s technical support system and stole about 44 GB of data. The stolen data reportedly included source code, project information, and confidential documents. 

This followed a pattern Hellcat used in other attacks: credentials stolen by infostealer malware, then reused against systems like Jira  that still accepted them.

Ascom didn’t report critical losses and kept operating. Still, the incident illustrates how much technical information exists outside a central repository.

💡Recovery lesson: Ticketing systems hold the working memory of software delivery: bug history, technical context, links between code and operations. Treat them as DevOps recovery data, with secure backups and a recovery path separate from the environment accessible to attackers.

Diskriter: how one ransomware attack can hit source code and backups at once (June 8, 2022)

Diskriter provides health information management, revenue cycle management, and staff recruitment for medical facilities and government clients in the US.

In June 2022, the ransomware-as-a-service group Hive announced it had attacked the company and stolen over 160 GB of files. These included business documents, employee information, patient-related files, and data tied to software source code. Hive also claimed to have encrypted Diskriter’s backups. In one incident, the company faced data and credential exposure, a threat to its source code, and a compromised data recovery path, all at once.

Asked how they broke in, the attackers gave a blunt answer: Simple. Very poor network security.

💡Recovery lesson: Assume DevOps data and backups can be hit together. Keep repository backups outside the primary environment. Limit who can change backup policy or delete recovery copies.

ERT: ransomware disrupted clinical trial software workflows in the middle of the pandemic (September 20, 2020)

In September 2020, eResearchTechnology (ERT) suffered a ransomware attack. The timing could not have been worse, as the world was amid the COVID-19 pandemic, and ERT provides software used in clinical trials. Its clients included IQVIA, which was supporting AstraZeneca’s COVID-19 vaccine trials, and Bristol Myers Squibb, which was working on a rapid COVID-19 test.

ERT took its systems offline. Some researchers ran tests with pen and paper for about a week. IQVIA and Bristol Myers Squibb kept the damage limited because they had backups. Many other organizations in the same position hadn’t taken the same precautions.

No patients were harmed, but it slowed down the work at a time when every delay in COVID-19 research was critical.

💡Recovery lesson: Well-planned, tested backups save the day when things go wrong. Know which software assets support your critical work, and prove you can restore them quickly, before an incident happens.

Xybion: hardcoded credentials turned code into an access path (February 2020)

In 2020, Dutch security researcher Jelle Ursem discovered a set of public GitHub repositories exposing healthcare data and credentials. Xybion, a software and consulting provider for healthcare and life sciences, was one of the companies named.

In Xybion’s case, a developer left code in a public GitHub repository. That code reportedly included hard-coded credentials that, combined with the rest of the code’s context, gave access to billing back-office systems containing PHI for about 7,000 patients and over 11,000 insurance claims dating back to 2018.

The repository didn’t need to contain a full patient database to pose a threat. A single credential inside code was enough to turn it into an access path.

💡Recovery lesson: Credential exposure is a timeline problem. Keep repository history long enough to trace when a secret appeared, who had access to it, which systems trusted it, and which clean restore point can support remediation.

Rules for shaping a recovery plan for DevOps in healthcare

These six cases don’t share one failure mode. Some exposed code, credentials, or configuration. Others showed how fast backups or clinical software workflows can become part of the incident itself.

The rules below help healthcare and life sciences teams build a DevOps recovery plan around those dependencies.

1. Recover the working context around regulated software work

Ascom’s case pointed to a problem in code restoration: a repository holds code, but the delivery record usually lives in Jira and in pull requests.

In healthcare, that record may decide whether restored code is allowed back into the controlled workflow. QA needs to see approved changes, resolved defects, and confirmation that the tested version is the one being restored.

When that context is missing, you can restore the repository and still have to hold the release, because nobody can confirm the restored version matches the approved process.

Keep enough history to trace when a risky change entered the workflow, and which restore point still carries the approved record. Your DevOps backup has to bring back the code and the decision trail around it.

2. Define who can approve a restored state

A restore in regulated software is both a technical and a quality decision and has to involve more than just IT and security.

Engineering confirms that repository and build path work. QA/RA decides whether the restored version still complies with the approved release record. Privacy and legal step in when patient data or obligations towards customers are involved. Define these roles in advance.

Also separate daily DevOps access from backup policy and delete rights, so a compromised production account can’t rewrite the recovery path.

3. Keep recovery copies outside the same failure path

Diskriter shows that attackers now target the recovery flow itself. And since the FBI’s 2025 IC3 report names healthcare among the sectors most impacted by ransomware, you should treat your backup as a high-value asset.

Apply the 3-2-1-1-0 rule to your code and DevOps data. Keep backup copies outside the primary platform, off the same admin path, and with at least one copy protected from change or deletion.

When choosing a storage location for backup copies, bear in mind that it has to resist attacks and keep data in an authorized location.

Healthcare recovery copies often carry HIPAA, GDPR, or product-control obligations, especially where patient data, research IP, or release evidence is involved. A backup for an EU project stored outside the EEA, for instance, can become an international data transfer under GDPR.

4. Test your backup and DR plan against real failure scenarios

A restore test against an empty repository proves almost nothing for a healthcare software team. 

Test the failures that would actually block regulated work: a compromised token in a patient-facing app project, a deleted Jira project with QA evidence, or a broken pipeline for a regulated release. 

The team should also practice where it would restore data during a real incident. A recovered repository can still carry a malicious workflow polluted configuration, or broken approval record. Drop that straight into the original workspace and you risk contaminating the controlled path behind a medical device or a patient-facing fix.

Try a restore into a separate environment and inspection of the restored state before anything returns to production.

That tells you whether your data recovery is technically feasible, whether the data is reliable, and whether the approval chain is working.

Once you’ve defined your recovery plan, GitProtect helps you run it.

Automatically back up your DevOps data across GitHub, GitLab, Bitbucket, Azure DevOps and Jira. Protect your intellectual IP and work context. Restore repositories and project data, metadata included, to the original platform or to a separate recovery environment. 

Choose approved storage for each backup plan, so recovery copies stay where your security policy and compliance obligations allow.

For a practical example, read the SURGAR case study on how a healthcare software company moved from DIY GitHub backup scripts to a managed DevOps backup solution.