Cyber Resilience Act: all tools and articles
Regulation (EU) 2024/2847, Annex I · ISO/IEC 27001:2022, Annex A
The CRA's essential requirements, mapped to ISO 27001
A manufacturer with a certified ISMS asks one question first: how much of the technical file do I already hold? The answer has three parts. For the 14 requirements of Part I, the product's properties, the ISMS runs the process and the product supplies the evidence. For 3 of the 8 vulnerability-handling requirements of Part II, the ISMS record is the evidence. And for 4 of the 22, nothing in Annex A produces what the Regulation asks for.
A management system is not a product
ISO 27001 certifies how an organisation manages information security. The Cyber Resilience Act regulates a product: what it does, how it is built, and how its vulnerabilities are handled for its support period. The two meet in the development controls of Annex A, which govern how the product is built, and in the vulnerability-handling controls, which govern what happens after release. They do not meet in the product's own properties: no ISMS record shows that a product ships with a secure default configuration. The product's documentation and tests do.
Three answers, not one score
- The ISMS record is the evidence
- 3
- The record the control produces is what the technical file cites: the vulnerability register, the remediation log, the test reports.
- The ISMS runs the process, the product supplies the evidence
- 15
- The control fixes the requirement, the principle, the coding rule or the test; the evidence that the product meets it is the product's own, per version.
- Not produced by Annex A
- 4
- Nothing in Annex A publishes anything, draws up a bill of materials of a product, or commits to free updates. These are written for the Regulation.
Part I: the product's properties
Point 1 is the general duty, based on the risk assessment. Point 2 lists thirteen properties, each applying on the basis of that assessment, so a property judged not applicable is excluded with a justification in the file. For all of them the ISMS supplies the process: the security requirements the product must meet, the principles it is designed on, the coding rules, the testing before release. The evidence of each property is the product's.
I.1 Appropriate level of cybersecurity by design
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
What the file still needs: A cybersecurity risk assessment for the product itself (Article 13(2) and (3)), kept in the technical file under Annex VII point 3. The ISMS assesses the organisation's risks; the product's is a separate record.
In the technical file pack: Cybersecurity risk assessment
I.2.a No known exploitable vulnerabilities at release
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
What the file still needs: The check is per release and per component shipped, and its result stays with that version. A scan of the organisation's own systems is a different record.
In the technical file pack: Standards applied and test evidence
I.2.b Secure by default configuration
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
What the file still needs: The secure default configuration and the reset to it are properties of the product, shown by its documentation and tests, not by a configuration baseline for the organisation's systems.
In the technical file pack: Standards applied and test evidence
I.2.c Security updates
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
What the file still needs: An update mechanism in the product, automatic by default with a way for the user to opt out, and a notification to users when an update is available: a feature, not a process.
In the technical file pack: Standards applied and test evidence
I.2.d Protection from unauthorised access
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
In the technical file pack: Standards applied and test evidence
I.2.e Confidentiality of data
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
In the technical file pack: Standards applied and test evidence
I.2.f Integrity of data, commands and configuration
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
In the technical file pack: Standards applied and test evidence
I.2.g Data minimisation
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
In the technical file pack: Standards applied and test evidence
I.2.h Availability of essential and basic functions
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
In the technical file pack: Standards applied and test evidence
I.2.i No negative impact on other devices and networks
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
In the technical file pack: Standards applied and test evidence
I.2.j Limited attack surface
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
In the technical file pack: Standards applied and test evidence
I.2.k Reduced impact of incidents
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
In the technical file pack: Standards applied and test evidence
I.2.l Security logging and monitoring
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
In the technical file pack: Standards applied and test evidence
Part II: vulnerability handling for the support period
Eight requirements on the manufacturer, none of which may be excluded. This is where an ISMS is closest to the Regulation, and where the specific gaps are: the bill of materials, the public disclosure, the policy, the contact address and the free updates.
II.1 Identify and document vulnerabilities and components, with an SBOM
The ISMS record is the evidence
The process, in Annex A
What the file still needs: A software bill of materials in a commonly used, machine-readable format, covering at least the product's top-level dependencies. No Annex A control asks for a bill of materials of a product.
In the technical file pack: Software bill of materials procedure
II.2 Remediate vulnerabilities without delay
The ISMS record is the evidence
The process, in Annex A
What the file still needs: Security updates delivered separately from functionality updates where technically feasible: a release practice Annex A does not name.
In the technical file pack: Security updates and support statement
II.3 Regular testing and review
The ISMS record is the evidence
The process, in Annex A
In the technical file pack: Vulnerability handling process
II.4 Disclose fixed vulnerabilities
Not produced by Annex A
What the file still needs: Public disclosure of each fixed vulnerability once the update is available: description, affected products, impact, severity and how users remediate. Annex A has no control that publishes anything.
In the technical file pack: Vulnerability handling process
II.5 Coordinated vulnerability disclosure policy
Not produced by Annex A
What the file still needs: A coordinated vulnerability disclosure policy, put in place and enforced. Annex A requires an incident process, not a published policy for outside reporters.
In the technical file pack: Coordinated vulnerability disclosure policy
II.6 A contact for reporting vulnerabilities
Not produced by Annex A
What the file still needs: A published contact address for reports of vulnerabilities in the product and in its third-party components, and a way of receiving them.
In the technical file pack: Coordinated vulnerability disclosure policy
II.7 Secure and timely distribution of updates
The ISMS runs the process, the product supplies the evidence
The process, in Annex A
What the file still needs: The distribution mechanism is the product's: updates signed, delivered securely and in time, automatically where applicable.
In the technical file pack: Security updates and support statement
II.8 Free security patches with advisories
Not produced by Annex A
What the file still needs: Security updates free of charge for the support period, without delay, with an advisory to users. A commercial commitment and a publication, neither of which Annex A names.
In the technical file pack: Security updates and support statement
4 things Annex A does not produce
Written out so a certified manufacturer knows what to write, not just what to cite. Each of the 4 lands in one of 3 documents of the technical file pack, and those documents are drafted from the product record rather than from the ISMS.
II.4 Disclose fixed vulnerabilities
Public disclosure of each fixed vulnerability once the update is available: description, affected products, impact, severity and how users remediate. Annex A has no control that publishes anything.
II.5 Coordinated vulnerability disclosure policy
A coordinated vulnerability disclosure policy, put in place and enforced. Annex A requires an incident process, not a published policy for outside reporters.
II.6 A contact for reporting vulnerabilities
A published contact address for reports of vulnerabilities in the product and in its third-party components, and a way of receiving them.
II.8 Free security patches with advisories
Security updates free of charge for the support period, without delay, with an advisory to users. A commercial commitment and a publication, neither of which Annex A names.
What this page is not
Not a coverage score. No percentage is computed here and none should be. A requirement whose process is in the ISMS and whose evidence is not yet in the file is not a fraction covered; it is a document to write.
Not a presumption of conformity. Only a harmonised standard cited in the Official Journal gives one (Article 27), and ISO 27001 is not, and will not be, that standard. Where the harmonised standards stand, and what their absence means for each tier
Not the NIS2 mapping. NIS2 regulates the organisation and its measures are written from ISO 27001, which is why that mapping is closer. The NIS2 Implementing Regulation mapped to ISO 27001
Read next
CRA Annex I: the 22 essential requirements, as a checklist
Annex I of the Cyber Resilience Act is what your product has to meet from 11 December 2027 and what the technical file has to show. Part I is 14 product requirements, 13 of them 'where applicable' on the basis of your risk assessment; Part II is 8 vulnerability-handling requirements that always apply. Here they are as one table, with what each one asks and whether you may exclude it.
What goes in the CRA technical file: Annex VII, point by point
From 11 December 2027 every product with digital elements placed on the EU market needs technical documentation before it is placed, kept for ten years or the support period, whichever is longer. Annex VII says what it contains in eight points. Here they are, what each one actually asks for, the four documents Part II of Annex I presumes exist, and how long you keep it.
Harmonised standards for the CRA: what request M/606 asks for, when, and what a manufacturer has today
Article 27 gives a presumption of conformity to products that follow harmonised standards cited in the Official Journal. On 3 February 2025 the Commission asked CEN, CENELEC and ETSI for 41 of them, with deadlines from 30 August 2026 to 30 October 2027; the three accepted on 3 April 2025. On 12 September 2026 the Commission's index of harmonised standards still has no entry for the Regulation, which for a class I product means no self-assessment route under Article 32(2). What was requested, the dates, and what to build against in the meantime.
Self-assessment under the CRA: what module A actually requires, from Annex VIII and the Commission's FAQ
Most software products will never see a notified body. They use module A, the internal control procedure of Annex VIII, and 'self-assessment' is the word everyone uses for it without saying what it contains. Annex VIII Part I is five points; the Commission's FAQ adds the list of activities, the fact that no test methodology is mandated, where a software product carries its CE mark, the two forms of the declaration of conformity, and the harmonised standards timeline that decides when self-assessment stops meaning 'against Annex I directly'.
The CRA cybersecurity risk assessment: what Article 13 actually requires, and the one output it must produce
Article 13(2) to (4) of the Cyber Resilience Act make the risk assessment the document every other CRA obligation hangs off. It must analyse risks from the intended purpose, foreseeable use and conditions of use over the expected time in use; state whether and how each Part I, point 2 requirement applies; say how Part I, point 1 and Part II are applied; be documented, kept updated over the support period, and included in the technical file, with a clear justification for every requirement left out. The four paragraphs, and a one-page structure that satisfies them.
Does the CRA require an SBOM? Yes, and here is exactly what it says
Annex I, Part II, point 1 of the Cyber Resilience Act requires a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. It goes in the technical file, it is not published, and a market surveillance authority can ask for it on a reasoned request. The three sentences that decide it, and what they leave open.
The coordinated vulnerability disclosure policy the CRA requires: three provisions, and a one-page policy that meets them
Annex I, Part II, point 5 of the Cyber Resilience Act requires every manufacturer in scope to put in place and enforce a coordinated vulnerability disclosure policy. Article 13(17) requires a single point of contact for reporting that is easy to find and not limited to automated tools; Annex II, point 2 requires the contact and the policy's location in the user information; Annex VII, point 2(b) puts both in the technical file. What each provision asks, what a policy must say, and what it must not promise.
The Cyber Resilience Act for a small software manufacturer, in twelve steps
Everything a ten-person company that ships installed software or a device has to do under the CRA, in the order to do it: the scope determination, the tier, the CSIRT and the enforcer, the reporting procedure that has applied since 11 September 2026, then the technical file, the 22 requirements, the SBOM, the support period, the CE mark and the declaration due by 11 December 2027. Each step with its article and the piece that explains it.
The 4 gaps are 3 of the 11 documents of the file
StandardOS keeps the ISMS records the 23 mapped controls produce, and the technical file pack drafts the 11 documents of Annex VII from the product record, the disclosure policy, the update statement and the SBOM procedure among them. The mapping on this page is the join between the two.
Annex I applies from 11 December 2027. The controls are the 93 of Annex A of ISO/IEC 27001:2022, cited by reference; the mapping is ours and is not ISO's or the Commission's. This is not legal advice, and the Regulation is the text to read: Regulation (EU) 2024/2847.