One cyberattack brought real estate transactions across an entire country to a halt.

Following the attack on Romania’s National Agency for Cadastre and Land Registration, key digital systems became unavailable. Notaries could not process transactions, citizens could not obtain the necessary extracts, and banks could not register mortgages. The problem was no longer limited to the IT system. It affected the real estate market, financial institutions, companies, and citizens.

Although information about the full scope of the incident that occurred on 14 July still varies, the business impact is clear: critical services were unavailable for days, and restoring the systems required isolating the affected environment, checking data and applications, and gradually bringing them back into operation in a controlled manner.

The Romanian case therefore raises a question that every management board should be asking today:

Is it enough to know that we have a backup, or do we need to know how quickly and safely we can restore business operations?

Backup is not the same as business recovery

An organization may have backup copies of all important data and still be unable to continue operating for days.

The reason is simple: data is only one part of the system. . To restore a business service, it is necessary to recover applications, infrastructure, user accounts, access rights, configurations, and connections with other systems. . At the same time, it must be verified that data copies are complete and correct, and that the environment into which they are restored is truly secure.

In practice, the most important question is therefore not simply: “Do we have a backup?”

Much more important questions are:

• How much time do we need to restore a key business service?
• How much data can we afford to lose without seriously jeopardizing business operations?
• In what order do we restore applications and systems?
• How do we confirm that we are not returning a security problem to production?

If the answers have not been verified through concrete tests, the organization does not have a confirmed recovery plan — it has an assumption that recovery will work.

One gap can be enough

According to information published so far by Romanian institutions, the attackers most likely combined known, unpatched vulnerabilities with previously compromised access credentials.

This is an important lesson because it shows that a major incident does not always have to be the result of a sophisticated attack. Sometimes access to a single account, an unresolved vulnerability, or insufficiently restricted privileges is enough.

That is why protection cannot rely on a single product or one line of defense. The protection of identities, endpoints, networks, privileged access, and backup environments must be connected with continuous monitoring, timely response, and a predefined recovery plan.

The goal is not to create a system we believe will never be compromised. The goal is to ensure that one compromised account or device does not allow an attacker to move freely through the entire organization and reach the most critical systems.

Recovery speed is a business metric, not just an IT metric

When a key process is fully digitalized, system unavailability also means the unavailability of the business service.

Every additional hour of downtime can bring:

• lost revenue
• inability to meet contractual obligations
• interruption of work for employees and partners
• regulatory and legal consequences
• loss of customer trust
• reputational damage.

That is why the decision on an acceptable recovery time should not be made by the IT department alone. Business functions must determine which processes are critical, how long they can be unavailable, and what minimum level of operation must exist during recovery.

Only after that can technology be designed in line with real business priorities.

Restore is not the final step

The pressure to bring systems back online as quickly as possible can lead to another mistake: restoring compromised data, applications, or configurations into the production environment.

Secure recovery therefore means more than the technical restoration of data. It is necessary to identify the last known safe version, verify the integrity of copies, remove the root cause of the incident, and perform restoration in an isolated environment. Only after additional security checks can systems be gradually returned to production.

Otherwise, the organization risks restoring the same problem that caused the incident together with the data.

Five questions for the management of a company or institution

The Romanian case can serve as a reason for leadership to check its own readiness:

• When did we last test the full recovery of a key system?
• Can an attacker who compromises the production environment also access backup copies?
• How long can we operate without each of our critical systems?
• Who decides the order in which business services are restored, and who confirms that they are secure?
• How does the business function while technical recovery is underway?

If the answers are not clearly defined, documented, and verified through a realistic exercise, the problem is not only cybersecurity. The problem is business resilience.

Cyber resilience is proven before an incident

The most resilient organizations are not those that believe an attack will never happen to them. They are the organizations that know what to do when it does.

They have multi-layered protection, separated and verified backup copies, defined priorities, realistically set recovery timelines, and a plan for operating during disruption. Most importantly, they test those plans regularly.

The real question is no longer only whether an organization can preserve its data.

The real question is whether it can continue operating when its key systems stop.