Of all the duty of care measures, this is the one with a clock in it. Anyone reading it for the first time during an incident is already too late.
Which deadlines apply?
For organisations with a reporting obligation the law has three steps: an early warning within 24 hours of discovering a significant incident, a fuller report within 72 hours, and a final report within a month. The first report may be brief; what matters is that a report is made.
As a supplier you probably do not fall under that legal reporting obligation yourself. But your customer does, and they can only make their own 24 hours if you report quickly. That is why more and more contracts contain a reporting deadline for suppliers, often the same 24 hours.
What has to be in an incident procedure?
Who calls whom, who may decide to shut systems down, who informs customers, and in what order. With names and phone numbers, not with job titles alone. Print the procedure too: in a ransomware attack your own network, including the document with the procedure, is often the first thing to become unreachable.
Also keep a template report ready: which customer contacts get word, and which three sentences you send in the first hour. That stops the wording from becoming more important than the speed.
Do staff have to be able to report incidents internally?
Yes, and in practice this is the weakest link. Someone who has clicked a phishing link should know within a minute who to call, and feel safe enough to do it. One clear point of contact, repeated regularly, and the agreement that reporting is never punished: that is the whole recipe.
Do I have to log incidents?
Yes, the small ones too. An auditor will ask for your incident log; an empty log is suspicious and no log at all is a finding. The date, what happened, what you did and what you changed afterwards is enough. The log is also your own learning curve on paper.
When is an incident big enough to report?
The law speaks of a significant incident and gives two characteristics: it causes severe operational disruption or financial loss, or it affects others through considerable material or non-material damage. An infected laptop you wipe within the hour is not that. An outage of a service your customer runs on, or an attacker who was able to view customer data, is.
For you as a supplier the question is more practical: what did my customer agree contractually? Contracts usually carry a broader wording than the law, along the lines of any incident affecting the service delivered or the customer's data. When in doubt, report; a report that turns out to be unnecessary costs you a phone call, a missed report costs you the contract.
What do I agree with my IT provider?
That is the link where the clock breaks. At most suppliers the knowledge of the systems sits with an external managed service provider, who is not automatically reachable outside office hours. So record how quickly they respond to a security incident, who they call, and that they inform you rather than only fixing the problem.
Without that agreement, you discover at the first incident that your 24-hour deadline starts running while your provider is still in the queue. The same reasoning applies more broadly to your own suppliers.
Do I also have to report a data breach to the privacy regulator?
That is separate, and it is the mistake made most often. If personal data was affected, the GDPR reporting duty runs alongside: within 72 hours to the Dutch Data Protection Authority, and informing the people involved if it is likely to pose a high risk to them.
So one incident can produce two reports, with different deadlines, different recipients and different thresholds. Put them side by side in the same procedure, with who makes each report and where the form is. Work that out during the incident and you lose the hours you need most. How this ties into your wider policy is covered in risk analysis and security policy.
The full overview of the other nine topics is in the ten duty of care measures.