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 contract-clause punch list for the cloud, supply and support stack; and a short note on what was done and why. It is delivered in English or in German.

Our product is a medical device. Does the CRA reach it?

No, and settling that is often the first thing the assessment does. The CRA does not apply to a product to which the MDR applies, nor to one to which the IVDR applies (Art. 2(2) lit. a and lit. b CRA), so a workstream a company had planned may come off the list. The boundary is narrow, and the assessment states it rather than assuming it: a companion product that falls outside the MDR comes back under the CRA. What does not come off is the security obligation itself, which sits in 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?

By breadth against depth, and the two are sequential rather than alternative. The posture audit surveys a product's whole regulatory surface at entry level and tells a company which instruments reach it. This assessment goes deep on one stack: it settles the CRA class and the NIS2 entity classification, works the dated duties that follow, and checks the contract stack against them. A company that already knows cyber is its exposure can start here; a company that does not yet know where it stands overall is better served by the audit first.

Does the assessment test our systems?

No. It is a legal applicability and gap review, worked from documentation and from 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.

We are a Swiss company. Does any of this reach us?

Often, by two 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) lit. d NIS2), and it does that through the contract it signs with its Swiss supplier.

Cyber Readiness Assessment | Life Sciences & ICT

Who it serves

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 who have been told the CRA applies to them, and need the boundary settled before budgeting for it.
Pharmaceutical developers and manufacturers that turn out to be NIS2 entities through the sector they operate in rather than through anything they build.
Companies whose customers have started sending NIS2 supply-chain questionnaires, and who would rather answer from a determined position than from a form.
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.

What's included

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 tracked source the public regulatory tracker publishes, so the calendar cannot drift from it.
Gap review: the client's documentation against the obligation set, rated group by group, with the gap stated and the remediating action named. What is reviewed is the legal artifact: the governance and approval trail, the reporting chain and who is on it, the supplier flow-down clauses, the vulnerability-handling policy as a document with legal consequences.
Contract-stack check: 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.
Method note and sign-off: a short account of what was done and why, and the attorney's sign-off before anything leaves the firm, in the careful and conscientious practice the professional rules require (Art. 12 lit. a BGFA).

The three variants

The assessment is one product with three instrument sets. Which set applies follows from what the company places on the market, and the set is fixed at intake rather than discovered during the work.

MedTech

For device and IVD manufacturers. The first question the assessment answers is usually the one that removes work rather than adding it: the CRA does not apply to a product to which the MDR applies, nor to one to which the IVDR applies (Art. 2(2) lit. a and lit. b CRA). That boundary is narrow and is stated rather than assumed, because a companion product falling outside the MDR comes back under the CRA on its own account. What does not fall away is the security obligation itself: 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 lit. 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 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.

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 category is an important product and takes a stricter conformity route (Art. 7, Annex III CRA), while an Annex IV category can be made subject to a European cybersecurity certificate (Art. 8, Annex IV CRA). 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, where the rest 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 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) lit. 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: ICT & Digital Health.

Pharmaceutical developers and manufacturers

For companies developing or manufacturing medicinal products. The classification tends to surprise, because it follows the sector rather than anything the company builds: 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, below them an important one (Art. 3(1) lit. a and Art. 3(2) NIS2), and the difference decides the supervisory regime rather than the duties. Those duties reach the board: 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). An incident runs on a three-step clock, 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 & Pharma.

What the assessment does not cover

The boundary is stated in writing before work begins, because a bounded scope is what a fixed fee rests on. 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;
take a national transposition on trust, and equally does not settle one that is 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 is a triage signal that sets the order of action. 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.

What the firm needs from the client

A description of the product and of the entity that places it: what it does, what it connects to, where it is sold, which legal entity sells it, and the headcount and turnover that decide the size thresholds.
The documents that already exist: the security and vulnerability-handling policies, the incident procedure and its reporting chain, and the cloud, supply and support contracts in their current form.
One scoping call, usually under an hour, to settle anything the questionnaire leaves open.
No system access, no credentials and no technical telemetry. The assessment works from documents and from structural facts, and the intake is built so that nothing else is requested.

How it works

Intake. The variant's questionnaire and a short scoping call establish the product, the entity and its structural facts.
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 every uncertainty is flagged rather than resolved quietly.
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.
Attorney pass. Every applicability call, every classification and every rating is confirmed or corrected, the flagged points are resolved, and the priority order is set.
Quality gate and delivery. Citation integrity against the sources, consistency across the ratings, then the rated report, the contract-clause punch list and the method note. Nothing leaves the firm without the attorney's sign-off.

Where the outcome is a remediation program rather than a single answer, it is scoped from the report and runs as cyber and digital resilience work. Where a company does not yet know whether cyber is its exposure at all, the broader regulatory posture audit surveys the whole surface first and this assessment is one of the things it can point to.

Fees

One fixed fee per product or entity

Quoted before engagement

The fee is set by how many products or legal entities are in scope and by how many national transpositions have to be worked rather than named. Group-wide and multi-entity work is scoped and quoted separately. A written fee proposal follows the intake request and precedes any engagement.

Common 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 contract-clause punch list for the cloud, supply and support stack; and a short note on what was done and why. It is delivered in English or in German.
Our product is a medical device. Does the CRA reach it?: No, and settling that is often the first thing the assessment does. The CRA does not apply to a product to which the MDR applies, nor to one to which the IVDR applies (Art. 2(2) lit. a and lit. b CRA), so a workstream a company had planned may come off the list. The boundary is narrow, and the assessment states it rather than assuming it: a companion product that falls outside the MDR comes back under the CRA. What does not come off is the security obligation itself, which sits in 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?: By breadth against depth, and the two are sequential rather than alternative. The posture audit surveys a product's whole regulatory surface at entry level and tells a company which instruments reach it. This assessment goes deep on one stack: it settles the CRA class and the NIS2 entity classification, works the dated duties that follow, and checks the contract stack against them. A company that already knows cyber is its exposure can start here; a company that does not yet know where it stands overall is better served by the audit first.
Does the assessment test our systems?: No. It is a legal applicability and gap review, worked from documentation and from 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.
We are a Swiss company. Does any of this reach us?: Often, by two 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) lit. d NIS2), and it does that through the contract it signs with its Swiss supplier.

Cyber Readiness Assessment