Know who to contact among regulators, law enforcement and other authorities, and keep those contacts current so you can reach them quickly during an incident or to meet a legal duty.
What an auditor, or Sekit's evidence engine, asks for.
Incident response plan
The plan defining how the company acts when a security incident occurs: who does what, who is notified, and within what timeframes.
From the Sekit evidence catalog
In practice
In practice this means the incident response plan names, by role, who calls the data protection authority, sector regulator, insurer, and affected clients, and within what deadline for each. Auditors ask to see the notification list itself, not merely a promise to comply, and check whether contact details were verified recently rather than copied once and forgotten. The common gap is a plan that names 'the regulator' generically without a current phone number, portal login, or named contact, so the first real incident becomes the first time anyone tries to reach them.
Common gaps
The incident response plan lists notification duties in general terms but never names which authority, portal, or contact to use for this specific business.
Contact details for regulators and authorities were captured once at plan creation and never verified since, so a real incident risks calling a dead number.
Notifications sent during past incidents were not logged, so there is no record proving the required deadlines were met.
Questions your auditor will ask
Who is responsible for notifying the data protection authority after an incident?
The incident response plan names a specific role, not merely a department, along with the deadline that role must meet.
How do you know your regulator contact details are still current?
The contact list is reviewed on the same cadence as the incident response plan itself, and the last review date is recorded.
Can you show a record of a notification being sent within the required deadline?
Notification logs from past incidents or exercises show who sent what, to which authority, and the timestamp against the deadline.
Where regulation demands it
NIS2 3.5 requires an incident response capability that includes notifying the right authorities, which is exactly what a current contacts list makes possible.
NIS2 3.1 requires a documented incident handling policy, the policy that must name who notifies which authority and by when under A.5.5.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.