ISO 27001 or the Cyber Resilience Act: which to pursue first
If you make software or connected products and sell into the EU, the question is not really which one to choose. ISO/IEC 27001 certifies your organization's information security management system, issued by an accredited certification body after an audit of your ISMS. The Cyber Resilience Act (CRA) applies to the products themselves, through essential requirements, vulnerability handling, CE marking and reporting, and it is enforced by market surveillance authorities. An ISO certificate gives you no presumption of conformity under the CRA. Only harmonized standards whose references are published in the Official Journal carry that effect, so the certificate does not stand in for the CRA's product obligations. For most makers, both are needed, and the CRA is the binding legal obligation for any product that falls within its scope.
Because the CRA is the legal duty, its dates should set the order of work. Start by confirming whether each product is in scope under Article 2(1) and which Annex III class applies, since that decides whether a notified body is needed. Reporting obligations under Article 14 apply from 11 September 2026, and the main obligations apply from 11 December 2027. Work backward from those dates to product-level tasks such as technical documentation, support periods and vulnerability handling. Confirm the current status of the harmonized standards with your conformity assessment advisers, because their deliverable deadlines fall between 2026 and 2027.
Some organizations begin with the ISMS instead. An ISMS can supply the governance, asset inventory, risk assessment and supplier controls that support CRA vulnerability handling and incident reporting, so the work is not wasted if you later pursue both. Treat it as a foundation, not as CRA evidence. Before committing budget, ask any certification body what the audit covers, how the ISMS scope is set, and whether it will assess your products. Ask your CRA advisers which product evidence they expect, and confirm both answers in writing.
How ISO 27001 and the CRA differ on scope, proof and enforcement
This table compares what each framework applies to, who requires it, what proof it produces, how it runs over time and how it is enforced. Read it as two different questions: ISO/IEC 27001 asks whether an organization runs a certified management system, while the CRA asks whether a specific product meets essential requirements before it is sold in the EU.
| Dimension | ISO/IEC 27001:2022 | Cyber Resilience Act (Regulation (EU) 2024/2847) |
|---|---|---|
| What it applies to | An organization's information security management system, within the scope the organization sets | Products with digital elements placed on the EU market, including direct or indirect logical or physical data connections |
| Who requires it | Nothing in law. Customers, partners or contracts may ask for it | Manufacturers, importers and distributors of in-scope products, by law |
| Artifact produced | A certificate issued by an accredited certification body after audit | A CE marking with the notified body number where required, and an EU declaration of conformity |
| Cycle | Three-year certification cycle with at least one audit every calendar year (ISO/IEC 17021-1) | Conformity assessment per product before placing on the market, plus substantial modification and vulnerability handling over the support period |
| Key dates | ISO/IEC 27001:2022 published 25 October 2022; 2013 certifications had to expire or be withdrawn by 31 October 2025 | Reporting obligations apply from 11 September 2026; the regulation applies from 11 December 2027 |
| Enforcement | Voluntary. Certification bodies can suspend or withdraw certificates, and there are no administrative fines | Member state market surveillance authorities enforce. Article 64 fine ceilings: EUR 15 million or 2.5% of worldwide turnover for Annex I and Articles 13 and 14, whichever is higher |
| Presumption of conformity | None. An ISO certificate does not give presumption of conformity with the CRA | Available only through harmonized standards referenced in the Official Journal (Article 27(1)); confirm current publication status |
What counts as a product under the Cyber Resilience Act
Whether the Cyber Resilience Act applies to your offering starts with Article 2(1). The regulation covers products with digital elements made available on the EU market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Both halves of that test matter. A product can be in scope through a network link it does not need for its core function, and a product that is sold in the EU but carries no connection at all may fall outside the regulation. Software counts too, so a desktop application, firmware image or library shipped as a distributable item needs the same question asked of it as a hardware device.
Commission guidance C(2026) 5252, section 2.2, addresses the case most software vendors ask about. Software that runs remotely and is only accessed 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. The exception is remote data processing that supports a product's functions. Read that exception narrowly and test it against the actual architecture. A hosted service that a connected device cannot operate without is likely to be treated as part of the product, while an analytics back end that the device never depends on is less clearly so.
*Illustrative example:* a connected sensor sold in the EU whose alerts only work when a vendor cloud service processes its readings. The sensor is a product with digital elements, and the cloud service may need to be assessed as part of the product's functionality, so the vulnerability handling and reporting duties would extend to it. Build a written classification for each product line, record the functional dependencies that drove the decision, and have counsel review it against the guidance and the current Official Journal text before you commit engineering budget to either path.
Where ISMS work overlaps with CRA obligations
ISO/IEC 27001 and the Cyber Resilience Act both expect documented risk assessment, controlled change, supplier management and a way to receive and act on vulnerability information. The overlap is real in process terms, but each framework still produces its own proof, and the CRA's product-level evidence sits outside what an ISMS certificate covers.
Vulnerability handling process
Annex I, Part II of the CRA sets eight vulnerability handling requirements for manufacturers, covering identification, documentation, remediation, coordinated disclosure and security updates for the product's support period. An ISMS usually has incident and vulnerability management controls, but they are written for the organization's own systems. Check whether your ISMS procedures reach the products you place on the market, including how a vulnerability in a shipped component is triaged, fixed and disclosed. Confirm each requirement against the Annex text and with counsel.
Documented risk assessment
ISO/IEC 27001 requires a documented information security risk assessment and risk treatment process, and the CRA expects manufacturers to base their cybersecurity risk assessment on the product's intended purpose and reasonably foreseeable use. The method can be shared, but the scope differs. The ISMS risk register covers organizational assets, while the CRA assessment covers the product and its components. Ask whether one risk method can record both, and keep the product-level results separate so they can be handed to a conformity assessment body.
Supplier and component evidence
Both frameworks reach into third-party software. The ISMS supplier controls in Annex A cover how suppliers are assessed and monitored, while the CRA requires manufacturers to identify and document components, including open-source components, and to manage their vulnerabilities. A supplier questionnaire or contract clause may satisfy an ISMS control without producing a software bill of materials. Confirm what component inventory your product teams can produce and how it links to supplier records.
Secure development records
Secure development is a theme of the ISO/IEC 27002:2022 guidance that supports Annex A, and it is a theme the CRA's essential requirements address for products. An ISMS can show that development procedures exist and are followed in the organization. The CRA then asks for product-specific evidence such as technical documentation, test results and version history for each product. Check that your development records can be traced to a specific product release, not only to a process document.
What ISO 27001 does not replace
An ISO/IEC 27001 certificate does not give a CRA presumption of conformity, because presumption under Article 27(1) applies only to harmonized standards published in the Official Journal. ENISA states that its own mapping is not a measure of equivalence and does not assess whether a standard fully covers the regulation. For products that need a notified body under module H, the notified body still assesses the full quality system and the CE marking carries its number. Plan the CRA technical documentation and conformity route separately from the ISMS audit.
Which products need a notified body and which can self-assess
Most products with digital elements follow self-assessment under module A, where the manufacturer carries out the conformity assessment itself and draws up the EU declaration of conformity. No notified body is involved in that route. The Commission's 2022 impact assessment (SWD(2022) 282) estimated third-party assessment at an average of EUR 25,000 per product, against EUR 18,400 for self-assessment, so the choice of path materially changes the cost of each product.
- Default category: Products outside the important and critical categories in Annex III and Annex IV generally fall under module A.
- Documentation burden: Self-assessment shifts the evidence work to you, including the technical file, risk assessment and vulnerability handling records under Annex I.
- Cost components: The EUR 18,400 figure covers internal assessment effort, not a fee paid to a third party.
- Open-source products: Free and open-source products in Annex III that publish their technical documentation may also use module A under Article 32.
Confirm with your product classification, in writing, which Annex category each product falls under before you budget for either path.
Class I important products may use module A without a notified body when the harmonized standards, common specifications or certification schemes are applied in full. The Commission's CRA FAQ 6.1 and 6.2 treat this as the condition that keeps the self-assessment route open for class I products. Harmonized standards only give a presumption of conformity under Article 27(1) once their references are published in the Official Journal.
- Full application: Partial use of a standard removes the self-assessment route for class I products and brings in a notified body.
- Standards deadlines: Commission CRA FAQ 6.10 gives 30 August 2026, 30 October 2026 and 30 October 2027 as the deadlines for different standards deliverables.
- Standards under request M/606: The request asks for 41 harmonized standards, 15 horizontal and 26 product-specific.
- Timing risk: A product built against drafts that are not yet published may need rework once references appear.
- ISO 27001 role: An ISO/IEC 27001 certificate does not itself act as a harmonized standard, so it does not switch on this presumption.
Check the Official Journal references for each standard your product depends on, and confirm with a notified body or your authority whether your application is complete.
A notified body is needed for class I important products where harmonized standards are not applied in full, and for class II and critical products (Article 32; Commission CRA FAQ 6.1 and 6.2). Under module H, the notified body assesses the manufacturer's full quality system for design and production. The CE marking then carries the notified body's identification number, which is visible to customers and authorities.
- Module H scope: The notified body reviews the full quality system, not only the product file.
- CE marking: The number of the notified body appears alongside the CE mark.
- ISO 9000 is not a substitute: Accreditation against ISO 9000 does not by itself replace the notified body's involvement under Article 30(4).
- Cost driver: Third-party assessment carries the EUR 25,000 average estimate in the 2022 impact assessment, which varies by product and quality system.
- Certification schemes: Where a European cybersecurity certification scheme applies, check whether it changes the route.
Ask any notified body for a written scope, the modules it will assess, its lead times and what it needs from your quality system before you sign.
Who assesses each framework and what it issues
This table compares who checks each framework and what document or status the organization receives at the end. Read it to see that an ISO certificate is issued by a third-party certification body, while CRA conformity rests on the manufacturer's declaration or a notified body's assessment, and CRA reporting goes to national and EU bodies rather than producing a certificate.
| Aspect | ISO/IEC 27001 (ISMS) | Cyber Resilience Act (products) |
|---|---|---|
| Who issues the outcome | An accredited ISMS certification body issues the certificate. ISO itself does not certify organizations. | The manufacturer draws up the EU declaration of conformity and affixes the CE marking. No EU body issues a CRA certificate for most products. |
| Governing assessment rules | ISO/IEC 17021-1:2015 with ISO/IEC 27006-1:2024, which accreditation bodies applied to all clients by 31 March 2026 under IAF MD 29:2024. | Module A self-assessment for most products. Module H requires a notified body to assess the full quality system for design and production. |
| Who needs an outside assessor | Every organization seeking certification, through an accredited certification body. | Class I important products where harmonized standards are not applied in full, class II important products and critical products (Article 32). |
| Certificate or validity period | Three-year certification cycle with at least one audit, surveillance or recertification, in every calendar year. | No certificate cycle. Conformity is declared for the product as placed on the market, and substantial modification can require a new assessment. |
| Verifying the result | Check the certificate in the IAF CertSearch database, which ISO still points to for accredited certificates. | Check the CE marking, the notified body number where one applies, and the EU declaration of conformity supplied with the product. |
| Ongoing obligations to a regulator | None to a government body. Obligations run to the certification body through audits and certificate maintenance. | Manufacturers report actively exploited vulnerabilities and severe incidents to the designated CSIRT and ENISA through the Single Reporting Platform. |
| Regulator role | No government regulator issues the ISMS certificate. Accreditation bodies oversee certification bodies. | Market surveillance authorities supervise compliance and can impose administrative fines, so the CRA does not operate as a certificate issuer. |
| Does it create a CRA presumption? | No. An ISO certificate gives no presumption of conformity under the CRA, because only harmonized standards referenced in the Official Journal do. | Not applicable |
How to sequence ISO 27001 and CRA work
The sequence settles which products the Cyber Resilience Act covers before any ISMS scope is drawn, then lets one set of risk, supplier and vulnerability evidence serve both the certification audit and the CRA technical file. Teams that run it in this order avoid building the same process twice.
Confirm product scope and classification
Product counsel and the engineering lead list every software and connected product, including firmware, cloud-linked components and products that depend on remote data processing. For each one, they record whether it has a direct or indirect logical or physical data connection, whether it is a default, important (class I or II) or critical product under Annex III or IV, and whether it is free and open-source software. Browser-only web applications are not products with digital elements on that basis alone, so check the Commission guidance before excluding them. The output is a signed product register that names the conformity assessment route each product will need, including whether a notified body is required.
Set the ISMS scope around development and vulnerability handling
The ISO 27001 scope statement must cover the functions that create and maintain in-scope products, including the secure development lifecycle, build and release pipelines, vulnerability intake and the customer support path. Scope is an ISMS boundary, not a product list, so confirm with the certification body that the chosen boundary is accepted and that it reflects the products in the register. The output is an approved scope statement and a list of excluded locations or services with reasons.
Map shared evidence to both obligations
Build one crosswalk that links the ISO risk assessment, the supplier and third-party controls, and the vulnerability management process to the CRA essential cybersecurity requirements in Annex I and the eight vulnerability handling requirements in Part II. ISO/IEC 27001 Annex A controls on supplier relationships, change management and technical vulnerability management often cover the same ground as CRA obligations, but neither standard maps to the other automatically. Mark each CRA requirement as covered by an existing control, partly covered or a gap. The output is a reviewed crosswalk that the auditor and the market surveillance file can both read.
Build the CRA technical file and vulnerability process
For each in-scope product, the manufacturer assembles the technical documentation, the risk assessment, the support period definition and the conformity assessment evidence, using the route confirmed in step one. The Article 14 reporting process needs a named owner, an escalation path to the CSIRT designated as coordinator and a tested way to submit through the CRA Single Reporting Platform. These reporting obligations applied from 11 September 2026, so this work should be finished before that date for any in-scope product already on the market. The output is a technical file index and a tabletop test of one actively exploited vulnerability notification.
Apply the Article 69 transition to the existing product base
Products placed on the EU market before 11 December 2027 fall under the regulation only if they are substantially modified from that date, but the Article 14 reporting obligations apply to all in-scope products whenever they were placed on the market. Legal and product teams should record the placement date for every product in the register and flag any planned change that could count as a substantial modification. The output is a dated list that separates products under full obligations from those under the transition rule, along with the reporting duties that still apply to the second group.
Schedule the ISO certification audit against the three-year cycle
Ask an accredited certification body to plan the initial certification audit after the ISMS scope and the shared evidence are in place. Under ISO/IEC 17021-1, a management system certification cycle lasts three years with at least one audit in every calendar year, so the surveillance plan should be set when the certificate is issued. Confirm that the certification body applies ISO/IEC 27006-1:2024 to the engagement, as required for all clients by 31 March 2026. The output is a written audit plan and a calendar that avoids clashing with CRA reporting exercises or product release freezes.
Confirm the notified body route and its timing
If any product is a class I important product without full application of harmonized standards, or a class II or critical product, a notified body must assess it. The notified body track has its own lead time, so the manufacturer should request quotes early and ask for the assessment scope in writing. Confirm which standards are published in the Official Journal, since presumption of conformity under Article 27(1) applies only to published harmonized standards. The output is a signed assessment agreement or a documented decision to self-assess under module A, with the reasons recorded.
Review both programs together each year
Once both programs run, an annual review should compare the ISO surveillance findings, the CRA technical file and the vulnerability records against the crosswalk. Changes to products, support periods or suppliers should trigger updates to both the ISMS and the technical file. The output is a dated review record that names the owner for each open item and shows which evidence has changed since the last cycle.
What drives the cost of each path
The two paths are paid for in different places, and the main difference is who receives the money. An ISO/IEC 27001 certificate is issued by an accredited certification body, which charges for the initial certification audit and then for surveillance audits and recertification. Under ISO/IEC 17021-1, the certification cycle lasts three years with at least one audit in every calendar year, so the audit fee recurs for the life of the certificate. The CRA route is different: for most products the manufacturer self-assesses under module A and pays internal engineering and documentation effort, while a notified body is paid per product only where the regulation requires one, and that fee is one-time for the assessed version or recurs when the product is substantially changed. Do not treat a certification body invoice as a CRA cost, and do not assume a notified body is needed for your product until you have checked its class.
The EU-level figures in the Commission's 2022 impact assessment (SWD(2022) 282) estimated third-party assessment at an average of EUR 25,000 per product, against EUR 18,400 for self-assessment. These are averages from 2022 for the EU as a whole, not prices you will be quoted, and they do not include the internal engineering, testing and documentation work that both routes require. The cost drivers that matter most are the number of products in scope, their class under Annex III or Annex IV, whether harmonized standards are applied in full, the size and complexity of the software bill of materials, and how often a product is substantially modified. Internal effort, tooling for vulnerability handling and the support period you commit to are usually larger line items than any single fee, and they recur as long as the product is supported.
When you request a quote from a certification body, a notified body or an implementation partner, ask for a written scope that names the ISMS boundary or the product list, the Annex III or Annex IV classification of each product with the reasoning, and the standards or conformity route assumed. Ask which deliverables are included: gap analysis, policy and technical documentation, evidence collection, internal audit, management review support, surveillance audit preparation, vulnerability handling procedures and the Article 14 reporting workflow. Confirm the surveillance and recertification cadence, what triggers an extra audit, and what a substantial modification would cost to re-assess. Also confirm which items are one-time and which recur, so that the first-year budget and the ongoing budget are separated.
Questions buyers ask before choosing ISO 27001 or CRA work
Does an ISO 27001 certificate satisfy the Cyber Resilience Act?
No. An ISO/IEC 27001 certificate gives no presumption of conformity under the Cyber Resilience Act. ISO does not certify organizations, accredited certification bodies do, and the certificate covers your information security management system, not the essential requirements for each product. Presumption of conformity under Article 27(1) applies only to harmonized standards whose references are published in the Official Journal, and the Commission's FAQ gives standards deadlines of 30 August 2026, 30 October 2026 and 30 October 2027 for different deliverables. An ISO certificate can still support parts of your CRA work, such as access control and supplier processes, but confirm the mapping with your notified body or assessor before you rely on it. Accreditation against an ISO standard does not by itself replace notified body involvement where the CRA requires it.
Which of my products need a notified body under the CRA?
Most products follow self-assessment under module A, and a notified body is needed for class I important products where harmonized standards, common specifications or certification schemes are not applied in full, and for class II important products and critical products (Article 32; Commission CRA FAQ 6.1 and 6.2). Default-category products can self-assess, as can class I products where the harmonized standards are applied in full. Annex III lists 19 class I categories and 4 class II categories, and Annex IV lists 3 categories of critical products. Commission Implementing Regulation (EU) 2025/2392 describes each category. Check each product against those lists first, because the category decides the conformity route and the cost of the route.
Do open-source components count as products under the CRA?
It depends on how the software reaches the market. Software is in scope when it is a product with digital elements made available on the EU market, and the Commission's guidance states that browser-only web applications are not on that basis products with digital elements, unless they are remote data processing that supports a product's functions. Free and open-source products listed in Annex III may use module A if they publish their technical documentation. If you incorporate open-source components into a commercial product you place on the market, you may take on manufacturer obligations for that product, so confirm your position with counsel and your notified body. Keep an inventory of components and their maintainers so you can show vulnerability handling for each one.
How long does each take, and what does it need from our engineers?
No supplied figure gives a duration for either route, so ask each provider for a written schedule tied to your product count, scope and existing controls. The dates that bind you are fixed: Article 14 reporting obligations apply from 11 September 2026, Chapter IV on conformity assessment bodies applies from 11 June 2026, and the regulation applies from 11 December 2027 (Article 71). For ISO/IEC 27001, the certification cycle lasts three years with at least one audit in every calendar year under ISO/IEC 17021-1. Engineers will need to provide component inventories, vulnerability intake and patching records, secure build evidence and reporting workflows. Certification bodies must also apply ISO/IEC 27006-1:2024 to all clients by 31 March 2026, so confirm that your chosen body does.
Can we do the ISO 27001 and CRA work ourselves?
You can build the management system and most CRA technical documentation in-house, and most products may use self-assessment under module A. Two limits apply. An ISO/IEC 27001 certificate can only be issued by an accredited certification body, so an internal audit alone produces no certificate. A notified body is mandatory for class II and critical products and for some class I products. Self-assessment still takes steady internal capacity, because someone must own the technical documentation, the vulnerability handling process and reporting to the CSIRT. For cost context, the Commission's 2022 impact assessment (SWD(2022) 282) estimated third-party assessment at an average of EUR 25,000 per product, against EUR 18,400 for self-assessment. Those are 2022 averages that exclude your internal time, so ask whether your team can run the process for the full cycle, not only the first assessment.
What does a DeployOpen engagement cover, and what stays with our auditor or notified body?
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and prepares systems, controls and evidence for compliance assessments. Depending on the written scope, that can include readiness work against ISO/IEC 27001:2022 and the CRA essential requirements, evidence packs, and hardening and testing of the systems that produce the evidence. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not issue ISO certificates, audit reports, CRA conformity assessments or CE marking, and it does not issue attestations. Your certification body or notified body makes those decisions. Ask for a written scope that states which evidence goes to which assessor.
What are the maximum fine levels under Article 64 of the CRA?
Article 64 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 maximums of EUR 10 million or 2%, and incorrect or misleading information given to authorities carries maximums of EUR 5 million or 1%, whichever is higher. These are ceilings set by the regulation, not expected fines. Products placed on the market before 11 December 2027 fall under the regulation only if they are substantially modified from that date (Article 69(2)), but Article 14 reporting applies to all in-scope products whenever they were placed on the market. Check which products are in scope and map your reporting duties now, because the reporting obligations start earlier than the rest of the regulation.
How DeployOpen scopes and supports ISO 27001 and CRA readiness
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For ISO 27001 vs Cyber Resilience Act work, we prepare the management system, controls and evidence on each side, while the certification body and the notified body make their own independent determinations.
How we scope
- Written scope states which products, product lines or ISMS boundaries are covered before any work starts
- Engagements are fixed-scope, with deliverables and timelines agreed in writing
- We confirm early whether each product counts as a product with digital elements under the CRA
- We identify which products may need a notified body and which may use self-assessment
How we build
- We map existing ISMS controls and processes against the Annex A control set and CRA essential requirements
- We set up vulnerability handling and reporting workflows for CRA obligations in your environment
- We run security testing on the in-scope systems and record findings against the relevant controls
- We document technical files and evidence so each claim can be traced to a artifact
How we hand over
- Handover includes documentation of the controls, evidence set, and configuration in your infrastructure
- We document which items remain for the certification body or notified body to assess
- We record open gaps, owners and dates so your team can continue the work without us
- Training for your staff covers how to maintain the evidence and respond to vulnerability reports
How we support
- Ongoing support, upgrades and continuous testing are available as retainers
- Retainers can cover periodic internal audits and preparation for surveillance audits
- Support can track CRA standards and guidance updates against your documented products
- Ask any quote to state what recurs, what is one-time, and who is responsible for each item
Sources and further reading
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex ↗
- Commission guidance on the application of Regulation (EU) 2024/2847, Annex to C(2026) 5252 ↗
- Commission FAQs on the Cyber Resilience Act, version 1.4 ↗
- ISO/IEC 27001:2022 (ISO) ↗
- ISO: Certification ↗
- IAF MD 29:2024 Transition requirements for ISO/IEC 27006-1:2024 ↗
