Is a Security Operations Center (SOC) required to comply with the requirements of the National Cybersecurity System Act (KSC / NIS2)?

There has been a great deal of misunderstanding surrounding this topic. Some cybersecurity service providers suggest that every organisation covered by the National Cybersecurity System Act (KSC) must build a full 24/7 Security Operations Center. In practice, the rules are more flexible. The Act does not expressly require an SOC, but it does impose an obligation to ensure continuous monitoring and to apply technical and organisational measures appropriate to the level of risk.

This means that for some entities, the appropriate solution may be an external SOC or an MDR service, while for others, well-designed monitoring based on SIEM, alerts, on-call duty and clearly described incident response procedures will be sufficient. The key issue is therefore not the mere possession of a particular service, but the ability to detect, analyse and handle security events in a manner proportionate to the scale of operations, the criticality of the systems and the potential consequences of an incident.

In this article, we explain how continuous monitoring required under the KSC differs from a full SOC, when an SOC is justified, what alternative models exist, and how to choose a solution suited to an organisation’s risk profile. We also show why the path to compliance with the NIS2 Directive and the KSC should not begin with the purchase of a tool, but with a thorough risk analysis and the identification of which systems actually require constant monitoring. 

Key takeaways from the article

• The KSC and NIS2 do not impose an obligation to have a Security Operations Center (SOC).
• The rules require continuous monitoring of information systems, but do not specify any particular technology or organisational model.
• The choice of monitoring method should result from a risk analysis, the size of the organisation and the importance of the protected systems.
• For many organisations, an in-house SOC will be disproportionately expensive and not commercially justified.
• Continuous monitoring can be implemented using various models, from basic SIEM with on-call duty to MDR services and full SOC.
• The Ministry of Digital Affairs has indicated that monitoring requirements may also be met using SIEM tools, appropriate procedures and automation.
• Organisations must be able to demonstrate to the supervisory authority that monitoring is functioning effectively and supports the incident response process.
• Monitoring procedures, log retention and readiness to report incidents within the time limits set out in the KSC are of key importance.
• An in-house SOC is justified mainly for organisations with the highest risk profile, such as banks, critical infrastructure operators or large key entities.
• The path to KSC compliance should begin with risk assessment, and only then with the selection of security tools and services.

Where did the myth of mandatory SOC come from?

The regulatory impact assessment indicates that the amended KSC provisions will cover a total of approximately 38,000 entities across 18 sectors of the economy. Of these, at least 27,900 are entities from the public sector, while the remainder are entities operating, among others, in the energy, transport, banking, food production, and digital services sectors.

The implementation of these provisions has caused considerable panic in the market. The clock is already ticking: by 3 October 2026, self-identification must be carried out and registration must be submitted, and by 3 April 2027 full implementation of risk management measures is required.

During this tense period, many myths have arisen, fuelled by the aggressive marketing of security service providers. One of the most frequently repeated claims is that the NIS2 Directive and the amended KSC absolutely require the use of a SOC.

A SOC is a specialised organizational unit (or service) whose primary task is the continuous monitoring, analysis, and protection of IT infrastructure against cyber threats. The SOC team monitors digital screens around the clock (on a continuous basis) and looks for traces of suspicious activity. When the system raises an alert, SOC experts determine whether it is a false alarm or signals a real threat.

The key areas of SOC responsibility include:

• continuous monitoring (24/7) – aggregation and ongoing observation of logs and events from across the entire IT infrastructure: from servers and network devices to cloud applications and users' endpoint devices,
• threat detection and analysis – use of SIEM (Security Information and Event Management) systems and machine learning algorithms to identify anomalies and unwanted events,
• incident response – taking immediate remedial action once an attack has been confirmed, e.g. isolating infected workstations, blocking malicious network traffic, and preventing the escalation of the threat,
• proactive and preventive measures – searching for hidden threats (eng. threat hunting) and managing vulnerabilities in systems, which makes it possible to harden the infrastructure against potential attack vectors.

Many organizations believe that without a large SOC budget, compliance with KSC regulations is unattainable. However, the true regulatory, technological, and operational picture is much more nuanced – and decidedly more favorable to smaller and medium-sized organizations, provided they approach the issue analytically and strategically.

Let us start with the basics, not with ready-made solutions

In the KSC itself, the word „SOC” does not appear even once. What does appear is „monitoring” – and in two key places:

„Monitor in continuous mode” does not mean SOC.

• in the list of obligations of key entities or important entities – as „covering the information system used to provide the service with a continuous monitoring system” (Article 8(1)(2)(g)),
• in Annex No. 4 to the Act – as a possible element of an information security management system in important entities that are public entities: „monitoring access to information and the operating status of information systems using dedicated software used by employees or using the services of a managed cybersecurity service provider in this respect” (Part II, point 5).

Article 8(3) of the KSC introduces an important exception:

„An important entity that is a public entity or an entity referred to in Article 7(1)(1–4 and 6–7) of the Act of 20 July 2018 – the Law on Higher Education and Science, which is not a research organization, to the extent that it performs public tasks using information systems, shall not apply the provision of paragraph 1. The entity referred to in the first sentence shall develop, implement, carry out, monitor, and maintain, in the information systems controlled by that entity, an information security management system meeting the requirements specified in Annex No. 4 to the Act”.

This means that:

• key entities – must apply continuous monitoring,
• important entities that are public institutions or universities and institutes – do not have to,
• other important entities – must apply continuous monitoring.

By “continuous monitoring” is meant the uninterrupted detection and observation of events in the system. The provision specifies a particular outcome, but does not determine the form of its implementation – this follows from the obligation to implement “appropriate and proportionate, in relation to the assessed risk, technical and organizational measures taking into account the state of the art, implementation costs, the size of the entity, the likelihood of incidents occurring, the entity’s exposure to risks, and social and economic consequences” (Article 8(1)(2) of the KSC Act).

These measures must be:

• appropriate – tailored to the identified threats,
• proportionate to the assessed risk – justified by the level of social and economic consequences and the consequences for the entity, as well as by the likelihood of an incident occurring,
• taking into account the latest state of knowledge, the costs of the solutions, and the size of the entity.

This leads to the conclusion that the specific solution must have a rational, practical justification. We therefore know that monitoring must be conducted continuously, but the form it takes will depend on the risk assessment.

Continuous monitoring, or... how?

Before choosing a solution, it is necessary to take a closer look at what lies behind the concept of continuous monitoring.

The Ministry of Digital Affairs, in the document “Ustawa z dnia 5 lipca 2018 o krajowym systemie cyberbezpieczeństwa po nowelizacji. Pytania i odpowiedzi,” explains how continuous monitoring should be understood:

“the point is to ensure accountability for actions taken in the system and to analyze the events that occur. It is not necessarily necessary to hire an additional person for this purpose; open-source SIEM tools may be used and appropriate rules configured. In particular, events that may be the cause or consequence of an incident should be monitored. Monitoring applies in particular to traffic from and to the entity, access to the system, accounts with privileged access, critical configuration files and backup copies, logs from cybersecurity tools (e.g. antivirus, anti-spyware), and environmental events that may affect the operation of the system infrastructure (flooding, fire, etc.)” (p. 31).

This means that:

• monitoring must operate in real time, 24 hours a day, 7 days a week – daily checks at a fixed time are not sufficient,
• continuous monitoring must cover the systems necessary for providing the service, not all systems,
• events from the systems must be analyzed on an ongoing basis – one option is to route them to a SIEM solution.

It is also worth remembering that attackers deliberately choose nights, weekends and public holidays, as they count on a delayed response. That is why monitoring carried out only during the organisation’s working hours does not fulfil its function of detecting incidents in a timely manner.

What can continuous monitoring look like in practice?

Before considering the options, it is worth knowing that entities covered by the KSC are subject to supervision.

• Key entities – ex ante (prior) supervision: the supervisory authority is entitled to proactively review procedures, infrastructure and documentation. The key entity must, at its own expense, carry out a comprehensive external audit of the information system’s security at least once every 3 years. In addition, the competent authority may at any time request access to data in the course of inspection activities or order security scans and vulnerability tests to be carried out.
• Important entities – ex post (subsequent) supervision: this is usually carried out in the form of ad hoc audits, typically after the organisation has experienced a serious incident or when information about gross violations reaches the authority. Important entities carry out an audit only at the request of the competent cybersecurity authority.

The competent cybersecurity authority may ask a key entity or an important entity to provide evidence of the implementation of an information security management system. This may include documents such as procedures, policies, authorisations, job descriptions, as well as statements from staff. What is required is proof of the actual application of KSC provisions, not the submission of formally correct documents.

Therefore, entities must have, among other things:

• a monitoring policy (or procedure) – precisely defining what is monitored, why, and who is responsible for responding to alerts and incidents, and within what timeframes, as well as setting out the framework for on-call duty arrangements or cooperation with external providers,
• system logs – retained for a minimum of 12 months (the KSC does not define this period, but such practice provides a historical audit trail enabling the investigation of incidents during which the so-called dwell time – the time an intruder spent in the system – was relatively long).

The ability to carry out continuous monitoring is intrinsically linked to the incident response procedure and to the strictness of incident reporting, especially those classified as serious:

• early warning – within 24 hours of detecting the incident,
• serious incident notification – within 72 hours of detection,
• final report – within one month of reporting the incident.

The final report is a detailed analytical document that closes the incident handling process, containing a description of the attack vector, root cause analysis, and a summary of all impacts.

Let us take a closer look at SOC

A traditional SOC requires physical operational space, SIEM-class event correlation systems, and a specialised team of analysts, divided into different support tiers, carrying out incident response processes in a documented manner on a continuous basis, i.e. 24 hours a day.

• Tier 1 – round-the-clock monitoring of the SIEM console, initial verification of incoming events and alerts, and filtering out false alarms.
• Tier 2 – in-depth analysis of incidents escalated by tier 1, as well as taking active remediation and attack containment measures.
• Tier 3 – the most experienced experts handling advanced analysis and proactive threat hunting, conducting forensic analysis and developing new detection rules.

Having an in-house SOC gives an organisation full autonomy and a high degree of flexibility. Internal teams know their company’s business and technological specifics extremely well. This knowledge enables them to accurately and instantly distinguish false positives and phenomena characteristic of a given industry from real attacks. Analysts work closely with the IT department, which ensures the fastest possible isolation of critical incidents and blocking of compromised segments of the infrastructure. It can be said that an in-house SOC is a kind of „final boss” of event monitoring.

A SOC has not only advantages but also significant limitations. One of them is the high fixed operating cost: to ensure continuous 24/7 operation, taking into account on-call duties, public holidays, staff rotation and vacations, it is necessary to employ at least 5–6 analysts for the first level alone (tier 1). In addition, one must also take into account the high demand for specialists (and their shortage on the labour market), steadily rising remuneration in the cybersecurity sector, and the costs of licences for commercial enterprise-class systems, priced either on a volumetric basis (depending on indexed data in GB/day) or based on the number of events per second (EPS – Events Per Second).

Mature SOCs increasingly use SOAR-class systems (Security Orchestration, Automation and Response), which automate repetitive tier 1 tasks such as isolating an infected host, blocking a malicious IP address, or creating incident tickets. SOAR does not replace analysts, but it makes it possible to reduce their number and shorten response times. However, this is a solution for organisations with established security processes. For most entities covered by the NIS Act, it remains outside the scope of consideration.

An in-house SOC is therefore an option mainly for the largest players. However, the NIS Act allows the form of continuous monitoring to be tailored to the level of risk. Below we present the available alternatives.

Model 1: basic monitoring

8/5 monitoring with on-call support – this consists in combining full, round-the-clock automation of threat detection with flexible staff response times. Security systems operate continuously (24/7), while event analysis by a human is carried out continuously during business hours (8/5), and after hours – on an alert-based (reactive) basis.

Example implementation:

• Wazuh – an active SIEM/XDR-class system responsible for ongoing log analysis for attack patterns, monitoring the integrity of system files, and detecting software vulnerabilities.
• Syslog server – a repository of raw data ensuring that logs from network devices (firewalls, switches) are sent to a separate, secure location. Although Wazuh can collect logs on its own, a separate Syslog server provides additional benefits:
  • if the Wazuh dashboard is compromised and alerts are deleted, the Syslog server retains physical evidence of the attack,
  • overloading Wazuh does not result in log loss – the lightweight Syslog server will continue to record them,
  • logs in Syslog are unprocessed, which may increase their evidential value.
• Alert handling:
  • during business hours – by a designated IT administrator,
  • after hours – by the on-call administrator, to whom the SIEM system sends notifications of the highest priority (e.g. via SMS or messenger).
• Costs: licences – PLN 0 (open source), implementation – the administrator’s labour cost, maintenance – the cost of on-call shifts.
• Role allocation:
  • tier 1 – SIEM automation and administrators during business hours,
  • tier 2 – the on-call administrator or senior IT administrator,
  • tier 3 – in the event of a very serious incident; this is generally not present in small organisations.

Monitoring in this model can be extended with additional components, e.g.:

• NDR (Network Detection and Response) – a high-end solution based on machine learning and artificial intelligence, enabling the detection of an intruder who is concealing their presence so effectively that SIEM correlation rules are unable to identify them,
• Honeypot – the cheapest intrusion detector, which pretends to be an easy target (e.g. a server with open access to a database), so that any movement towards such a trap is an unambiguous signal of an intruder’s activity,
• EDR agents (Endpoint Detection and Response) – software installed directly on endpoint systems that sends event data to the server, verifies file checksums, detects vulnerabilities in installed packages, and executes automated blocking scripts in response to specific alerts,
• FIM (File Integrity Monitoring) module – a tool monitoring important files and folders which, upon detecting any change, immediately generates an alarm in Wazuh.

Model 2: own SIEM – external SOC

In this model, continuous monitoring tools are managed by the organisation, while day-to-day monitoring and incident analysis are outsourced to an external provider. If the provider confirms a genuine incident, it will notify the organisation or the administrator on on-call duty. Monitoring and human analysis take place continuously on a 24/7 basis, while response takes place on an 8/5 basis, and after working hours – on an on-call basis.

Companies that wish to avoid vendor lock-in choose this model. If the external SOC raises prices or lowers the quality of services, the organisation simply changes provider – analysts from the new company log in to its SIEM system.

Example implementation:

• SIEM systems, e.g. Microsoft Sentinel, Splunk, Rapid7 InsightIDR.
• Alert handling – 24/7 by the provider’s SOC.
• Costs:
  • SIEM – depending on the solution and implementation method,
  • SOC – depending on scale and the number of events as well as the team’s workload; in the case of a small scale, a cost in the range of PLN 5–10 thousand net per month may be considered.
• Role division:
  • tier 1 – SOC provider,
  • tier 2 – hybrid: SOC provider (incident experts) and the organisation (system administrators),
  • tier 3 – SOC provider.

Model 3: MDR (Managed Detection and Response)

The organisation installs lightweight data collectors on its premises (e.g. log forwarders) and agents (EDR/XDR). The data is transmitted to the provider’s SIEM system. This system, usually operating in the cloud (SaaS), is maintained, updated and equipped with proprietary detection rules by the provider.

The provider supplies its own proven tools, because only then can it guarantee that it will detect and block an attack within a specified time (e.g. 15 minutes).

Example implementation:

• Log configuration on the organisation’s side – logs are sent to the appropriate collectors („gatherers”) and transmitted to the SIEM system provided and maintained by the provider.
• Alert handling – 24/7 by the provider’s SOC.
• Costs:
  • subscription fee – most often a fixed monthly cost “per device” or “per user”,
  • no maintenance costs – the organisation does not pay for SIEM servers, power, log storage or training of analysts,
  • predictability – the cost of the SIEM licence is included in the price of the SOC service.
• Role division
  • tier 1 – SOC provider,
  • tier 2 – hybrid: the SOC provider (incident experts perform technical analysis and may take specific actions, such as isolating a laptop via the EDR agent) and the organisation (system administrators can, for example, restore a server from backup),
  • tier 3 – breach expertise, digital forensics and support in reporting the incident to supervisory authorities (e.g. CSIRT).

Model 4: in-house SOC – full autonomy

The organisation has its own infrastructure (SIEM/XDR), its own procedures and, above all, its own team of experts working in shifts. This model is intended for entities with the highest risk profile: banks, critical infrastructure, and large key entities covered by KSC.

• Infrastructure – an enterprise-class SIEM (e.g. Microsoft Sentinel, Splunk, FortiSIEM) installed on-premises or in a private cloud, with full control over the architecture, logs and correlation rules.
• Operating mode – genuine 24/7/365 monitoring: the team responds immediately, without intermediaries and without delays resulting from communication between different organisations.
• Alert handling – all competency levels (tier 1, 2 and 3) are located within the organisation.
• Costs (high entry barrier):
  • salaries – maintaining a team of 6–10 cybersecurity specialists and continuously investing in the team’s certification and knowledge,
  • enterprise-class SIEM licences – high cost at a large log volume scale.
• Role divisions:
  • tier 1 (SOC analysts) – minimum 5–6 people working in shifts, responsible for continuous monitoring of the console and immediate response to every alert,
  • tier 2 (IR specialists) – experienced Incident Response experts handling in-depth analysis (e.g. malware analysis) and coordinating threat containment,
  • tier 3 (threat hunters/engineers) – experts responsible for proactively searching for vulnerabilities, writing their own detection rules, and advanced system architecture.

Comparison of monitoring models

The table below summarises the models described and facilitates selecting a solution appropriate to the organisation’s profile and scale.

What for whom

The choice of model depends on the risk analysis: what the consequences of an incident are, whom they affect and how quickly a response is required. Consider two extreme cases:

Waste management entity

• Risk profile – the main threat is logistical and operational paralysis: a cyberattack may disable route-planning systems or automation control in the sorting facility. The consequences (uncollected waste, risk of fire or contamination) become critical only after several hours or days. There is therefore a time window for response before the problem turns into an epidemiological threat.
• Recommended solution – model 1 (SIEM 8/5 + on-call): automated monitoring runs continuously, and if an anomaly is detected at night, the IT administrator is notified during the on-call shift. This makes it possible to take corrective action before the morning shift, without the need to maintain costly night staffing.

National Bank of Poland

• Risk profile – the highest possible: it concerns the security and financial stability of the state. Attacks may have different origins – political (APT) or terrorist. The consequences of a successful breach may be catastrophic for the entire economy, which is why response time must be measured in seconds. Due to state secrecy and the critical nature of operations, data should not be analysed by third parties in shared models.
• Recommended solution – model 4 (in-house SOC – full autonomy): an in-house team of analysts working in shifts on site. Enterprise-class systems enable immediate isolation of threats and full control over the flow of information, which is the only acceptable standard for strategic institutions.

Conclusions

A number of myths have grown up around the NIS2 Directive and the amendment to the national cybersecurity system act – including the most costly one: that compliance requires building your own Security Operations Center. The Act does not impose such a requirement. It does, however, impose an obligation to carry out continuous monitoring. Importantly, the manner in which this is implemented must be proportionate to the risk profile of the given entity – not to the service catalogue of an external provider.

The path to compliance with the national cybersecurity system does not begin with purchasing a SIEM system or signing a contract with an MDR provider. It begins with a reliable risk analysis that identifies the systems requiring monitoring and determines the level of protection needed. Only on that basis is it worth selecting tools and operational models.

Three questions worth asking at the outset:

• which systems are critical to the provided service and must be subject to continuous monitoring?
• what level of response – automated or involving human intervention – does our risk profile require?
• does the organisation have its own resources to analyse incidents, or should it use external support?

The answers to these questions – supported by documentation of the monitoring policy and risk assessment – are the proper starting point for any organisation covered by the national cybersecurity system. The regulations provide freedom in selecting tools, but they require that such a choice be informed and justified.

FAQ – frequently asked questions

Does the national cybersecurity system Act require the implementation of a SOC?

No. The national cybersecurity system Act does not contain an obligation to have a Security Operations Center. It does, however, require the implementation of continuous monitoring of information systems and security measures adequate to the level of risk.

How does continuous monitoring differ from a SOC?

Continuous monitoring is the regulatory outcome required by law, consisting in the ongoing detection and analysis of security events. A SOC is one way of achieving this objective, but not the only one.

Does a small or medium-sized company have to build its own SOC?

In most cases, no. For many organisations, implementing a SIEM system, appropriate procedures, and an on-call duty model or cooperation with an external security services provider will be sufficient.

What are the alternatives to an in-house SOC?

The most commonly used alternatives are:

• SIEM-based monitoring combined with administrator on-call duties,
• an in-house SIEM operated by an external SOC,
• an MDR (Managed Detection and Response) service,
• a hybrid model combining internal and external resources.

Does monitoring have to operate 24/7?

Yes. The KSC requires continuous monitoring. This means the ability to detect events around the clock, including at night, on weekends and on public holidays.

How should the monitoring model be selected to meet KSC requirements?

The starting point should be a risk analysis taking into account the criticality of the systems, the potential impact of an incident and the required response time. Only on this basis should the tools and organisational model be selected.

Does an entity covered by KSC have to use an external SOC service?

No. An organisation may carry out monitoring on its own, if it is able to ensure an appropriate level of incident detection and response and document compliance with the statutory requirements.

What will be checked during an inspection or audit?

The supervisory authority may verify, among other things, monitoring policies, incident response procedures, stored logs, information security management system documentation, and the actual functioning of the implemented processes.