# ISO 27001 vs the Cyber Resilience Act: What Actually Overlaps

Source: https://scadable.com/blog/iso27001-vs-cra
Published: 2026-07-12

---

**ISO 27001 and the Cyber Resilience Act regulate different subjects. ISO 27001 certifies that your organisation runs an ongoing information security management system, an ISMS. The CRA, Regulation (EU) 2024/2847, regulates products with digital elements placed on the EU market and binds the manufacturer directly, with no size threshold. But of all the framework pairs a compliance team compares, this one has more genuine technical overlap than most: both demand a real risk-assessment process, both demand a working vulnerability-handling and incident-response capability, and both expect security to be an ongoing operational practice rather than a one-time audit.**

That overlap is worth taking seriously rather than assuming away. Device makers often meet these two in the wrong order, treating ISO 27001 as the "real" security work and the CRA as paperwork layered on top, or the reverse. Neither framing holds up. Our [ISO 27001 framework page](/frameworks/iso-27001) covers the certification in full, and our [Cyber Resilience Act framework page](/frameworks/cyber-resilience-act) covers the regulation; this post is about the specific ground they share.

## What is the difference between ISO 27001 and the CRA?

ISO 27001 certifies an organisation. An accredited third-party auditor examines whether your ISMS, the policies, risk assessments, and Annex A controls you run to manage information security, is documented and actually operating, then issues a certificate valid for three years with annual surveillance audits. Nothing forces a company into ISO 27001 by law; it shows up as a buyer requirement, most often from enterprise customers, EU customers, or public-sector tenders.

The CRA regulates a product. It is a regulation, so it applies directly in every EU member state without national transposition, and it attaches to a product with digital elements the moment that product is placed on the EU market, regardless of the manufacturer's size or sector. The CRA requires secure-by-design development, a Software Bill of Materials, vulnerability handling, security updates through the support period, conformity assessment, and CE marking, per product.

The clean test: ISO 27001 asks "does this organisation run security management well, on an ongoing basis?" The CRA asks "is this specific product secure and supported, and can you find out fast when it isn't?" A company can be excellent at one and still have nothing built for the other, because they are certifying and regulating different things.

## ISO 27001 vs CRA at a glance

| | ISO 27001 | CRA |
| --- | --- | --- |
| Legal form | Voluntary international standard (ISO/IEC 27001:2022), certified by accredited third parties | Regulation (EU) 2024/2847, applies directly in every member state |
| Regulates | The organisation's information security management system | Products with digital elements placed on the EU market |
| Trigger | A buyer, enterprise customer, or public-sector tender asking for it | Placing a product with digital elements on the EU market, commercially |
| Who asks for it / enforces it | Enterprise and international buyers, public-sector procurement (a market requirement, no regulator) | EU market surveillance authorities and notified bodies (a legal requirement, statutory fines) |
| Certification vs regulation | Certification: a certificate issued after audit, proving the ISMS works | Regulation: legal obligations on the manufacturer, checked via conformity assessment and CE marking |
| Where they overlap technically | Risk assessment, vulnerability handling, incident response, the same operational muscle underneath both |

For what happens if the CRA side goes wrong, see [CRA penalties and fines](/blog/cra-penalties-and-fines); for the ISO 27001 side against the other US-market attestation, see [SOC 2 vs ISO 27001](/blog/soc2-vs-iso27001).

## Where do they actually overlap?

More than most framework pairs, because both are built around the same underlying discipline: know what you have, assess the risk, watch for problems, and be able to act fast when something goes wrong.

**Risk assessment.** ISO 27001 requires a formal risk assessment and treatment process, the backbone of the whole ISMS, documented in a Statement of Applicability that justifies which Annex A controls apply and why. The CRA requires manufacturers to carry out a product-level cybersecurity risk assessment under Annex I, informing what "secure by design" means for that specific product. Different scope (organisation-wide versus per-product), same discipline: identify what could go wrong, decide what to do about it, document the reasoning.

**Vulnerability handling.** ISO 27001's Annex A technical controls cover vulnerability management as an ongoing operational practice. The CRA's Article 13 obligations go further for products specifically: manufacturers must handle vulnerabilities throughout the support period, including a coordinated disclosure process and security updates. A device maker that builds real vulnerability monitoring for CRA compliance, knowing what components are in every deployed product and what CVEs affect them, is running the same capability ISO 27001's auditors want to see evidence of.

**Incident response.** ISO 27001's Annex A.5.24 through A.5.28 controls require a documented incident-management process: detection, assessment, response, and learning from what happened. The CRA's incident-response requirement is sharper and clock-driven, a 24-hour early-warning notification for actively exploited vulnerabilities or severe incidents, followed by a 72-hour notification and a 14-day final report. Building a process that can hit a 24-hour deadline under the CRA produces an incident-response capability that comfortably satisfies ISO 27001's less time-pressured version of the same control.

The practical upshot: a device maker who builds real CRA-grade vulnerability monitoring and reporting has already done most of the hard operational work ISO 27001's risk-treatment and incident-response controls ask for. The reverse holds too, an organisation with a mature ISMS already has the inventory and process discipline that makes CRA compliance faster to stand up. Neither substitutes for the other's paperwork, but neither has to be built from zero if the other already exists.

## Does ISO 27001 satisfy the CRA, or the other way around?

No, in either direction, and this is the part worth being precise about. ISO 27001 certifies your ISMS, not any individual product, and it says nothing about a Software Bill of Materials, product-specific conformity assessment, or CE marking, all of which the CRA requires per product. Holding an ISO 27001 certificate does not make your connected device CRA-compliant.

CRA compliance runs the other direction just as cleanly: doing the product-level work, secure-by-design development, vulnerability handling, 24-hour reporting, does not get you an ISO 27001 certificate. That requires the ISMS itself, the Statement of Applicability, and a Stage 1 and Stage 2 audit from an accredited body. They are genuinely separate deliverables. What overlaps is the underlying operational capability, not the paperwork each one produces.

## Should a device maker pursue both?

If you make connected products sold into the EU, the CRA is close to non-negotiable: no size threshold, no sector carve-out beyond a short list of already-regulated categories, and its 24-hour reporting obligation applies from 11 September 2026. Use our [CRA readiness check](/cra-readiness-check) to see exactly where your product stands against it.

ISO 27001 stays a market decision, driven by whether an enterprise buyer, an EU customer, or a public-sector tender is actually asking for it. If one is, or you can see one coming, doing the two together is more efficient than doing them in sequence: build the risk-assessment and vulnerability-handling capability once, then point it at both frameworks' specific requirements rather than rebuilding it a second time. If you're also weighing SOC 2 into the mix, [SOC 2 vs the CRA](/blog/soc2-vs-cra) covers the equivalent comparison against the US-market attestation.

## Frequently asked questions

**What is the difference between ISO 27001 and the CRA?** ISO 27001 is a certification for an organisation's information security management system, the ISMS, issued by an accredited third party after an audit. The CRA, Regulation (EU) 2024/2847, is a law that regulates products with digital elements placed on the EU market and puts obligations directly on manufacturers. One certifies how a company manages security, the other regulates what a company ships.

**Does ISO 27001 certification satisfy CRA requirements?** No. ISO 27001 certifies your organisation's ISMS, not any specific product. The CRA requires product-level conformity assessment, a technical file, an SBOM, and CE marking for each product with digital elements. An ISO 27001 certificate does not substitute for any of that, though the risk-management and vulnerability-handling processes it certifies do overlap with what the CRA expects operationally.

**Does CRA compliance help with ISO 27001 certification?** It helps materially without covering it. A device maker building CRA-required vulnerability monitoring and 24-hour reporting capability is building most of the operational muscle ISO 27001's incident-response and risk-treatment controls ask for. You still need the ISMS itself, the Statement of Applicability, and the certification audit, but the underlying capability is not being built twice.

**Where do ISO 27001 and the CRA actually overlap technically?** Three places. Both require a real risk-assessment process, ISO 27001's formal risk treatment plan and the CRA's product-level risk assessment under Annex I. Both require a vulnerability-handling capability, ISO 27001's Annex A technical controls and the CRA's Article 13 vulnerability-handling obligations. And both expect an incident-response capability that can act on a real clock, ISO 27001's Annex A.5.24 to A.5.28 and the CRA's 24-hour early-warning reporting.

**Should a device maker do ISO 27001 and the CRA at the same time?** If you sell connected products into the EU and also need ISO 27001 for enterprise or public-sector buyers, doing them together is usually cheaper than doing them in sequence, because the risk-assessment and vulnerability-handling work is shared. The CRA is mandatory with no size threshold if you sell into the EU, so it is rarely optional the way ISO 27001 can be.

Last reviewed: July 12, 2026.

## Where Scadable fits

Scadable builds the shared risk-management and vulnerability-handling capability once, then applies it to both frameworks' specific requirements instead of running two disconnected compliance projects. For a device maker doing CRA work, that means the same live component inventory, monitoring, and 24-hour reporting pipeline that satisfies Article 13 and Article 14 also generates the evidence ISO 27001's auditors want to see for risk treatment and incident response. Run the free two minute [CRA readiness check](/cra-readiness-check) to see where your product stands, or [book a call](https://cal.com/rahbaral/quick-chat) to talk through both.