An incident record is the overview you maintain of what happened, when, in which system and who was involved, from the moment you notice something unusual until the moment it is resolved. For an ICT service provider, this concretely means: the time of the first report, which customer systems were affected, which employee or subcontractor had access at that time, what steps were taken, and when the situation returned to normal.
This record is not a statutory reporting obligation in itself — that applies to organisations that fall under the Cybersecurity Act themselves, not automatically to their suppliers. But a customer who is subject to the obligation must be able to assess their own supply chain, and they do this by asking you how you document incidents and make them demonstrable. Without an organised answer to that question, a contract often does not progress beyond intake.
Why this matters specifically for ICT service providers
An installation company or a consultancy typically has one environment to monitor: their own. An ICT service provider structurally works in the systems of others, often remotely, sometimes with far-reaching administrator rights. If something goes wrong there, the question is not only what happened at your end, but also what was affected at the customer and whether that can be traced back to a session, an account or a moment of access. Customers who themselves fall under the duty of care expect you to be able to demonstrate that traceability, even if the incident occurred months ago.
Remote management: what you record
Remote management involves three things that must be traceable separately from each other: who started the session, from which account or which workstation, and what was done in that session. Many remote management tools log this automatically, but the question that matters is not whether the tool logs it, but whether you can show that logging when a customer or a regulator asks for it. Maintaining a separate list of which customer environments are remotely accessible and by whom is often sufficient to answer that question without having to delve into the technical details.
Access to customer systems: granted, used, revoked
Access to a customer system is usually not a permanent state but a moment in time: someone receives an account, uses it for a task, and access is then revoked. In an incident, the first question is often who had access at that time, not who ever had access. A register showing when access was granted and when it was revoked makes it possible to answer that question quickly and specifically. If that overview is missing, you have to reconstruct it at the moment when time is already pressing, and that is precisely the moment when it is most difficult.
Subcontractors: the chain does not stop with you
If you yourself work with a subcontractor for part of the management, the question does not shift, it extends. A customer assessing your work wants to know whether an incident that occurs at your subcontractor is also visible to you, and not only discovered afterwards via a phone call. In practice, this means that agreements with subcontractors say something about mutual notification periods, and that your own incident record leaves room to indicate which part of an incident lay with a third party. worked through by subject what is relevant for your situation provides a good starting point to see which supply chain questions apply to your type of service provision.
What a record is and is not
An incident record is a documented account, not a response. It concerns what you can demonstrate after something has been resolved, not how quickly you react or what technical measures you deploy during an incident — that latter work belongs to incident response teams, SOCs, and forensic investigators, and it is explicitly not what this article or secria.eu is about. What we do provide is clarity in overview: which measure corresponds to which piece of evidence, and who within your organisation is responsible for it. answers to questions that SME suppliers frequently ask shows where the boundary lies between documenting and actually responding.
Where you place this
Whether you yourself fall under the Cybersecurity Act or are affected through a customer, the question about incident recording appears in almost every security questionnaire. An organised answer starts with knowing exactly where you stand: in a few questions see whether and how you are affected makes that clear in a few minutes, without requiring you to create an account.
Would you like to know how such a record becomes a living file in practice, with a status, a piece of evidence and an owner for each measure? Do the free NIS2 check or read the knowledge base on secria.eu; both are available without an account.