From Alert to Action. NIS2 After Self-Registration: What's Next?
Self-registration is behind us. Your company has been entered in the KSC Register, the confirmation has been saved, and the topic has briefly disappeared from the management board’s calendar. Congratulations, now the real fun begins 😊
Then someone asks: “Right, but what do we actually need to do now?”
The best way to answer is with another question: if a serious alert appears tomorrow, will the company know who needs to make a decision and on what basis?
Because much of the practical implementation of NIS2 happens between “the system detected something” and “we know what we’re doing.” And we feel that we’ve been forgetting that a little lately.
You’re registered. Now you need a system that works
In Poland, NIS2 requirements are implemented through the amended Act on the National Cybersecurity System. For entities that already met the statutory criteria on 3 April 2026, the self-registration deadline was 3 October. The next important deadline is 3 April 2027, marking the end of the period for implementing the new obligations and starting to use the S46 system. The registration date does not start a new, full year of preparation.
What does this mean for a medium-sized or large company?
Risk management, security controls, incident handling, business continuity and cooperation with suppliers need to be brought together into one working mechanism. The Ministry of Digital Affairs identifies these areas as elements of preparing an organisation to meet its KSC obligations.
The easiest way to check this mechanism is to follow the journey of a single alert.
1. An alert needs to reach someone
A security tool has detected suspicious activity. An employee has reported an unusual message. A supplier has notified you of a service issue.
At this stage, the company has a signal. It does not yet have the full picture.
The first thing to establish is very practical: who will receive that signal? A “security@” inbox will be of little help if nobody checks it after hours. Having the administrator’s phone number does not solve everything either if the administrator is currently on holiday. And the legislator wants to see that you are making an effort.
You need agreed reporting channels, responsible people, backup arrangements and escalation rules. These are also needed when a problem occurs outside working hours.
This is a good example of the difference between a document and implementation. The document contains a contact address. In practice, someone receives the report and knows what to do next.
2. A technical message needs to be translated into consequences for the company
“Suspicious login to a privileged account” sounds like an IT issue.
But is it an account that can be used to change a service’s configuration? Access customer data? Stop warehouse operations? Shut down the system that handles orders?
Without this knowledge, it is difficult to set a priority. So let’s look at how this can be done in practice, using one of our clients as an example.
In the project materials for a company providing hosting and domain registration services, the starting point was to connect services, systems and access rights with risk and the incident response procedure. This way of working allows you to look beyond the tool’s notification and ask: what could this activity mean for the service being provided?
In a medium-sized or large organisation, the same logic involves more dependencies. A system may be maintained by central IT, used by several companies and supported by an external supplier.
That is why a server inventory is only the beginning. You also need an answer to the question: which business process depends on each of these systems, and who is responsible for that process?
3. Someone needs the authority to make a decision
A specialist confirms that the threat is real. They recommend restricting access or temporarily taking part of a service offline.
And that is when the second conversation begins.
Can order processing be stopped? Who approves the interruption? Can the supplier block an account independently? When does the management board need to get involved?
These rules should not be left until an incident occurs.
A useful example comes from a project for a manufacturing company for which we developed implementation recommendations: alongside Audyt 0, the scope of our work included a responsibility assignment model, or RACI. Its practical value lies in establishing who performs a task, who is accountable for it, who needs to be consulted and who must be informed.
The acronym may sound corporate. The questions it answers are very specific:
Who can disconnect a system? Who assesses the impact on operations? Who approves communications? Who makes sure the incident is reported to the CSIRT?
An IT supplier can carry out technical actions and support the analysis. However, the company needs its own rules for oversight and decision-making. Simply stating that “the service is provided by an external company” leaves too much room for guesswork.
4. Assessing the reporting obligation runs alongside the response
Not every alert means a significant incident. Not every incident requires the same notification.
That is why the procedure should include an assessment of the event against the applicable criteria and thresholds. Among other things, you need to establish the impact on the service, the scale of the disruption and the possible consequences.
When an obligation to report a significant incident arises, the standard model includes an early warning within 24 hours of detection, an incident notification within 72 hours and a final report within one month of the incident notification. For trust service providers, the deadline for the incident notification is shorter. If incident handling is still ongoing, a progress report and a subsequent final report are required.
This means that the company must be able to act with incomplete knowledge. The initial information will not have the level of detail found in a completed investigation report. But it will have to be submitted by the company, and that matters.
Starting the reporting process cannot depend on first establishing all the causes of the incident.
It is worth checking access to S46, user permissions, backup arrangements and the way information for the notification will be collected in advance. Registration in the register and readiness to report are separate tasks. Also remember that access to S46 does not have to be limited to the head of the organisation. Your service provider or SOC can also have access.
5. Restoring operations also requires a decision
“The system is back up” is good news. However, you still need to establish whether it is safe to return to normal operations.
Has the cause of the problem been addressed? Is the restored data correct? Have access rights been checked? Has the process owner confirmed that the service is working properly?
A business continuity plan should help answer these questions. It should define recovery priorities, acceptable downtime and data loss, and the conditions for returning to normal operations.
Simply saying “we have backups” does not establish how long recovery will take or whether the company will be able to resume operations afterwards. That needs to be checked in practice.
6. A decision should leave a record
During an incident, action matters. Afterwards, you need to be able to reconstruct what happened.
When was the event detected? What was known at the time? Who decided to restrict access? Why was a particular classification adopted? What actions were taken, and was their effectiveness confirmed?
This information may be held in incident logs, service tickets, reporting confirmations and test results. What matters is that it is consistent and available to authorised people.
A record of decisions also helps improve the process. It shows where data, contact details, permissions or clear responsibility were missing.
What should you do now, after self-registration?
A good next step is to review the current situation and identify gaps, then prepare an action plan with owners, deadlines and a budget. At SPIREE, Audyt 0 serves this purpose: it establishes the starting point and helps determine the order of work.
It is also worth planning a short exercise involving IT, the person responsible for security, the business process owner, management and a key supplier.
Choose one event identified in the risk assessment. Walk through it from the first signal to the restoration of operations. Check who receives the report, who assesses the consequences, who makes the decision and who documents its implementation.
If the conversation stops at “the supplier probably does that” or “we would have to ask the CEO,” you have just found a specific task to address.
After self-registration, what matters most is the company’s ability to act: from recognising a problem, through assessing the risk, to making a decision and checking its consequences.
That is the journey worth putting in order now.
Information current as of 28 October 2026. The implementation deadlines stated above apply to entities that met the criteria on 3 April 2026. For entities brought into scope later and organisations subject to specific rules, the timeline needs to be established separately.