Knowing you've been breached doesn't tell you what's safe to restore. An organization may be able to recover its files but you need to justify reconnecting the systems that use them. It still needs to establish what the intruder changed and whether access created during the attack remains.
October gave three warnings in quick succession. Vulnerabilities in PHP were exploited before a patch was available and organizations, including the Dutch National Cyber Security Centre and ourselves, took websites offline as a precaution. On October 21, Microsoft described how the state-aligned group Storm-0940 used the agentic AI framework ARTEX to attack hundreds of organizations, including through a supply chain compromise. In some cases the attackers went from a first foothold to privileged cloud access in less than three hours. And the Dutch Institute for Vulnerability Disclosure, DIVD, was hit by an attacker working at machine speed: two previously unknown vulnerabilities, and more than 2,500 traces where a careful human attacker leaves twenty or thirty.
The pattern is clear. AI can uncover weaknesses faster than organizations can fix them, leaving defenders with less time to act. When an attack moves faster than anyone can respond, the only option left may be to pull the plug. The harder question comes after that: how quickly can you restore critical operations, and how do you know it’s safe to do so?
Albert Heijn's October disruption offers a sense of the financial stakes. Retail experts consulted by RTL Z estimated that the chain missed €120 million to €150 million in revenue. Home deliveries restarted on October 23, nearly two weeks after the incident began, initially with about a third of normal delivery capacity. Physical stores had remained open but with some empty shelves. What caused the incident, and why recovery took the time it did, has not been made public. The lesson is simply that time is money.
Recovering fast takes two things: information and the people who can interpret it. Logs show what happened. Only a team that knows how the environment was built, how it changes and what depends on what, can judge what that means for the service and whether it is safe to restore. Without the logs, that team is guessing. Without the team, the logs are noise.
Writing this article sharpened a second lesson. With advanced agentic attacks, detection becomes the easy part. These attacks are noisy: thousands of actions at machine speed. The weight shifts almost entirely to response, and that is where the real challenge lies. When attackers can reach privileged cloud access within three hours, there is no time to first find out how an environment works. The team has to establish quickly, from information logged beforehand, what is going on. That is what keeps the time to recover short.
The information behind a recovery decision
A serious alert establishes a need to investigate. It may say little about the full extent of a compromise. For recovery, teams need to work out which systems and identities were affected, what the attacker changed and how confident they are in those findings.
Closing the original entry point may leave more work to do. Microsoft's guidance includes investigating credentials and permissions changed during an attack, because additional access can persist after that entry point is closed. A system that functions normally may still offer an intruder a route back in.
The same care applies to the material used for restoration. NIST's incident-response guidance recommends checking backups and other restoration assets for integrity before use. It also calls for checking restored systems for signs of compromise and addressing the incident's root causes before production use. Those checks require evidence about the attack as well as the systems being recovered.
That evidence depends partly on what was recorded before anyone knew there was a problem. Logs from identities and applications need to be connected to activity in the infrastructure supporting the service. Investigators must also know where visibility is incomplete. The absence of a record from an unmonitored component can't establish that the component was untouched.
Volume adds to the challenge. An attacker working at machine speed leaves thousands of traces, as DIVD experienced. Analyzing them by hand takes time the business doesn't have, so investigation needs automation as well as people who can judge what the evidence means.
An organization won't always have a complete forensic account before recovery begins. NIST's guidance recognizes that recovery may begin while incident response continues. The task is to establish enough reliable information for a bounded decision, while making remaining uncertainty explicit.
What has to be prepared before the incident
Preparing that information is an engineering responsibility. Teams need to establish which attack scenarios matter to a critical service and whether the relevant activity would be observable. Log sources must remain connected and usable as the environment changes. Detection logic needs to reflect how the service actually operates, including its identities and dependencies.
Architecture also shapes how precisely a team can investigate and recover. Segmentation can limit the systems an attacker reaches. Carefully bounded access can restrict what a compromised identity can do. Separately manageable components can give responders options to contain an incident and restore parts of a service in a controlled sequence.
Responsibility needs the same clarity. The people accountable for the service must know who can authorize its return. Those relationships should already be working when an incident forces the decision.
Where MCDR contributes
We call our approach Mission Critical Detection and Response, or MCDR. It brings specialized detection and investigation together with the teams responsible for operating the environment. Their knowledge of how the service was built and how it changes helps turn security findings into decisions about containment and recovery.
What we do differently is where the work sits. A central platform collects and stores the logs and runs a standard set of detection use cases for every environment. The operational work sits with the teams that manage the environment and have the context: threat modelling for their service, developing bespoke use cases, making application logs available and responding to incidents. Our security specialists support them and step in where the evidence gets complex. That way, the people who know the systems are the ones who judge the findings.
MCDR also takes on the volume. When an attacker leaves thousands of traces, the platform automates threat hunting and the first steps of an investigation at scale: collecting the relevant logs, correlating activity across identities, applications and infrastructure, and bringing forward what needs attention. That leaves the team with context to do what automation can't: judge what the evidence means for the service and decide what is safe to restore.
We have rolled out MCDR to all mission-critical environments we manage, also where a customer already has its own internal or external security operations center. That security operations center retains its enterprise-wide role. MCDR adds depth within the mission-critical environment, where investigators and operating teams need to work from the same evidence. Relevant findings must reach the people able to act, with agreed authority and a clear account of the implications for the service.
This is also why response can't depend on a central SOC alone. A central team loses time on hand-offs and lacks the context of the environment. With three hours on the clock, response has to be organized close to the systems, by the teams that run them. The central SOC keeps its role across the enterprise. The response capability moves to where the context is.
Implementation starts with the critical service and the attack paths that could affect it. We assess visibility along those paths, improve the log sources needed for investigation and develop detection logic that fits the environment. Response procedures then connect findings to executable actions. Testing establishes whether the team can obtain the information it needs and carry out the intended intervention.
This is practical engineering work. During the Log4j response, our engineers developed detection logic as the incident unfolded and examined available logs for evidence of exploitation. A published interview describes how security specialists and customer teams combined their knowledge to understand the affected environments and organize action.
For recovery, MCDR supplies investigative findings that help establish what was affected and what changed. Those findings support the engineers and service owners making restoration decisions.
MCDR is a crucial part of the answer, and one of several things an organization has to get right. Recovering quickly also depends on patching fast, knowing what you run, limiting how far an attacker can get and having practised the response. The information position and the team with context are where it starts.
An organization can test this preparation on one critical service, taking a credible attack scenario all the way to recovery. The people responsible should be able to explain which evidence supported the decision to resume the service and what uncertainty remained.
The records needed for investigation and the relationships between the people using them should be established while the business is operating normally. Gaps discovered then can be addressed before an outage turns them into a commercial cost.
If recovery has to wait for information, the business keeps paying for the wait.
Sources
[1] Microsoft Security Research and Microsoft Threat Intelligence. AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise. October 21, 2026.
[2] Ahold Delhaize. Ahold Delhaize update on status of cybersecurity incident. October 19, 2026.
[3] NCSC. Update PHP kwetsbaarheden nog steeds reden om direct te patchen. October 21, 2026, updated October 23, 2026.
[4] Schuberg Philis. Jenda Brands on being a Mission Critical Security Engineer and a detection and response expert. April 9, 2024.
[5] NIST. Incident Response Recommendations and Considerations for Cybersecurity Risk Management A CSF 2.0 Community Profile. SP 800-61 Rev. 3, April 2025, recovery guidance on page 34.
[6] AGF reporting estimates made for RTL Z. Cyberproblemen kosten Albert Heijn naar schatting 120 tot 150 miljoen euro omzet. October 20, 2026.
[7] Albert Heijn. Mediastatement inzake cybersecurity incident. Updates of October 21 and 23, 2026.
