Category: Uncategorized

Choosing an AI SOC provider in Europe is, at heart, a procurement and risk decision: you are deciding who detects, investigates and contains threats across your estate, where the underlying AI runs, and how much autonomy it holds. The right provider combines genuine European data sovereignty, transparent and reversible automation, and human accountability that maps cleanly onto DORA, NIS2 and the EU AI Act. The wrong one introduces opacity, lock-in and regulatory exposure. This guide sets out ten questions to ask any AI SOC vendor, why each matters, and what a strong answer looks like.

Use it as an evaluation framework whether you are replacing a traditional managed service, augmenting an in-house team, or selecting a first SOC. Each question is designed to separate marketing claims from operational reality.

1. Where does your data and your AI actually run?

Why it matters: Data residency is only half the question. Many providers store logs in an EU region but route AI inference, model training or support operations outside it. For regulated Nordic and DACH organisations, the location of processing including AI processing determines sovereignty and legal exposure.

What a good answer looks like: A credible European SOC provider keeps both telemetry and AI inference inside your chosen EU cloud regions, with no model training on your data outside that boundary and no offshore administrative access. Sovereignty should be the default architecture, not a premium add-on. Nordic SOC is EU-sovereign by design: data and AI stay in the chosen EU region. For the full picture, see EU data sovereignty in the SOC.

2. How much can the AI act on its own and what are the guardrails?

Why it matters: Autonomy without controls is a liability. An AI that can isolate hosts, disable accounts or block traffic can also cause outages if it acts on a false positive. The question is not whether the AI acts, but how its actions are bounded.

What a good answer looks like: Containment actions should be pre-approved against defined playbooks, reversible, and verified before and after execution, with human sign-off required on major incidents. Ask the AI SOC vendor to demonstrate the guardrail model, not just describe it. Vokter operates this way across its modes see how autonomous containment stays safe.

3. Can the provider explain every decision the AI makes?

Why it matters: EU AI Act transparency obligations apply from August 2026, and DORA and NIS2 already require demonstrable, auditable security operations. A black-box model that cannot justify a triage decision or a containment action is a regulatory and operational risk.

What a good answer looks like: Every detection, triage decision and action should carry a clear, human-readable rationale and a full audit trail, mapped to recognised frameworks such as MITRE ATT&CK. Explainability should be built into the workflow, not reconstructed after the fact.

4. How does the AI SOC integrate with your existing stack?

Why it matters: Few organisations want to rip out their SIEM, SOAR, EDR or identity tooling. A provider that demands wholesale replacement increases cost, risk and time-to-value.

What a good answer looks like: A strong AI SOC vendor offers flexibility: operating SIEM-less where appropriate, or layering AI-driven L1 triage over your existing SIEM and SOAR where you have already invested. Vokter’s Hybrid mode runs over your current stack, while Autonomous mode removes the SIEM dependency entirely.

5. When does a human get involved, and what is the SLA?

Why it matters: AI handles the volume, but serious incidents demand human judgement, threat hunting and forensics. A provider that cannot tell you precisely when a person engages and how fast is selling automation, not security operations.

What a good answer looks like: Named analysts, defined escalation thresholds and a contractual SLA. Look for a model where AI resolves the routine majority and skilled humans own the consequential minority. Nordic SOC’s Guardian mode pairs AI handling roughly 85-90% of activity with named Nordic analysts, threat hunting, forensics and a contractual SLA.

6. What compliance evidence does the AI SOC provider produce for DORA and NIS2?

Why it matters: DORA has applied since 17 January 2025 and NIS2 was adopted in 2022; both place direct accountability on the regulated entity. Your SOC must generate the evidence auditors and regulators expect, not leave you to assemble it.

What a good answer looks like: Ready reporting that maps to regulatory expectations incident timelines, detection and response metrics, action logs and retention aligned to your obligations. The provider should treat compliance evidence as a standing output of the service.

7. Are the AI’s actions reversible?

Why it matters: Reversibility is the safety net that makes autonomy acceptable. If a containment action proves wrong, you need to undo it quickly and cleanly, with a record of what changed.

What a good answer looks like: Every automated action should be designed to be reversed, with clear rollback procedures and verification that the environment returned to its prior state. Reversibility plus verification is what separates responsible automation from reckless automation.

8. What coverage hours do you genuinely provide?

Why it matters: Attackers do not keep office hours. Some providers advertise 24/7 coverage that, on inspection, means after-hours alerting rather than active response. The distinction is critical at 3am.

What a good answer looks like: Continuous detection and response, with AI providing always-on coverage and humans available around the clock for escalations without depending on exhausting night-shift rotations to function. See SOC-as-a-service for the Nordics for how this model works in practice.

9. What does reporting look like for the board and for the SOC team?

Why it matters: A SOC that cannot communicate clearly to both technical and executive audiences erodes trust and slows decision-making. Reporting is where the value of the service becomes visible.

What a good answer looks like: Layered reporting concise, risk-framed summaries for leadership and detailed, evidence-rich output for analysts delivered on a predictable cadence and on demand. Metrics should reflect outcomes, not just alert counts.

10. How do you handle exit and lock-in?

Why it matters: The hardest provider to evaluate is the one you cannot leave. Proprietary data formats, opaque tooling and unclear offboarding terms turn a security decision into a long-term dependency.

What a good answer looks like: Clear exit terms, portable data in standard formats, and an offboarding process defined in the contract. An independent European MDR provider should be confident enough in its service to make leaving straightforward.

A quick AI SOC provider evaluation scorecard

Use the following table to score candidates consistently. Rate each criterion from 1 (weak) to 5 (strong) and compare totals across shortlisted vendors.

A provider that answers all ten questions convincingly is rare, and worth shortlisting. To understand how Nordic SOC approaches these criteria, explore Vokter Guardian, read more about Nordic SOC, or get in touch to discuss your environment. MSPs and technology partners can review the partner programme.

Conclusion

Selecting an AI SOC provider in Europe comes down to a simple test: can the vendor demonstrate sovereignty, accountability and reversibility, and prove it against your regulatory obligations rather than assert it? The ten questions above turn an abstract comparison into a structured, defensible evaluation. Ask them of every candidate, score the answers, and you will move from vendor claims to operational certainty.

DORA compliance for your SOC means proving, with evidence, that your security operations can detect, classify, report and withstand ICT disruptions. The Digital Operational Resilience Act requires financial entities to manage ICT risk continuously, report major incidents to regulators within defined timelines, test their resilience, and govern third-party ICT providers. In practice, your SOC must produce structured incident records, classification decisions, audit-ready reporting and a defensible trail of every detection and response action. This article explains what DORA expects of security operations and how a modern, AI-driven SOC delivers it.

DORA (Regulation (EU) 2022/2554) applies from 17 January 2025. It is an EU regulation that harmonises digital operational resilience requirements across banks, insurers, investment firms, payment institutions, crypto-asset service providers and many other financial entities, as well as the critical ICT third-party providers that serve them. Where NIS2 sets a broad cybersecurity baseline across sectors, DORA is the sector-specific, directly applicable rulebook for financial services.

What does DORA require for SOC operations?

DORA is built around several pillars that together define operational resilience for financial entities. Each pillar translates into concrete expectations for security operations. A SOC is no longer judged only on whether it stops attacks; under DORA it must also demonstrate, on demand, that its processes are governed, repeatable and evidenced.

The five pillars most relevant to a SOC are ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. The table below maps each pillar to what your SOC must deliver.

ICT risk management: what your SOC must monitor

The Digital Operational Resilience Act places ICT risk management at the centre of operational resilience. DORA expects financial entities to maintain a sound, documented ICT risk-management framework and to monitor the security of their ICT systems continuously. For a SOC, this means full visibility across endpoints, identity, cloud workloads, network and critical applications, with detection logic that is documented and maintained rather than ad hoc.

Continuous monitoring is the practical heart of this requirement. Your SOC must collect and correlate telemetry around the clock, surface anomalies quickly, and ensure that nothing material goes unobserved. This is where alert volume becomes a compliance issue as well as an operational one: undetected or de-prioritised alerts undermine the assurance DORA expects. AI-driven triage helps by handling high alert volumes consistently and reducing the risk that a genuine threat is lost in noise. See our note on AI alert triage and alert fatigue for how this works in practice.

DORA incident reporting: detection, classification and timelines

Incident management is the pillar where SOC capability is most visible to regulators. DORA requires financial entities to detect ICT-related incidents, classify them against defined criteria, and report major incidents to the relevant competent authority. Reporting follows a staged model: an initial notification, one or more intermediate updates as the situation develops, and a final report once root cause and remediation are understood, each within regulator-defined timelines.

To meet this, your SOC must deliver three things reliably:

• Consistent detection and classification. Every incident must be assessed against severity and impact criteria using a repeatable method, so that the decision to classify something as “major” is defensible and documented.
• Timely, structured reporting. The SOC must produce initial, intermediate and final DORA incident reporting outputs with the data fields regulators expect, on the clock, without scrambling to reconstruct events after the fact.
• A complete timeline. Detection time, classification decisions, escalation steps and containment actions must be captured automatically so the reporting narrative is accurate and verifiable.

This staged reporting model is similar in spirit to obligations under NIS2, and entities subject to both frameworks benefit from aligning their processes. Our NIS2 SOC checklist covers the overlap in more detail.

How a DORA compliance SOC handles testing and third-party risk

Operational resilience under DORA is not only about responding to incidents; it is about proving the response will work. DORA requires a programme of digital operational resilience testing, ranging from routine vulnerability assessment to threat-led penetration testing for significant entities. Your SOC supports this by providing the detection telemetry that tests exercise, validating that simulated attacks are seen and handled, and tracking findings through to remediation with evidence at each step.

Third-party ICT risk is equally central. Financial entities depend on external providers for core ICT services, and DORA holds entities accountable for monitoring and managing that dependency. A DORA compliance SOC must therefore extend visibility beyond the perimeter: monitoring third-party and remote access, watching for supply-chain indicators, and ensuring incidents that originate with or traverse a provider are detected, classified and reported in the same disciplined way as internal events.

Evidence and audit trails: the SOC’s compliance output

Underpinning every DORA pillar is the need for evidence. A regulator, auditor or internal risk function should be able to ask “show me” and receive a clear, tamper-evident record. For security operations this means your SOC must produce, as a routine by-product of its work:

• A time-stamped record of every alert, detection and decision.
• Classification rationale for each incident, mapped to DORA criteria.
• The full sequence of response and containment actions, including who or what performed them.
• Reporting artefacts aligned to the initial, intermediate and final stages.
• Evidence linking testing findings to remediation.

Manual SOCs often struggle here, because evidence is reconstructed after the fact from disparate tools. An audit-ready SOC instead captures the trail as events unfold. This is also where MITRE ATT&CK automated investigation adds value: mapping activity to a recognised framework gives auditors and analysts a consistent, explainable account of what happened.

How an AI SOC delivers DORA compliance

A modern AI SOC is well suited to DORA because the regulation rewards speed, consistency and documentation, which are exactly the qualities automation provides. AI handles the high-volume detection and triage work continuously, applies classification logic uniformly, and records each step automatically, producing audit-ready evidence without analysts having to assemble it manually.

Nordic SOC delivers this through Vokter, our AI SOC, with DORA- and NIS2-aligned evidence and reporting built into the service. Vokter Guardian combines AI that handles the large majority of detection and triage with named Nordic analysts available 24/7 for threat hunting, forensics and incident leadership under a defined SLA, an arrangement well suited to financial entities that need both speed and human accountability for major incidents. Crucially for DORA, delivery is EU-sovereign: incident data, logs and reporting stay within EU jurisdiction, supporting both the regulation and broader EU data sovereignty expectations.

For organisations evaluating providers, the key question is whether the SOC produces the evidence DORA demands as a standard output, not as a bespoke project after each incident. You can learn more about Nordic SOC or contact our team to discuss DORA-aligned security operations.

Conclusion

DORA reframes the SOC as an evidence-producing function as much as a defensive one. From 17 January 2025, financial entities must demonstrate continuous ICT risk monitoring, consistent incident classification, staged reporting within regulator-defined timelines, resilience testing, third-party oversight and a complete audit trail. A modern AI SOC meets these expectations by combining fast, consistent detection with automatically generated, audit-ready evidence, delivered within EU jurisdiction. The result is operational resilience that can be both achieved and proven.

EU data sovereignty in security operations means that the data flowing through your security operations centre (SOC) logs, alerts, telemetry, case files and the AI processing applied to them remains under EU jurisdiction and EU law, not exposed to foreign lawful-access regimes. It matters because a SOC sees almost everything: authentication events, network traffic, endpoint activity and the detail of every incident. If that data, or the AI that analyses it, can be compelled out of the EU, sovereignty is lost regardless of where the servers physically sit. This article explains what sovereignty means for security operations, how it differs from simple data residency, and what to verify before you trust a provider with your most sensitive telemetry.

What does EU data sovereignty mean for a SOC?

Sovereignty is a question of control and jurisdiction, not just geography. A sovereign SOC is one where every place your data lives and is processed including the machine-learning and AI components that triage alerts and drive investigations is governed exclusively by EU law and operated by an entity that cannot be compelled to hand that data to a non-EU authority.

This is a higher bar than it first appears. A SOC is among the most data-rich functions in any organisation. It ingests identity events, email metadata, network flows, cloud audit trails, endpoint detections and the full narrative of every security incident. Concentrated in one place, that telemetry is a map of how the business operates and where it is weakest. The question where does SOC data go is therefore not a procurement footnote it is a core risk decision.

Data residency EU versus true sovereign cybersecurity

The terms are often used interchangeably, but they describe different things. Data residency answers a physical question: in which country or region is the data stored and processed? Sovereignty answers a legal and operational one: under whose jurisdiction does the data fall, and who can be lawfully compelled to access it?

A provider can offer EU data residency storing your data in an EU cloud region while remaining a subsidiary of a non-EU parent subject to foreign disclosure laws. In that case the bytes sit in Europe, but the legal control does not. Genuine sovereign cybersecurity closes that gap by ensuring both the location and the controlling entity sit inside the EU, and by ensuring AI inference happens in-region rather than being routed to an external model endpoint elsewhere.

Why EU data sovereignty matters now

Three forces have moved sovereignty from a nice-to-have to a board-level concern.

Non-EU lawful access. Some jurisdictions assert authority to compel companies under their control to disclose data they hold, including data stored abroad. Where a provider is owned or controlled outside the EU, that exposure can in principle reach EU-hosted telemetry a structural risk that EU residency alone does not remove.

Regulation. GDPR remains the EU’s baseline data-protection regulation and governs the personal data inevitably present in security logs. Sector rules raise the bar further: DORA has applied to financial entities and their ICT providers since 17 January 2025, and NIS2 (adopted in 2022) widens cybersecurity and oversight duties across essential and important entities. Both push organisations to understand and govern their third-party security supply chain.

The EU AI Act. A modern SOC runs on AI for alert triage and investigation, which brings it into scope of the EU AI Act. The Act’s transparency obligations begin to apply from August 2026, requiring clarity about AI systems and how they are used. For security operations this reinforces a sovereignty principle: you must know not only where your data sits, but where and how the AI that processes it operates.

Where does SOC data go? A provider verification checklist

Sovereignty claims are only as good as the answers a provider can give in writing. Use the following to test any managed security operations or AI-SOC vendor.

• Region: In which specific EU region is data stored, and can you choose it?
• Control: Which legal entity controls the data, and to which jurisdiction is it subject?
• AI inference: Where does AI processing physically occur in-region, or routed to an external endpoint?
• Sub-processors: Who are the sub-processors, and are any outside the EU?
• Keys: Who holds the encryption keys, and can you retain custody?
• Access: Who can access your telemetry, from where, and under what controls?
• Lawful access: Could any parent or affiliate be compelled to disclose your data under non-EU law?
• Evidence: Can the provider document AI transparency, data flows and retention to support GDPR, DORA and NIS2 obligations?

How a sovereign SOC is built by design

Sovereignty cannot be retrofitted with a contractual clause; it has to be an architectural choice. A sovereign SOC keeps ingestion, storage, analytics and critically AI inference inside the chosen EU region, run by an EU-governed entity, with a disclosed EU-scoped sub-processor chain and EU-held encryption keys.

Nordic SOC is built on this principle. Everything, including the AI, runs and stays inside the EU region the customer chooses. The Vokter AI SOC applies this across its modes: Autonomous for SIEM-less, AI-driven detection and response; Hybrid to run on your existing stack; and Guardian for AI combined with 24/7 Nordic analysts. Because the platform is EU-sovereign by design, the answer to where does SOC data go is unambiguous it stays in your chosen EU region, and so does the AI that reasons over it. For background on the company and its independence, see the about page, and to discuss a specific environment, get in touch.

Sovereignty also intersects with adjacent compliance work. Financial entities weighing operational-resilience duties should read our note on DORA compliance and the SOC, and any organisation comparing vendors will find a structured approach in choosing an AI-SOC provider in Europe.

Conclusion

EU data sovereignty in security operations is ultimately about control: keeping the most revealing data in your organisation, and the AI that interprets it, under EU jurisdiction and EU law. Data residency is a starting point, not the destination. As GDPR, DORA, NIS2 and the EU AI Act’s transparency obligations converge, the providers worth trusting are those that can show not merely assert that data and AI processing stay inside the EU region you choose.

Managed Detection and Response (MDR) is a security service in which an external provider monitors an organisation’s IT environment around the clock, detects threats, investigates alerts, and responds to confirmed incidents on the customer’s behalf. So what is MDR in practice? It combines technology, threat intelligence, and human or AI-driven expertise to deliver continuous detection and active response as an outcome not just tooling. Unlike a product an organisation buys and operates itself, MDR is a managed service: the provider owns the detection engineering, the triage, and the remediation workflow. This makes managed detection and response well suited to organisations that lack a fully staffed in-house security operations centre but still require 24/7 protection.

What is MDR and what does it include?

At its core, managed detection and response packages a set of capabilities that an organisation would otherwise have to build, integrate, and staff itself. A credible MDR service spans the full incident lifecycle rather than a single point in it.

• Telemetry collection: ingesting logs, endpoint signals, network data, identity events, and cloud activity into a central analysis layer.
• Threat detection: applying detection rules, behavioural analytics, threat intelligence, and correlation to surface suspicious activity.
• Alert triage and investigation: separating true threats from noise, enriching alerts with context, and reconstructing what happened across the kill chain.
• Incident response: containing, isolating, or remediating confirmed threats and, in advanced services, taking automated containment actions within agreed guardrails.
• Reporting and continuous improvement: regular reporting, detection tuning, threat hunting, and post-incident review.

The defining characteristic of MDR services is the response element. Many monitoring offerings stop at raising an alert; MDR commits to acting on it, whether by guiding the customer’s team or by executing containment directly.

MDR vs EDR: service versus product

The most common point of confusion is MDR vs EDR. Endpoint Detection and Response (EDR) is a technology product that detects and records malicious activity on endpoints such as laptops and servers. It is powerful, but it is something an organisation buys and must operate someone still has to watch the console, interpret detections, and respond. MDR is the service layer that operates detection technology (which may include EDR, but also SIEM, identity, network, and cloud telemetry) and delivers the human or AI-driven response. In short: EDR is a tool; MDR is an outcome built on tools.

MDR vs MSSP: detection depth versus alert forwarding

The MDR vs MSSP distinction matters when comparing managed offerings. A traditional Managed Security Service Provider (MSSP) typically manages security devices and forwards alerts to the customer, often leaving investigation and response to the in-house team. MDR goes further: it takes ownership of detection engineering, investigates alerts to a verdict, and drives or executes response. MSSPs tend to optimise for device management and volume; MDR optimises for threat outcomes and reduced dwell time.

Comparison: MDR vs EDR vs MSSP vs in-house SOC

Who needs MDR services?

MDR services suit organisations that need mature detection and response capability without the cost and complexity of building a 24/7 SOC from scratch. This commonly includes mid-sized enterprises, regulated firms in finance, healthcare, and critical infrastructure, and organisations with lean security teams facing persistent alert volumes. It is also relevant to companies subject to European regulation: under DORA, applicable from 17 January 2025, and the NIS2 Directive adopted in 2022, in-scope organisations must demonstrate continuous monitoring, incident detection, and timely response. MDR provides a structured way to meet these expectations.

Managed service providers (MSPs) also turn to MDR to add detection and response to their portfolios without standing up their own security operations centre.

How AI is reshaping MDR

Traditional MDR depends heavily on human analysts working through alert queues, which constrains speed and scale. AI is changing the economics of managed detection and response. AI-driven systems can triage alerts, correlate signals across sources, and reconstruct attack narratives in seconds rather than hours reducing the analyst alert fatigue that erodes detection quality. This shift is closely tied to the rise of the AI SOC, where automation handles the high-volume, repeatable work and human expertise concentrates on complex investigation and decision-making.

The practical effect is faster mean time to detect and respond, more consistent triage, and the ability to sustain 24/7 coverage without proportionally scaling headcount. As the EU AI Act’s transparency obligations take effect from August 2026, the governance and explainability of these AI systems also becomes a procurement consideration for European buyers.

AI-driven, EU-sovereign MDR with Vokter

Nordic SOC delivers AI-driven MDR through the Vokter platform, operated EU-sovereign data, processing, and operations remain within European jurisdiction and EU cloud regions, supporting DORA and NIS2 obligations. Vokter Guardian combines AI that handles 85-90% of detection and triage with named Nordic analysts providing 24/7 oversight, threat hunting, forensics, and a defined SLA a complete managed detection and response service. For organisations that already run a SIEM and SOAR stack, Vokter Hybrid layers AI-driven Level 1 detection and triage over the existing toolset, freeing analysts for higher-value Level 2 and Level 3 work. Both deliver the response outcome that distinguishes MDR from monitoring alone. For a broader view of managed operations in the region, see our overview of SOC as a service in the Nordics, or contact us to discuss requirements.

Conclusion

MDR closes the gap between owning security tools and achieving security outcomes. By combining continuous monitoring, expert detection, investigation, and active response into a managed service, it gives organisations the protection of a mature SOC without the burden of building one. As AI absorbs the repetitive work of triage and investigation, MDR is becoming faster, more consistent, and when delivered EU-sovereign better aligned with European regulatory and data-sovereignty requirements.

MITRE ATT&CK is a globally accessible, free knowledge base of adversary tactics and techniques, maintained by MITRE and built on observations of real-world attacks. For a SOC, MITRE ATT&CK provides a shared vocabulary that turns a raw alert into context: instead of an isolated signal, an event becomes a recognised step in an attacker’s playbook. That context is what makes the difference between alert noise and an investigation a team can act on quickly.

This primer explains what the framework contains, how ATT&CK mapping improves detection coverage, and how an AI SOC uses the framework to explain and prioritise incidents during automated investigation.

What is MITRE ATT&CK and why does it matter to a SOC?

ATT&CK stands for Adversarial Tactics, Techniques and Common Knowledge. It is a structured catalogue of how attackers behave once they have a foothold or are attempting to gain one. Rather than focusing on specific malware signatures, MITRE ATT&CK SOC practice centres on behaviour: what an adversary is trying to do and the methods they use to do it. Because the knowledge base is free and openly maintained, any security team can adopt it without licensing barriers.

The value to a SOC is consistency. When every analyst, tool and report describes activity using the same framework, investigations become repeatable and comparable. An alert mapped to a known technique carries instant context about likely intent, typical follow-on activity and appropriate response, which shortens the path from detection to decision.

Tactics, techniques and procedures explained

ATT&CK is organised into a hierarchy. Understanding the three layers, often summarised as tactics, techniques and procedures (TTPs), is the foundation for any ATT&CK mapping work.

• Tactics describe the attacker’s goal at a given stage, the why. Examples include Initial Access, Persistence, Privilege Escalation and Exfiltration. Tactics form the columns of the ATT&CK matrix.
• Techniques describe how an attacker achieves a tactic. Many techniques are further broken down into sub-techniques that capture specific variations of a method.
• Procedures are the concrete, observed implementations of a technique by a particular adversary or tool, the real-world detail seen in telemetry.

The framework is published as several matrices to reflect different environments. The Enterprise matrix covers IT systems, endpoints, cloud and network. The Mobile matrix addresses mobile platforms, and the ICS matrix covers industrial control systems and operational technology. This separation lets a SOC apply the framework accurately to the estate it actually defends.

The techniques above are illustrative examples drawn from the framework’s structure; the authoritative and complete catalogue is maintained by MITRE.

How does ATT&CK mapping improve threat detection coverage?

ATT&CK mapping means associating detections, alerts and telemetry with the relevant tactics and techniques. Done consistently, it changes how a SOC understands its own capability and its incidents.

Coverage visibility. By mapping existing detection rules to the ATT&CK matrix, a team can see which techniques are well covered and which are blind spots. This turns an abstract question, “are we protected?”, into a concrete heat map of strengths and gaps that informs tuning and investment.

Context on every alert. An alert tagged with a technique tells the analyst what the activity represents and what commonly follows it. A credential-access alert, for instance, signals the need to check for subsequent lateral movement, guiding the investigation rather than leaving the analyst to start from scratch.

Connected narratives. Real intrusions span multiple techniques across several tactics. Mapping individual alerts to ATT&CK lets a SOC stitch separate signals into a single chain of behaviour, distinguishing a genuine multi-stage attack from unrelated noise. This is central to reducing the alert overload many teams face; our note on AI alert triage and alert fatigue explores that challenge in more detail.

How an AI SOC uses MITRE ATT&CK for automated investigation

Manual ATT&CK mapping is valuable but slow, and it depends on analyst availability and expertise. An AI SOC applies the same framework programmatically, at machine speed, across every alert. This is where MITRE ATT&CK SOC practice scales from a reference exercise to an operational engine for automated investigation.

When an alert arrives, the AI correlates the underlying telemetry against ATT&CK techniques, assigns the most likely tactic and technique, gathers related events, and assembles a structured account of what appears to be happening. Crucially, the mapping is explainable: the incident summary states which technique was matched and on what evidence, so analysts and auditors can follow the reasoning rather than trust a black box.

The result is faster, better-prioritised investigation. By placing each event in the context of the wider attack, the AI can rank incidents by likely severity and stage, so the most advanced or impactful activity rises to the top. The Hybrid mode applies this AI mapping as a first analyst layer over an existing SIEM and SOAR, while the Autonomous mode runs investigation without a separate SIEM. ATT&CK context also underpins safe response decisions, a topic covered in our piece on autonomous containment done safely.

ATT&CK mapping, reporting and assurance

Beyond live investigation, consistent ATT&CK mapping strengthens reporting. Mapping incidents to recognised techniques gives leadership and auditors a defensible, standardised view of what the SOC detects and how it responds. As obligations under frameworks such as DORA, applicable from 17 January 2025, and NIS2, adopted in 2022, raise expectations around incident handling and reporting, a common behavioural vocabulary makes evidence clearer and comparisons across time and teams more meaningful.

Conclusion

MITRE ATT&CK gives a SOC a free, structured language for adversary behaviour, organised into tactics, techniques and procedures across Enterprise, Mobile and ICS matrices. Mapping alerts to this framework improves detection coverage, adds context to every event and connects isolated signals into coherent attack narratives. When an AI SOC performs that mapping automatically, the framework becomes a practical engine for fast, explainable and well-prioritised investigation, helping analysts focus on what matters and respond with confidence.

NIS2 SOC requirements centre on continuous security monitoring, fast incident detection and structured notification to authorities. The NIS2 directive expects in-scope organisations to operate risk-based security measures, detect incidents promptly, and report significant ones to their national CSIRT or competent authority within tight timeframes. A modern security operations centre (SOC) is the operational backbone that makes these obligations achievable, by maintaining 24/7 visibility, triaging alerts, investigating threats, and producing the evidence regulators expect.

This article sets out a practical checklist of what NIS2 expects from security monitoring and incident response, who is in scope, and how a SOC, supported by AI, helps you meet each obligation.

What does NIS2 require of a SOC?

The NIS2 directive modernises and broadens the EU’s earlier network and information security rules. For a SOC, the practical implications fall into a handful of areas: you must be able to detect incidents, respond to them, notify the right authorities, manage risk across your supply chain, and demonstrate that senior management oversees all of this. NIS2 does not mandate a specific technology or operating model. It sets outcomes, and a SOC is how most organisations achieve those outcomes day to day.

Crucially, NIS2 raises the bar on accountability. Management bodies are expected to approve and oversee cybersecurity risk-management measures, and members can be held responsible for failures. That shifts security monitoring from a purely technical concern to a governance obligation, and it makes consistent, evidenced SOC operations a board-level priority.

Who is in scope: essential and important entities

NIS2 applies to medium and large organisations operating in sectors the directive considers critical, and it classifies them as either essential entities or important entities. The split reflects how critical a sector is and the size of the organisation, rather than a difference in the security expected.

• Essential entities typically include sectors such as energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure, and public administration.
• Important entities typically include sectors such as postal and courier services, waste management, manufacturing of certain products, food production and distribution, and digital providers.

Both categories must implement comparable risk-management measures and meet the same reporting duties. The principal difference lies in supervision: essential entities face proactive, ongoing oversight, while important entities are generally supervised reactively, after an incident or indication of non-compliance. Because national transposition varies, organisations should confirm their classification under the law of each member state in which they operate.

The core NIS2 SOC requirements checklist

The table below summarises the main NIS2 obligations relevant to security monitoring and incident response, and how a SOC addresses each one.

NIS2 incident reporting: what your SOC must support

NIS2 incident reporting is one of the directive’s most operationally demanding requirements. For significant incidents, the directive sets out a phased notification process to the national CSIRT or competent authority:

• An early warning shortly after the organisation becomes aware of a significant incident, indicating whether it may be caused by unlawful or malicious acts or could have cross-border impact.
• A fuller incident notification with an initial assessment, including severity, impact, and any indicators of compromise.
• A final report later, describing the incident, its root cause, mitigation, and any cross-border effects.

The exact deadlines, including the short window for the initial early warning, are defined in each member state’s transposition of the directive, so organisations operating across borders should confirm the precise timeframes that apply to them. What matters operationally is that your SOC can determine quickly whether an incident is significant, capture the facts needed for each stage, and produce accurate notifications under time pressure. This is difficult to do manually at scale, which is where automation and AI become decisive.

How an AI SOC meets NIS2 SOC requirements

The hardest parts of NIS2 compliance are speed and consistency: detecting significant incidents quickly, investigating them thoroughly, and reporting them accurately within tight windows. An AI SOC is built for exactly this. AI-driven triage filters noise and prioritises genuine threats, reducing the delay between an event occurring and an analyst acting on it. Automated investigation correlates signals across the estate, reconstructs the attack path, and assembles the context needed to judge whether an incident is significant under NIS2.

Just as importantly, an AI SOC generates structured, time-stamped records as it works. That documentation, covering detection, investigation, containment, and outcome, becomes the evidence base for both incident notifications and supervisory audits. Vokter Hybrid applies AI-driven Level 1 triage and investigation over your existing SIEM and SOAR, strengthening detection and reporting without replacing your stack. For organisations that need named analysts, threat hunting, forensics, and a contractual SLA alongside the AI, Vokter Guardian combines AI with 24/7 human oversight, with NIS2- and DORA-aligned evidence built in.

Because Nordic SOC operates as an independent, EU-sovereign provider with data held in EU cloud regions, monitoring and evidence remain within European jurisdiction, which matters for both NIS2 obligations and broader EU data sovereignty requirements. Organisations subject to financial-sector rules should also review how these capabilities map to DORA compliance, which applies from 17 January 2025 and shares much of NIS2’s emphasis on incident reporting and operational resilience.

A practical readiness checklist

Use the following checklist to assess whether your security monitoring and incident response are ready for NIS2:

• Confirm your classification as an essential or important entity in each member state where you operate.
• Map your risk-management measures to the directive’s requirements and document them.
• Ensure 24/7 monitoring coverage across endpoints, network, cloud, and identity.
• Define and test incident-handling playbooks, including containment and recovery.
• Establish a process to assess incident significance quickly and consistently.
• Build a phased notification workflow aligned to your national transposition’s deadlines.
• Extend monitoring and risk assessment to suppliers and third-party access.
• Provide management with regular, evidenced reporting on cyber risk and incidents.
• Retain logs, investigation records, and notifications as audit-ready evidence.
• Review readiness regularly and after any significant incident or regulatory change.

If you would like to assess your NIS2 readiness against your current monitoring and reporting capability, contact Nordic SOC to discuss your environment.

Conclusion

NIS2 turns continuous monitoring, rapid incident response, and structured reporting from good practice into a legal and governance obligation. A capable SOC is how organisations meet these expectations in practice, and an AI SOC makes the speed, consistency, and evidence the directive demands realistic at scale. With transposition timelines varying by country, the practical step is to confirm your obligations under the national law that applies to you and ensure your monitoring and reporting can satisfy them.