SOC, SIEM, SOAR — implementation and Managed SOC compliant with NIS2 and DORA | Virtline

SOC, SIEM and SOAR — from raw logs to automated incident response

SIEM, SOAR and UBA were sold for years as separate tools. In practice, every modern SOC (Security Operations Center) combines these three layers in one platform: SIEM collects and correlates logs, UBA detects behavioural anomalies, and SOAR triggers an automated response — from isolating an endpoint to notifying the team and opening a ticket. A client who buys “just SIEM” ends up with raw alerts that nobody analyses. A client who buys “just SOAR” automates nothing, because there is no input data.

Virtline deploys integrated SOC environments for organisations subject to NIS2 (art. 21(2) — monitoring, detection, response), DORA (art. 10 — detection of anomalies in ICT operations) and ISO/IEC 27001:2023 (Annex A.5.24, A.5.25, A.8.16 — logging and monitoring). We work with enterprise-class platforms (Microsoft Sentinel, Wazuh, OpenSearch, Splunk) and MSP-class solutions for smaller clients (RocketCyber, ConnectWise SIEM). We deliver SOC as a managed service or as an on-premises deployment with competency transfer to the client’s team.

Three SOC deployment models with Virtline

1. SOC as a Service (Managed SOC) — Virtline provides 24/7 monitoring with its own analyst team. The client does not buy a SIEM licence or hire engineers — they receive a ready service with a response-time SLA. Ideal for organisations of 50–500 seats without an in-house cyber team.

2. On-premises SOC with competency transfer — we deploy the platform (Microsoft Sentinel, Wazuh, Splunk) in the client’s infrastructure and train the IT team. After 3–6 months the client maintains the environment independently; we act as 3rd-line support. For mid-market companies that want data kept in-house.

3. Hybrid SOC — the client maintains the platform; we deliver SOC-as-a-Service at the analysis and response layer. Cost-optimal for organisations that already have corporate licences (e.g. E5) and want to leverage tools they have already paid for.

SIEM and SOAR platform integrations

We work with enterprise-class platforms and open-source solutions. Tool selection depends on scale, the client’s licensing model and regulatory requirements. We most often deploy:

• Enterprise SIEM — Microsoft Sentinel (cloud-native, M365/Azure integration), Splunk Enterprise Security, IBM QRadar (banking and insurance), Elastic Security (Elastic Stack), LogRhythm (organisations with high compliance requirements).
• Open-source / MSP SIEM — Wazuh (open source, low TCO for 50–500 endpoints), OpenSearch Security, RocketCyber and ConnectWise SIEM (MSP models for the SMB market).
• SOAR — Palo Alto Cortex XSOAR (broadest playbook and integration library), Splunk SOAR (formerly Phantom, natural complement to Splunk ES), IBM Security QRadar SOAR (formerly Resilient, for QRadar environments).
• UBA / UEBA — Microsoft Defender for Identity, Exabeam, Securonix (detection of privileged account abuse and lateral movement).
• Threat Intelligence — MISP (open source), AlienVault OTX, Recorded Future, Mandiant (commercial feeds with APT group attribution).

Regardless of the chosen platform, we follow the same deployment model: scoping → source onboarding → correlation rules → SOAR playbooks → compliance reporting.

SOC mapping to NIS2, DORA and ISO 27001 requirements

The SOC is the central evidence mechanism in an audit — it demonstrates that the organisation actively monitors, detects and responds to incidents. In a typical audit we highlight the following mappings:

• NIS2 art. 21(2)(b) and (e) — monitoring, detection and incident response. SOC as the organisational and technical implementation of the obligation.
• NIS2 art. 23 — incident reporting to the national CSIRT within 24 hours (early warning) and 72 hours (incident notification). SOAR automates report preparation.
• DORA art. 10 — detection of anomalies in ICT operations. UBA and SIEM correlation rules as evidence of compliance.
• DORA art. 17 — ICT incident management process (classification, escalation, post-incident review). SOAR playbooks and SOC runbooks cover the required lifecycle.
• DORA art. 18 — incident classification by impact and reporting to the competent supervisory authority (EBA, ESMA, EIOPA). SOC provides classification data.
• ISO/IEC 27001:2023 Annex A.5.24 — planning and preparation of information security incident management.
• ISO/IEC 27001:2023 Annex A.5.25 — assessment of and decisions on information security events.
• ISO/IEC 27001:2023 Annex A.5.26 — response to information security incidents (SOAR playbooks).
• ISO/IEC 27001:2023 Annex A.5.27 — learning from information security incidents (lessons learned, post-incident review).
• ISO/IEC 27001:2023 Annex A.5.28 — collection of evidence (forensic-grade logs from SIEM).
• ISO/IEC 27001:2023 Annex A.5.29 — information security during disruption (SOC continuity even in DR mode).
• ISO/IEC 27001:2023 Annex A.5.30 — ICT readiness for business continuity.
• ISO/IEC 27001:2023 Annex A.8.16 — monitoring. SOC as the operational implementation of the control.

For whom we implement SOC

• Banks, financial institutions, investment firms, insurers (DORA art. 10)
• Critical infrastructure operators (NIS2 essential entities)
• ICT service providers serving regulated clients (NIS2 important entities)
• Manufacturing companies with OT/IT integration requiring monitoring
• Organisations pursuing ISO 27001:2023 certification that must implement Annex A.5.24–A.5.25
• SMBs that want a subscription-based SOC service rather than building their own team