Backups and Recovery: Why Environmental Labs No Longer Need to Fear Data Loss

Why has data loss become the biggest operational risk for an environmental lab?

It’s a Thursday afternoon. The lab receives an email with an attachment that looks like an outstanding invoice. A technician opens it. In under five days — the average time it now takes ransomware groups to go from initial access to encryption — the lab’s shared folders, including the LIMS database running on the local server, are locked. A note on the screen demands payment to restore access. The IT lead checks the backup system: the last working copy is ten days old, and it was stored on a drive permanently connected to the very network that just got encrypted. That copy is gone too.

This scenario is no longer a remote hypothesis. Spain alone confirmed 164 ransomware attacks in 2025 and ranked as the sixth most-targeted country in the world during the second half of the year, against a backdrop of a 51.5% global increase in this type of incident.

The water sector is not immune to this trend. Recent threat intelligence reports point to a rise in intrusion attempts specifically targeting critical infrastructure tied to water and chemical processing, with treatment plants increasingly showing up on the target lists of ransomware groups alongside pipelines and energy providers.

Here’s the detail that changes the conversation: most ransomware attacks no longer stop at encrypting production data. According to industry analyses cited in specialist press, 93% of attacks also attempt to compromise, encrypt, or outright delete backup copies — precisely because attackers know an intact backup is the one thing that neutralizes their leverage. A backup stored on a drive connected to the same network you’re trying to protect isn’t a backup at all: it’s a second victim waiting its turn.

What is the 3-2-1-1-0 rule, and why has it replaced the classic 3-2-1?

For two decades, the industry benchmark was the 3-2-1 rule, popularized by photographer Peter Krogh: keep three copies of your data (the original plus two backups), on two different types of storage media, with at least one copy off-site. It’s a solid baseline against hardware failure, human error, or a fire in the lab.

The problem is that 3-2-1 was never designed with an active attacker deliberately trying to destroy backup copies in mind. That’s why the industry has moved toward the 3-2-1-1-0 model, which adds two requirements:

One immutable or air-gapped copy: A backup that, once written, cannot be modified or deleted during its retention period — not even with compromised administrator credentials.

Zero verified errors: A backup only counts as such if its restoration has actually been tested, on a regular basis. A backup that has never been restored is, in practice, an unverified promise.

The difference isn’t cosmetic. A 3-2-1 environment without immutability leaves open exactly the path a modern attacker exploits first: the backup itself. Only once at least one copy sits beyond the reach of whoever has compromised the network — immutable, isolated, verified — does recovery stop depending on negotiating with a cybercriminal.

RPO and RTO: the two metrics that determine how much you can afford to lose

Beyond how many copies exist, the question that actually matters to a lab is operational: if the worst happens, how many results are lost, and how long is the lab unable to work? Two metrics answer that:

For a water lab working under sampling deadlines set by frameworks such as the EU Drinking Water Directive (2020/2184) or the US Safe Drinking Water Act, with incident notifications that must go out immediately when parametric limits are exceeded, or with results reported into national or state water information systems, a high RPO — losing several days of work — isn’t just a technical inconvenience. It can mean repeating sampling runs, missing contractual deadlines, or, in the worst case, being unable to demonstrate a result’s traceability during an accreditation audit.

Recovery isn’t usually immediate either when a backup strategy fails. Multiple studies on ransomware incidents agree that only a minority of affected organizations manage to restore operations in under 24 hours, while a significant share take up to two weeks to return to normal. That gap between “having a copy” and “being able to operate again within hours” is exactly what a well-defined RPO and RTO deliver over a simple, untested folder of backups.

What does ISO/IEC 17025:2025 require for backups and data continuity?

The new edition of the standard, published on September 27, 2025, doesn’t treat data protection as a purely IT matter — it builds it into the lab’s technical competence requirements. The revision introduces explicit provisions on digital record management, electronic signatures, and validation of software used to process or report results, with a three-year transition period running until September 2028 for accredited laboratories to fully adapt.

In practice, this translates into very specific requirements for any system that manages test data, LIMS included:

Integrity of primary records: Data must remain accurate, complete, and traceable from instrument capture through to the final report.

Change traceability: Any modification to a data point must be logged without overwriting the original value (the ALCOA+ principle).

Periodic backups: The standard explicitly requires regular backups as part of the laboratory’s information protection.

Role-based access control: Only authorized personnel can modify a result, and there’s a record of who made the change and when, protecting against unauthorized tampering.

A lab that cannot demonstrate to an accreditation assessor — whether from A2LA, UKAS, DAkkS, or another recognized body — that its backups exist, run at the right frequency, and have been tested has an accreditation problem, not just an IT problem. Backup management stops being an IT maintenance task and becomes evidence of technical competence.

How Zendo LIMS protects your laboratory’s data

A cloud LIMS shifts most of this responsibility onto infrastructure specifically designed not to fail at the worst possible moment, instead of relying on someone remembering to swap a tape or check an external drive every night.

This architecture doesn’t eliminate the risk of an incident — no system can promise that — but it does eliminate the most common point of failure: the only backup copy living in the same environment you’re trying to protect. By separating production data storage from recovery copies, a cyberattack against the lab’s systems doesn’t automatically compromise its ability to restore information.

What should happen if your lab suffers a data-loss incident

No backup strategy replaces an incident response plan. If the worst case does materialize, the sequence that separates an hours-long disruption from a weeks-long crisis tends to follow a recognizable pattern from industry incident-response guides:

Isolate affected systems: Disconnect them from the network immediately, without powering them off, to preserve evidence and prevent the incident from spreading to other equipment.

Identify the real scope: Determine which systems, which data, and which time period were affected.

Notify internally: And, if personal data is affected, notify the relevant data protection authority — within 72 hours under GDPR in the EU, or per applicable breach-notification rules elsewhere.

Restore from a verified backup: Use the most recent backup that has been verified and kept isolated from the compromised network — never one that could have been encrypted along with the original data.

Fix the entry vector: Review and correct the original point of entry before bringing systems back into production, to avoid immediate reinfection.

The figure that sums up why prevention outweighs reaction is a simple one: paying a ransom guarantees nothing. In Spain, only 57% of SMEs that paid a ransom over the past year recovered part or all of their data; 31% found that the decryption key handed over by attackers simply didn’t work, and 29% suffered a second attack shortly after the first. A lab with automatic, verified backups isolated from its production network never needs to enter that negotiation in the first place.

Frequently Asked Questions

How often are backups performed in a cloud LIMS like Zendo LIMS?

Zendo LIMS runs periodic backups automatically as part of its infrastructure, with no need for the lab to schedule or execute them manually. This removes the human risk of forgetting or postponing a backup, which is one of the most common causes of data loss at labs running local servers.

Is a backup the same thing as a disaster recovery plan (DRP)?

No. A backup is the copy of the data; a disaster recovery plan (DRP) is the procedure that defines how, in what order, and how quickly systems are restored from those copies. A lab can have perfectly good backups and still take days to resume operations if it hasn’t defined and tested that procedure.

Why isn’t a network-connected backup enough to protect against ransomware?

Because modern ransomware actively hunts for network-connected backups before encrypting production data, specifically to eliminate the recovery path and force ransom payment. Only an immutable or disconnected copy guarantees an intact version of the data survives a compromised network.

Does ISO/IEC 17025:2025 require labs to have backups?

Yes, explicitly. The standard requires laboratories to protect the integrity of primary records, maintain traceability of changes, and perform periodic backups of test and calibration data — as part of technical competence requirements, not as a mere IT best-practice recommendation.

What happens to my lab’s data if I stop using Zendo LIMS?

Backup and continuity management for a cloud LIMS should come with clarity on the portability and export of the lab’s historical data. It’s a legitimate question worth resolving with the vendor before signing on, along with the retention periods for backup copies.