NIS2 vs Cyber Resilience Act: which to pursue first and when to do both
NIS2 governs the entity and the Cyber Resilience Act governs the product, so a vendor with EU customers that is also an in-scope entity usually needs both. Start with the question that is hardest to change later: whether the organization is an essential or important entity under NIS2 Article 3. That depends on sector (NIS2 covers 18 sectors across Annexes I and II) and on size, not on what the company ships. If the organization is in scope, the risk management and incident reporting duties in Articles 21 and 23 already apply through national transposition laws. Confirm the classification with your national competent authority or qualified counsel before you plan the rest.
The CRA timeline turns on when each product reaches the market. Article 14 reporting applies from 11 September 2026 to in-scope products whenever they were placed on the market, while the full essential requirements apply from 11 December 2027. Products already on the market before that date fall under the full regulation only if they are substantially modified afterward. Scope also depends on the form of the software. Under the Commission's guidance on applying the CRA, a web application used only through a browser is not, on that basis alone, a product with digital elements. A cloud backend that the product cannot perform its functions without can still be in scope under Article 3(2). A SaaS-only firm may therefore find CRA scope narrower than expected, while an installed-software vendor should not assume NIS2 scope follows from the product.
Run both assessments from one inventory. List every product with digital elements and every hosted service that supports it, then record the NIS2 entity status and the CRA category for each. Most products follow self-assessment under module A, but class I important products without full harmonized standards and class II or critical products need a notified body, so ask certification bodies about their queues early. The reporting paths also differ: NIS2 incidents go to the national authority or CSIRT, while CRA reports go through ENISA's Single Reporting Platform, which launched on 11 September 2026. The Digital Omnibus proposal would add a single entry point for several laws, but it is still a proposal and does not change current duties. DeployOpen prepares technical evidence and control mappings for both regimes. It does not certify compliance under either, and NIS2 creates no certificate, so the authorities and the notified bodies make those determinations.
Who each regime applies to: entities under NIS2 and products under the CRA
NIS2 applies to organizations, not to products. Directive (EU) 2022/2555 covers 18 sectors: 11 sectors of high criticality listed in Annex I and 7 other critical sectors listed in Annex II. An organization in one of those sectors is classified as either an essential or an important entity under Article 3, and both classes face the same risk-management measures in Article 21 and the same reporting duties in Article 23. The difference lies in supervision: essential entities face ex ante supervision, while important entities face ex post supervision under Articles 32 and 33. Because NIS2 is a directive, obligations reach you through the national transposition law of each Member State where you operate, and Article 5 allows states to keep or adopt stricter rules. Confirm the sector annex, size threshold and national authority that apply to each establishment.
- Sector placement: Map each service line to an Annex I or Annex II sector, since the sector determines whether you are a high-criticality or other critical entity.
- Essential or important: Article 3 classification drives the supervisory regime, not the substance of the duties.
- Transposition: Check the law of each Member State where services are provided, because national rules set registration and enforcement details.
- Managed service providers: Managed and managed security service providers are themselves in scope under Annex I when they meet the size-cap rule.
- Pending changes: The Commission's February 2026 proposal COM(2026) 13 would add a small mid-cap category, but it remains a proposal.
Before relying on a classification, confirm it with your national competent authority and your own counsel.
The Cyber Resilience Act, Regulation (EU) 2024/2847, applies to products with digital elements placed on the EU market. It is a product rule: manufacturers must meet the essential cybersecurity requirements in Annex I and handle vulnerabilities for the product's supported life. Scope turns on what the product is, not on the sector of the company. Article 3 extends the regulation to remote data processing when the manufacturer designed it, or had it designed under its responsibility, and the product could not perform one of its functions without it, so a cloud backend can sit inside an in-scope app or device. The Commission's guidance on the application of the regulation, annexed to C(2026) 5252, states that software which runs remotely and is accessed only by the user, such as a web application used exclusively through a browser or a website, is not on that basis a product with digital elements, unless it is remote data processing that supports a product's functions.
- Product test: Ask whether the software or device is a product with digital elements that is placed on the EU market.
- Remote processing: Apply the Article 3 test to backends that a connected product cannot function without.
- Browser-only services: Services used solely through a browser are not on that basis in scope, so confirm whether any client software or device component sits alongside them.
- Timing: The regulation applies from 11 December 2027, with reporting obligations from 11 September 2026.
- Classification: Annex III class I and class II products, and Annex IV critical products, change the conformity route.
Review the Commission guidance section on remote data processing against your own architecture diagrams.
Some organizations are caught by both regimes. A company can be an NIS2 essential or important entity because it runs a sector service, and also a CRA manufacturer because it ships software or connected hardware. The two regimes do not merge. NIS2 asks how the entity manages its own cyber risk and reports incidents affecting its services. The CRA asks whether each product meets the essential requirements and whether vulnerabilities in that product are handled and reported. A single engineering team may serve both roles, so the scope mapping should list each service and each product separately, with the regime it falls under.
- Dual role: A SaaS provider with a companion installed agent may face NIS2 for the service and CRA for the agent.
- Separate scope maps: Record service lines under NIS2 and product lines under the CRA, with the owner of each.
- Supplier duties: NIS2 risk management covers suppliers, and the CRA acquisition duties require security updates and component information from your own suppliers.
- Overlapping evidence: Reuse of engineering evidence is possible, but the authority and the report differ for each regime.
- Open-source components: Check the CRA guidance on free and open-source software before assuming the regulation does not apply.
Confirm your dual role with counsel and with the competent authority or market surveillance authority where the answer is unclear.
NIS2 and CRA side by side: scope, obligations, supervision and fines
This table sets NIS2 and the Cyber Resilience Act side by side on what each regulates, who must comply, their risk and reporting duties, how they are supervised and their fine ceilings. Read each row as a question: does this rule attach to my organization as an entity, to my products, or to both?
| Dimension | NIS2 (Directive (EU) 2022/2555) | Cyber Resilience Act (Regulation (EU) 2024/2847) |
|---|---|---|
| Legal form | Directive, so obligations reach entities through national transposition laws | Regulation, directly applicable in all Member States once in force |
| What is regulated | Essential and important entities across 18 sectors and their network and information systems | Products with digital elements placed on the EU market, including remote data processing that a product needs to function |
| Who must comply | Entities classified as essential or important under Article 3, with sector and size tests | Manufacturers, importers and distributors of in-scope products; most products follow self-assessment under module A |
| Risk management duties | Article 21 risk-management measures, applied through the implementing requirements of Regulation 2024/2690 where they apply | Annex I essential cybersecurity requirements for product properties, plus eight vulnerability handling requirements in Part II |
| Reporting duties | Article 23 incident reporting for significant incidents affecting the entity's services | Article 14 reporting of actively exploited vulnerabilities and severe incidents in products, through the CRA Single Reporting Platform |
| Supervision | National competent authorities use inspections, security audits, security scans and information requests (Articles 32 to 34); essential entities face ex ante and important entities ex post supervision | Market surveillance and notified bodies for conformity assessment where required (Article 32 and Chapter IV); no certificate of compliance is issued for the regulation as a whole |
| Fine ceilings | Set through national law, so the maximum depends on each Member State's transposition | Article 64: up to EUR 15 million or 2.5% of worldwide annual turnover for Annex I and Articles 13 and 14 breaches, whichever is higher |
| Key application dates | Applied from 18 October 2024 (Article 41); the first NIS Directive was repealed with effect from the same date (Article 44) | Article 14 reporting applies from 11 September 2026; the main obligations apply from 11 December 2027 (Article 71(2)) |
Where the work overlaps between NIS2 and the CRA
NIS2 and the Cyber Resilience Act both reach software and supply chain practice, but they apply to different subjects and answer to different authorities. The cards below show where one body of work can serve both, and where each regime still needs its own evidence. Neither regime is a substitute for the other, and a mapping between them is not proof of equivalence.
Vulnerability handling processes
The CRA requires manufacturers to run vulnerability handling for their products, and to report actively exploited vulnerabilities through the Single Reporting Platform. NIS2 requires essential and important entities to manage cyber risk in their own services, including how they learn of and respond to weaknesses. Check whether one intake, triage and disclosure process can feed both the product security file and the entity's risk register, and who owns the decision to report.
Component and supplier information
Implementing Regulation 2024/2690, Annex point 6.1.2, requires acquisition processes to collect information on hardware and software components. The CRA asks manufacturers to document the components inside their products, which makes the same bill of materials useful for NIS2 supplier and supply chain risk work. Confirm that component records are kept current per release, and that open-source and third-party components are included in the inventory.
Security updates over the support period
Point 6.1.2 of Implementing Regulation 2024/2690 requires acquisition processes to require security updates over the product's lifetime, which sits alongside the CRA duty to provide security updates for the support period. For a software vendor that is also an NIS2 entity, the same patch cadence may serve customers under both regimes. Check how support end dates are published and how customers are told when a product leaves support.
Incident handling procedures
NIS2 reports significant incidents affecting the entity's services to its CSIRT, while the CRA reports actively exploited vulnerabilities and severe incidents in products to the Single Reporting Platform. The two regimes use different triggers and recipients, so a shared incident procedure must branch early. Map each incident type to its trigger, recipient and deadline, and test the branch with a tabletop exercise before any real event.
Secure development evidence
The CRA's essential requirements in Annex I shape how manufacturers design and test products, and NIS2 Article 21 measures cover secure development and maintenance of systems. Records such as threat modelling, code review, security testing and release approvals can serve both, provided they are written to show what was checked and by whom. Ask an auditor or the competent authority which records they expect before building a single evidence set.
Supplier duties under both regimes
Entities caught by NIS2 must manage risk from suppliers, including managed service providers, and recital 86 calls for increased diligence when selecting managed security service providers. Manufacturers under the CRA must also check the components and services they rely on. Map which suppliers feed your products and which supply your operations, then set one due diligence questionnaire that asks for update commitments, incident contacts and component data.
How software vendors end up caught by both regimes
A vendor can be caught by both regimes at once when it is an in-scope NIS2 entity in its own right and also places products or remote data processing on the EU market. The clearest route is a managed service provider or a cloud or data centre operator listed in Annex I, which NIS2 treats as an essential or important entity. The same company may ship a client application or device that depends on its hosted backend. Under the CRA, Article 3(2) can bring that remote data processing into the product when the manufacturer designed it, or had it designed under its responsibility, and the product could not perform one of its functions without it. Illustratively, a company that runs a regulated cloud service and also sells a companion app that cannot log in without that service would need to ask whether the backend is part of the in-scope product, because the answer decides which vulnerability handling and reporting duties apply to the code it runs.
Once the scope question is answered, the two regimes ask different things of the same engineering team. NIS2 Article 21 risk management and Article 23 incident reporting cover the entity's own services and systems, while the CRA covers the product and its exploited vulnerabilities. Recital 86 of NIS2 asks entities to show increased diligence when selecting managed security service providers, so a vendor that buys monitoring or patching from a third party should be able to show how that supplier was assessed. Confirm which supplier evidence your authorities or customers will expect, and map each supplier's duties to the NIS2 and CRA obligations that depend on them. The CRA's Annex I supply-side expectations for acquired components point the same way. Ask suppliers for security update commitments, component information and validation evidence, and record the answers in the same register.
Who assesses each regime and what proof it produces
This table compares who checks compliance under NIS2 and the Cyber Resilience Act, what each produces, and how the review cycle works. Read it to see which regime needs a third-party assessor and which relies on your own documented evidence.
| Dimension | NIS2 (Directive 2022/2555) | Cyber Resilience Act (Regulation 2024/2847) |
|---|---|---|
| Who assesses | National competent authorities in each Member State, through national transposition laws | The manufacturer self-assesses most products under module A; a notified body is needed for some class I important products, class II and critical products (Article 32) |
| Output of assessment | No certificate of compliance; authorities use inspections, security audits, security scans, information requests and administrative fines (Articles 32 to 34) | For self-assessed products, the manufacturer's own conformity documentation; confirm the exact technical file and declaration content in the Commission FAQs and the regulation |
| Supervision timing | Essential entities face ex ante supervision; important entities face ex post supervision (Articles 32 and 33) | Market surveillance and notified body involvement depend on product class; confirm the timing with the Commission guidance for your product category |
| Review cycle | Ongoing supervision by national authorities, triggered by inspections, scans, information requests or incidents | Conformity assessed before placing on the market; reporting duties under Article 14 apply from 11 September 2026 and the main obligations from 11 December 2027 |
| Notified body role | Not part of the NIS2 model; authorities perform oversight directly | Required for class I important products where harmonized standards are not fully applied, and for class II and critical products (Article 32) |
| Fines ceiling | Set through national law; minimum maximums are defined by the directive, confirm figures with your national authority | Up to EUR 15 million or 2.5% of worldwide annual turnover for Annex I and Articles 13 and 14 breaches, whichever is higher (Article 64) |
Reporting channels: CSIRT under NIS2 and the CRA Single Reporting Platform
This sequence shows how one vendor that is both a NIS2 entity and a CRA manufacturer routes each report to the right recipient. It ends with two separate filings, one per regime, built from one consistent set of incident facts.
Map each activity to its regime
Sort your offerings into NIS2 entity services and CRA products with digital elements before any incident occurs. Software that runs remotely and is only accessed through a browser is not, on that basis alone, a product under the Commission's CRA guidance (section 2.2). A cloud backend can still be in scope if the product could not perform one of its functions without it (Article 3(2)). Output: a written scope map that names which services and products each regime covers, reviewed by legal counsel.
Identify the trigger for each report
Define the event that starts each filing. Under NIS2, the trigger is a significant incident affecting the entity's services. Under the CRA, the triggers are an actively exploited vulnerability in a product or a severe incident affecting its security. The two triggers overlap but are not identical, so one event can require one filing, both, or neither. Output: a trigger matrix that your incident response team can apply within a live incident. Timing for each stage belongs to the sibling NIS2 vs CRA incident reporting comparison.
Confirm the national NIS2 reporting route
Confirm with your national competent authority or CSIRT which body receives NIS2 significant incident reports under Article 23 in each Member State where you are an in-scope entity. Member States transposed NIS2 through national law, so the channel, format and contact points can differ between countries. Record the designated recipient, the submission method and the named contacts for each market. Output: a current contact register, checked against the national transposition text and updated when the authority changes.
Set up access to the CRA Single Reporting Platform
Register your organization on ENISA's CRA Single Reporting Platform before you need it. ENISA launched the initial operating capability on 11 September 2026, the day manufacturer reporting obligations began, so the platform is live now. Confirm with ENISA how accounts are created and which named users may submit. Output: tested access for at least two named staff, with credentials held in your secrets store and a documented fallback contact if the platform is unavailable. Launch details are in ENISA's published announcement.
Route each CRA notification to two recipients
Submit each CRA Article 14 notification through the Single Reporting Platform. The platform sends it to the CSIRT designated as coordinator for the manufacturer and makes it available to ENISA at the same time, so you do not file separately with ENISA. Confirm which CSIRT is your coordinator before a live event. Output: a submission record showing the coordinator CSIRT as recipient and the notification reference, saved to your incident file.
Reconcile the NIS2 and CRA filings
Keep one incident fact record and generate both filings from it, so the NIS2 report to the national CSIRT or competent authority and the CRA notification describe the same event consistently. Note which facts each regime needs and which fields differ in scope. Have legal counsel approve the final text for each recipient. Output: two filings with matching timestamps, a reconciliation log of any differences, and a sign-off record for each submission.
Track the Digital Omnibus proposal
Record the Commission's Digital Omnibus proposal of 19 November 2025 as a proposal only. It would create an ENISA-run single-entry point for incident reports under NIS2, GDPR, DORA and other laws. The Commission says it would not modify existing reporting obligations. Until the European Parliament and the Council adopt it, keep your current NIS2 and CRA channels. Output: a dated watch note assigned to a named owner, reviewed with counsel at each legislative milestone.
Supplier duties: what NIS2 and the CRA ask you to demand from vendors
Implementing Regulation (EU) 2024/2690 point 6.1.2 is the clause a NIS2 entity should turn into contract terms. It requires acquisition processes to demand security updates over the product's lifetime, information on hardware and software components, and validation that delivered products meet security requirements. For a NIS2 entity buying software, that translates into specific asks at procurement: a stated support period for security patches, a software bill of materials or equivalent component list, a written statement of the security requirements the product was tested against, and a right to receive evidence before acceptance. Legal and procurement teams should confirm with the vendor which of these it can provide in writing, how long patches are guaranteed, and what notice it gives before end of support. Those answers belong in the contract, not in a sales deck.
A CRA manufacturer uses the same records from the other direction. Its own duties under the regulation depend on knowing what is inside the product, so supplier and component records become evidence it will need for technical documentation and vulnerability handling. Ask suppliers for component lists in a machine-readable form, a point of contact for vulnerability reports, and notice when a component reaches end of support. Check whether each supplier agreement lets you pass security updates to customers within the support period you promise. Illustrative example: a device maker that cannot name the open-source library behind a flagged vulnerability will struggle to decide whether an exploited flaw is reportable. Confirm the exact content of the technical documentation requirements against the regulation text and the Commission guidance before you finalize your templates.
Doing both: the order and the evidence to share
This sequence lets one team meet NIS2 entity duties and CRA product duties without running two unrelated programs. It starts with scope, then builds shared processes, then produces the product and entity evidence each regime expects.
Confirm NIS2 entity status and sector
Start by establishing whether the organization is an in-scope entity under NIS2 and whether it is classified as essential or important (Article 3). Check the sector against the 18 sectors in Annexes I and II, and confirm the size-cap position with counsel or the national competent authority, since national transposition laws govern how obligations reach the company. Also check whether any pending amendments, such as the Commission's January 2026 proposal, could change the classification. The output is a written scope memo that names the entity category, the sector and the authority that would supervise it. Ask the national authority or counsel to confirm the classification before relying on it.
Map products and their market placement dates
List every product with digital elements, including any cloud backend that the product cannot perform its functions without (Article 3(2)), and sort each one by whether it is installed software, SaaS or a hybrid. Under the Commission's guidance, a web application used only through a browser is not in scope on that basis alone, so record the reasoning for each item. For each in-scope product, record when it was first placed on the EU market and whether any later change would count as substantial modification. Products placed on the market before 11 December 2027 fall under the regulation only if they are substantially modified from that date, but Article 14 reporting applies to all in-scope products whenever they were placed on the market. The output is a product register that a reviewer can check against the Commission guidance.
Prepare for the 11 September 2026 reporting start
Note that CRA Article 14 reporting obligations apply from 11 September 2026, which is earlier than the general application date of 11 December 2027. Identify who in the manufacturer organization can decide that an actively exploited vulnerability or severe incident needs reporting, and confirm the designated CSIRT coordinator for each Member State where the products are sold. Confirm that the ENISA Single Reporting Platform is the channel used for CRA notifications. The output is a named reporting owner, a documented decision path and a contact list for the coordinating CSIRT. Ask the CSIRT and ENISA to confirm the current submission steps, since the platform launched recently.
Set up one vulnerability and incident process
Build a single intake, triage and classification process that serves both regimes. NIS2 incident reporting under Article 23 covers significant incidents affecting the entity's own services, while CRA reporting covers actively exploited vulnerabilities and severe incidents in products. Use the same ticketing record, severity scale and timestamps so that one event can be routed to the correct regime without rework. Document which events trigger which notification and who approves each submission. The output is a runbook with a routing table, reviewed by legal and the product security lead. Test the runbook with a tabletop exercise using an illustrative vulnerability in a shipped product.
Build the product-level technical file
For each in-scope product, assemble the technical documentation that supports the Annex I essential cybersecurity requirements and the Part II vulnerability handling requirements. Include the risk assessment, the software bill of materials, the support period, the coordinated vulnerability disclosure policy and the test records. Where the product is subject to a notified body requirement, such as class I important products without full application of harmonized standards, or class II and critical products, plan for that review early. Use the Commission's CRA guidance and the Commission FAQs as the reference for what each section must show. The output is a versioned technical file per product that auditors and market surveillance authorities can inspect.
Build the entity-level risk-management evidence
For the entity as a whole, evidence the Article 21 risk-management measures and the management body's oversight. Use ENISA's non-binding technical implementation guidance for Implementing Regulation 2024/2690, which gives examples of evidence and mappings to ISO/IEC 27001:2022 and NIST CSF 2.0. Remember that a mapping is not equivalence, and ENISA says so itself. Cover supplier and managed service provider diligence, since recital 86 calls for increased diligence in selecting managed security service providers, and collect the security update commitments that acquisition processes need under point 6.1.2 of the implementing regulation. The output is an evidence index that maps each measure to the document that proves it and the owner who maintains it.
Share evidence between product and entity files
Connect the two evidence sets so that one artifact can serve both regimes. The vulnerability handling records, the SBOM, the supplier assessments and the incident log usually appear in both the product technical file and the entity risk file, so keep one controlled copy and link to it from each. Confirm that version history and access controls cover the shared records. Review the index with the compliance lead before each product release and after any substantial modification. The output is a cross-reference register that shows where each piece of evidence is used, with a named owner and a review date set by the organization.
How much does NIS2 and CRA readiness cost and how long does it take?
What drives the cost of NIS2 and CRA readiness work?
The main cost drivers are how many products, services and entities are in scope, how much of your existing security program can be reused, and how much evidence must be produced. NIS2 readiness centers on the risk-management measures in Article 21 and the reporting duties in Article 23, so cost rises with the number of in-scope services, sites and suppliers. CRA readiness depends on the number of products with digital elements, whether they are important or critical products, and whether a notified body is needed for conformity assessment. Ask each vendor to split the quote into scoping, gap analysis, remediation, evidence preparation, testing and training, and to state which items are one-time and which recur.
Can our own team do NIS2 and CRA work in-house?
Yes, many organizations do the scoping and gap analysis internally, but the work needs people who understand both the legal duties and the technical controls. NIS2 has no certificate of compliance, so you will need to show national competent authorities evidence through inspections, audits, scans and information requests under Articles 32 to 34. CRA duties for manufacturers include the essential requirements in Annex I and vulnerability handling, and conformity assessment may require a notified body under Article 32. Consider in-house capacity for interpretation, documentation and reporting, and consider an external party where you lack testing or conformity assessment experience. Decide this per product and per entity.
How much time do NIS2 and CRA readiness work typically need?
The duration depends on your starting maturity and on the fixed dates in the regulations. The CRA reporting obligations under Article 14 apply from 11 September 2026, the notification conformity assessment body chapter applies from 11 June 2026, and the rest of the regulation applies from 11 December 2027 (Article 71(2)). NIS2 national transposition measures applied from 18 October 2024, so entities in scope should already be working against national law. Products placed on the market before 11 December 2027 fall under the CRA only if substantially modified, but Article 14 reporting applies to them regardless. Ask each provider for a written schedule keyed to these dates and to your change freeze windows.
What do our engineering and legal teams need to contribute?
Engineering owns the technical evidence, and legal or compliance owns the scope determinations and regulator interactions. Engineering typically provides architecture diagrams, asset and software component inventories, vulnerability handling records, patch and update processes, and logging and incident response runbooks. Legal should confirm entity classification as essential or important under Article 3, supplier contract terms, and how the Article 14 CRA reports and NIS2 incident notices will be signed off. Expect a named owner on each side and a regular review cadence. Confirm in the statement of work which staff hours are included in the quote and which are your responsibility.
Can one compliance program cover both NIS2 and the CRA?
A single program can share evidence, governance and vulnerability processes, but the two regimes apply to different subjects. NIS2 regulates the entity, while the CRA regulates the product, so an organization that builds software may need both an entity risk-management program and product-level conformity documentation. ENISA's technical guidance on Implementing Regulation 2024/2690 includes mappings to ISO/IEC 27001:2022 and NIST CSF 2.0, but ENISA states that a mapping is not a measure of equivalence. Ask providers to show which artifacts serve both regimes and which are separate, such as CRA technical documentation and NIS2 incident reporting procedures.
What are the CRA fine ceilings, and why do they matter for budgeting?
Article 64 of the CRA sets maximum administrative fines of EUR 15 million or 2.5% of total worldwide annual turnover for breaches of Annex I and Articles 13 and 14, whichever is higher. Other listed obligations carry EUR 10 million or 2%, and incorrect or misleading information to authorities carries EUR 5 million or 1%. These are ceilings, not estimates of what an authority would impose. They matter for budgeting because the cost of a gap that is left unresolved can exceed the cost of remediation, so a quote should include time for risk ranking and for verifying that gaps are closed.
Does DeployOpen certify NIS2 or CRA compliance?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. NIS2 creates no certificate of compliance, and under the CRA conformity assessment is performed by the manufacturer under self-assessment for most products, with a notified body required for some product classes. Independent auditors and certification bodies perform those assessments. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Ask any provider, including DeployOpen, to state in writing which parts of the work are preparation and which are formal assessment.
How DeployOpen prepares NIS2 and CRA readiness
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, and prepares the systems and evidence that support NIS2 and Cyber Resilience Act readiness. We start by separating which obligations attach to your organization as an entity and which attach to the products you place on the market.
How we scope
- We agree a written scope before work starts, covering which entities, services and products are in view for NIS2 and the CRA.
- We confirm with you whether your software is installed, delivered as a product, or run remotely as a service, since that changes the CRA analysis.
- We identify which suppliers, managed service providers and open-source components your scope depends on and records them for review.
How we build
- We implement and harden the self-hosted platforms in your cloud accounts, data centers or air-gapped networks, with configuration documented as you build.
- We run security testing against the scoped systems, using methods agreed in the scope, and track findings to closure with your team.
- We set up the vulnerability handling and incident intake processes that your reporting duties will depend on, and test them with you before go-live.
How we hand over
- We document the control design, system configuration and evidence locations so your compliance team can review them independently.
- We deliver a readiness record that maps your evidence to the obligations in scope, noting where a qualified authority or auditor must still decide.
- We train the operators and named owners on reporting steps, so the process runs without relying on DeployOpen staff.
How we support
- Engagements are fixed-scope, and any change to scope is agreed in writing before the work changes.
- Ongoing support, upgrades and continuous testing are available as a retainer, which can cover updates as the CRA and NIS2 implementing rules evolve.
- Ask us to confirm which open items sit with your legal counsel, national competent authority or notified body, and which sit with our delivery team.
