Does NIS2 for managed service providers apply to my MSP or MSSP business?
NIS2 defines managed service providers and managed security service providers and lists them in Annex I under ICT service management (business-to-business), so an MSP or MSSP serving other businesses is in scope. Annex I entities that exceed the medium-sized enterprise ceilings are essential entities, while smaller in-scope Annex I entities are generally important unless another Article 3(1) category makes them essential. The definitions in Article 6 turn on what you do, not on how you describe yourself: services covering installation, management, operation or maintenance of ICT systems, delivered on customers' premises or remotely, fall within the definition, and an MSSP is an MSP that carries out or assists with cybersecurity risk management. If a customer or regulator has asked about your status, start by mapping each service line against those two definitions and recording your headcount, turnover and balance sheet totals against the size ceilings.
Your actual obligations depend on more than the headline category. Size, service mix, the customers you serve (some of which may themselves be essential entities), and the Member State where you have your main establishment all affect which national authority supervises you and how that supervision runs. Confirm the transposition law in each Member State where you provide services, and confirm with counsel which one applies to your main establishment. Under the Implementing Regulation, cloud, managed and managed security service providers are also covered by EU-level technical requirements and incident criteria, so the depth of work differs from a general IT services firm. You own your controls and decide how to run them. An independent auditor or assessor may test them and issue any report, and DeployOpen prepares systems and evidence but does not issue reports or certificates. NIS2 creates no certificate of compliance, so a customer asking for proof should receive evidence of your controls and a clear statement of scope, not a NIS2 certificate. Treat any vendor or consultant who offers one with caution. The Commission's January 2026 proposal (COM(2026) 13) would amend NIS2, including a new small mid-cap category, but it still needs approval by the European Parliament and the Council, so plan against the directive as adopted and monitor the proposal for changes that could alter your category.
Essential or important: which status fits an MSP or MSSP
An MSP or MSSP that is an Annex I entity and exceeds the medium-sized enterprise ceilings is treated as an essential entity under Article 3(1)(a) of NIS2. Annex I covers ICT service management (business-to-business), which includes managed service providers and managed security service providers. Essential status means the national competent authority supervises the entity ex ante, before any failure, rather than only after an incident or evidence of non-compliance. Ex ante supervision is the more demanding regime, and the entity should expect inspections, information requests and security scans to be part of normal oversight. The same Article 21 risk-management duties and Article 23 reporting duties apply, but the supervisory posture is stricter.
- Status basis: Annex I ICT service management plus size above the medium-sized ceilings.
- Supervision: Ex ante under Article 32, with inspections and security audits available before any incident.
- Penalties: Maximum administrative fines under Article 34 apply to essential entities at the higher level.
- Governance: Management body approval and oversight of the Article 21 measures under Article 20 applies in full.
- Size measurement: Headcount, turnover and balance sheet are tested against the Commission recommendation or the national transposition law.
Confirm the headcount and financial figures used in the size test, and check whether the national law applies any additional threshold.
An MSP that is an Annex I entity but stays within the medium-sized enterprise ceilings is generally an important entity under Article 3, unless another Article 3(1) category makes it essential. Important entities face the same Article 21 risk-management measures and Article 23 reporting obligations as essential entities. The difference is supervision: important entities are supervised ex post under Article 33, which means authorities act mainly once they have evidence of non-compliance. Smaller providers should not read this as a lighter security obligation. Customers will still ask for the same evidence, and an incident can trigger the same reporting clock.
- Status basis: Annex I ICT service management with size at or below the medium-sized ceilings.
- Supervision: Ex post under Article 33, triggered by evidence, incidents or complaints.
- Reporting: The Article 23 early warning, notification and final report still apply to significant incidents.
- Customer expectations: Buyers may still require the same contractual security terms as essential providers.
- Other categories: Check whether a different Article 3(1) category, such as a national designation, changes the status.
Confirm the size position with the national competent authority or legal counsel, because a growth event can move the entity into the essential category.
A managed security service provider is defined as a managed service provider that carries out or provides assistance for activities relating to cybersecurity risk management under Article 6(40). An MSSP that performs monitoring, vulnerability management or incident handling for customers falls within this definition, whatever its size. Recital 86 notes that close integration in an entity's operations creates a particular risk, which is why MSSPs attract increased scrutiny from customers and authorities. The status question is still answered by size, so an MSSP above the ceilings is essential and one below is generally important. The security role raises the stakes for supervision and for the EU-level requirements in Implementing Regulation (EU) 2024/2690.
- Definition: Article 6(40) turns on whether the provider carries out or assists cybersecurity risk management.
- Status: Size still decides essential or important status under Article 3.
- Implementing regulation: Managed and managed security service providers are covered by the EU-level technical requirements in Regulation 2024/2690.
- Incident thresholds: Significant incident criteria in the implementing regulation apply to managed services.
- Customer scrutiny: Recital 86 calls for increased diligence in selecting these providers.
Confirm whether each service line counts as cybersecurity risk management, since mixed portfolios may fall partly inside and partly outside the definition.
A group that provides managed services from entities in more than one Member State must determine where each entity is established for NIS2 purposes. Under Article 26(1)(b), managed service providers and managed security service providers fall under the Member State of their main establishment in the Union. Status is then assessed against the rules of that Member State, and the national transposition law may differ in how it applies size tests and designations. Entities outside the main establishment may still have obligations or relationships with other authorities, so the group needs a clear map of which entity sits under which regime. Registration information was due to be submitted by 17 January 2025 under Article 27(2).
- Jurisdiction: The main establishment in the Union determines the competent Member State under Article 26(1)(b).
- Consistency: Status for each legal entity should be recorded with its size data and national basis.
- Registration: Registration information under Article 27(2) must match the status chosen.
- Divergent laws: National transposition details can differ, so one group-wide rule is not enough.
- Intra-group services: Check whether services between group entities create separate provider obligations.
Confirm the main establishment decision and the status of each entity with the relevant national competent authority or legal counsel before finalizing the group position.
When an MSP outage becomes a significant incident
For a managed service provider or managed security service provider, an outage becomes a significant incident under Implementing Regulation (EU) 2024/2690 when a service is completely unavailable for more than 30 minutes, or limited for more than 5% or more than 1 million of its EU users, whichever is smaller, for over one hour. These criteria sit in Articles 7, 9 and 10 of the regulation. The test is applied to the service, not to a single customer's environment, so an MSP should measure outages against its whole service footprint and record the timestamps needed to prove each threshold was or was not crossed.
Consider an illustrative example. A remote monitoring and patching platform serves several hundred customers across the EU, and its management console goes down for 45 minutes. Each customer sees only a partial impact, so no single customer may feel it is significant. Yet the MSP must add up the users affected across its customer base. If the number of affected EU users exceeds the lower of the two limits and the limited impact lasts over an hour, the incident is significant even though no individual customer crossed a threshold. The same arithmetic applies to a managed security service that stops collecting logs for some clients while others remain fully served. Both the duration and the user count need to be reconstructed from the service's own telemetry, which is why monitoring and status records should be kept in a form that can be audited later.
Once an outage is significant, the reporting duties of Article 23 of NIS2 apply, including the early warning, notification and final report timelines. Because a managed provider often must notify its own supervisor and also inform affected service recipients, the MSP should confirm with its national competent authority which reporting portal, format and contact points it must use, and whether the national transposition law adds requirements. Those answers should be written into the incident response plan before an outage occurs, not worked out during one.
What Implementing Regulation 2024/2690 asks of MSPs and MSSPs
Implementing Regulation (EU) 2024/2690 sets the technical and methodological requirements for the Article 21(2) measures that managed and managed security service providers must meet. The six areas below group those requirements by the work an MSP or MSSP does for its customers, and each card names the evidence a supervisor is likely to ask for. Confirm every detailed requirement against the Annex to the regulation itself.
Governance and risk assessment
The provider needs a documented risk assessment that covers its own managed services, the customer environments it administers, and the tools it uses to do so. Management must approve the policies that follow from it. Expect a supervisor to ask for the current risk register, the scope of each assessment, the dates of review, and records showing that management reviewed and accepted residual risk. Check that the assessment treats remote administration paths as in scope, not only the provider's office network.
Access and identity controls
An MSP or MSSP holds privileged access to systems it does not own, so its own administrator accounts are a primary target. Controls to verify include multi-factor authentication for all administrative access, separate accounts for customer work and internal work, least-privilege roles, and prompt removal of access when staff or customers change. Evidence usually includes access review records, privileged account inventories, and logs of administrative sessions into customer tenants.
Monitoring and incident handling
The provider must detect incidents affecting its own systems and its customers' environments, assess whether they are significant, and report them in line with Article 23. Supervisors look for log collection with defined retention, alert triage procedures, documented escalation to customers, and records of past incidents and how they were handled. Ask whether the provider's detection covers the managed platforms themselves, not only the endpoints it watches for customers.
Business continuity and backups
The provider must be able to keep its managed services running, or restore them, after a disruption. That covers tested backups of its management platforms and configuration, documented recovery procedures, and defined recovery priorities for customer services. Evidence commonly includes restore test records, backup location and access controls, and continuity plans that name the people and tools needed. Confirm whether backups are held outside the failure domain of the systems they protect.
Supply chain and vendor control
MSPs and MSSPs depend on their own suppliers, including software vendors, hosting providers and subcontractors who can reach customer systems. Recital 86 of NIS2 highlights the particular risk of close integration with managed security providers, so supervisors expect the provider to assess these suppliers, contract for security obligations, and monitor them. Evidence includes supplier registers, due diligence records, contract clauses on incident notice and access, and review dates.
Secure configuration and vulnerability handling
The provider must keep the systems it manages in a hardened, documented state and fix known vulnerabilities within defined timeframes. Typical checks cover baseline configurations for each platform, change records for customer-facing components, patch and vulnerability scan results, and a process for coordinated disclosure of issues found in its own tools. Ask for the configuration baseline and the most recent scan report, and confirm how exceptions are approved and tracked.
Which country supervises an MSP that serves customers across the EU
For NIS2 purposes, a managed service provider or managed security service provider is supervised by the Member State where it has its main establishment in the Union. Under Article 26(1)(b), that rule applies to managed and managed security service providers even when they serve customers in many countries. An MSP with offices in several Member States therefore does not face parallel NIS2 supervision in each of them. The first task is to decide, with your legal counsel, which establishment is the main one under the Article 26 test, and to record the reasoning so it can be shown to an authority if asked.
Article 27(2) requires Member States to collect registration information from managed and managed security service providers, and the deadline they had to set was 17 January 2025. Confirm that your organization is registered with the authority named in the national transposition law of the Member State you have identified as your main establishment, and keep the submission and any acknowledgment on file. Registration details can change as your services, addresses or contacts change, so assign an owner to update them. The NIS2 Directive page on the European Commission website is a useful starting point for confirming which national rules apply.
Groups that operate in several Member States should map where security decisions are actually made. Supervisors look at where the management body approves risk-management measures, where the security operations and incident response functions sit, and which entity signs customer contracts. If a parent company in one country sets policy while subsidiaries in others run the services, the record should show how that structure fits the main establishment analysis. Ask your customers which supervisor they expect to see named in their supplier files, since many will ask for this when they assess you under the supplier requirements in their own NIS2 programs.
How an MSP prepares for customer and supervisor scrutiny
This sequence takes a managed service provider from confirming its NIS2 status to holding an evidence pack that customers and national supervisors can test. Each step ends with a named output the provider can show.
Confirm status and supervising authority
Start by confirming whether the organization is an Annex I managed or managed security service provider, whether it exceeds the medium-sized enterprise ceilings (which makes it essential), and which Member State holds jurisdiction as its main establishment in the Union. Legal counsel or the national competent authority's guidance should confirm the classification, because the Member State rules and the national transposition law decide the practical supervision route. The output is a short written classification memo that names the entity category, the supervising authority and the reasoning behind both. Confirm the status again whenever the service catalog or group structure changes.
Map Article 21(2) measures to the implementing regulation
Build a matrix that lists each of the ten Article 21(2) measures and the matching requirements in Implementing Regulation (EU) 2024/2690 for managed and managed security service providers. Read ENISA's June 2025 technical implementation guidance alongside the Annex, since it gives examples of evidence for each requirement. Assign an owner to each row, usually a named role inside the provider. The output is a traceability matrix that links every requirement to a policy, a control and a place where evidence lives.
Inventory existing controls against the matrix
Walk each row of the matrix against the controls the provider already operates, including controls run for customers under managed contracts. Record where a control exists, where it exists only in a document, and where nothing exists. Include the provider's own internal systems, such as its remote management tooling, ticketing platform, identity provider and jump hosts, because supervisors and customers will test those as well. The output is a current-state register with a status for every requirement.
Identify and rank gaps
Turn each gap in the register into a remediation item with an owner, a risk rating and a dependency list. Rank items by their effect on customers, because managed providers hold privileged access to client environments and gaps in that access path carry the most weight in a supervisor's view. Recital 86 of NIS2 notes that close integration with customer operations creates particular risk, so treat privileged access and remote administration as priority areas. The output is a signed remediation plan that management has reviewed.
Assemble evidence for each control
Collect the artifacts that show each control operates in practice. Typical items include approved policies, configuration baselines, change records, access reviews for privileged and customer-facing accounts, monitoring and alert logs, vulnerability scan results and tested incident procedures. Store each artifact with a date, an owner and a link to the matrix row it supports. Check that logs cover the period the provider claims and that access reviews show who approved each change. The output is an indexed evidence repository that an assessor can navigate without help from the provider's staff.
Test the incident and significant incident process
Confirm that the provider can identify a significant incident under the thresholds in Implementing Regulation (EU) 2024/2690 and send the Article 23 notifications in the required sequence, including the 24-hour early warning, the 72-hour notification and the one-month final report. Run a tabletop exercise that walks through a realistic scenario in which a customer environment is affected, and record who decided, who notified and what the customer was told. The output is an exercise report with gaps logged and fixed. Treat the provider's own customer notification duties as part of the same test.
Confirm registration and jurisdiction records
Check that the provider has submitted its registration information to the competent authority of its Member State of main establishment, as required by Article 27 of NIS2 for managed and managed security service providers. Confirm that the details still match the current legal entity, the services offered and the contact points. Record any change in services or group structure that requires an update. The output is a registration confirmation on file with the date of submission and a process for keeping it current.
Prepare the customer evidence pack
Package the matrix, the summary of controls, selected evidence, the incident process, the registration confirmation and the remediation status into a pack that customers can review under their own supplier due diligence. Keep client-specific details out of the general pack, and provide a clear statement of responsibilities that separates what the provider runs from what the customer must still own. Ask an independent assessor or the provider's counsel to review the pack before release, since only an independent auditor or certification body issues reports or certificates. The output is a versioned evidence pack with a change log and a named contact who answers follow-up questions.
What customers will ask an MSP or MSSP to prove
Customers now send due diligence questionnaires before they sign or renew a managed service. Recital 86 of NIS2 asks entities to take extra care when selecting managed security service providers, because those providers are closely integrated into day-to-day operations. The cards below cover the questions that come up most often and what your evidence should show for each.
Proof of NIS2 status and registration
Customers will first ask whether you are an essential or important entity, which Member State has jurisdiction over you, and whether you have registered. Under Article 27, providers of managed and managed security services must submit registration information, so ask your national competent authority or legal adviser to confirm your main establishment and the registration status you should state. Keep a dated record of the registration confirmation so you can produce it on request.
Evidence mapped to Article 21
Customers want a control-by-control view of how your own service is protected against the ten minimum measures in Article 21(2), with the additional technical detail in Implementing Regulation (EU) 2024/2690 for managed service providers. Build a single matrix that names each measure, the owner, the control in place and the evidence file. ENISA's June 2025 guidance gives examples of evidence you can align to, so confirm with customers which framework mapping they accept.
Incident notification commitments and timing
Customers will ask how quickly you notify them of an incident affecting their environment and what you will tell them. A significant incident for managed service providers is defined in Implementing Regulation (EU) 2024/2690, and the Article 23 reporting clock applies to your own reporting duties. Write notification commitments into the contract with named contacts, an escalation path, and the information you will supply in each update so the customer can meet its own deadlines.
Subcontractor and cloud dependencies
Customers will want a list of the subprocessors, subcontractors and cloud platforms your service depends on, along with where they run and how you assess them. A managed provider that relies on a hosting or tooling supplier passes that supplier's risk into the customer's environment. Maintain a current register, review each supplier's own assurance evidence, and tell customers how changes to the list are communicated before they take effect.
Administrator access controls for customer environments
Because managed providers act with administrative rights inside customer systems, customers will ask how those rights are granted, reviewed and recorded. Expect questions on named individual accounts, privileged access workflows, session logging, time-limited elevation, and how quickly access is removed when staff leave. Be ready to show access review records and a sample of privileged session logs, with retention periods agreed in writing.
Independent assurance and what customers accept
Customers will ask what independent evidence supports your claims, such as an audit report, a certification or a third-party penetration test. NIS2 creates no certificate of compliance, so no single document settles the question. Only an independent auditor or certification body can issue a report or certificate, and your implementation partner can prepare evidence for one. Ask each key customer which assurance evidence they will accept before you commit to a format.
Who owns the controls, who prepares the evidence and who issues assurance
The provider's management body and internal security team remain accountable for NIS2 compliance. Under the governance duties in Article 20, the management body must approve and oversee the Article 21 risk-management measures, and it can be held liable for infringements. For an MSP or MSSP, this group also decides how managed services are delivered to customers, which incidents are significant, and when reports go to the national authority and to affected service recipients.
- Approval of the Article 21 measures: The management body reviews and signs off the risk-management measures that apply to the provider's own operations, including its management tooling and privileged access to customer environments.
- Ownership of controls: Named internal owners run access control, logging, vulnerability handling and backups, and they answer for the results in audits and supervisory inquiries.
- Incident reporting decisions: Internal staff classify incidents against the significant incident criteria in Implementing Regulation (EU) 2024/2690 and own the 24-hour, 72-hour and one-month reporting clock.
- Management training: Board members and senior managers complete the cybersecurity training that Article 20 requires.
- Supplier oversight: The team keeps control of the vendors it depends on, including any partner.
Confirm that your management body has written minutes showing approval and review of these measures, and that each control has a named internal owner.
An implementation partner such as DeployOpen works inside the provider's environment to plan, build, harden and document the systems that the controls depend on. Its work product is prepared systems, configuration records, test results and evidence packs. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in the client's own infrastructure, and it runs security testing of applications, APIs, cloud and infrastructure. It does not issue audit reports, attestations or certifications, and hiring a partner does not guarantee a supervisory outcome.
- Build and hardening: The partner configures logging, identity, backup and monitoring platforms, then documents the settings and the reasons for them.
- Evidence preparation: The partner assembles the records an assessor or supervisor will ask for, such as configuration exports, test reports and change history.
- Security testing: Application, cloud and infrastructure testing produces findings that the internal team must triage and close.
- Documentation handover: Runbooks and architecture records are delivered so that the provider can operate the platforms after the engagement.
- Written scope: Scope, deliverables and timelines are agreed in writing before work starts, and the internal team keeps decision rights over the outcome.
Check that the partner's statement of work states that it prepares evidence and does not attest to compliance.
Independent auditors, assessors and certification bodies test controls and issue any report or certificate that a customer may request. NIS2 creates no certificate of compliance. Instead, national competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines under Articles 32 to 34. Essential entities face ex ante supervision and important entities face ex post supervision, so the timing of scrutiny depends on the provider's classification.
- Testing and opinion: An independent party tests the controls against the evidence and states its conclusion in its own report.
- Certification bodies: Where a customer asks for a certificate under another scheme, such as ISO/IEC 27001, only an accredited certification body issues it.
- Supervisory action: The national authority decides whether to inspect, request information or impose measures, and it may require an external audit.
- Registration: Providers register with the authority of their main establishment, which is a regulatory step rather than an assurance outcome.
- Independence: The assessor must not be the party that built or prepared the controls it tests.
Ask any assessor to confirm its independence and the exact scope and report type it will issue before the engagement begins.
How to choose a NIS2 consultant or implementation partner for an MSP
An MSP or MSSP that buys outside help for NIS2 should test the partner on the same points a supervisor will test the provider on. The cards below cover the legal basis, the handling of the MSP's own controls and customer data, the independence of any assessment, the handover, and the written scope that governs the work.
Confirm the Annex I point 9 scope
Ask the partner to explain why ICT service management for business customers places managed service providers and managed security service providers in Annex I, and what that means for your entity classification. A partner who cannot describe the Article 6 definitions, or who treats your services as generic IT support, is not ready for NIS2 work. Ask how they map your services to the implementing regulation's requirements for managed services and managed security services, and which of them they will verify in your environment.
Keep your controls and customer data in place
Ask where the partner's work will run, which accounts and networks they will access, and whether any customer data will leave your environment. Your own controls over administrative access, logging and management systems must stay under your ownership, even when a partner prepares or tests them. Recital 86 flags the close integration of managed security providers into customer operations as a particular risk, so ask for a written access model, named accounts, and a method to revoke that access at the end of the engagement.
Check multi-tenant operating experience
An MSP often runs shared platforms for many customers, so the partner must separate tenants in the design and in the evidence. Ask how they have handled tenant isolation, per-customer logging, and access reviews across shared administration tools. Ask them to show how one customer's evidence can be produced without exposing another customer's data. Request a sample of the customer-facing artifacts they would produce, such as a control summary or an incident timeline, and check that they are scoped to a single tenant.
Separate preparation from assessment
Preparing systems and evidence is different from issuing an assessment result. DeployOpen prepares systems, controls and evidence for compliance assessments, and it does not issue audit reports or certifications. Ask whether any person or firm that configures your controls will also judge them, and who holds the independent review. Where a supervisor or an external assessor is involved, make sure the partner's role is written down and that independent testers do not report to the team that did the work.
Define the handover and its format
Ask what the partner delivers at the end: configuration records, runbooks, policy documents, evidence packs, test reports, and the source code or infrastructure definitions needed to reproduce the setup. Confirm the formats (for example, editable documents, version-controlled configuration files, and exported logs) and who will own them. Ask how the handover supports the Article 23 reporting process and the evidence a national authority may request, so that your team can operate and defend the controls without the partner present.
Fix scope and timeline in writing
Ask for scope, deliverables, acceptance criteria and timeline in a written agreement before any work begins. DeployOpen works on fixed-scope engagements agreed in writing and does not publish a price list, so a quote follows from that written scope. Ask every candidate to itemize what is one-time work, such as design and hardening, and what recurs, such as monitoring, upgrades and retesting. Compare quotes on the same scope rather than on headline figures.
Questions MSPs and MSSPs ask about NIS2
Is every managed service provider automatically essential under NIS2?
No. Under Article 3(1)(a), an Annex I entity is essential when it exceeds the ceilings for medium-sized enterprises. An MSP or MSSP that is larger than that threshold is essential, and an MSP below it is generally important unless another Article 3(1) category makes it essential. Your status depends on your headcount, turnover and balance sheet measured against the EU recommendation on enterprise size, so confirm the figures with your national competent authority or a qualified adviser before you classify yourself. The classification matters because essential entities face ex ante supervision, while important entities face ex post supervision.
Is a small managed service provider in scope of NIS2 at all?
It can be. The size cap does not remove an MSP from NIS2 by itself. ICT service management for business customers is an Annex I sector, and managed service providers and managed security service providers are named within it. A small MSP that falls within the scope rules and is established in an EU Member State therefore needs to check whether its national law applies to it, and it can be important rather than essential. Ask your national authority how its transposition law treats small providers, because national rules can differ in detail.
Does being a managed security service provider change my NIS2 duties?
Yes, it raises the stakes. NIS2 defines a managed security service provider as an MSP that carries out or assists with cybersecurity risk management. Recital 86 notes that close integration with customers' operations poses a particular risk, which is why customers are expected to apply increased diligence when selecting MSSPs. Your Article 21 measures, incident handling and supplier controls will be examined closely, and Implementing Regulation (EU) 2024/2690 sets EU-level technical requirements for managed and managed security service providers. Expect customers to ask for evidence that your own controls are sound before they rely on you.
How long does NIS2 preparation take for an MSP?
No reliable duration can be given without a written scope, because it depends on your service catalog, customer base, existing ISO/IEC 27001 or similar controls, and how much evidence is missing. Ask any consultant or implementation partner for a written plan that lists the workstreams, the deliverables for each, the dependencies on your staff, and the milestones you can check. A fixed-scope plan lets you compare offers on the same basis. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and provides a quote from that scope.
What does NIS2 preparation require from our internal staff?
Preparation needs named owners inside your organization, even if outside specialists do the technical work. Management must approve the Article 21 measures and oversee them, and the people who run your platforms must provide configuration details, access records, logs and change histories. Your service desk and engineers will need to follow the incident process so that the reporting deadlines can be met. Plan for time from your architects, operations leads and legal or compliance staff, and confirm that time commitment in the written scope before work begins.
Can our team prepare for NIS2 without an outside partner?
Yes, some organizations do, provided they have the skills and capacity. The work covers risk management, policies, technical controls, supplier assessment, incident reporting and evidence collection, and an assessor will expect the evidence to be consistent across all of them. Internal teams often underestimate the documentation and testing effort. You can use ENISA's non-binding technical implementation guidance, published on 26 June 2025, as a reference for evidence. An outside partner can prepare systems and evidence, but the organization keeps ownership of its controls and decisions.
Does the 2026 Commission proposal with a small mid-cap category change our status?
Not yet. On 20 January 2026 the Commission proposed targeted amendments to NIS2 (COM(2026) 13), including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council, so current obligations and classifications remain those of the Directive and your national transposition law. Track the proposal's progress and review your classification once its text is final. Do not restructure your compliance program around the proposal alone, because it may change before adoption.
How DeployOpen works on this
DeployOpen helps managed service providers and MSSPs prepare the systems, controls and evidence that NIS2 expects, inside their own infrastructure. We scope the work in writing first, build and test the platforms that produce the evidence, and document everything for the organization's own owners and independent assessors.
How we scope
- The written scope names which service lines, customer environments and EU establishments the NIS2 work covers.
- We confirm which Article 21 measures and Implementing Regulation 2024/2690 requirements apply to your managed and security services.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy and harden self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks.
- We configure logging, access control, backup and monitoring so they can produce the records supervisors ask to see.
- We run security testing of applications, APIs and infrastructure to check the controls before evidence is collected.
How we hand over
- You receive documentation covering configurations, runbooks, control owners and the evidence each control produces.
- Policies and procedures are drafted for management body approval, which remains your responsibility under Article 20.
- Independent auditors and competent authorities, not DeployOpen, assess compliance and issue any reports or certificates.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Retainers can keep the incident reporting tooling, backups and evidence collection current as your services change.
- Ask any provider, including DeployOpen, to confirm the scope, deliverables and assessor roles in writing before signing.
