How do you choose a managed security service provider under NIS2?
NIS2 expects increased diligence when you select a managed security service provider, because recital 86 recognizes that an MSSP is closely integrated into the entity's operations and therefore poses a particular risk. Outsourcing SOC monitoring, incident detection or other cybersecurity risk management does not transfer accountability. The Article 21 measures remain the responsibility of your entity, and the management body that approves and oversees them can be held liable for infringements under Article 20(1). Before you sign, your board should be able to explain why this provider was chosen, what it is allowed to touch and how you will know whether it is performing.
The right depth of diligence depends on your scope, your sector, the tooling you already run and the MSSP's own status. An essential entity under ex ante supervision will be asked to show more than an important entity under ex post supervision, and an MSSP that is itself in scope as a managed security service provider under Implementing Regulation (EU) 2024/2690 brings its own obligations to evidence. Confirm with your national competent authority how it expects outsourced monitoring to appear in your documentation. Also check whether your sector law displaces NIS2 for any part of the service. No NIS2 certificate exists that you can ask a provider to produce. Ask instead for evidence that maps to the Article 21 measures and the implementing regulation's requirements, and for the scope of any independent audit report the provider holds.
Roles should be written down before the contract starts. Your organization owns its controls and decides the risk appetite. The MSSP operates services such as log collection, alert triage and response within the boundaries you set. Only an independent auditor or the national authority assesses compliance, and no vendor, including your provider, can issue a NIS2 attestation. Your DeployOpen-style implementation partner, if you use one, can prepare logging architecture and evidence but does not issue reports. Map each monitoring function to a named owner on both sides so that alarm thresholds, escalation and reporting deadlines have someone accountable at each step.
What increased diligence means in practice
Recital 86 asks entities to take increased diligence when selecting managed security service providers, because their close integration in daily operations creates particular risk. The six checks below turn that expectation into questions you can put to a provider before the contract is signed, and each one ties to a requirement your management body remains accountable for.
Provider's own NIS2 status
Establish whether the provider is itself an essential or important entity under NIS2, since managed security service providers can fall within Annex I (ICT service management) when they meet the size-cap rule. Ask which Member State supervises them, whether they have registered and how they meet Article 21 themselves. A provider that cannot answer these questions clearly is a weak choice for a function you depend on.
Access model and privileged staff
Map every route the provider uses into your environment, including remote sessions, jump hosts and service accounts. Under point 6.7.2(h) of the Implementing Regulation, service provider connections may be allowed only after an authorization request and for a set period, such as the duration of a maintenance operation. Confirm who holds privileged access, how it is vetted, and how each session is approved, recorded and revoked.
Logging and detection coverage
Point 3.2 of the Annex requires procedures and tools to monitor and log activity on network and information systems, with monitoring automated to the extent feasible. Ask which log sources the provider will collect, where they are stored, how long they are kept, and which alarm thresholds trigger a response. Confirm that logs are reviewed regularly for unusual trends and that the response is timely and qualified.
Incident notification path
Your own reporting clock under Article 23 is short: a 24-hour early warning, a 72-hour notification and a one-month final report. The provider must notify you without undue delay, and the contract should define the channel, the named contacts and the information you will receive at each stage. Test this path in an exercise before go-live, because the provider's first report to you may decide whether you meet your deadlines.
Subcontractors and their controls
Ask for a complete list of subcontractors that touch your systems, data or telemetry, including hosting, ticketing and threat intelligence tools. The Annex expects contracts to set subcontracting rules, so confirm whether the provider needs your approval for changes, what security obligations flow down, and how you will learn of a subcontractor failure. Each subcontractor is a link in your supply chain, even when you have no contract with it.
Exit and data return terms
Exit obligations are part of the contract requirements in point 5.1.4 of the Annex. Define how monitoring data, logs, configurations, runbooks and access credentials return to you at the end of the contract, in what format, and within what period. Confirm that the provider removes its access and its copies of your data. Without these terms, a change of provider can leave you without the evidence you need for supervisors.
What the MSSP must meet and what you must verify
A managed security provider often connects into your network to monitor, patch or respond, and that connection is itself a route an attacker could use. The Implementing Regulation's annex on access control allows service provider connections only after an authorization request and only for a set period, such as the duration of a specific maintenance operation. Your job is to decide who approves each connection, how long it stays open, and how you confirm it closed.
- Authorization requests: Ask for a written request per connection that names the purpose, the systems affected, the engineers involved and the planned window.
- Time-limited access: Confirm that access expires automatically or is revoked at the end of the window, not left open for convenience.
- Session records: Request logs showing who connected, when, from where and what they changed.
- Named accounts: Verify that each provider engineer uses an individual account, with no shared administrator credentials.
- Access review: Ask for a periodic list of standing provider accounts and proof that unused ones were removed.
Before signing, check that your own change process can approve and revoke these connections on the timelines the contract sets, and that someone inside your organization owns each approval.
Point 3.2 of the Implementing Regulation annex requires the provider, as a managed security service provider, to run procedures and tools that monitor and log activity on the systems it manages, so that events that could become incidents are detected. Monitoring should be automated to the extent feasible. Point 3.2.4 adds that logs must be reviewed regularly for unusual trends, that alarm thresholds must trigger alarms (automatically where appropriate), and that alarms receive a timely and qualified response. Detection that nobody answers does not meet the requirement.
- Coverage statement: Ask which log sources are collected, which are excluded and why, and how gaps are reported to you.
- Alarm thresholds: Request the documented thresholds and the process for changing them, with your sign-off on any change.
- Response records: Ask for samples of triaged alerts showing the analyst's decision, the time to response and the escalation path.
- Log integrity and retention: Confirm where logs are stored, who can alter them and how long they are kept.
- Regular review evidence: Request the reports or meeting records that show trend reviews took place.
Request a test alert during onboarding and confirm that it reaches a qualified responder within the time you agreed, then ask for the record of that test.
Point 5.1.4 of the annex sets out the terms a contract should include where appropriate. Those terms cover cybersecurity requirements, staff training and background checks, incident notification without undue delay, a right to audit or receive audit reports, vulnerability handling, subcontracting rules and exit obligations. The clauses do not replace your own oversight, but they give you the rights you need to exercise it. Treat each term as something to verify, not just something the contract says.
- Security and staffing: Require the provider's security baseline and evidence of staff training and background checks for people with access to your systems.
- Notification: Set a notification duration in the contract that lets you meet your own reporting deadlines, and ask for a named contact.
- Audit rights: Secure either a right to audit or a current independent report, and confirm which parts of the provider's environment it covers.
- Subcontracting: Require prior notice of subcontractors that touch your data or access, with the same obligations flowing down.
- Exit: Specify return or deletion of data, handover of configurations and logs, and the support period after termination.
Have counsel and your security lead review the clauses together, and ask the provider to show how each one is evidenced in its own operations.
Why accountability stays with your management body
Outsourcing security operations does not move the legal duty. Article 20(1) of NIS2 allows the management bodies of essential and important entities to be held liable for the entity's infringements of Article 21, so the board or equivalent body remains answerable for the risk-management measures even when a managed security service provider runs the monitoring, detection and response. The Article also preserves national liability rules for public institutions, public servants and elected or appointed officials, so public sector buyers should check how their Member State's transposition law applies those rules. This is an explanation of the structure of the duty, not legal advice. Confirm the position with counsel familiar with your national law.
In practice, the management body keeps four jobs that cannot be handed to the provider. It approves the Article 21 measures, including the decision to rely on an external provider for security operations. It decides which functions are outsourced and which stay in-house, and it records the reasons. It oversees the arrangement by reviewing the provider's reports on alerts, incidents, vulnerability handling and service performance, and by asking what those reports show about the entity's own risk. It also completes the cybersecurity training that Article 20 makes mandatory for management body members, so that members can understand and challenge what the provider tells them.
A useful test is whether a board member could explain, after an incident, what the provider was contracted to do, what the entity itself still decides, and which report would have shown a problem earlier. Ask the provider for a written statement of which decisions it makes on your behalf and which it only recommends, and document who in your organization owns each one. Keep a dated record of the management body's approvals and reviews. These records are the evidence a competent authority is most likely to ask for when it asks who was responsible.
How the MSSP selection process runs
The sequence runs from deciding what you hand over to a provider through to the contract and recurring oversight, so that each step produces a record your management body can review and a supervisor can inspect.
Define the outsourced security functions
Your security lead and the business owners list every security operations function you intend to outsource, such as monitoring, vulnerability scanning, incident triage, firewall management or identity administration. For each one, record which Article 21 measures it supports and which functions stay in-house, including decisions on risk acceptance and incident reporting to authorities. The output is a written scope statement, approved by the management body, that marks the boundary of the outsourced service. The step is complete when every function has an owner on each side of that boundary.
Assess the provider's own NIS2 status
Establish whether the candidate is itself a managed security service provider in scope of NIS2 and, if so, how it meets the rules for its own sector. Request its risk management documentation, its incident reporting procedures, its staff vetting approach and any evidence of supervision or independent assessment it holds. Confirm which Member State regulates it. The output is a due diligence file that records the questions asked, the answers given and the gaps you accepted or rejected. Treat any certificate as one input, since it shows what was assessed and not how the provider operates today.
Run the technical and access review
Your technical team reviews how the provider would connect to your environment, including the architecture, the tools it uses, where its analysts work from and how it authenticates. Confirm that remote access is granted only after an authorization request and only for a set period tied to a defined task. Verify that the provider's own administrative accounts are protected and logged. The output is a set of access authorization records that list each connection, its purpose, its approver, its start and end conditions and the logs that will show its use. Ask the provider to demonstrate these controls in a test or walkthrough.
Negotiate the Implementing Regulation clauses
Legal and procurement staff, with your security lead, turn the reviewed requirements into contract terms. The clauses should cover cybersecurity requirements, staff training and background checks, incident notification without undue delay, your right to audit or receive audit reports, vulnerability handling, subcontracting rules and exit obligations, as point 5.1.4 of the Annex to Implementing Regulation 2024/2690 expects where appropriate. Ask counsel to confirm how each clause interacts with your reporting timelines under Article 23. The output is a contract schedule that maps each clause to the requirement it serves and to the evidence you will receive.
Agree the logging and escalation runbook
Your security lead and the provider's service manager write the operational runbook together. It should define what is logged, where logs are stored and who can read them, how alarm thresholds are set and who tunes them, and how alarms reach your staff. Include the qualified response steps and the handover points at which the provider must inform you so you can meet the reporting deadlines. Confirm that monitoring is automated to the extent feasible, as point 3.2 requires. The output is a signed runbook with named contacts, tested escalation paths and a record of the first test.
Set the reassessment cadence
Before the service goes live, the management body approves how often the provider will be reassessed and which triggers prompt an earlier review, such as a significant incident, a change of subcontractor, a change in the provider's own ownership or a material change in the service. Assign owners for collecting audit reports, reviewing log summaries and checking that access authorizations have closed. The output is an oversight plan and a recurring review record that shows what was checked, when, by whom and what was decided. Accountability for these decisions remains with your management body.
Which outsourcing model fits your entity
This table compares three ways to split security operations between your organization and a managed security service provider. Read each row against your own staffing and decision rights, because NIS2 keeps accountability with your management body whichever model you choose. The main takeaway is that log ownership and escalation authority should be settled in writing before the contract starts.
| Question | Fully outsourced SOC | Co-managed monitoring with in-house incident response |
|---|---|---|
| Who keeps log ownership | Provider collects and stores logs, so the contract must give you full ownership, export rights and retention terms | Your organization owns the log platform and retention, while the provider monitors through agreed access |
| Who decides on incident escalation | Provider triages and escalates under a runbook you approve, but you must define who is called for significant incidents | Your in-house team decides escalation and reporting, with the provider handling first-line alerts |
| Who owns NIS2 reporting deadlines | Your management body and incident lead remain accountable, and the provider must notify you without undue delay | Your incident team runs the early warning, notification and final report steps directly |
| Fits organizations that | Have little in-house security staff and accept less direct control over day-to-day alert handling | Have some analysts and want control over evidence, containment decisions and regulator communication |
| Main diligence focus | Provider's own NIS2 status, staff vetting, access controls and where monitoring data is processed | Integration quality, shared runbooks and whether your staff can work the provider's alerts |
| In-house operations with a specialist MSSP for specific tasks | Your team runs monitoring and response, and a specialist supplies testing or threat intelligence on defined tasks | Scope limits are the main risk, so confirm which tasks, data and access the specialist receives |
Questions buyers ask about MSSPs under NIS2
Does outsourcing security operations to an MSSP remove our NIS2 liability?
No. Outsourcing shifts work, not accountability. Recital 86 of NIS2 calls for increased diligence when selecting managed security service providers because their close integration into an entity's operations creates particular risk. Article 20(1) makes management bodies of essential and important entities answerable for infringements of Article 21, and that answer does not change when a provider runs the day-to-day controls. Your management body still approves the risk-management measures, oversees them and receives reporting. Ask any provider to show which obligations it performs under contract and which remain with your own team.
Does an MSSP need its own NIS2 registration or entity status?
It depends on the provider's size and classification, and you should confirm the answer with the national competent authority in the Member State where the provider is established. Under NIS2, managed service providers and managed security service providers are themselves in scope under Annex I (ICT service management) when they meet the size-cap rule. A provider that is in scope has its own obligations as an entity. Ask the provider for its entity classification, the authority that supervises it and how it meets Article 21 and Article 23 duties, rather than assuming its status from its marketing.
What must an MSSP log and how long must it keep those logs?
The minimum logging and monitoring requirements come from Implementing Regulation (EU) 2024/2690, which requires procedures and tools that monitor and log activity on network and information systems to detect events that could become incidents, with monitoring automated where feasible. Logs must be reviewed regularly for unusual trends, and alarm thresholds must trigger an alarm, automatically where appropriate, followed by a timely, qualified response. The regulation does not set a retention period in the facts supplied here, so confirm retention with the implementing rules, your own risk assessment and your contract. Specify in the contract which log sources the provider covers, who can access the logs, and how you receive them during an incident.
Does an MSSP's ISO 27001 certificate or SOC 2 report prove NIS2 compliance?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. A certificate or attestation from a provider can support your assessment of its controls, but it does not show that the provider meets Article 21 requirements for your specific services, scope and risk. Ask for the scope statement, the controls covered, the date of the report and any exceptions, and ask how the provider's evidence maps to the Article 21 measures it performs for you.
How much internal security effort remains after we hire an MSSP?
Less operational work, but the decisions and the reporting remain internal. Your management body still approves the risk-management measures, sets risk appetite, reviews incidents and accepts residual risk. Your team still owns the Article 23 reporting duties toward authorities and service recipients, and must be able to make the early warning and notification deadlines regardless of who detects the event. Plan for internal staff to review provider reports, test escalation paths, manage access approvals and keep supplier records current. Ask the provider which of these tasks it will perform and which will depend on your people.
How does DeployOpen fit into an MSSP decision under NIS2?
DeployOpen is not an MSSP and does not issue audit reports, attestations or certifications. As a Chainscore Labs company, it plans, implements, hardens, documents and supports self-hosted open-source platforms in your own infrastructure, runs security testing and prepares systems, controls and evidence for compliance assessments. Where your organization wants to bring operations in-house on open-source tooling, that work can include logging and monitoring design and the evidence you give your management body and supervisor. Independent auditors and certification bodies remain the only parties who issue reports. Scope, deliverables and timelines are agreed in writing before work starts.
How DeployOpen works on this
DeployOpen helps NIS2 entities test whether a managed security provider can meet the diligence, logging and access expectations that apply when security operations are outsourced. We prepare the evidence and the self-hosted tooling your team needs to check the provider's claims, while the management body keeps the decision and accountability.
How we scope
- Agree in writing which managed security services, systems and log sources fall inside the engagement before work starts.
- Map the provider's proposed monitoring, remote access and incident escalation paths to the entity's own Article 21 measures.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing; ongoing support is available as a retainer.
How we build
- Deploy self-hosted logging and monitoring in your own infrastructure so you hold the log copies the provider's activity depends on.
- Configure time-limited, authorized remote access paths for provider connections, with session recording and documented approval steps.
- Set up alarm thresholds and review workflows so provider responses to unusual log trends can be shown to a supervisor.
How we hand over
- Document the provider diligence file, including questionnaire responses, contract clause gaps and evidence requests you still need to send.
- Test the escalation path with a tabletop exercise so both your team and the provider know who notifies whom and when.
- Deliver configuration records, runbooks and evidence catalogs that your team can maintain after the engagement closes.
How we support
- Offer a retainer for periodic re-review of provider performance, access logs and alarm handling as the service evolves.
- Retest provider-facing connections and monitoring controls after changes to the provider, scope or your own systems.
- Confirm with your independent assessor or certification body which evidence they expect; DeployOpen prepares evidence but does not issue reports or certificates.
Sources and further reading
- Commission Implementing Regulation (EU) 2024/2690, EUR-Lex ↗
- NIS2 Article 6 Definitions, EUR-Lex ↗
- NIS2 Article 21 Cybersecurity risk-management measures, EUR-Lex ↗
- NIS2 Article 20 Governance, EUR-Lex ↗
- NIS2 Technical Implementation Guidance (June 2025), ENISA ↗
- NIS2 Directive: securing network and information systems, European Commission ↗
