ISO 27001 and the Cyber Resilience Act: What Your Certificate Covers and What It Does Not

While working on Cyber Resilience Act (CRA) compliance for our customers, the first question we hear from every ISO 27001 certified company is the same: we already have the certificate, so how much of the CRA do we already cover? The short answer is that ISO 27001 covers most of the day-to-day security work the CRA expects, and almost none of the product paperwork it demands.

When we went looking online, we could not find any resource that maps the CRA against the ISO 27001 controls one by one and says how much each control actually covers, and that is why we wrote this. This article goes through every CRA requirement, shows the closest ISO 27001:2022 control, says whether that control covers it fully, partly or not at all, and then lists exactly what you still have to create. If you own the ISO 27001 programme in your company, treat this less like a blog post and more like the list of things to add on top of it.

Two dates matter. If you are a manufacturer, the reporting obligations in Article 14 have applied since 11 September 2026, so you are already expected to report actively exploited vulnerabilities and severe incidents. Every other obligation in the regulation applies from 11 December 2027. That later date also covers all obligations on open-source software stewards, including their reporting duties.

The terms used in this article

• ISO 27001 and ISMS: ISO 27001 is the international standard for managing information security in an organisation. The set of policies, processes and records you build to meet it is called an information security management system (ISMS).
• Annex A control: ISO 27001:2022 lists 93 security controls in its Annex A, each with a number such as A.8.25. When this article says "control", it means one of these.
• CRA: the EU Cyber Resilience Act, Regulation (EU) 2024/2847. It sets mandatory security requirements for software and hardware products sold or made available in the EU.
• Manufacturer: whoever develops a product, or has it developed, and offers it on the EU market under their own name, paid or free. This role carries nearly all the CRA obligations.
• Open-source software steward (OSS steward): an organisation that supports an open-source project meant for commercial use without itself placing it on the market as a manufacturer. Stewards have a much shorter list of obligations.
• SBOM: software bill of materials, a list of the components your product is built from.
• CVD policy: coordinated vulnerability disclosure policy, the public rules for how outsiders can report a security problem to you and what you will do about it.
• CSIRT and ENISA: the national computer security incident response team in your EU country, and the EU's cybersecurity agency. CRA reports go to both.
• Full, Partial, None: the verdict in every table below. "Full" means a working ISMS already produces what the CRA wants. "Partial" means ISO covers the area but the CRA goes further, usually by wanting it as a property of the product you ship and not only of your organisation. "None" means you start from a blank page.

A certificate for an organisation versus a law about a product

ISO 27001 and the CRA are different in kind, and most of the gaps below follow from that.

ISO 27001 certifies a management system. It is voluntary, you choose the scope, an accredited certification body audits you, and the output is a certificate saying your organisation runs a functioning ISMS. At no point does the auditor pick up a product you ship and form a view on whether its defaults are secure or whether it can receive updates. The standard has no concept of a product. It has information assets, risks and controls, and the 93 Annex A controls in the 2022 edition describe what a reasonable organisation does to protect its own information.

The CRA is product legislation. It is not optional. Scope is per product placed on the EU market, and the enforcer is a national market surveillance authority, not an auditor you hired. Fines for breaching the essential requirements reach EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Article 64(2)). And the CRA requires documents and information for each product: a risk assessment, a technical file, a Declaration of Conformity, a CE marking, a declared support period, and an SBOM.

One consequence: your ISO certificate is evidence you can reuse, not a presumption of conformity. Article 27 grants that presumption only to products built against harmonised European standards published for the CRA, Commission common specifications, or certain European cybersecurity certification schemes. ISO 27001 is none of those. Your vulnerability scan logs, code review records and incident records are good evidence for the technical file. The certificate itself proves nothing about the product.

Are you a manufacturer or an open-source steward?

Decide which path you are on before mapping anything, because the tables differ.

You are a manufacturer if you develop a product with digital elements and make it available on the EU market in the course of a commercial activity, under your own name. "Commercial" is broader than "paid": Article 3 defines making available on the market as supply "whether in return for payment or free of charge", so a free tier of a commercial product still counts. Manufacturers get Article 13, Article 14, Annex I in full, Annex II, Annex VII and the CE marking machinery.

You are an open-source software steward if you are a legal person, other than a manufacturer, whose purpose is to systematically support, on a sustained basis, the development of specific free and open-source software that is intended for commercial activities, and who ensures the viability of that software, without placing it on the market commercially yourself. Stewards get Article 24, which is short, plus the parts of Article 14 that Article 24(3) imports. Article 64(10) says administrative fines do not apply to any infringement by a steward. The paragraph is drafted as a derogation from paragraphs 3 to 9 of Article 64, but Recital 120 confirms that stewards are not fined for any infringement, and adds that Member States should not impose other financial penalties on them either. That is not the same as being exempt from the obligations.

If you sell software and also maintain an open-source project, you may be both, for different products. Map each product separately.

The manufacturer mapping

Each table has four columns: the CRA requirement, the closest ISO 27001:2022 Annex A control or controls, the verdict, and one line of reasoning. The complete list of what you have to create is in "The exact gaps" section further down.

Annex I Part I: product security properties

One general requirement plus thirteen specific ones under point (2), so fourteen rows.

CRA requirement (Annex I Part I)	Closest ISO 27001:2022 control(s)	Match	Why
(1) Designed, developed and produced with cybersecurity appropriate to the risks	A.8.25 Secure development life cycle; A.8.27 Secure system architecture and engineering principles	Partial	ISO makes you run a secure development process. It never asks for a per-product risk assessment tied to intended purpose.
(2)(a) Made available without known exploitable vulnerabilities	A.8.8 Management of technical vulnerabilities; A.8.29 Security testing in development and acceptance	Partial	A.8.8 covers the systems you operate. The CRA turns it into a check the product must pass before it ships.
(2)(b) Secure by default configuration, resettable to original state	A.8.9 Configuration management	Partial	A.8.9 hardens your infrastructure. The CRA wants the defaults your customers get, plus a factory reset.
(2)(c) Security updates, automatic by default where applicable, with opt-out and user notification	A.8.8; A.8.32 Change management	None	Nothing in ISO obliges your product to have an update mechanism at all.
(2)(d) Protection from unauthorised access via authentication, identity and access management; reporting on attempts	A.5.15 Access control; A.5.16 Identity management; A.8.5 Secure authentication	Partial	ISO governs access to your information. The CRA wants these built into the product for its users.
(2)(e) Confidentiality of stored, transmitted and processed data, such as by encrypting relevant data at rest or in transit	A.8.24 Use of cryptography	Partial	A.8.24 gives you a cryptography policy. The CRA wants data protection as a verified property of the product.
(2)(f) Integrity of data, commands, programs and configuration; reporting on corruptions	A.8.9; A.8.24; A.8.32	Partial	Same pattern: your controls protect your assets, the CRA wants integrity protection inside the product.
(2)(g) Process only data adequate, relevant and limited to what is necessary	A.5.34 Privacy and protection of PII	Partial	A.5.34 points at GDPR. The CRA's minimisation applies to all data the product processes, personal or not.
(2)(h) Availability of essential functions, including after an incident; resilience against denial-of-service attacks	A.5.29 Information security during disruption; A.5.30 ICT readiness for business continuity; A.8.6 Capacity management; A.8.14 Redundancy of information processing facilities	Partial	ISO protects your operations' availability. The CRA wants the product itself to keep working under attack.
(2)(i) Minimise negative impact on the availability of other devices or networks	none	None	No ISO control asks what your product does to other people's networks.
(2)(j) Limit attack surfaces, including external interfaces	A.8.27; A.8.26 Application security requirements	Partial	The principle is there. Per-product evidence is not something an ISO audit collects.
(2)(k) Reduce incident impact using exploitation mitigation mechanisms	A.8.27; A.8.28 Secure coding	Partial	A.8.28 pushes secure coding. The CRA wants hardening in the product, documented in the technical file.
(2)(l) Record and monitor relevant internal activity, with a user opt-out	A.8.15 Logging; A.8.16 Monitoring activities	Partial	ISO logs your infrastructure. The CRA wants the product to give its users security logs.
(2)(m) Users can securely and permanently remove all data and settings	A.8.10 Information deletion; A.5.14 Information transfer	Partial	Your deletion procedures cover your own information. The CRA wants a way for users to wipe their own data from the product.

Twelve of fourteen rows are Partial, nearly always for the same reason: ISO asks you to do something to your organisation, and the CRA asks you to do the equivalent to the product and prove it. If your ISMS scope covers the product's development, you have the process. You do not have the product-level evidence, because nobody asked for it.

Two rows are marked None, meaning ISO 27001 gives you nothing to build on.

The first is point (2)(c): the product must be able to receive security updates, and where possible install them automatically. This is a feature the product either has or does not have. It matters most for products installed at the customer's site or built into a device. If the only way to update your product is for someone to visit the customer and install the fix by hand, you will have a hard time meeting this point, unless your risk assessment explains why automatic updates are not possible for that product. No policy or process can make up for a product that cannot be updated.

The second is point (2)(i): the product must not harm the availability of other devices or networks. For most products this is easy to meet, but no ISO 27001 control covers it, so you have to address it from scratch.

On (2)(a): most ISO-certified teams already scan their software for known vulnerabilities automatically before every release, and that is the right evidence. The gap is a written rule that a release with a known exploitable vulnerability does not ship. "We scan" is not the same as "we block the release".

Annex I Part II: vulnerability handling

Part II applies for the whole support period, not just at release.

CRA requirement (Annex I Part II)	Closest ISO 27001:2022 control(s)	Match	Why
(1) Identify and document vulnerabilities and components, including a machine-readable SBOM covering at least top-level dependencies	A.5.9 Inventory of information and other associated assets; A.5.21 Managing information security in the ICT supply chain	None	An asset register and supply-chain risk management do not produce an SBOM file for each release in a standard format such as CycloneDX or SPDX.
(2) Remediate vulnerabilities without delay; where feasible, security updates separate from functionality updates	A.8.8; A.8.32	Partial	The patching discipline exists. "Ship security fixes separately from features" is a release policy ISO never mentions.
(3) Effective and regular tests and reviews of the product's security	A.8.29; A.8.8	Full	With development in scope, this is what A.8.29 already makes you do and keep evidence of.
(4) Once a fix is available, publicly disclose the vulnerability: description, affected versions, impact, severity, remediation	A.5.26 Response to information security incidents; A.5.27 Learning from information security incidents	None	ISO incident communication is internal. A public advisory for each fixed vulnerability is a new document.
(5) Coordinated vulnerability disclosure policy	A.8.8; A.5.6 Contact with special interest groups	None	No Annex A control requires a public disclosure policy. The ISO 27002 guidance for A.8.8 recommends one, but an ISO audit will not ask for it.
(6) Publicly accessible contact for reporting vulnerabilities	A.6.8 Information security event reporting; A.8.8	Partial	You have a reporting channel. It faces inward. The ISO 27002 guidance for A.8.8 recommends a public point of contact, but it is guidance, not a requirement.
(7) Secure update distribution, automatic where applicable	A.8.24 (signing and key management)	Partial	Code signing under A.8.24 is real coverage. The distribution channel is product work.
(8) Security updates free of charge and without delay, with advisories telling users what to do	none	None	A commercial term and a communications duty. Neither exists in ISO.

This table is the reason we said at the start that ISO 27001 covers almost none of the product paperwork. Out of the eight requirements:

• One is fully covered. Regular security testing, row (3), is something your ISMS already makes you do if you comply with ISO 27001.
• Three are partly covered. Fixing vulnerabilities quickly (2), having a contact for vulnerability reports (6), and distributing updates securely (7). You will have the internal process for each if you comply with ISO 27001, but not the product-facing part the CRA asks for.
• Four are not covered at all. The SBOM (1), public security advisories (4), a vulnerability disclosure policy (5), and free security updates (8). These are documents you publish and promises you make to your users. ISO 27001 only looks inside your organisation, so it never asks for them.

The SBOM part trips people up because it feels covered. A.5.9 says keep an asset inventory. A.5.21 says manage supply-chain risk. Both are satisfied by a vendor spreadsheet. Neither produces a machine readable list of the top-level components in a specific release of your product, which is what a market surveillance authority can ask for under Annex VII point 8 and, for EU-wide dependency assessments, Article 13(25).

Article 13 and Article 14 duties outside Annex I

Paperwork, process and reporting rather than product properties.

CRA requirement	Closest ISO 27001:2022 control(s)	Match	Why
Art. 13(2) to 13(4): documented cybersecurity risk assessment per product, kept current, included in the technical file	Clause 6.1.2 (ISMS risk assessment); A.8.25	Partial	The ISMS assessment is about your information. The CRA wants one per product about its users and intended purpose, mapped to each Annex I point.
Art. 13(5) and 13(6): due diligence on third-party and open-source components; report their vulnerabilities upstream	A.5.19 Information security in supplier relationships; A.5.21	Partial	Supplier controls cover vendors under contract. An open-source component you downloaded for free is not an A.5.19 supplier, and ISO never asks you to report problems back to the people who maintain it.
Art. 13(8): a support period you determine per product, at least five years unless expected use is shorter	none	None	ISO has no concept of a support period.
Art. 13(9): security updates available for at least ten years after issue, or the rest of the support period, whichever is longer	A.5.33 Protection of records	None	Record retention is about your records. Keeping every update downloadable for a decade is a distribution commitment.
Art. 13(12), 13(13), Art. 31, Annex VII: technical documentation per product, retained at least ten years after placing on the market or for the support period, whichever is longer	A.5.37 Documented operating procedures; A.5.33	Partial	The ISMS gives you documentation discipline and most of the raw evidence. The Annex VII file itself does not exist.
Art. 13(12), Art. 32, Art. 28, Art. 30: conformity assessment, EU Declaration of Conformity, CE marking	none	None	Pure CRA machinery.
Art. 13(17): single point of contact for vulnerability reports, not limited to automated tools	A.6.8	Partial	The channel exists. It is not public.
Art. 13(18) and Annex II: information and instructions to users, available ten years or the support period, whichever is longer	none	None	Product documentation with mandated content.
Art. 13(19): support period end date, month and year, visible at purchase	none	None	Follows from 13(8).
Art. 13(21): corrective measures, withdrawal or recall when non-conforming	A.5.26; A.5.27	Partial	Incident response exists. Withdrawal and recall are not ISO concepts.
Art. 13(22): documentation and cooperation for market surveillance authorities on request	A.5.5 Contact with authorities; A.5.31 Legal, statutory, regulatory and contractual requirements	Partial	A.5.5 says keep contact details for authorities. The CRA duty is specific and comes with a document set.
Art. 14(1) to 14(4): report actively exploited vulnerabilities and severe incidents to the national CSIRT and ENISA: early warning within 24h, notification within 72h, then a final report within 14 days of a fix being available (vulnerabilities) or within one month of the notification (incidents)	A.5.24 Information security incident management planning and preparation; A.5.25 Assessment and decision on information security events; A.5.26	None	Detection, triage and response are yours. The external report, the clock, the platform and the CRA severity thresholds have no ISO counterpart.
Art. 14(8): inform impacted users of the vulnerability or incident and of mitigations	A.5.24	Partial	A.5.24 covers communication with interested parties. A duty to notify product users with remediation steps is stronger.

The Article 14 row carries a deadline that has already passed for manufacturers. Your ISMS almost certainly has a working incident process with severity levels, an escalation chain and a post-incident review. That is A.5.24 through A.5.27 and it is real. What it lacks is the trigger. An "actively exploited vulnerability" is one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission (Article 3). A "severe incident" is defined in Article 14(5) around impact on the confidentiality, integrity, authenticity or availability of sensitive or important data or functions, or the introduction or execution of malicious code. Your Low/Medium/High scale maps to neither, and somebody has to decide within 24 hours whether an event crosses one of those lines.

The steward mapping

The steward path is shorter, because Article 24 is shorter. All of it, including the two reporting rows, applies from 11 December 2027.

CRA requirement	Closest ISO 27001:2022 control(s)	Match	Why
Art. 24(1): a cybersecurity policy, put in place and documented "in a verifiable manner", that fosters secure development of the project	A.8.25; A.8.29	Partial	Internal secure development and security testing policies cover the substance. ISO never asks for a version written for a specific open-source project that someone outside your company can verify.
Art. 24(1): the policy covers vulnerability handling, in particular documenting, addressing and remediating vulnerabilities	A.5.24; A.5.25; A.5.26; A.5.27; A.5.28 Collection of evidence; A.8.8	Partial	Internal incident and vulnerability management covers this. Same gap: it is not written per project in a verifiable form.
Art. 24(1): the policy fosters voluntary vulnerability reporting by the project's developers (Article 15) and sharing of vulnerability information within the open-source community	A.5.6 Contact with special interest groups	Partial	A.5.6 asks you to stay in touch with security communities. It does not ask you to encourage contributors to report and share what they find.
Art. 24(2): cooperate with market surveillance authorities and hand over the policy documentation on a reasoned request	A.5.5 Contact with authorities; A.5.31 Legal, statutory, regulatory and contractual requirements	Partial	A.5.5 says keep contact details for authorities. The CRA duty is specific and comes with a document.
Art. 14(1) via Art. 24(3): report an actively exploited vulnerability in the project, where you are involved in its development, to the CSIRT and ENISA on the Article 14 timelines	A.5.24; A.5.25; A.5.26; A.5.27	None	Internal detection and response are covered. Reporting to an outside CSIRT is not.
Art. 14(3) and 14(8) via Art. 24(3): report a severe incident on your development infrastructure affecting the project on the Article 14 timelines, and inform affected users	A.5.24; A.5.25; A.5.26; A.5.27	None	Same as above.

Notice what is absent compared to the manufacturer tables: no Annex I, no SBOM, no support period, no technical file, no Declaration of Conformity, no CE marking. The steward layer on top of an ISMS is thin. It is almost entirely "take what you already do and write it down per project, in a form someone outside can verify", plus the reporting process.

One clarification, because many guides get this wrong. Article 24 does not literally require a steward to publish a coordinated vulnerability disclosure policy or a public reporting contact. Those are manufacturer duties under Annex I Part II points (5) and (6) and Article 13(17). We still recommend both for stewards: a public page and a public contact are the simplest way to show that your policy handles vulnerabilities "in a verifiable manner", and most serious open-source projects already have them.

The exact gaps

The list to hand to your ISMS owner. Each item is something no ISO 27001 control produces, and each one says who it applies to.

An SBOM per release. Manufacturers only. A standard format such as CycloneDX or SPDX, covering at least the top-level components, generated automatically with every release and kept with it. You do not have to publish it, but a market surveillance authority can request it (Annex VII point 8).

A documented, verifiable cybersecurity policy for each project. Stewards only, under Article 24(1). It describes how the project is developed securely, how vulnerabilities are documented, addressed and remediated, and how contributors are encouraged to report and share what they find.

A public coordinated vulnerability disclosure policy. Manufacturers, under Annex I Part II point (5) and Article 13(8). Annex II point 2 requires you to tell users where the policy can be found, which in practice makes it public. Recommended for stewards as the practical way to meet Article 24(1). How to report, how fast you acknowledge, how you triage, when you disclose after a fix, and a safe harbour for good-faith researchers. One document can cover several products.

A public vulnerability reporting contact. Manufacturers, under Annex I Part II point (6) and Article 13(17). Recommended for stewards for the same reason. A dedicated email address, plus a security.txt file on your website and in each code repository, pointing at the CVD policy. Article 13(17) adds that it cannot be an automated tool alone.

Public security advisories. Manufacturers only, under Annex I Part II (4). Once a fix ships: description, affected versions, impact, severity, remediation.

A declared support period, and updates that stay available. Manufacturers only. At least five years per product, end date shown as month and year at purchase, and every security update kept available for ten years after issue or the rest of the support period, whichever is longer.

Secure by default and a secure update mechanism as product properties. Manufacturers only. Features, not documents. If your product cannot receive updates, no policy fixes that.

A per-product cybersecurity risk assessment. Manufacturers only. Intended purpose, foreseeable use, operating environment, and for every Annex I point either how it is met or why it does not apply. Your ISMS risk assessment is an input, not a substitute.

Annex VII technical documentation. Manufacturers only. One file per product: description, architecture, vulnerability handling process, risk assessment, support period justification, standards applied, test reports, a copy of the Declaration of Conformity. Here most of your ISO evidence will get reused.

EU Declaration of Conformity and CE marking. Manufacturers only. Annex V template for the declaration, CE mark affixed before placing on the market. For software the mark can sit on the declaration or the product website (Article 30).

Article 14 external reporting. Both, with the steward scope narrowed by Article 24(3). Written criteria for "actively exploited vulnerability" and "severe incident" in CRA terms, a named owner who makes the call, EU Login accounts set up in advance for the people who will file reports, and templates for each stage: 24-hour early warning, 72-hour notification, and the final report within 14 days of a fix being available for vulnerabilities, or within one month of the 72-hour notification for incidents. For manufacturers this has applied since 11 September 2026. For stewards it applies from 11 December 2027. One practical note: ENISA asks that you register on its Single Reporting Platform only when you actually have a notification to submit, which takes a few minutes once you have an EU Login account, so prepare the account and know which national CSIRT you report to, and leave the platform registration for the day you need it.

User notification. Manufacturers under Article 14(8), since 11 September 2026; stewards for the severe-incident scenario via Article 24(3), from 11 December 2027. Tell affected users what happened and what they can do.

Cooperation with market surveillance authorities. Both. A short documented commitment, a named contact, and knowledge of which documents you would hand over. Article 13(22) for manufacturers, Article 24(2) for stewards.

Keep the ISMS, add a product layer

Do not build a second compliance programme next to your ISO one. The CRA is not asking you to run your organisation differently; it is asking you to make specific commitments about specific products and to prove them. Your ISMS is where that proof already lives. Vulnerability scan logs are the evidence for Annex I Part I (2)(a) and Part II (3). Code review records are evidence for A.8.25 and therefore for the secure development section of the technical file. Incident records under A.5.24 to A.5.28 show the vulnerability handling process is real. Point the Annex VII file at them.

On sequencing: if you are a manufacturer, reporting first, because that deadline is already here. Write the trigger criteria, name the owner, set up the EU Login accounts, draft the templates. It is a few days of work and it is the part with a clock. Stewards have until 11 December 2027 for everything, reporting included, but the same preparation is worth doing early. Then the public documents, because they are cheap and they are what a researcher or an authority looks for first. Then, for manufacturers, the per-product paperwork before December 2027: risk assessment, support period decision, an SBOM with every release, technical file, Declaration of Conformity, CE marking.

Need help getting compliant?

If you want to know more about the CRA, ISO 27001 or any other compliance requirement your organisation is facing, and how you can meet it using open-source software, we would be glad to talk it through. Book a consultation with us.