On July 14, Romania's property market stopped working.

The country's National Agency for Cadastre and Real Estate Advertising, ANCPI, saw its e-Terra land registry application go dark. The agency first called it a "major technical incident," then confirmed it as a cyber attack. Notaries could not record transactions. Citizens could not obtain proof that they owned their own homes. Deals already in progress simply stalled. The agency's email servers went down with everything else.

Then came the detail that should interest anyone who runs a business on software. According to sources cited by Risky Business, the attacker got in using valid credentials, spent time mapping the internal network, tried to extort the agency, failed, and then wiped the systems.

And the backups.

That is the part worth sitting with. Not the breach. The backups.

Deleting the backups is the plan now

There is an old mental model where a backup is the safety net you fall into when something goes wrong. Hardware fails, someone drops a table, you restore from last night's copy and lose a few hours. That model assumes the thing going wrong is an accident.

An attacker running an extortion play is not an accident. Your backups are the reason you might not pay him, which makes them the first thing he goes looking for. Destroying them is not a cruel flourish at the end. It is the setup.

This changes what a backup actually has to be. If your backup lives on the same network, reachable by the same credentials, administered through the same console as your production system, it is not a copy of your system. It is a folder inside your system. The credentials that let someone ruin your Tuesday let them ruin your recovery in the same session.

Romanian officials have since restored the agency's website and posted a notice that they are rebuilding the entire network from scratch. Rebuilding a national network from scratch is a bad month. It is a survivable month only because, as Risky Business notes, the agency appears to have held an offline copy of the data. The hacker claimed to have deleted the backups. He deleted the ones he could reach.

Everything Romania still has is the stuff that was not plugged in.

This is not a Romania problem

It would be comfortable to file this under foreign government IT and move on. The list argues otherwise. Romania is now the seventh country in three years to have its land registry attacked, joining Poland, Slovakia, Greece, Morocco, Russia, and Ukraine.

Adrian Vascu, a senior partner at the Romanian advisory firm Veridio, put the underlying problem plainly in a LinkedIn post while the systems were still down. "A failure can happen at any time, but it is mandatory to ensure continuity or an alternative," he wrote. "Digitalization quickly creates dependency, but it must also ensure trust."

That is a fair description of what happens to most businesses over about a decade. You put the customer list in the CRM. Then the scheduling. Then invoicing, then job photos, then the pricing sheet everyone actually uses. Nobody ever decides to become fully dependent on software. You just stop keeping the other copy, one system at a time, because keeping two of anything is annoying and the software has never failed you.

The dependency arrives quietly. The test of it does not.

Three questions worth being able to answer

You do not need a security program to get most of the value here. You need honest answers to three questions, and most owners we talk with can answer the first one and stall on the other two.

Where is the copy that your own login cannot delete? Not the one in the same cloud account. Not the one in the connected drive that syncs automatically, because sync is a delivery mechanism for deletion as much as for files. Somewhere that requires a different key, or no network at all. If a stolen password can reach every copy of your data, you have one copy.

How long from zero to serving a customer again? Not how long to restore a file. How long until you can look up what a customer ordered, tell them what they owe, and take the next job. That number is the only one that matters, and it is almost never the number people assume. A backup that takes nine days to turn back into a working business is a nine-day outage with a comforting name.

When did someone last actually restore it? Restores fail for boring reasons. The archive was corrupt for eight months. The export ran but silently skipped attachments. Nobody has the decryption key because the person who set it up left. A backup nobody has restored from is a belief, not a plan, and the moment you find out which one it is happens to be the worst possible moment. That is the same failure mode as depending on the one person who understands your software: everything looks fine until the day it is tested.

The unglamorous part of the work

None of this is exciting to buy. There is no demo for a restore drill. It sits in the same category as the maintenance work most plans quietly skip, which is exactly why it goes unbought until the year it is the only thing that matters.

When we build custom software for a client, the recovery story is part of the architecture rather than an operational afterthought bolted on at the end. Where does the data go, who can reach it, what does the business do on the day the primary system is unavailable, and how do we know that answer is true rather than assumed. It is the same thinking behind ongoing maintenance and support: the value is not in the months where nothing happens. It is in being the business that is back on Thursday instead of the one rebuilding from scratch.

Romania will get its land registry back. It will take months, and it will cost more than any backup strategy ever would have. The thing that made recovery possible at all was not clever security. It was a copy of the data sitting somewhere the attacker could not click.

Most businesses have never checked whether they have one. If you are not sure what your own answer is, that is a good conversation to have on an ordinary week rather than a bad one.