When it comes to incident recording in software development, there are two different things that are often confused: a vulnerability or defect in the software you build and deliver, and an incident in your own development environment — the setting in which you create that software. What you document, who needs to know, and what follow-up action is required differs depending on the type. Those who fail to make this distinction often miss the incident that matters most: a compromise in the build pipeline that spreads through the code to all customers who use it.
A vulnerability in delivered code affects the customer directly: they run the software, so they bear the risk. An incident in your development environment — a stolen access key, a compromised build account, a leak in the source code repository — affects you first, but can extend to every customer who works with that code. For both, a security questionnaire or an auditor does not ask whether something ever went wrong, but whether you can show what you have documented about it and what you learned.
What you document when there is an incident in the code
With a vulnerability or defect in delivered software, it is about: when it was discovered, by whom or what (internal testing, customer report, scan, external researcher), which part of the software it affects, what the possible impact is, what action was taken and on what date, and who within your organization owns the follow-up. Good documentation also makes it clear whether a fix has been rolled out to all customers using the affected version, or only to those who reported it. This last point is exactly what a customer asks about in a questionnaire: not whether you ever had a vulnerability, but whether your process ensures that everyone affected by it is informed.
What you document when there is an incident in your development environment
An incident in your own development environment — a compromised account with access to the source code, a build server behaving unexpectedly, a dependency that later proves to be malicious — requires slightly different documentation. Here it is about: which system or account was involved, who had access during the period in question, whether there are signs that code was changed or viewed, and which customers may be using software that was built or delivered during that period. This is the type of incident where access controls in the development environment directly come into play: without a current overview of who may access what, answering this question during an incident becomes considerably harder.
Who you inform, and who you do not
Whether you yourself fall under the cybersecurity duty of care or not determines who you inform about an incident. Entities identified as essential or important entities have a duty to report to their regulator; exactly what must be reported and within what timeframe is described in the directive and the national law, and varies depending on the situation. A software company affected through the supply chain — meaning it is not itself subject to the duty, but supplies a customer who is — does not have that duty to report to the regulator, but typically has a contractual obligation to inform the customer. This does not make your own documentation less important: a customer asking whether you ever had an incident wants to see a concrete answer, not a retrospective estimate.
A living register, not an archive
Incident registration works best as a living document: a list in which the status, evidence and owner of each incident can be found, rather than a separate report that disappears into a folder after resolution. This aligns with how the broader duty of care is structured, with ten measures that each require a status and an owner. Those wishing to see how incident registration relates to the other nine measures will find that overview on the page with all topics by situation.
Whether your organization falls directly under the duty of care, is affected through the supply chain, or neither, can be seen with a few questions via the NIS2 check which provides an indication in a few questions. For those who want to know precisely where the information on secria.eu comes from and how it is maintained, that is explained on the page about how it works. And those who, after reading, want to know what a subscription adds to what is available here for free, will find that clearly set out in the overview of what is included.
This text is general information and not legal advice on your own situation. For an assessment of your specific incident process or reporting obligation, you can consult a lawyer or the regulatory authority responsible for your sector.