Managed security and SOC, built to the 24-hour clock.
Attackers move from one endpoint to the next in about half an hour, and NIS2 gives you 24 hours to file an early warning. We run continuous detection on Wazuh, respond on defined runbooks, and produce the evidence your regulator and your board ask for, from inside the EU.
A managed security operations service watches your systems for threats around the clock, responds when one lands, and documents both for the people who need proof. In 2026 two forces make it hard to skip in Europe: attackers now move from a foothold to lateral movement in minutes, and NIS2 and DORA attach legal deadlines to how fast you detect and report. Argus Root runs the detection and the response inside the EU, for organisations in regulatory scope that cannot staff a 24/7 operation of their own.
In short
- The average eCrime breakout time fell to 29 minutes in 2025 (from 48 in 2024); the fastest on record was 27 seconds, and in one case data exfiltration began within 4 minutes of access.
- 82% of intrusions are now malware-free — attackers log in with stolen credentials, so identity and cross-domain correlation matter more than signatures.
- NIS2 sets an early warning within 24 hours, a notification within 72 hours and a final report within one month; DORA adds a major-incident clock measured in hours.
- A 24/7 in-house SOC needs roughly 9 to 14 staff and commonly costs €1.5–2.9M a year once fully loaded — the reason most organisations buy detection rather than build it.
- The SOC and your security telemetry stay inside the EU: a SOC on a US-owned platform puts your logs back under foreign jurisdiction.
Minutes to breakout, hours to report.
The CrowdStrike 2026 threat report puts average breakout time at 29 minutes: the gap between an attacker landing on one endpoint and moving to the next. A part-time admin checking alerts in office hours cannot meet that. On the other side, NIS2 hands essential and important entities a 24-hour early warning deadline and a 72-hour detailed notification, with a final report within a month. Detection and reporting are now a timed exercise.
| Framework | Early warning | Detailed report | Final report |
|---|---|---|---|
| NIS2 | 24 hours | 72 hours | 1 month |
| DORA | Initial notification | Intermediate update | Final report |
| GDPR | 72 hours to the DPA | n/a | n/a |
The squeeze is measurable. The median time for an intruder to move from a first foothold into the rest of the network, the breakout time, has fallen to around 29 minutes, and AI-enabled attackers increased their operations by nearly 90% year on year. Detection that runs only in office hours, or a response that waits for an analyst to arrive in the morning, loses the race before it starts. The clock that matters most is the attacker's, and it now runs in minutes.
The regulator's clock runs alongside it. NIS2 expects an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72, and a final report within a month; DORA imposes its own incident reporting on financial entities; and the NIS2 Implementing Regulation published in late 2024 spells out concrete monitoring, detection, testing and documentation duties that land on managed security providers directly. A SOC that detects late does more than let an attacker run longer: it starts the legal clock against you from behind.
What we run for you.
Detection that runs continuously, response that follows a runbook, and a record that holds up afterward.
Continuous detection
Wazuh SIEM and host intrusion detection across your fleet: log analysis, file-integrity monitoring and correlation, running around the clock rather than during office hours.
Incident response
Documented runbooks tied to the NIS2 clock, so containment and the 24-hour and 72-hour notifications happen in order instead of being improvised mid-incident.
Active response & hardening
Fail2Ban, nftables geo-blocking and automated containment at the edge, with the host hardening that stops an alert becoming a breach.
Vulnerability & patch management
Tracking, assessing and remediating exposures, the Article 21 discipline NIS2 expects, before a known CVE turns into your incident.
Supply-chain monitoring
Visibility into third-party access and supplier connectivity, the area both NIS2 and DORA single out as the soft entry point.
Reporting & evidence
The record a board and a regulator ask for: control effectiveness, residual risk and readiness against deadlines, not raw alert counts. See compliance →
What does a managed SOC really cost?
The cheapest security service on paper is often the most expensive in practice, because the contract price hides the staff it still demands. A managed SIEM at around eight thousand a month that needs two of your own analysts to investigate its alerts costs far more, all in, than a detection-and-response service at twelve thousand that does the investigating for you. The honest comparison is total cost of operation, the fee plus the internal hours, rather than the line on the quote.
The models differ mainly in how much work stays with you. Managed SIEM hands you the tooling and the triage; managed detection and response adds the people who investigate and act; a full outsourced operations centre runs the lot. Security-services spending is growing faster than any other part of the market in 2026 precisely because organisations have concluded they cannot staff this internally at the speed the threat now demands. We scope the model to the team you have rather than the one a brochure assumes.
| Model | What you still run | Best when |
|---|---|---|
| Managed SIEM | Investigation and triage | You have analysts to spare |
| MDR | Little; we investigate | You want response, not headcount |
| SOCaaS | Almost nothing | You want it fully outsourced |
| Co-managed | Remediation, your call | You keep authority, we detect |
Alert fatigue, and the move to an AI-assisted SOC.
Detection on its own is not enough, because detection produces noise. A busy environment generates thousands of alerts a day, the vast majority of them false or trivial, and a team buried under them misses the one that matters. This is alert fatigue, and it sits behind a surprising share of breaches that the tooling technically caught and no human reached in time.
The answer the field has settled on for 2026 is automation that does the repetitive work at machine speed: triage, enrichment and the first response steps handled automatically, so analysts spend their judgement on the decisions that need a human rather than on clearing a queue. We run detection and active response automatically on Wazuh, with human response following documented runbooks, so the volume is handled by the machine and the people sit where they add value. The goal is fewer, better alerts reaching a person, rather than a bigger queue for a smaller team.
The SOC is in the EU too.
A SOC that ships your logs to a US-owned platform quietly reintroduces the jurisdiction problem you were trying to solve. We run detection on Wazuh inside the EU, so your security telemetry stays in-region. Detection runs continuously and automated; response follows documented runbooks, with response tiers scoped to your risk profile rather than sold as a fixed package. The monitoring sits on the same foundation as our observability work.
<!-- 6 failed SSH logins in 120s from one source → contain --> <group name="local,syslog,sshd,"> <rule id="100200" level="10" frequency="6" timeframe="120"> <if_matched_sid>5710</if_matched_sid> <description>SSH brute force from same source</description> <mitre><id>T1110</id></mitre> </rule> </group> <!-- ossec.conf: drop the source at the edge for 600s --> <active-response> <command>firewall-drop</command> <rules_id>100200</rules_id> <timeout>600</timeout> </active-response>
Detection you own, not a black box you rent.
A hidden cost of an outsourced operations centre is lock-in. When the provider owns the detection logic, the correlation rules and the tuning, leaving them means starting over: organisations have lost months of custom rules, threat integrations and business-context tuning overnight when switching vendor. The intelligence built up about your own environment ends up trapped inside someone else's platform.
We build detection in open formats, SIGMA rules and Wazuh configuration, versioned and owned by you, so the work done to understand your environment stays yours. If you ever move on, the detection logic goes with you rather than evaporating, and while we run it you can see and audit what is watching you rather than trusting a sealed box. It is the same instinct that runs through the rest of what we do: the operator runs it, but the asset belongs to you.
Co-managed or fully run?
Not every team wants to hand over response authority, and the co-managed model exists for that. We handle detection and escalation while your own people keep the authority to remediate, which suits a team with a SIEM investment to preserve or a service provider that owns its client relationships. Where you would rather offload the lot, we run detection and response from end to end.
Either way we integrate with the stack you already have rather than demand a rip-and-replace, augmenting your SIEM, identity and endpoint tooling instead of insisting on ours. The transition is planned so there is no coverage gap while it happens, and the split of who does what is written into the engagement rather than discovered during the first incident. The model follows your team and your appetite for control, rather than a single way of working applied to everyone.
Who needs a managed SOC?
The clearest case is an organisation in NIS2 or DORA scope without a round-the-clock security operation of its own, which most below enterprise scale cannot staff: continuous monitoring needs a rota of analysts that few mid-sized teams can justify or recruit into a market short millions of people. Close behind are companies whose insurers or customers now require evidence of continuous monitoring and incident response before they will sign or renew.
What they share is an attack surface that has outgrown office-hours, best-effort security, and a regulatory or commercial reason that protection now has to be demonstrable rather than assumed. A business still relying on a firewall and hope, or on an IT generalist watching security among ten other duties, is the typical fit. Where an organisation genuinely has the scale to run its own mature SOC, we will say so, and co-management is often a better answer than duplicating what it already has.
What an incident looks like, against the clock.
When an alert is confirmed as a real incident, the response follows a runbook rather than improvisation, and the runbook is built around the deadlines. The first job is containment: isolating the affected host, cutting the attacker's access and stopping the spread while the breakout clock is still running. In parallel, the facts are recorded as they are established, because the report that has to follow depends on a timeline nobody can reconstruct accurately after the event.
Then the regulatory clock takes over. Within 24 hours of becoming aware of a significant incident, NIS2 expects an early warning to the authority; within 72 hours, a fuller notification with an initial assessment; within a month, a final report with root cause and the measures taken. DORA imposes a parallel discipline on financial entities. Each is a deliverable with a deadline, and missing one is its own breach on top of the original. Our runbooks produce them in order, so the work during an incident is execution against a known sequence rather than a scramble to work out what is owed to whom and by when.
The value of rehearsing this in advance is that the worst time to design an incident response is during an incident. We document and test the runbooks before they are needed, so when something lands the team follows a path it has walked before rather than inventing one under pressure with regulators and customers waiting on the other end.
Detection engineering, not a switch you flip.
A SIEM out of the box catches the obvious and buries you in the rest. The work that makes detection useful is engineering: writing and tuning the rules to your environment, mapping coverage against a framework like MITRE ATT&CK so the gaps are known rather than assumed, and cutting the false positives that cause the fatigue described above. A tool watched without that work is a source of noise; a tool with it is a source of signal.
We treat detection as an ongoing discipline rather than a one-time setup. Coverage is mapped to the techniques an attacker would use against a business like yours, rules are tuned as the environment and the threats change, and threat hunting looks for the activity no rule yet catches. Because the rules are written in open formats and owned by you, the coverage is auditable rather than a vendor's secret, and it improves rather than ossifying after the install. The difference shows up as a higher proportion of real threats caught and a lower proportion of analyst time wasted on noise.
How does onboarding work?
Standing up the service starts with visibility rather than disruption. We deploy the detection agents across your fleet, establish a baseline of what normal looks like in your environment, and tune the initial rules against it before anything goes to alerting, so the first week produces understanding rather than a flood of false alarms. Nothing about your applications has to be rebuilt; the monitoring sits around what you run and reads it.
From there the service moves to live detection and response on an agreed scope, with the runbooks, the escalation paths and the reporting cadence settled in the engagement. Where you are moving off an existing SOC or SIEM, the transition is sequenced so there is no window with nothing watching. The aim is a working operation within weeks, refined over the following months as the detection tunes to your environment, rather than a long integration before any protection is live.
What should you ask any SOC provider?
The market is full of services that sound alike and deliver very differently, so a few questions separate them. Ask for the provider's own detection and response times from its client base rather than industry averages, and be wary of any that cannot share them. Ask which compliance frameworks the reporting genuinely supports, NIS2, DORA, SOC 2, ISO 27001, since a generic security report will not satisfy a specific regulatory obligation. Ask whether the service augments your existing tooling or demands a full replacement, and what the coverage gap looks like during the transition.
Then ask the awkward ones. Who owns the detection rules if you leave? Is response limited to alerting you, or does it include active containment? Where is the telemetry stored, and under whose jurisdiction? A provider confident in its answers gives them plainly; one that deflects is telling you something. We would rather you ask all of this upfront and choose on the answers than discover the gaps during an incident, which is why we put our own answers in writing: EU-resident telemetry, detection rules owned by you, and active response scoped in the engagement rather than left vague.
Beyond servers: cloud, identity and endpoints.
An attack surface in 2026 is more than a fleet of servers. The compromise often starts at an identity, a stolen credential or a session token, moves through a cloud control plane, or lands on an endpoint that a server-only view never sees. Detection that watches the hosts alone misses the half of a modern intrusion that happens in the cloud account and the identity provider, which is exactly where an attacker goes to move quietly.
We bring those layers into one picture: the host signals through Wazuh, the cloud and identity activity, and endpoint telemetry, correlated so that a credential used at an odd hour, a new cloud role granted to it, and a process it then runs on a server read as one chain rather than three unrelated alerts. That breadth is what lets the detection follow an attacker across the boundaries they deliberately cross to stay hidden, instead of losing the trail at the edge of one tool's view. A SOC that sees only one layer protects only one layer.
Threat intelligence, in context.
Raw threat feeds are easy to buy and hard to use; a list of malicious addresses with no bearing on your environment adds noise rather than protection. Intelligence earns its place when it is filtered to what matters for a business like yours: the techniques active against your sector, the vulnerabilities being exploited in the wild right now, the indicators tied to threats you are plausibly exposed to rather than every threat in existence.
We fold that context into the detection rather than bolt it on as a separate dashboard, so a rule carries the knowledge of what is currently being used against organisations like yours, and the prioritisation reflects real-world activity instead of a generic severity score. The point of intelligence is to spend attention where the threat is live, and that works only when it is married to detection that can act on it rather than left as a feed someone is supposed to read and rarely does.
What's the difference between MDR, MSSP and managed SIEM?
The distinction comes down to one question: when something is found, who acts? Managed Detection and Response is, in effect, a remote security operations centre that both detects a threat and contains it — its defining feature is that the provider's own team responds, not just notifies. A traditional managed security service provider, or MSSP, mostly raises alerts and leaves the investigation and the response to you. Managed SIEM gives you the platform and the visibility but still expects your team to do the analysis. And SOCaaS is the fully outsourced operations centre. The labels blur in marketing, so the useful test is not the acronym but whether the service stops at telling you something happened or carries through to doing something about it.
That difference is where the value sits, because the damage from most intrusions scales with how long they run, and an alert that waits for an under-resourced team to notice it buys an attacker hours. Managed security is among the fastest-growing categories in the field precisely because organisations have learned that detection without response is half a control, and that the firms able to contain an incident quickly rather than merely flag it suffer dramatically smaller breaches. What we provide is the response end of that spectrum: a managed SOC that detects and contains, with the automated active response handling the seconds-matter containment at the edge and human-led action following agreed runbooks — so the model is scoped to what your team can realistically run rather than sold as an acronym and quietly handed back to you at the moment of an incident.
Zero Trust: an architecture, not a product you buy.
Zero Trust is sold as a product often enough that it is worth saying plainly: it is a design principle, not a thing you purchase and switch on. The principle is to stop treating the network perimeter as a trust boundary — to verify every request as though it came from an open network, grant the least privilege that the task needs, and assume a breach has already happened rather than that the inside is safe. In 2026 it is shifting from a recommended posture to an expectation written into the security requirements of some regulated sectors, which means it increasingly has to be demonstrable rather than aspirational.
Because it is an architecture, a managed SOC does not sell you Zero Trust so much as operationalise it. Identity becomes the centre of gravity, so the detection watches for identity-based attack — credential abuse, anomalous access, privilege escalation — as closely as it watches the network, and the segmentation that limits how far an intruder can move is monitored rather than assumed. The same logic runs through our compliance and sovereignty work, where verifying access and minimising trust is also how data stays under control. Zero Trust, done honestly, is the set of habits the rest of the security operation already practises, made explicit and provable rather than a dashboard with the name printed on it.
Questions buyers ask.
What is a managed SOC?
How does a managed SOC help with NIS2 and DORA?
What are the NIS2 reporting deadlines?
What is the difference between managed SIEM, MDR and SOCaaS?
Do you provide continuous, round-the-clock detection?
Is the SOC itself operated in the EU?
What is the difference between MDR and a SOC?
How fast do you detect and respond?
Will I drown in alerts?
Do I lose my detection rules if I leave?
Can you co-manage with our existing security team?
Do you map detection coverage to MITRE ATT&CK?
How long does onboarding take?
Do you provide active containment or only alerts?
What telemetry do you ingest?
Do you replace our existing EDR or antivirus?
How do you handle ransomware specifically?
Do you implement Zero Trust?
Tell us your attack surface. We'll show you what's watching it.
Send us what you run and which frameworks apply. We map your detection coverage, the gaps against the NIS2 and DORA clocks, and the response model that fits your team, before you commit to anything.