Cyber readiness assessment

The cyber readiness assessment establishes which of the CRA, NIS2, the MDR and the ISG apply to one product or entity, with the resulting duties and deadlines. It is for software vendors, device makers and pharmaceutical developers placing a connected product or a service on the EU or Swiss market: it determines the CRA class and NIS2 classification, dates the duties in one calendar, rates the legal and contractual gaps and names the clauses that cloud, supply and support contracts must carry, for a capped fee.

From classification to next steps
Establish scope
Product and entity classification
Identify obligations
Duties and deadlines
Review documents
Governance and contractual gaps

A legal document review, not a technical security audit or certification

Who this is for

  • Software and hardware vendors placing a product with digital elements on the EU market, which the CRA reaches by the product's connection to a device or a network rather than by its sector (Art. 2(1) CRA)
  • Device and IVD makers that need the boundary between the CRA and the MDR or IVDR settled before budgeting for compliance
  • Pharmaceutical developers and manufacturers subject to NIS2 because of their sector, irrespective of the products they develop
  • Companies whose customers have started sending NIS2 supply-chain questionnaires, and need to establish their legal position before responding
  • Swiss-seated cloud, data center and digital trust-service providers, and makers of hardware or software that sits inside Swiss critical infrastructure, both of which the ISG reaches on its own terms

Scope

  • Applicability and classification:
    whether the CRA reaches the product and in which class; whether the entity is essential or important under NIS2 and under which national transposition; whether the ISG's reporting duty reaches it in Switzerland; and where a sector-specific regime displaces NIS2 instead (Art. 4(1) NIS2), which is the route a financial-sector client takes out of it and into DORA
  • Obligation calendar:
    the dated duties that follow from that classification, per instrument, drawn from the same dataset as the public regulatory tracker
  • Gap review:
    the client's documentation against the obligation set, rated group by group, with the gap stated and the remediating action named. The review covers the legal documentation: the governance and approval trail, the reporting chain and who is on it, the supplier flow-down clauses, and the vulnerability-handling policy as a document with legal consequences
  • Contract review:
    the clauses the cloud, supply and support contracts must carry once the classification is known, including the switching and data-access terms the EU Data Act now puts into cloud agreements, and the supply-chain terms a NIS2 customer is obliged to push down

Sector-specific scope

The assessment has three versions, each covering the laws relevant to the product and sector. The applicable version is agreed at intake.

MedTech

For device and IVD manufacturers. The assessment first establishes the applicable rules: the CRA does not apply to a product to which the MDR applies, nor to one to which the IVDR applies (Art. 2(2)(a) and (b) CRA). The scope needs to be checked because a companion product falling outside the MDR comes back under the CRA on its own account. Device security obligations still apply: software in a device must be developed to the state of the art including information security, and the manufacturer must set out the minimum hardware, network and IT-security requirements needed to run it as intended (Annex I, Sections 17.2 and 17.4 MDR). On the entity side a device or IVD manufacturer is listed in Annex II of NIS2 rather than Annex I (Annex II, point 5(a) NIS2), which makes it an important entity rather than an essential one, with a lighter supervisory regime and the same duties; a maker of devices on the public-health-emergency critical list sits in Annex I NIS2 instead. In Switzerland the ISG reaches a device maker only where its hardware or software is used by a critical infrastructure and either carries remote-maintenance access or controls operational systems (Art. 74b Abs. 1 lit. u ISG). Sector page: MedTech and diagnostics

Software and cloud vendors

For software, platform and connected-product companies selling into the EU. The CRA qualifies a product by its connection (Art. 2(1) CRA) and sets the class by its function: a product whose core functionality falls in an Annex III CRA category is an important product and takes a stricter conformity route (Art. 7, Annex III CRA), while an Annex IV CRA category can be made subject to a European cybersecurity certificate (Art. 8, Annex IV CRA). Where the product is itself a high-risk AI system, it is deemed to meet the cybersecurity requirements of Art. 15 AI Act if it meets the CRA's essential requirements and its CRA declaration of conformity shows the level of protection that the AI Act requires (Art. 12(1) CRA; Art. 42(3) AI Act). Part of the CRA is already live. An actively exploited vulnerability goes to the coordinating CSIRT and to ENISA as an early warning within 24 hours, a vulnerability notification within 72 hours and a final report within 14 days of a fix being available (Art. 14(2) CRA), and that article has applied since 11 September 2026, whereas most of the regulation applies from 11 December 2027 (Art. 71(2) CRA). On the NIS2 side the exposure is often indirect rather than direct: a vendor that is not itself an essential or important entity is still reached through its customers, who must manage the security of their supply chain and the contracts they hold with their suppliers (Art. 21(2)(d) NIS2). In Switzerland the ISG reaches a cloud, data center, search or digital trust-service provider only where it has a seat here (Art. 74b Abs. 1 lit. t ISG). Sector page: Technology and digital health

Pharmaceutical developers and manufacturers

For companies developing or manufacturing medicinal products. Classification depends on the sector rather than the product: entities carrying out research and development of medicinal products, and entities manufacturing basic pharmaceutical products and preparations, are both listed in the high-criticality annex (Annex I, point 5 NIS2). Above the ceilings for medium-sized enterprises that makes the company an essential entity, and a medium-sized company an important one, while a smaller company generally falls outside NIS2 (Art. 2(1), Art. 3(1)(a) and Art. 3(2) NIS2); the difference between essential and important decides the supervisory regime rather than the duties. Management duties also apply: the management body approves the risk-management measures, oversees their implementation, can be held liable for the entity's infringements, and its members are required to follow training (Art. 20 NIS2). Incident reporting has three stages: an early warning within 24 hours, a notification within 72 hours and a final report within one month of it (Art. 23(4) NIS2). Which national transposition applies is settled per matter rather than assumed. In Switzerland a company that holds a license under the HMG for the manufacture, the placing on the market or the import of medicinal products must report a cyberattack to the BACS within 24 hours of discovering it, because Art. 74b Abs. 1 lit. h ISG keys that duty to the license rather than to a sector label (Art. 74e Abs. 1 ISG). Sector page: Biotech and pharma

What the assessment does not cover

The assessment does not:

  • test anything: no penetration test, no technical security audit, no review of controls as implemented;
  • certify anything, and it produces no conformity assessment and no statement that a product conforms;
  • draft or remediate any document; each of those is its own deliverable, priced separately;
  • assume the content of national implementing legislation or anticipate legislation still in passage: which text applies is verified per matter, and a gap in a national implementation is reported as one;
  • correspond with an authority, a notified body or a CSIRT;
  • handle a live incident, which is response work rather than readiness work.

The rating helps prioritize further work. It is not a reasoned legal opinion on any single question; that is a separate deliverable, and the assessment names it where one is needed.

How the work proceeds

  1. Intake The questionnaire for the applicable version and a short scoping call establish the product, the entity and its structural facts.
  2. Applicability and classification Each instrument in the set is tested against those facts, the CRA class and the NIS2 classification are fixed, the Swiss position is determined, and any uncertainty is recorded for review.
  3. Obligations and gaps The dated duties that follow are put on one calendar, the client's documents and contracts are read against them, and each obligation group is rated with its gap and the action that closes it.
  4. Legal review Every applicability call, every classification and every rating is confirmed or corrected, the flagged points are resolved, and the priority order is set.
  5. Final checks and delivery Sources, citations and the consistency of the ratings are checked before the report, the list of required contract clauses and the method note are delivered.

Any follow-up work identified in the report is scoped separately under cyber and digital resilience work. For a company that first needs to establish which regulatory areas apply, the broader regulatory posture audit provides an initial overview and may recommend this assessment.

An example report

The example below shows the readiness summary and the first entries in the prioritized list of findings.

Illustrative excerpt

Scope. One product line and the entity that places it. A network management platform sold both as software and as a rack appliance to enterprise and public-sector customers across the EU, with remote diagnostics and over-the-air updates. An intrusion-prevention module ships in the same appliance as an option. The manufacturer is seated outside the EU and Switzerland and sells through resellers, and roughly a fifth of its customers are entities their national NIS2 transpositions reach.

Readiness summary

  • 1 red
  • 3 amber
  • 1 green
  • 3 out of scope

Eight obligation groups assessed across four instruments. Each group recorded as out of scope carries the trigger that would bring it back in, and the event on which it is tested again.

  • The vulnerability-reporting duty already applies. Most of the CRA applies from 11 December 2027, but its reporting article has applied since 11 September 2026. An actively exploited vulnerability must reach the coordinating CSIRT and ENISA within 24 hours. The company's disclosure policy routes reports to its own support desk and to neither of them.
  • The optional module affects the conformity-assessment procedure. The platform is an important product, and as a network management system it sits in Class I, where the manufacturer may still assess conformity itself, but only if it applies the harmonized standards in full. The intrusion-prevention module, if it is core functionality rather than an add-on, puts the product in Class II, where that route is not available at all.
  • NIS2 affects the company through its customer contracts. It has no establishment in the EU and is not one of the digital-service providers that must designate an EU representative, so it has no registration and no incident reporting of its own (Art. 26 NIS2). Its customers that are essential or important entities must manage the security of their supply chain, and the instrument they do it with is the contract they sign with this company. Those duties apply under each Member State's transposition, which the Directive required from 18 October 2024, so the clauses are already arriving in renewals.

Recommended next steps. The reporting route is built first, because the reporting duty already applies to each relevant report received. The class determination is second: it is not overdue, but it fixes the conformity route and with it the standards work that has to be finished before December 2027, so the classification needs to be established before that work can be planned. The contract position is third and is scoped against the renewal calendar rather than against any regulatory date.

Prioritized gap register, first three entries

  1. Red: Vulnerability reporting to the coordinating CSIRT and to ENISA

    A manufacturer that becomes aware of an actively exploited vulnerability in its product must notify the coordinating CSIRT and ENISA through the single reporting platform: an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. This article applied ahead of the rest of the regulation, on 11 September 2026. The company's policy directs disclosures to its own support desk, so the exposure is live and recurs with every report it receives.

    Art. 14(1) and Art. 14(2) CRA, applicable under Art. 71(2) CRA

    Follow-up service: Cyber and digital resilience

  2. Amber: The class of the appliance, and the conformity route it fixes

    A network management system is an important product with digital elements. In Class I the internal-control route stays open, but only where harmonized standards, common specifications or a certification scheme at assurance level at least substantial are applied in full; where they are not, or do not yet exist, the product goes to an EU-type examination or to full quality assurance. In Class II there is no internal-control route at any point. Whether the intrusion-prevention module is core functionality is undetermined on the facts given, and the determination is what this entry asks for.

    Art. 7, Art. 32(2) and Art. 32(3), Annex III CRA

    Follow-up service: Cyber and digital resilience

  3. Amber: Supply-chain terms required by customers under their NIS2 duties

    The company carries no NIS2 duty of its own. Its customers that are essential or important entities must take measures covering supply-chain security, including the security-related aspects of the relationships with their direct suppliers, and those measures apply under the national transpositions that the Directive required from 18 October 2024. The clauses, audit rights and notification windows that follow are already appearing in renewals, and the company holds no standard position, so each one is negotiated from the customer's paper. The exposure is commercial rather than regulatory, and is included in the assessment because it affects the company's contractual obligations.

    Art. 21(2)(d) NIS2, applicable since the date set by Art. 41(1) NIS2

    Follow-up service: ICT commercial contracts

Illustrative excerpt based on fictional facts, not a client matter. A full report also includes the applicability map, the remaining register entries, the obligation calendar, the list of required contract clauses, the method note and the attorney's sign-off.

Fees

Capped fee

The fee is set by how many products or legal entities are in scope and by the number of national implementing laws requiring review. If priority handling is expressly agreed, a 50 percent uplift applies.

Questions

What does the assessment produce?
A single rated report in five parts: an applicability conclusion for each instrument, with the class or the entity classification it produces and the provision that decides it; the dated obligation calendar that follows from that classification; a rating of each obligation group with the gap stated and the remediating action named; a list of required contract clauses for the cloud, supply and support contracts; and a short note on what was done and why. It is delivered in English or in German.
Does the CRA reach a medical device?
Not if the MDR or the IVDR applies to it: the CRA excludes such products (Art. 2(2)(a) and (b) CRA), and the assessment checks this boundary at the outset. The scope is checked for each product: a companion product that falls outside the MDR comes back under the CRA. Security obligations remain under the MDR's own requirements for software and for the IT security a device needs to run as intended (Annex I, Sections 17.2 and 17.4 MDR).
How does this differ from the regulatory posture audit?
The posture audit provides an initial overview of the laws that apply to a product. This assessment examines cybersecurity in detail: the CRA class, NIS2 entity classification, resulting duties and deadlines, and required contractual terms. A company with identified cybersecurity questions can start here. The posture audit may be more suitable where the applicable regulatory areas are not yet clear.
Does the assessment test a company's systems?
No. It is a legal applicability and gap review, based on documents and the intake questionnaire. It is not a penetration test, a technical security audit, a conformity assessment or a certification, and it produces no statement that a product conforms. Where a technical measure is the answer to a legal duty, the report names the duty and the gap; the measure itself is the client's to implement or to procure.
Does any of this reach a Swiss company?
Often, by three routes. Switzerland has no NIS2 equivalent as a regime, but it does have a reporting duty: a company that operates a critical infrastructure must report a cyberattack to the BACS within 24 hours of discovering it (Art. 2 Abs. 5 and Art. 74e Abs. 1 ISG), and the catalog of who is caught reaches undertakings rather than only authorities (Art. 74b Abs. 1 ISG). The second route is contractual: an EU customer subject to NIS2 must manage the security of its supply chain (Art. 21(2)(d) NIS2), and it does that through the contract it signs with its Swiss supplier. A third route is direct: the CRA applies to products with digital elements made available on the EU market, whoever makes them (Art. 2(1) CRA).

Discuss your matter

Briefly describe the matter and the legal advice you need.