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

A SOC continuously observes the environment, qualifies alerts, investigates and contains incidents, and escalates cases to system owners, management and the relevant response teams. In practice, it combines technical work with decision-making. An analyst needs to know not only that an account performed an unusual operation, but also whether it is privileged, which business process it supports and what blocking it would disrupt.

The terms used to describe these services are not interchangeable:

• SIEM collects and correlates data; it is a tool, not a response team.
• SOAR (Security Orchestration, Automation and Response) connects security tools, runs approved playbooks and records their execution. It can automate alert enrichment, case creation, device isolation or account blocking, but it does not replace the SOC or human accountability for high-impact decisions.
• SOC is an organisational capability for detection, analysis and response.
• CSIRT/CERT is a response team with a defined remit. It may operate in the same organisation as the SOC, but usually has a broader coordination and communication role.
• MDR is a managed detection and response service. It may cover endpoints only or a much wider set of telemetry; the service name does not determine its coverage.

An in-house SOAR is particularly important for data sovereignty and confidentiality. The platform may have access not only to alerts, but also to logs, identity data, security configurations, API tokens and incident evidence. 4crypto.eu is developing its own SOAR, designed to operate without communicating with external automation or AI providers in the United States or Asia. This enables data and playbook execution to remain in a controlled environment in Poland or the EEA, limits unnecessary transfers outside the EEA and reduces dependence on additional subcontractors.

A European server address alone does not establish sovereignty. Buyers should examine infrastructure ownership, provider jurisdiction, the processor list, remote administrative access, product telemetry, backups, key management and every outbound connection. Transfers of personal data outside the EEA are governed by Chapter V of the GDPR ^[12], while the KSC Act requires supply-chain security and continuity to be considered in risk management ^[7]. A claim that the platform has no external-service connections should be confirmed in the architecture, contract, subcontractor register and network-traffic tests.

The operating model may be in-house, outsourced or co-managed. The choice should follow risk, available expertise, required response time, data jurisdiction and the ability to delegate authority securely. SOC research shows that alignment between organisation, processes and tools matters more than the model label itself ^[19].

A 24/7 mode is justified when a critical service runs continuously, the cost of delay rises quickly or short escalation deadlines apply. It need not mean that every role is fully staffed at all times. Automated monitoring with a round-the-clock first-line analyst and on-call specialists may be appropriate, provided that a decision-maker on the organisation's side can actually be reached and the permitted actions have been agreed in advance.

SOC work forms a closed loop. Every stage depends on the quality of the previous one, so automation alone cannot repair poor visibility.

1. Scope and priorities. First identify the critical services, assets, identities and data flows. Abuse cases and telemetry sources follow from this. An inventory of devices without links to business services is not enough.
2. Reliable data collection. Useful sources include identity and authentication logs, EDR, network systems, email, cloud services, applications, edge devices, hypervisors and administration tools. The SOC should control data completeness, delay, time synchronisation, integrity and retention. A missing log should be detected like a failed sensor.
3. Normalisation and context. An event becomes useful only after it is linked to the asset owner, criticality, vulnerabilities, user role and prior activity. IP geolocation or a single reputation indicator is only a clue, not proof of an attack.
4. Detection. Rules, behavioural analytics and threat intelligence should answer specific hypotheses. MITRE ATT&CK organises knowledge about adversary behaviour and helps describe coverage, but it is not a certificate of effectiveness. Version 19.2 is an evolving catalogue of tactics, techniques, detection strategies and analytics ^[16].
5. Triage and investigation. The analyst determines whether the alert describes real activity, its scope and impact, and what remains unknown. The conclusion should be reproducible, with a timeline, evidence, data sources and confidence level.
6. Response. Isolating a device, revoking a session or blocking an account or address may limit harm, but may also interrupt a service. Automated actions should be pre-authorised, limited to well-understood cases, logged and reversible. NIST SP 800-61 Rev. 3 treats incident response as part of risk management, not as a separate stage triggered only after an alert ^[14].
7. Feedback. After an incident, rules, configuration, architecture, instructions and training need to be improved. Otherwise, the SOC repeatedly handles the same problem instead of reducing risk.

A SOC cannot see everything. Encryption restricts content inspection, edge devices and SaaS systems may provide insufficient telemetry, and an attacker may disable a sensor or erase logs. The health of data sources, copies of evidence and independent control mechanisms are therefore part of the detection architecture, not optional extras.

Annual reports describe different datasets. Their figures cannot be compared as though they measured the same population, nor can they support a promise about the effectiveness of a particular SOC.

• Mandiant M-Trends 2026. The report is based on more than 500,000 hours of investigations conducted in 2025. Global median attacker dwell time was 14 days, up from 11 days a year earlier; for cyber-espionage and North Korean IT worker cases it was 122 days. Exploitation of vulnerabilities accounted for 32% of observed initial access vectors ^[3]. Dwell time is not the same as an internal MTTD measured from alert arrival.
• Verizon DBIR 2026. The dataset includes more than 31,000 incidents and over 22,000 confirmed data breaches in 145 countries, recorded from November 2024 through October 2025. Vulnerability exploitation was the initial vector in 31% of breaches, while ransomware was present in 48% ^[4]. The operational conclusion goes beyond buying EDR: the SOC needs visibility into edge devices, a vulnerability-management process and data on third-party dependencies.
• ENISA Threat Landscape 2025. The analysis covers 4,875 incidents from 1 July 2024 to 30 June 2025. DDoS accounted for 77% of recorded events, many linked to hacktivism, while ransomware was rated the threat with the greatest impact ^[5]. Event volume is therefore not a measure of severity.
• CERT Polska for 2025. The team received 658,320 reports and registered 260,783 unique incidents from them. Computer fraud accounted for 97% of handled incidents ^[6]. Growth in registrations may reflect attacker activity as well as better detection, greater awareness and new reporting channels.

These sources point to a common conclusion: endpoint monitoring remains necessary but is not sufficient. A detection programme should include identities, web applications, edge infrastructure, cloud services, backups and third-party dependencies.

Alert overload is not merely a volume problem. Alahmadi, Axon and Martinovic surveyed 20 practitioners and interviewed 21 people from seven SOCs. They found that "false positive" may refer both to an erroneous alert and to the correct detection of legitimate activity. Alerts need context, explainability and reproducible reasoning ^[2]. The title "99% False Positives" does not demonstrate that 99% of alerts in a typical SOC are wrong.

Coverage gaps are more dangerous than the absence of another tool. An organisation may collect a huge volume of events while failing to record cloud configuration changes, administrator activity, VPN appliance activity or application-token use. Coverage should be measured against threat scenarios and critical assets, then tested through controlled simulations ^[17][3].

Automation can accelerate both good and bad decisions. A rule that isolates a device is valuable when the signal is reliable and its impact is understood. The same mechanism applied to a domain controller or an OT component can cause a serious outage. Authority levels, a list of pre-approved actions, manual-confirmation modes and an audit trail are needed ^[14].

Metrics should describe capability and outcome, not activity for its own sake:

• the proportion of critical assets and scenarios covered by verified telemetry and working detections;
• time to acknowledge, detect, contain and recover, each with an unambiguous start and end;
• alert precision, missed events discovered by other means and the causes of errors;
• time to close telemetry and detection gaps, and the proportion of post-incident actions completed on time;
• case backlog, on-call workload and the quality of handovers between shifts.

MTTD alone can be misleading. A result measured from alert creation excludes the period between compromise and the appearance of a signal. It cannot be compared directly with dwell time from Mandiant investigations or with a response time defined differently by another provider.

The Polish KSC Act, as amended on 23 January 2026, entered into force on 3 April 2026. Entities that met the criteria for an essential or important entity on that date generally have 12 months to implement the obligations in Chapter 3, until 3 April 2027. Among other things, Article 8 requires systematic risk management, continuous monitoring of systems used to provide the service, and incident management. For a major incident, Article 11 provides for an early warning without undue delay and no later than 24 hours after detection, notification within 72 hours, and a final report within one month of notification ^[7]. The duties apply to entities that meet the statutory criteria and conduct activities listed in the annexes; they do not automatically cover every company.

NIS2 is a directive implemented in Poland through the KSC amendment. Articles 21 and 23 are important when interpreting the common EU model, but a Polish entity should determine its specific duties primarily under the national law in force ^[8].

DORA has applied since 17 January 2025 to the financial entities listed in the regulation. It requires anomaly-detection mechanisms and an ICT incident-management process ^[9]. Delegated Regulation 2024/1774 further specifies log collection, monitoring and analysis, alert prioritisation and handling outside working hours ^[10]. For a major ICT-related incident, the initial notification must be made as early as possible, no later than four hours after classification as major and generally no later than 24 hours after awareness of the incident; further deadlines are set by Article 5 of Delegated Regulation 2025/301 ^[11].

The GDPR does not impose a general obligation to operate a SOC. Article 32 requires security measures appropriate to the risk. Article 33 concerns a personal data breach, not every cybersecurity incident; the controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach, unless it is unlikely to result in a risk to people's rights and freedoms. A processor must notify the controller without undue delay ^[12].

Poland's National Interoperability Framework (KRI) requires public-task entities to maintain an information security management system and conduct an internal audit at least annually. Section 19(3) expressly refers to PN-ISO/IEC 27001, PN-ISO/IEC 27002 and PN-ISO/IEC 27005. These are Polish Standards in the formal sense-national adoptions of international ISO/IEC standards, not standards developed exclusively in Poland. The provision describes a route for deeming the requirements of Section 19(1) and (2) satisfied, but does not mandate certification or the purchase of a SOC. The separate Section 20 concerns mandatory logging of selected activities and log-retention periods ^[13].

Standards and frameworks play a different role from legislation. ISO/IEC 27001:2022 with Amendment 1:2024 specifies information-security management-system requirements ^[18]; ISO/IEC 27035-1:2023 gives principles and a process for incident management ^[15]; NIST CSF 2.0 and SP 800-61 Rev. 3 provide voluntary risk-management and response frameworks ^[17][14]. They may become contractual requirements or part of a chosen compliance method, but they are not themselves Polish law.

LLM/AI (language models) can summarise cases, suggest queries, organise timelines and help create rules. They are not an independent source of evidence. Results must be checked against raw telemetry, and generated queries or scripts tested before production use.

The main risks are disclosure of logs and customer data to the model provider, incorrect conclusions expressed with confidence, malicious instructions hidden in analysed content and automated execution of an action with excessive impact. Safe deployment requires data minimisation, tenant separation, access control, logging prompts and outputs, resilience testing and human approval for high-impact actions.

Updates to ATT&CK also influence how detections are designed. In release v19.2, MITRE expands detection strategies and analytics, helping teams link adversary behaviour to required telemetry ^[16]. A product's percentage of "covered" techniques remains a weak measure: one technique may have many variants, and a rule without the right data and testing does not provide real detection capability.

A mature SOC will therefore be judged less by the number of screens and alerts, and more by evidence that it can detect a material scenario, take a proportionate response and improve defences after the event.