Incident Reporting for NIS 2 in SecureVisio – A Practical Guide for SOC Operators

Introduction: New Obligations, Concrete Deadlines
Across Europe, the situation remains highly fragmented despite the formal EU deadline of 17 October 2024 for transposing the NIS 2 Directive. While Poland has now completed its legislative process with the publication of UoKSC, many EU Member States are at different stages of implementation.

In Poland specifically, from April 3, 2026 companies covered by the act have exactly 12 months to fully comply with its requirements. For SOC teams and security managers, one of the key questions is: how can incident reporting obligations to the appropriate authorities be fulfilled efficiently? This article answers that question in the context of the specific capabilities offered by the SecureVisio platform.

What Does NIS 2 Require in Terms of Incident Reporting?
Before moving to system configuration, it is important to clearly understand the legal framework, as it defines technical priorities.

Two Reporting Levels — Two Time Windows
The act introduces a two-stage model for reporting significant incidents to the appropriate teams — in Poland CSIRT NASK, CSIRT GOV, CSIRT MON, or a sectoral CSIRT, depending on the organization.

The first stage is an early warning and initial assessment, which must be submitted to CSIRT within 24 hours of detecting a significant incident. During this time, the operator must conduct a preliminary evaluation and classify the event based on defined thresholds. This is a very tight window—especially in environments where serious incidents are discovered at night or over the weekend.

The second stage is the formal incident notification, which must be submitted within 72 hours of detection. This report should include a full update of the information provided in the early warning, a description of the incident’s severity, its impact on the organization, and indicators of compromise (IoCs). While 72 hours may seem sufficient, in practice this period overlaps with ongoing incident response—the team must both contain the incident and prepare the report simultaneously.

Which Incidents Must Be Reported?
The reporting obligation covers a wide range of events: malware attacks, phishing, DDoS attacks, database breaches, intrusion attempts, and online fraud. However, not all such events are automatically reportable—the classification of the incident is decisive.

The act defines three levels:

• Critical incident: events causing significant harm to public security, international or economic interests, the functioning of public institutions, or human life and health.
• Significant incident: events that cause or may cause serious degradation or interruption of a key service, financial losses, or major material or non-material damage to other entities. This category carries direct reporting obligations and strict deadlines.
• Minor incident: events that may negatively impact IT system security but do not meet the thresholds for critical or significant incidents. These are not reported to CSIRT but must be handled internally.

For SOC operators, this taxonomy directly affects workflow: there must be a mechanism to quickly and unambiguously classify incidents and trigger appropriate escalation and notification paths. This is where SecureVisio provides tangible operational value.

How SecureVisio Supports NIS 2 Reporting — Configuration Layer

Incident Category Library as a Starting Point
The foundation of adapting SecureVisio to NIS 2 reporting requirements is proper configuration of the Incident Categories library. This dictionary defines classification options available to operators handling events.

The library can be accessed directly from the Incidents form in the Desktop application via a dedicated button and the Categories option. Configuration is performed once but has long-term implications for the entire reporting process—from what operators see during classification, through notification automation, to filtering and reporting of incidents that require CSIRT notification.

In practice, the library should include at least categories corresponding to reportable incident types—malware, phishing, DDoS, breaches, intrusion attempts, fraud—with clear indication of which qualify as significant or critical under the law. A well-designed taxonomy is foundational: without precise categories, neither automated notifications nor reporting will function as intended.

Incident Classification During Handling
When an incident enters the system, the operator can classify it as reportable to CSIRT directly from the event card in the Incidents tab of the Desktop application. The process is simple: open the event card and assign the appropriate category from the configured library.

This seemingly simple step has major process implications. Assigning a category that triggers reporting obligations marks the starting point for all subsequent actions—notifications, response playbooks, and most importantly, tracking statutory deadlines. In regulated environments, this starting point must be clear and auditable.

It is also important to note that classification does not have to be final. During investigation, the severity may change—what initially appears to be a minor incident may later qualify as significant. The system allows reclassification, which can trigger notification paths that were not activated initially.

Notifications as a Mechanism for Enforcing Deadlines

Why Notification Configuration Is Critical Under NIS 2
With only 24 hours to submit an initial report for a significant incident, you cannot rely on the right person checking the incident queue at the right time. Notifications in SecureVisio eliminate this risk—relevant individuals are informed immediately when configured conditions are met, regardless of whether they are actively monitoring the system.

Step-by-Step Notification Configuration
Notification settings are available from the Incidents list form in the Desktop application. After opening the configuration window, you can add new notification rules or edit existing ones.

Each configuration requires several elements:

• Configuration name: required and practically important—good naming helps manage growing rule sets.
• Trigger conditions: at least one must be defined; this is where you specify which incident categories trigger notifications. For NIS 2, these should clearly map to reportable categories.
• Resource and event conditions: allow narrowing notifications to specific systems, network zones, or event types.

Next, define communication channels: email, SMS, and SecureVisio’s internal messenger. For urgent events—like significant incidents with a 24-hour reporting window—it is advisable to configure more than one channel. SMS or internal messaging ensures faster delivery than email.

Finally, define recipients: specific individuals, groups, operational teams, or roles within the organization. The role-based option is particularly useful when responsibility for CSIRT communication is tied to a function (e.g., CISO, NIS 2 coordinator) rather than a specific person.

What This Means in Practice
A properly configured notification system ensures that classifying an incident as reportable automatically triggers a notification chain to the appropriate people. This means a SOC operator handling an incident at night does not need to manually call the CISO—the system handles it. Responsible parties are notified immediately, maximizing the available time within statutory deadlines.

Key Process Considerations Before Implementation

• Category taxonomy must be carefully designed: it determines which incidents enter the NIS 2 reporting workflow. Collaboration with legal and operational teams is essential.
• Notification recipients must understand their responsibilities: alerts are useless if recipients do not know what actions to take. Procedures must accompany technical configuration.
• Deadlines should be embedded in workflows: 24-hour and 72-hour deadlines are easy to miss during active incident response. Consider how the platform can provide reminders or deadline tracking.

Summary
NIS 2 for SOC teams means building an incident reporting process that is fast, precise, and auditable—especially given the strict 24-hour initial reporting deadline.

SecureVisio addresses this across multiple layers:

• the incident category library aligns classification with legal requirements,
• category assignment creates a clear and auditable starting point,
• and a configurable notification engine ensures immediate awareness via email, SMS, and internal messaging.

While this does not eliminate analytical work or formal reporting requirements, it removes delays caused by lack of awareness and insufficient automation—making a real difference under strict legal deadlines.