Contact
Silhouette of a person in front of a large screen filled with blue and green lines of data

Library

Incident response

Share via

What does an organisation do in the first 24 hours after a cyber incident?

Incident response is the structured handling of a cyber incident, from the first signal through to recovery and evaluation. The first 24 hours mainly decide whether the evidence survives and whether the organisation meets the statutory reporting deadlines. Under the Dutch Cybersecurity Act, in force since 15 August 2026, an early warning is due within 24 hours, followed by a notification within 72 hours.

Those deadlines keep running while the investigation is still under way. An organisation therefore reports on incomplete information, while recovery actions must not erase the traces that same investigation needs. That tension makes the first day difficult, not the technology.

We see decisions determine the outcome of an incident more often than the technology does. Who may shut systems down, who informs customers and who signs the notification is rarely settled in advance. That division of roles belongs in place beforehand.

In this article

When is something a cyber incident?

Incident response begins at detection and ends at the evaluation. Digital forensics is the investigative part that establishes what exactly happened. The two are often named in one breath as DFIR.

Not every alert is an incident. A blocked phishing email belongs to the normal work of administration and monitoring. There is an incident only when an attack actually affects systems or data.

The Dutch Cybersecurity Act calls an incident significant in the case of serious operational disruption. Financial loss or considerable damage to others can meet the threshold as well. Ministerial regulations set concrete threshold values per sector.

What happens in the first 24 hours

The first question is whether the incident is still active. As long as an attacker has access, every recovery action changes the picture and a visible intervention may alert them. Isolation therefore comes before clean-up, and securing evidence comes before reinstallation.

Reinstalling an infected machine straight away often costs the evidence that turns out to be needed later. Memory and log files disappear on a reboot, and without that data it stays unclear which information was accessed or taken. That is precisely what the supervisor will want to know afterwards.

The governance line runs in parallel. Someone decides on shutting down systems and informing customers. The moment the report goes out calls for a decision too.

Where and within what deadline must a report be made?

Several reporting duties run at the same time, each with its own deadlines and its own desk. Reporting under the Dutch Cybersecurity Act happens in three steps, through a single central desk on MijnNCSC. A report there reaches both the supervisor and the sectoral Computer Security Incident Response Team, or CSIRT.

Requirement Deadline Where to report
Early warning, Cyber Security Act Within 24 hours MijnNCSC
Incident notification, Cyber Security Act Within 72 hours MijnNCSC
Final report, Cyber Security Act Within 1 month after the notification MijnNCSC
Personal data breach notification, GDPR Article 33 Within 72 hours Dutch Data Protection Authority
Notification to affected individuals, GDPR Article 34 Without undue delay in case of high risk Directly to affected individuals

The clock starts as soon as the organisation becomes aware of the incident, not once the investigation is complete. Continuous detection in a Managed SOC therefore also decides how much of the deadline is left. A voluntary report goes only to the CSIRT and not to the supervisor. Organisations that still have to establish whether the duty applies to them find the scope in The Dutch Cybersecurity Act: 15 August 2026.

What the NCSC does and does not do

The NCSC supports incidents primarily in the identification phase. For containment, eradication and recovery the NCSC calls it essential to involve a specialised IR party in good time. Ultimate responsibility for the response stays with the affected organisation.

That distinction determines who gets called on day one. The CSIRT provides interpretation and advice on the threat. The organisation and its suppliers carry out the forensic investigation and the rebuild.

The supervisor also has a different role from the CSIRT. The CSIRT supports during the incident, the supervisor assesses compliance afterwards. The same report reaches both, but they read it with a different interest.

The boundaries of an incident response engagement

An incident response engagement is not a recovery project. Recovery is a phase within the investigation, and without insight into the way in it stays guesswork.

The reporting duty does not transfer to an external party. The organisation reports itself, signs itself and accounts for itself. Our specialists for Incident Response and Forensics deliver the facts that notification rests on.

Nor can the size of an incident be steered in advance. Preparation does prevent wrong decisions in the first hours from making the investigation impossible.

How an engagement proceeds after the first days

Containment is followed by the question of how large the incident is. Investigation establishes which systems and data were affected, and which path the attacker used to get in. Without that picture the way in may still be open.

Recovery is rarely a matter of restoring a back-up. In a compromised identity environment the organisation replaces passwords and keys, and rebuilds the underlying trust relationships. In environments with OT there is the added question of which production can keep running during recovery.

The engagement ends with an evaluation and an improvement plan. At that same moment the organisation prepares the final report for the supervisor. Compliance and governance records how that accountability is built up, so a board decision becomes demonstrable.

When is a retainer worthwhile?

A retainer sets out in advance who will come and how quickly. The value lies less in the response time than in the fact that procurement and introductions are already behind. Without arrangements, the first day often goes to arranging access and aligning expectations.

The model suits organisations where downtime has immediate financial or societal consequences. That applies to organisations under the Dutch Cybersecurity Act and to service providers with contractual recovery deadlines. For organisations with limited dependence on IT, the fixed fee weighs heavier than the benefit.

More important than the contract is the preparation around it. Current network documentation and log sources with sufficient retention determine how quickly an external team can really work. Without that basis the team is ready quickly and the investigation still gets going slowly.

Conclusion

Sound incident response limits the damage an attack ultimately causes. The first 24 hours are about preserving evidence, containing access and meeting the reporting deadline. Those three can get in each other's way, and preparation decides how often that happens.

The main limitation stays that no plan determines the size of an incident in advance. What a plan does determine is whether the organisation can afterwards show what happened and what it did about it.

Sources

NCSC, Reporting duty under the Cyberbeveiligingswet | NCSC, Help and support during cyber incidents | NCSC, Incident response plan | Rijksoverheid, Cbw and Wwke in force from 15 August 2026 | Cyberbeveiligingswet, Bulletin of Acts 2026, 187 | Regulation (EU) 2016/679, GDPR

Last reviewed: 4 September 2026.

← Back to library

Direct access to senior cybersecurity expertise

Discuss a security requirement, active risk or complex IT or OT environment with one of our senior specialists. The initial conversation focuses on the technical context, operational constraints and the most appropriate course of action.

  • No mailing lists or automated sales follow-up
  • Information is handled confidentially

Urgent assistance required?

Call +31 (0) 70 290 6 290
or email  info@deepbluesecurity.nl

Thank you. The message has been received and will be reviewed by one of our specialists.
The form could not be submitted. Please try again or contact info@deepbluesecurity.nl.