Hip of happening? | Cyberrecovery
Anyone who stood in front of an empty shelf at Albert Heijn in October or received a notification that their grocery order had been cancelled experienced first-hand how a cybersecurity incident can directly impact our daily lives. When was the last time your organisation tested whether its backups could actually restore business operations? A successful backup says little about how quickly you can get back to work after an outage or cyberattack. To do that, you need to know what to restore, in what order, and whether your data is secure. That’s exactly what this episode of the Hip of happening? podcast is all about.
Host Tom Jessen is joined by Peter Gommers, Senior Presales Consultant at PQR, a Bechtle company, and Elles van Blanken, Project Manager at a.s.r. Drawing on real-world experience, they explore the difference between storing data and being able to recover it when it matters most, and explain why every organisation should address that distinction before an incident occurs.
Backups are created every day, but restores are often only tested when a file goes missing or a system fails, allowing shortcomings to remain hidden for months or even years. Peter recalls an incident from his time at Atos: “The backups completed successfully every day. Yet when recovery was needed, we discovered that a particular folder hadn’t been included. The reporting accurately reflected what the backup solution had processed, but the organisation was still missing data it needed.”
Cases like these highlight an important reality: a successful backup job does not automatically guarantee a successful recovery. A backup administrator can see whether a task has completed successfully, but not necessarily whether all business-critical data have been captured, which is why application owners and data owners need to be involved in determining whether recovered data are complete and genuinely usable.
Elles encountered something similar at a previous employer. When a production issue needed to be investigated in a test environment, older data had to be restored first, but the recovery failed, ultimately leaving the team without a usable test environment at precisely the moment it was needed. As the incident unfolded, a simple question emerged: when had a successful restore last been performed? No one involved in the project could answer it.
Successfully restoring data on a small scale does not necessarily mean you are prepared for a major disruption. Peter therefore distinguishes between operational recovery, disaster recovery and cyber recovery.
- With operational recovery, you restore a file or database, for example.
- Disaster recovery focuses on restoring systems and services after a major incident.
- Cyber recovery introduces an additional challenge: which systems and data can still be trusted?
At a.s.r., the difference in scale became apparent following a storage incident in 2019. Failover was not an option because the issue originated deep within the storage environment itself. Backups had to be restored, but the process was simply too slow for the volume of data involved.
Elles stresses that production systems were affected far less severely and were brought back online relatively quickly. She explains: “The test environments were hit hardest. Recovering them took months, with the most critical process chains receiving priority.”
The incident ultimately led to the implementation of a new backup environment. When evaluating solutions, a.s.r. focused on the speed and completeness of recovery for both everyday incidents and large-scale disruptions. The connections to that environment also needed sufficient capacity. After all, even the fastest recovery software can only do so much if the data cannot be transferred quickly enough.
The recent Ahold Delhaize (Albert Heijn) incident highlights a key challenge in cyber recovery: it’s not just about restoring systems quickly, but also being confident that the data and systems you’re restoring are clean and trustworthy.
Peter Gommers, Senior Presales Consultant at PQR
A cyberattack adds another layer of complexity, as the recent Ahold Delhaize incident illustrates. Attackers may remain undetected for some time, meaning even the most recent backup can contain traces of the compromise. Peter explains: “Recent examples like these show that successful cyber recovery isn’t just about restoring systems quickly, but also being confident that the data and systems you’re restoring are clean and trustworthy.”
That requires close collaboration with specialists who can determine what happened, which malware was used and whether there are signs of compromise, enabling informed decisions about which data can safely be restored. This may involve analysing systems in an isolated recovery environment, often referred to as a clean room, as well as scanning backup data for potential threats.
It also changes the conversation around recovery speed, because the restore process itself is only one part of the overall recovery timeline. “Investigation, decision-making and preparing a secure environment all take time,” says Peter. “If you only start measuring from the moment someone presses the restore button, you underestimate how long the organisation is actually unable to operate.”
The cyber incident at Albert Heijn in October 2026 illustrates how these decisions play out in practice. The impact was felt by customers as well, with online orders being cancelled and store shelves left empty across the country. As a precaution, several systems were taken offline.
On 13 October, parent company Ahold Delhaize reported that it was working with external cybersecurity specialists on the investigation and recovery effort, while carefully bringing selected systems back online. That approach reinforces Peter’s point: the pressure to resume operations may be intense, but security must remain the guiding principle throughout the recovery process.
Any recovery strategy should start with your business processes. Peter refers to this as your minimum viable company. What is the minimum that needs to be operational for your organisation to resume its most critical activities? The answer determines which applications and data should take priority. You then need to understand which underlying IT services those applications and data depend on, because restoring an application achieves little if employees cannot log in or critical connections are still unavailable.
Together with the people responsible for those processes, define how much downtime your organisation can tolerate and how much data loss is acceptable. Two concepts are central to that discussion:
- Recovery Time Objective (RTO): the target timeframe within which a system or service must be restored.
- Recovery Point Objective (RPO): the maximum acceptable amount of data loss measured in time, for example the loss of the previous hour’s data.
These targets help define the requirements for your recovery solution, but testing must then demonstrate whether they can actually be achieved in practice. Elles stresses that preparation time must also be factored into the equation. “Fast recovery software doesn’t make that preparation time disappear.”
At a.s.r., preparation extended beyond technology alone. In tabletop exercises, employees work through realistic scenarios together and discuss how they would respond. Those discussions often raise uncomfortable but important questions:
- You may have a clean laptop, but how do you log in?
- Where is the required password stored?
- And can you still access it if the server storing it is unavailable as well?
The discussion can even extend to physical access. During an earlier disruption, access to the building itself became an issue. Even the Wi-Fi was unavailable because it depended on the affected storage systems, highlighting the kind of dependency that is easily overlooked when the focus is limited to the backup environment.
“If you don't prepare for that either, you'll find yourself searching for answers and holding discussions when the incident actually happens,” says Elles. Exercises reveal which information, resources and access rights need to be available in advance, while also forcing assumptions out into the open. What seems obvious to one colleague may turn out not to have been arranged at all for another.
Recovery decisions affect the organisation as a whole. Which services should take priority? How much disruption is acceptable? How much time and budget should be allocated to testing? These are not questions IT can answer on its own.
Regulation reinforces that responsibility:
- The Cybersecurity Act (NIS2) identifies business continuity, backup management, disaster recovery and crisis management as key elements of cyber risk management.
- It also requires the governing bodies of affected organisations to approve those measures and oversee their implementation.
- Financial institutions subject to DORA must also maintain documented backup and recovery procedures and carry out regular testing.
According to Elles, this increased attention helps bring the topic to the forefront. But exercises only deliver real value when their findings are acted upon, otherwise issues such as missing passwords, unclear responsibilities and slow recovery processes quickly disappear beneath day-to-day priorities. That’s why it’s important to set aside time not only for testing, but also for the improvements that follow.
Peter sees significant differences in recovery maturity across organisations. “In his experience, the financial sector is often further ahead, while many other organisations are only now discovering what still needs to be put in place.”
The next step does not necessarily require a new solution, but rather starting with a single critical business process and testing whether it can actually be recovered. Have the application owner validate the outcome, measure the time required and include the steps that come before the actual restore.
Peter recommends testing operational recovery regularly, automating it wherever possible, and conducting a larger disaster recovery or cyber recovery exercise at least once a year. Whatever type of exercise you choose, document what did not work and who is responsible for addressing it, creating evidence you can rely on when the next incident occurs.
Ask yourself this: if your most critical business process came to a standstill tomorrow, would you know how to restore it safely, or are you simply assuming your backup will be enough?
Cyber recovery – Hip or happening?
In the podcast series Hip or Happening?, we explore whether an IT development is merely attracting attention or already delivering tangible value, accompanied by the Bechtle Beat, the rhythm of innovation. One thing is clear: cyber recovery deserves a place on every organisation’s agenda. Listen now to the podcast episode featuring Peter Gommers and Elles van Blanken to learn more about cyber recovery and why it matters.
Assess your organisation’s readiness to recover from a cyber incident. This practical checklist helps you evaluate critical business processes, recovery testing and the requirements for restoring operations, making it easier to identify gaps and focus on the areas that matter most.
