• For an MSSP selling into regulated sectors, the blocker on AI in the SOC was not capability. It was whether a customer’s compliance team could approve it.
• An EU AI Act risk assessment and mitigation plan, written for the MSSP’s specific deployment, turned a stalled approval into several signed ones within days.
• Per-customer workspaces and per-customer autonomy modes let the MSSP give each regulated customer exactly the level of AI involvement its contract and risk appetite allow.
• Investigation depth is tuned to severity, so critical alerts are investigated and actionable inside the 15-minute commitment that regulated customers buy.
• Every query and every finding is recorded and rated, which is what a customer’s auditor needs and what makes the service defensible under NIS2 and DORA.

The MSSP had three operational problems, and one of them was a sales problem.

The first was working across tenants one portal at a time. Analysts operated inside each customer’s Sentinel and Defender XDR portals, switching by hand, with context living in whichever console was open. The second was ticket fatigue: alert volume and noise were consuming analyst attention on the tickets least likely to matter.

The third was the one that mattered commercially. Several customers sat under NIS2, and the financial-services customers sat under DORA. Their compliance functions would not sign off on an AI-assisted service until its classification, data handling and risk controls were documented against the EU AI Act. The MSSP could not sell AI-assisted operations to the customers who most wanted faster, more consistent investigation, because it could not yet answer the question “how is AI used in our service?” in a form an auditor would accept.

Whatever platform the MSSP chose had to be approvable, not just capable.

• Be documentable under the EU AI Act. Classification, data location, human oversight and the record of what the AI did, in a form a customer’s compliance team could review and approve.
• Keep customers separate. One workspace per customer, with data, playbooks, autonomy settings and reporting isolated per tenant.
• Let the MSSP decide how much AI each customer gets. Some customers would accept recommendations only. Others would accept autonomous action within boundaries. The platform had to serve both from the same service.
• Investigate fast enough for a 15-minute critical-incident commitment, and report time to assignment and time to resolution per customer.
• Handle noise before a person sees it, so the real alerts arrive with the investigation already done.
• Process and host data in the EU.

Morpheus was the MSSP’s first full SOC automation platform. There was no runbook library to migrate, so the decision was about what operations should look like from here, not what to preserve.

D3 produced an EU AI Act Risk Assessment and Mitigation Plan specific to the MSSP’s use of Morpheus. It is the document the MSSP now sends when a customer’s compliance team asks how AI is used in their service.

“Thank you for the documentation. We got three or four customer approvals right after we sent it.”

Security operations lead, Nordic MSSP, on the EU AI Act assessment

The effect was immediate. Customers whose compliance reviews had been open for weeks approved the AI-assisted service within days of receiving the document. From that point the MSSP could onboard regulated customers onto the same platform and workflows as everyone else, with the compliance answer already written.

Nothing in the detection stack was replaced. Morpheus connects to each customer’s Sentinel and Defender XDR tenant, to the MSSP’s ticketing system and to its threat-intelligence feed, and is where investigation and closure happen.

One workspace per customer

Each customer has its own workspace: separated data, playbooks, autonomy settings and reporting. An analyst moves between customers inside one interface rather than between portals. Onboarding a new customer means connecting the tenant and applying the standard playbook set, then adjusting autonomy to that customer’s appetite.

Autonomy set per customer

This is what makes one service work for customers with different compliance positions. A customer that has approved recommendations only runs in AI-Assisted mode: Morpheus investigates and proposes, a person approves every action. A customer that has approved bounded autonomous action runs in AI-Led or Autonomous mode for the action types it has agreed to. The mode is a setting in the workspace, recorded, and changed only by the MSSP.

Investigation depth tuned to the SLA

The MSSP commits to a 15-minute response on critical incidents. Attack Path Discovery is configured so a critical alert gets a fast, bounded investigation and a low-severity alert gets a fuller pass. Time to assignment and time to resolution are tracked per customer in the platform, which is what the MSSP reports against and what regulated customers ask to see. For customers under NIS2’s 24-hour early warning and DORA’s initial-notification clock, that timeline is also the evidence of when the MSSP knew what.

Noise handled before assignment

Pre-processing playbooks triage and dismiss obvious noise against known patterns, existing controls and recent activity. Dispositions are logged. What reaches a queue has already been investigated.

Playbooks from prompts

With no runbook library to carry over, most workflows were created by describing the desired behaviour in plain language and letting Morpheus draft the playbook. The team reviews and approves it; after that it runs deterministically. Morpheus also maintains playbooks against integration and schema changes so they do not break quietly, which matters when the same playbook set is applied across dozens of tenants.

“The investigations are accurate and they save time. The AI summary is very helpful.”

SOC team, Nordic MSSP, during production onboarding (condensed from recorded sessions)

Four autonomy modes, set per customer

• Every query is recorded, including those that returned nothing, so a reviewer can see what was checked.
• Every finding is rated confirmed, inferred or gap. Nothing is presented as certain that is not.
• Investigation is read-only. Attack Path Discovery only reads. State-changing actions go through playbooks under the mode set above.
• One audit trail per incident, readable the same way across all four modes.

• Regulated customers approved Several NIS2 and DORA-covered customers signed off on AI-assisted operations within days of receiving the EU AI Act assessment, after reviews that had been stalled.
• Dozens of tenants in production Customer tenants run daily triage in their own Morpheus workspaces, with the remainder of the base being onboarded.
• One service, many compliance positions Per-customer autonomy modes let the MSSP serve recommendation-only customers and bounded-autonomy customers from the same platform and playbooks.
• A compliance answer that closes business The “how is AI used in our service” question in procurement is now answered with a document, which shortens the sales cycle with regulated prospects.

Work in progress at the time of writing: finishing onboarding of the remaining customers, bringing user-reported phishing into the same investigation path, tightening critical-alert turnaround with a lighter investigation mode on the newest release, and expanding per-customer reporting on time to assignment and time to resolution so regulated customers can see the numbers directly.

“It’s a lot of work, but a lot of progress as well.”

Security operations lead, Nordic MSSP

Most of the AI SOC conversation is about capability. For an MSSP with customers under NIS2, DORA and GDPR, the commercial question is approvability: can the customer’s compliance function sign off on AI touching their environment, and can the MSSP prove, per customer, what the AI is and is not allowed to do?

The pattern that transferred here: a platform whose autonomy is a per-customer setting rather than a product-wide one, a complete record of what the AI did and why, and an EU AI Act assessment written for the actual deployment rather than a generic vendor statement. The MSSP kept the judgement and the customer relationship. The documentation did the selling.

• Global software company brings Tier 1 and Tier 2 SOC operations in-house Enterprise SOC exits its MSSP and runs L1 and L2 investigation on Morpheus across multiple SIEMs.
• European MSSP runs an agentic SOC on Microsoft Sentinel and Defender XDR across dozens of tenants One investigation layer over every tenant’s Sentinel and Defender, with autonomy set per client.
• Two global MDR providers, one agentic SOC platform across every client environment Pre-investigated cases over any client stack, and 1,000-plus tenants after replacing Cortex XSOAR.

Related reading on D3Security.com

• D3 Morpheus for MSSPs
• MSSP AI governance (glossary)
• Governed agentic SOC (glossary)
• Morpheus autonomy modes and guardrails
• NIS2 Directive, explained for SOC teams
• DORA compliance and the SOC
• Autonomous investigation with Attack Path Discovery
• D3 Security customer case studies

D3 Security builds D3 Morpheus, the agentic SOC platform that investigates and responds to security alerts autonomously. Morpheus connects to the SIEM, EDR, XDR, identity and cloud tools an organization already runs, investigates every alert with Attack Path Discovery, and executes response through deterministic playbooks under a human-set autonomy mode. It is used by enterprise SOC teams, MSSPs and MDR providers that need to scale investigation without scaling headcount, and deploys in cloud, on-premises, hybrid, sovereign-region and air-gapped environments.

Customer details in this case study are anonymized at the customer’s request. Figures are the customer’s own, from its evaluation and production records. Request a demo or read the D3 glossary of agentic SOC terms.

Canonical URL: https://d3security.com/resources/mssp-eu-ai-act-agentic-soc/