SOC 24/7 in 2026 - how it works, what the law requires, and how to assess its effectiveness

A SOC observes the environment, triages alerts, conducts technical investigations, limits the impact of incidents, and escalates cases to system owners, management, or the appropriate response teams. It therefore combines technical analysis with decision-making. Knowing that an account performed an unusual action is only the beginning. An analyst should know whether the account is privileged, which asset was used, which business process depends on that asset, and what the consequences of blocking the account or isolating the device might be.

The terms used to describe security services are not interchangeable.

• SIEM, or Security Information and Event Management, is used to collect, search, normalize, and correlate event data. It is a tool that supports operations, not a response team.
• SOAR, or Security Orchestration, Automation and Response, integrates security tools and executes defined workflows. It can automate alert enrichment, case creation, collection of additional telemetry, device isolation, session revocation, or account blocking. Automation does not remove the risk of a bad decision. High-impact actions should have clearly defined conditions, privilege boundaries, an audit trail, and, where appropriate, human approval ^[17].
• SOC is the organizational capability to detect, analyze, and respond. It can be operated internally, provided as an external service, or run in a co-managed model.
• CSIRT is an incident response team with a defined remit and constituency. The name CERT is widely used in a similar context, but the team name alone does not define its responsibilities. Polish KSC legislation expressly defines, among others, CSIRT MON, CSIRT NASK, CSIRT GOV, and sectoral CSIRTs ^[8].
• MDR, or Managed Detection and Response, is a service model for delivering some or all detection and response capabilities. One MDR offering may cover endpoints only, while another may include identities, networks, email, cloud services, and applications. The service label does not tell you which data sources are monitored or what the provider is permitted to do after a threat is detected.

An internal SOC gives an organization the greatest direct control over staff, telemetry, and response, but it requires expertise, shift coverage, platform maintenance, and continuous detection engineering. An outsourced model gives access to a specialized team and the provider's infrastructure, but makes contracts, technical integration, oversight, and data jurisdiction more important. A co-managed model divides responsibilities. For example, the provider may perform monitoring and initial analysis while the client retains decisions affecting critical systems. A study by Kokulu and colleagues, based on 18 interviews with SOC analysts and managers, illustrates the importance of matching the way a SOC is organized to the realities of its work, including the relationship between personnel, management, and technology ^[3].

A 24/7 model makes sense when a critical service operates continuously, when the cost of delayed response rises quickly, or when procedures and law impose short escalation deadlines. It does not mean every specialist role must be staffed at a console around the clock. A model can combine a 24-hour first line with on-call specialists and decision-makers. What matters more than the label "24/7" is who will actually receive an alert at 03:00, what authority that person has, how quickly the case can be escalated, and whether someone on the client side is available to approve an action that could affect the service.

A SOAR platform may have access to logs, identity data, security configurations, API tokens, vulnerability information, and incident evidence. In practice, this makes it a highly trusted part of the infrastructure. In the model being developed by 4crypto, the SOAR system is designed so that core automation and event-handling processes can operate in a controlled environment without requiring client operational data to be sent to external automation or generative AI services outside the adopted architecture. This is a design objective, not independent proof of security.

Locating a server in Poland or the EEA is not enough to establish service sovereignty. The organization should examine infrastructure ownership, the jurisdiction of entities involved in providing the service, subprocessors, remote administrative access, product telemetry, backups, key management, the update process, and outbound connections. If logs contain personal data, a transfer to a third country is subject to Chapter V of the GDPR ^[14]. For entities covered by KSC, supply-chain security is one element of cybersecurity risk management ^[8]. A provider's claim of local processing should therefore be tested against architecture, contracts, the list of processors, and observation of actual network traffic.

SOC operations form a cycle in which the quality of each stage constrains the next. Automation cannot repair missing telemetry, and a sophisticated SIEM cannot compensate for not knowing which assets are critical.

Scope and priorities. First identify the services, systems, identities, and data flows whose loss of confidentiality, integrity, or availability would have a material impact. From this follow the threat scenarios, required data sources, and response priorities. An inventory of devices alone does not show business dependencies.

Telemetry health. A SOC should know not only which logs it collects, but whether the sources are functioning correctly. Completeness, delay, time synchronization, field quality, integrity, retention, and secure export should be monitored. Missing events from a critical domain controller or VPN gateway should appear as a sensor problem, not be interpreted as a quiet night.

Context. An event becomes useful when it is linked to the asset owner, asset criticality, user role, known vulnerabilities, administrative changes, and previous activity. IP geolocation or a reputation indicator is evidence to consider, not standalone proof of compromise.

Detection. A rule should answer a specific hypothesis: what behavior are we trying to detect, what telemetry is required, and which legitimate activities can look similar? MITRE ATT&CK helps structure knowledge about adversary tactics and techniques and link that knowledge to detection. As of 29 August 2026, ATT&CK v19.2 data is available, including separate Detection Strategies and Analytics datasets ^[19]. An ATT&CK mapping is not a test result. Marking a technique as "covered" does not prove that a particular rule will work on the telemetry actually available.

Triage and investigation. The analyst should determine whether an alert describes real activity, its scope and impact, and what remains unknown. A good investigation is reproducible: it records the timeline, data sources, evidence, hypotheses, and level of confidence. Facts should also be clearly separated from the analyst's conclusions.

Response. Isolating a device, revoking a session, or blocking an account or address can reduce damage, but it can also interrupt legitimate activity. Automated response should follow a pre-approved scenario and be limited to cases in which the cost of a false response is acceptable. NIST SP 800-61 Rev. 3 treats incident response as part of broader cybersecurity risk management and connects preparation, detection, response, and recovery with the functions of NIST CSF 2.0 ^[17][20].

Learning. After an incident, rules, data sources, configuration, architecture, procedures, and training should be improved. If successful phishing was enabled by weak mail configuration, simply closing the incident does not solve the underlying problem. A review of SPF, DKIM, and DMARC, the authentication process, and security awareness may then be relevant. If entry occurred through a vulnerable edge service, vulnerability scanning, hardening, or penetration testing may be needed. These activities complement a SOC; they do not replace it.

A SOC cannot see everything. Encryption limits content inspection. Some SaaS services provide limited telemetry or require a higher subscription tier for administrative event logs. An edge device may be compromised before it sends an alert, an EDR agent may be disabled, and a local log may be deleted. Detection architecture should therefore include monitoring of data-source health, distribution of evidence, and, for the most important events, the ability to corroborate activity from more than one source.

The absence of an alert is not evidence that no attack occurred. It means only that, given the available data and detection logic, nothing generated an alert.

Mandiant, Verizon, ENISA, and CERT Polska reports describe different populations, use different definitions, and are built from different data sources. Their percentages should not be compared as though they measured the same market. They are useful for observing the types of problems visible in specific datasets, but they cannot establish the expected effectiveness of a particular SOC.

Mandiant M-Trends 2026 is based on more than 500,000 hours of Mandiant investigations conducted in 2025. Global median dwell time, meaning the period from compromise to detection, was 14 days, compared with 11 days the year before. In the cyberespionage cases and North Korean IT worker incidents examined, median dwell time was 122 days. Exploits accounted for 32% of the initial infection vectors observed by Mandiant ^[4]. These are Mandiant investigation data, not a universal statistic for all organizations.

The Verizon DBIR 2026 analyzes more than 31,000 incidents, including more than 22,000 confirmed data breaches involving organizations in 145 countries ^[5]. Verizon's public summary states that 31% of breaches began with exploitation of software vulnerabilities and that ransomware was involved in 48% of breaches ^[5]. The DBIR itself cautions that it describes events that entered its dataset and met the report's inclusion criteria. These percentages are therefore not the probability that any arbitrary organization will suffer a particular type of breach.

ENISA Threat Landscape 2025 covers 4,875 incidents from 1 July 2024 to 30 June 2025. DDoS accounted for 77% of reported incidents and was largely associated with hacktivism, while ENISA assessed ransomware as the threat with the greatest impact in the EU ^[6]. This demonstrates an important distinction: event frequency and severity are different measurements.

CERT Polska reports 658,320 submissions in 2025 and 260,783 unique registered incidents. Computer fraud accounted for 253,238 incidents, or 97.1% of all incidents registered ^[7]. The report also states that growth in submissions and registered incidents is associated, among other factors, with increasing awareness and the team's role in monitoring and analysis. The data therefore does not support a simple conclusion that the number of successful cyberattacks increased at the same rate.

The shared operational lesson from these sources is broader than simply deploying EDR. A detection program should account for endpoints, identities, internet-facing services, edge infrastructure, cloud services, email, and third-party dependencies because important attack paths do not stop at a workstation.

The study by Alahmadi, Axon, and Martinovic included an online survey of 20 practitioners working in SOCs followed by a qualitative investigation involving 21 practitioners ^[2]. The authors observed that some alerts practitioners described as false positives were in fact correct detections of legitimate activity. The distinction matters: a tool can correctly identify behavior matching a rule while the resulting alert still does not require incident response.

The title "99% False Positives" does not establish that 99% of alerts in a typical SOC are wrong. The study does not provide such a universal rate. It instead examines alert quality and interpretability and the need for contextual information that enables rapid validation ^[2].

Good detection tuning is therefore not merely a matter of reducing alert volume. Aggressive filtering may reduce false alarms while increasing missed events. Alert quality, scenario coverage, test results, and events discovered through other channels should be considered together.

An organization can process millions of events a day while failing to record cloud configuration changes, administrator activity, VPN appliance events, application-token use, or changes to access policies. Large data volume does not imply broad visibility.

Coverage is better described as a pair: threat scenario - required telemetry. The next questions are whether the data actually arrives, whether detection logic can identify the behavior, and whether response works. NIST CSF 2.0 can help structure desired cybersecurity outcomes ^[20], while ATT&CK can provide a model of adversary behavior ^[19]. Neither replaces a controlled test in the environment concerned.

Testing can range from replaying a single administrative event, through purple-team exercises, to a full penetration test with an agreed objective. The important result is whether the organization can observe and correctly handle a specific scenario.

SOAR reduces the time required for repetitive tasks and helps make response workflows consistent. The same mechanism can also amplify the consequences of an error. Automatically isolating an ordinary workstation and automatically cutting off a domain controller, a cluster node, or an OT component carry very different operational risks.

Actions should therefore be classified by impact. Some can run automatically, such as alert enrichment or additional data collection. Others may require a high confidence threshold and analyst approval. Actions capable of interrupting a service should have an agreed authorization path, a rollback mechanism where technically possible, and a complete execution record ^[17].

There is no single metric that adequately describes a SOC. Time metrics are especially easy to misuse.

MTTD may mean time from the beginning of an incident to detection, but another report may calculate it from alert creation to analyst confirmation. MTTR may mean time to respond, time to repair, or time to fully restore a service. Without an explicit start and end point, the number cannot be compared reliably.

Dwell time in the Mandiant report is also not the same as internal alert-handling time. It includes the period during which an attacker was present before detection ^[4].

A better set of metrics combines several perspectives:

• coverage of critical services, assets, and threat scenarios with verified telemetry and tested detections;
• data-source health, including completeness, latency, parser errors, and interruptions in telemetry delivery;
• alert quality, including confirmed alerts, benign true positives, and the causes of false and missed detections;
• timings with clearly defined measurement points: alert intake, confirmation, escalation, containment, and recovery;
• events discovered through another channel that the SOC should have detected;
• time required to close gaps in telemetry and detection, and completion of post-incident actions;
• case backlog, on-call workload, and the quality of handovers between shifts.

The goal is not to maximize the number of metrics. A metric is useful when it drives a decision: changing a rule, improving visibility, revising a procedure, providing additional training, or investing in a specific capability.

As of 29 August 2026, KSC applies in the form resulting from the amendment that entered into force on 3 April 2026. The current consolidated text prepared by the Chancellery of the Sejm as of 18 August 2026 incorporates Journal of Laws 2026 items 20, 252, 815, and 1003 ^[8][9]. NIS2 remains an EU directive; for Polish entities, the concrete national obligations arise primarily from KSC implementing that directive ^[10].

Article 8 requires an essential or important entity to implement an information security management system in the information system used in processes affecting delivery of its service. The requirements include continuous monitoring of such a system as well as incident, vulnerability, access, asset, business-continuity, and supply-chain risk management ^[8]. The Act therefore requires capabilities. It does not say those capabilities must be purchased as a product called a SOC.

Article 11 provides several stages for a major incident. The entity submits an early warning without undue delay and no later than 24 hours after detection, followed by a major-incident notification without undue delay and no later than 72 hours after detection. A final report is submitted no later than one month after the 72-hour notification ^[8]. The Act provides a separate 24-hour major-incident notification rule for trust service providers ^[8].

Transitional deadlines also require care. Entities that met the criteria for an essential or important entity on 3 April 2026 generally have 12 months to fulfill Chapter 3 obligations, resulting in a deadline of 3 April 2027 ^[9]. This is not a universal deadline for every entity that may fall within KSC in the future. When the criteria are met later, the mechanism in KSC applies from the date on which the entity meets them ^[8].

The reporting clocks in KSC and DORA should not automatically be stacked for the same event. Article 8i KSC establishes a specific relationship for essential or important entities in the banking and financial market infrastructure sectors. As a general rule, KSC provisions concerning the information security management system or reporting major incidents do not apply to them, subject to the exceptions expressly listed in the Act ^[8]. Within the scope of that exclusion, DORA has primary importance.

This distinction has a practical consequence for SOC operations. A reporting runbook should not contain one universal "NIS2/KSC/DORA/GDPR" path. The entity's status, the type of incident, and the applicable legal regime must be determined first.

DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 to the financial entities identified in the Regulation ^[11]. Among other things, it requires mechanisms for detecting anomalous activities and a process for managing ICT-related incidents.

Commission Delegated Regulation (EU) 2024/1774 adds technical detail. Article 23 requires, among other things, collection, monitoring, and analysis of specified information sources, identification of anomalous activities, and tools generating alerts at least for ICT and information assets supporting critical or important functions. Alerts must be prioritized so that detected ICT-related incidents can be managed within the expected resolution time both during and outside working hours ^[12].

For a major ICT-related incident, Commission Delegated Regulation (EU) 2025/301 requires the initial notification as early as possible and, in any case, within four hours after classification as major and no later than 24 hours after the financial entity became aware of the incident. The intermediate report is due no later than 72 hours after the initial notification, and the final report is generally due within one month after the intermediate report or its latest update ^[13].

DORA does not say that an institution must buy a particular SOC. In practice, however, it creates requirements that for many organizations imply a need for detection and escalation capability outside ordinary working hours.

The GDPR does not create a general duty to operate a SOC. Article 32 requires security measures appropriate to risk ^[14]. Article 33 concerns a personal data breach, not every cybersecurity incident.

Where a personal data breach occurs, the controller notifies the competent supervisory authority without undue delay and, where feasible, no later than 72 hours after becoming aware of the breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. A processor notifies the controller without undue delay after becoming aware of a personal data breach ^[14].

A SOC should therefore be capable of quickly providing the information needed to assess an incident, but legal qualification of a personal data breach is a separate process. The GDPR clock does not automatically start when an arbitrary SIEM alert is created. The controller's duties are discussed further in the material on the GDPR compliance audit.

As of 29 August 2026, the Regulation of the Council of Ministers of 21 May 2024 on the National Interoperability Framework, KRI, remains in force ^[15]. Section 19 imposes information security management system requirements on entities performing public tasks and requires a periodic internal information-security audit at least once a year. Section 19(3) provides a mechanism for deeming the requirements of paragraphs 1 and 2 satisfied where the ISMS has been developed on the basis of PN-ISO/IEC 27001 and the establishment of controls, risk management, and auditing are based on the relevant Polish Standards associated with PN-ISO/IEC 27001, including PN-ISO/IEC 27002 and PN-ISO/IEC 27005 ^[15].

Section 20 is particularly relevant to a SOC. It requires accountability for activity in information systems and, within its scope, logging of matters such as administrative access and changes to security configuration. Unless separate law sets another retention period, the log information is retained for two years ^[15]. KRI does not, however, require an organization to buy a SOC or obtain ISO/IEC 27001 certification.

The 2027 horizon must also be considered. ELI identifies 23 February 2027 as the date on which the current KRI Regulation is to cease to have effect ^[15]. A draft replacement regulation, RD313, was published in 2026 and, as of 29 August 2026, remains a draft rather than binding law ^[16]. Its justification assumes, among other changes, a relocation of some security regulation in light of the new KSC framework. The present wording of Sections 19 and 20 should therefore not be projected onto the legal position after 23 February 2027 without checking the law again.

ISO/IEC 27001:2022 with Amendment 1:2024 specifies requirements for an information security management system ^[21]. ISO/IEC 27035-1:2023 describes principles and the process of information security incident management ^[18]. NIST CSF 2.0 is a voluntary cybersecurity risk-management framework, while NIST SP 800-61 Rev. 3 provides incident-response recommendations aligned with CSF 2.0 ^[17][20].

These documents can be useful reference points and may become contractual requirements. They are not equivalent to a Polish statute or a directly applicable EU regulation. A KSC and NIS2 audit, KRI audit, or IT security audit should identify the assessment criteria explicitly. Conformity with one document should not be presented as automatic compliance with all the others.

Language models can help summarize cases, build timelines, suggest SIEM queries, organize data, and draft detection logic. Their output is not independent evidence. A model-generated claim should be confirmed against raw telemetry or another reliable source.

The risks are concrete. Client logs, personal data, technical secrets, or architectural information may be sent to an external model. A model may express an incorrect conclusion with confidence. The content of a ticket, message, website, or file being analyzed may contain instructions that alter the behavior of a system using an LLM. OWASP describes this as prompt injection, including indirect prompt injection when the instructions originate in external pages or files being processed ^[22]. The greatest risk arises when unverified model output is connected directly to authority to act on infrastructure.

A reasonable architecture limits data and privileges, isolates clients, records model calls, tests generated queries and scripts before production use, and requires approval for high-impact actions. A high degree of automation is valuable where the consequences of a wrong decision are well understood and controlled.

MITRE published the v19.2 update in August 2026, and its official datasets include techniques, Detection Strategies, and Analytics for the relevant ATT&CK domains ^[19]. This makes it easier to connect adversary behavior with required telemetry and detection logic.

A SOC should not, however, be judged solely by the percentage of ATT&CK techniques a product claims to "cover". A technique may have many variants. A rule may depend on a data source the organization does not collect. A detection may work for Windows but not for Linux or cloud workloads. Coverage becomes meaningful only after the scenario has been tested in the environment concerned.

A mature SOC is not defined by the number of screens, the number of detection rules, or the name of the service purchased. Its value can be demonstrated only when the organization knows what it needs to protect, has reliable telemetry, can detect a material threat scenario, can reproduce the reasoning behind an investigation, can take a proportionate response, and improves controls after an event.

A 24/7 model is justified where threats and consequences do not fit into office hours. Law may additionally require continuous monitoring or impose very short reporting deadlines. The underlying principle does not change: a tool, an on-call rotation, and formal compliance are only parts of an operational capability. Effectiveness depends on whether the whole process works when it is actually needed.