What is an MSSP? Services, MDR and how to choose one

An MSSP (managed security service provider) is a company that runs security work on your behalf: log monitoring, alert triage, incident response, and sometimes firewall and endpoint management. To choose one, look past the price first: what happens when an alert fires at night, how fast they tell you, what stays yours (data, rules, access) and how you leave at the end of the contract.

This guide is for IT managers, CISOs and compliance leads in European mid-market organisations who are picking a first MSSP or renewing a contract. It covers what the term means, what an MSSP usually includes, how it differs from MDR and from an in-house SOC, the questions that separate offers, and what NIS2 and DORA say about the contract.

What is an MSSP?

EU law has a definition. Directive (EU) 2022/2555 (NIS2) defines a managed security service provider as "a managed service provider that carries out or provides assistance for activities relating to cybersecurity risk management" (Article 6, point 40). A managed service provider, in turn, installs, manages, operates or maintains ICT products, networks and systems, either on the customer's premises or remotely (Article 6, point 39).

The definition is broad on purpose. The same label covers a firm that administers your firewalls and antivirus, a provider that runs a 24/7 Security Operations Centre (SOC), and a managed detection and response (MDR) service. Two offers that both carry the MSSP label can be two different purchases.

MSSPs are also regulated entities in their own right. NIS2 lists them in Annex I, sector 9, ICT service management (business-to-business), and the directive applies to those that are at least medium-sized (Article 2(1)). Commission Implementing Regulation (EU) 2024/2690 then sets out the technical and methodological requirements of the NIS2 risk-management measures for this group, alongside cloud and data centre providers (Article 1).

What an MSSP usually includes

Offers vary, but most combine some of these services:

• Security monitoring: collecting logs from endpoints, servers, cloud accounts, identity and network into a SIEM, and watching for suspicious activity.
• Alert triage and investigation: an analyst decides whether an alert is real, how serious it is, and what it touched.
• Incident response: containment steps such as isolating a machine or disabling an account, then support through recovery.
• Device and platform management: firewalls, EDR, email security, configuration and patching of security tools.
• Vulnerability management and testing: scanning, prioritisation and, in some offers, penetration testing.
• Reporting: monthly or quarterly reports on alerts, incidents and coverage.

Recital 86 of NIS2 names incident response, penetration testing, security audits and consultancy as areas where these providers play an important role. The same recital notes that MSSPs have themselves been targets of cyberattacks and, because they are closely integrated into their customers' operations, pose a particular risk. Its conclusion is that essential and important entities "should therefore exercise increased diligence in selecting a managed security service provider".

MSSP vs MDR vs in-house SOC

MSSP: the type of provider

MSSP describes who you buy from, not exactly what you buy. Some MSSPs stop at device management and alert forwarding. Others run a full SOC with investigation and response. Read the service description, not the label.

MDR: a service centred on detection and response

Managed detection and response is a service an MSSP (or a specialist) can deliver. Its focus is narrower and deeper: continuous monitoring, investigation of alerts by analysts, threat hunting and authorised response actions. The practical difference is the last step. A pure monitoring service tells you something is wrong. An MDR service is expected to act on it within limits you agree in advance.

In-house SOC: you own people, platform and shifts

An internal SOC gives you full control and deep knowledge of your environment. It also means hiring and keeping analysts, buying and running a SIEM, writing detection rules and covering nights, weekends and holidays. For many mid-market organisations the cost of round-the-clock cover is what tips the decision towards a managed service. A hybrid model is common: an internal team owns the context and the decisions, a provider covers monitoring and the night shift.

If the platform choice is still open, our guide to SIEM tools lists the criteria that matter whether you run the SIEM yourself or a provider runs it for you.

Before you talk to providers: three answers

1. Scope. Which systems are in: endpoints, servers, cloud, email and collaboration, network, identity.
2. Level of intervention. Is an alert enough, or do you want someone to isolate a machine or block an account at 3 a.m.? This choice weighs most on the contract and on the fee.
3. Regulatory constraints. If you are in scope of NIS2 or you are a financial entity under DORA, the contract with the MSSP has specific requirements. They are covered below.

Questions to ask an MSSP

About the service

• What happens when an alert fires at 3 a.m.? Who sees it, within how long, who decides, who calls you. Analysts on shift through the night and an on-call engineer are two different services.
• What can you do without asking me? Isolating an endpoint, disabling a user, blocking an address. Authorised response actions are written down before an incident, not negotiated during one.
• Which log sources do you collect, and which not? A service that only reads the antivirus will not see an unusual sign-in to a cloud account.
• How do you manage detection rules? Who writes them, how often they are updated, whether they are mapped to a reference such as MITRE ATT&CK, and whether you can ask for rules specific to your environment.
• How do you reduce false positives? A service that forwards every alert moves the work back to your team.

About people

• Where do the analysts work, in which language and time zone do you communicate, and is there a named contact who knows your environment?
• What is the escalation path, with names and numbers, for a serious incident?

About technology and data

• Is the platform yours or theirs? If the SIEM belongs to the provider, ask what you keep at the end: logs, rules, cases, reports.
• Where is the data processed and stored, for how long, and in what format can you export it?
• Who accesses your systems, with which accounts and which authentication? The provider's access is also a route into your network.

About the provider's own compliance

• Is the provider itself in scope of NIS2?
• Does it hold ISO/IEC 27001 certification? Ask for the certificate and read the scope: it should cover the service you are buying, not just an office.
• How will it help you meet your own incident reporting timeframes?

What NIS2 and DORA ask of the contract

NIS2: supply chain security and incident reporting

For essential and important entities, supply chain security, including the relationships with direct suppliers and service providers, is one of the minimum cybersecurity risk-management measures (NIS2, Article 21(2)(d)). When deciding which measures are appropriate, entities take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of their cybersecurity practices (Article 21(3)). An MSSP that reads your logs and holds privileged access is close to the top of that list.

Outsourcing security does not move the reporting obligation. Under Article 23(1), it is the essential or important entity that notifies its CSIRT or competent authority of a significant incident. The timeframes run from when you become aware of it: an early warning within 24 hours, an incident notification within 72 hours, and a final report no later than one month after the notification (Article 23(4)). The contract should therefore fix how quickly and through which channel the provider alerts you, and which information it hands over for the notifications. National transposition laws add the details, such as the competent authority, so check the rules of your Member State. Our NIS2 service page covers the wider programme.

DORA: minimum contractual provisions

For financial entities, Regulation (EU) 2022/2554 (DORA) lists the key contractual provisions for ICT services in Article 30. Among them:

• a clear description of the services, and whether subcontracting of a service supporting a critical or important function is permitted, and on what conditions (Article 30(2)(a));
• the regions or countries where services are provided and data is processed and stored, with advance notice if the provider plans to change them (Article 30(2)(b));
• for critical or important functions, full service level descriptions with "precise quantitative and qualitative performance targets" (Article 30(3)(a));
• rights of access, inspection and audit for the financial entity or an appointed third party (Article 30(3)(e));
• exit strategies, including a mandatory adequate transition period during which the provider keeps delivering the service (Article 30(3)(f)).

More on the wider framework is on our DORA service page.

GDPR: the processor contract

Logs contain personal data, starting with usernames and email addresses, so the MSSP processes them on your behalf. Article 28(3) of the GDPR (Regulation (EU) 2016/679) requires a contract with the processor that covers, among other things, the conditions for engaging another processor and the deletion or return of the data at the end of the service.

Outside NIS2 and DORA, these provisions still make a ready-made checklist for any MSSP contract.

Red flags

• The service only shows up in the monthly report. If nobody shows you a real alert during the sales process, the report is probably all you will see.
• No questions about your environment. A quote that arrives without asking about scope, log sources and who decides during an incident is a price list, not a service.
• SLAs only on platform availability. A console that is always up says nothing about how fast someone looks at an alert.
• Nights and weekends covered on call, with no written times.
• Data and rules that cannot be exported, or vague answers on where the data lives.
• Resistance to audit or exit clauses. A provider that works well has no reason to avoid them.
• Absolute promises: zero false positives, no incidents, guaranteed compliance. Reporting and risk-management measures stay your obligations, and no contract transfers them.

What drives the cost

There is no standard price list, because offers differ in what they include. The factors that move the fee are the number and type of log sources, the daily data volume, the hours of live cover, the level of response the provider is authorised to take, the retention period, and whether the platform licence is included or yours.

To compare offers, give every provider the same scope and the same level of intervention. Then ask each one to walk you through a scenario, for example an administrator's credentials used from an unusual country at 2 a.m. on a Sunday: what they see, what they do and what reaches you, with times. Ask for a sample report and an anonymised incident notice, and speak to a customer of similar size and sector.

In short

An MSSP is chosen on what it does when an alert fires, how fast it tells you and what it leaves you when the relationship ends. If you are in scope of NIS2 or DORA, the contract has concrete requirements: timely alerting, measurable service levels, subcontracting rules, audit rights and an exit plan. Compare fees only after that, on the same scope.

AmagisTech is a Google Cloud partner and runs a managed SOC and MDR service on Google Security Operations, with Mandiant threat intelligence and detection rules written for your environment. You can see how the service works on our observability and SecOps page, or talk to our team about your scope.