ISO 27001 for CRA Compliance: What Reuses in 2026

If your organisation holds ISO 27001 certification, you already have something most manufacturers starting their Cyber Resilience Act (CRA) journey do not: a functioning risk management process, a tested set of security controls, and a documented approach to vulnerability management and supplier security. That is a genuine head start.

It is not, however, a compliance programme.

The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Article 14 reporting obligations are already live as of 11 September 2026, and full product-level compliance applies from 11 December 2027. The regulation governs a product: what it does, how it is built, how its vulnerabilities are handled across its entire support period, and what documentation exists to prove all of that before it reaches the EU market.

ISO 27001 governs something different. It certifies how an organisation manages information security. The two frameworks share territory in secure development, vulnerability management and supplier controls. But they operate at different levels of abstraction, and that difference has direct consequences for the evidence your technical file needs to contain.

The practical question is not whether ISO 27001 helps. It does. The question is which of your existing controls generate evidence the CRA will accept, which require product-specific additions, and which gaps have no ISMS equivalent at all.

This guide works through each of those three categories and closes with a practical evidence-mapping workflow your team can use to build a defensible CRA programme without dismantling what you already have.

ISO 27001 and the CRA are not in conflict. They are simply regulating different things.

ISO 27001 asks: does this organisation have a systematic, risk-based approach to managing information security? The output is an ISMS: policies, controls, a Statement of Applicability, and a certification that the management system meets the standard.

The CRA asks: is this specific product secure? The output is a technical file: a per-product cybersecurity risk assessment, design and architecture documentation, security test evidence, an SBOM, a Declaration of Conformity, and CE marking. That file must be maintained for ten years or the product's support period, whichever is longer.

The distinction that matters: Your ISMS runs the process. The product supplies the evidence. For the majority of CRA Annex I requirements, ISO 27001 controls establish the process and principles, but the evidence that a specific product version meets those requirements is the product's own, not the ISMS's.

The JRC/ENISA Cyber Resilience Act Requirements Standards Mapping report confirms that no single standard covers all of Annex I. ISO 27001 is one part of the required combination, alongside standards such as IEC 62443-4-1 for secure product development lifecycle and ISO/IEC 29147 for vulnerability disclosure. Understanding where your ISMS contributes and where it falls short is the starting point for an efficient compliance programme.

The highest-value overlap sits in four control clusters. These are the areas where your ISMS records are not just relevant to the CRA: for some requirements, they are the evidence the technical file needs to cite.

Secure development lifecycle (A.8.25 to A.8.28)

Annex A controls covering secure development environment, secure coding principles, security testing and change management directly support the CRA's Annex I, Part I requirements for security by design. Your ISMS establishes the coding standards, the security requirements your products must meet, and the testing methodology applied before release. Where the ISMS record shows this process was followed for a specific product version, it can be referenced directly in the technical file.

What the file still needs: The product's own security test reports and a version-specific confirmation that the coding rules were applied and tested. Process evidence from the ISMS is not a substitute for product test evidence.

Technical vulnerability management (A.8.8)

Your vulnerability management policy, scanning cadence, and remediation tracking records are directly reusable for CRA Annex I, Part II. The ISMS record, including your vulnerability register and remediation log, is what the technical file cites for the ongoing vulnerability-handling obligation. This is one of the areas where the ISMS record itself serves as the evidence, not merely the process behind it.

Supplier and component security (A.5.19 to A.5.22)

Supplier security controls map to the CRA's supply chain requirements and to the SBOM obligation's underlying logic. Your supplier assessment records, contractual security requirements, and third-party risk processes provide the process foundation for demonstrating that component security is managed. Note that these controls do not generate the SBOM itself: they support the governance around it.

Risk assessment methodology (Clause 6.1 and A.5.7)

Your ISMS risk assessment methodology and threat intelligence processes provide the framework for conducting the per-product cybersecurity risk assessment that Article 13(2) requires. The ISMS does not produce that assessment for you, but a mature risk methodology means your team is not starting from scratch when scoping each product's Annex I obligations.

The table below summarises the three categories of ISMS contribution across CRA Annex I:

Even where your ISMS controls overlap with CRA requirements, the regulation demands something your ISMS audit cycle does not produce: per-product, per-version evidence that a specific product meets specific requirements.

The product cybersecurity risk assessment

Article 13(2) requires a cybersecurity risk assessment for the product itself, documented in the technical file under Annex VII. This is not your organisational risk register. It analyses risks from the product's intended purpose, foreseeable use, and conditions of use over its expected lifetime. It must state whether and how each Part I, point 2 requirement applies, with a clear justification for any requirement excluded as not applicable.

Your ISMS risk methodology provides the framework. The product risk assessment is the output your team must produce for each in-scope product.

Security test evidence

ISO 27001 A.8.29 covers security testing in development, but the ISMS audit does not generate product security test reports that a market surveillance authority can inspect. The technical file requires product-specific test evidence: penetration test results, fuzz testing records, and verification that the product's security properties were tested against the Annex I requirements before market placement.

Technical documentation (Annex VII)

The Annex VII technical file is a product-level artefact with no ISMS equivalent. It must contain:

1. A general description of the product and its intended purpose
2. The product cybersecurity risk assessment
3. Design and development documentation, including system architecture
4. A list of harmonised standards applied, with gap justifications where coverage is incomplete
5. Security test reports
6. The EU Declaration of Conformity
7. The SBOM in machine-readable format
8. Details of the vulnerability handling process and CVD policy
9. A lifecycle maintenance plan

This documentation must be available to market surveillance authorities on reasoned request and retained for at least ten years from the date of placing on the market, or for the support period, whichever is longer.

Lifecycle and support-period records

Your ISMS does not commit to a product support period or track the delivery of security updates against that commitment. The CRA requires manufacturers to determine and document a support period of at least five years (or the expected product lifetime if shorter), state the end date clearly at the point of purchase, and maintain records of security update delivery throughout that period. This is an ongoing engineering and commercial obligation, not a documentation exercise.

These are the obligations that have no meaningful ISO 27001 equivalent. They require new capability, new processes, or new artefacts, regardless of how mature your ISMS is.

Gap 1: Software Bill of Materials (SBOM)

Annex I, Part II, point 1 requires a machine-readable SBOM covering at least the top-level dependencies of each product. The format must be commonly used: CycloneDX and SPDX are the standards in current use. The SBOM must be created before market placement and updated whenever the product changes.

ISO 27001 A.8.26 and A.8.28 cover software component awareness and change management, but they do not produce a machine-readable SBOM. The CRA does not require public disclosure of the SBOM, but it must be available to market surveillance authorities and underpin your vulnerability management process for the product's entire support period.

Gap 2: CE marking and conformity assessment

CE marking under the CRA is a product certification process, not an organisational audit. Depending on the product's risk classification (default, Class I, Class II, or critical), conformity is demonstrated either through self-assessment or a Notified Body assessment. This is a pre-market requirement for every in-scope product. Your ISO 27001 certificate does not satisfy it.

Gap 3: EU Declaration of Conformity

Manufacturers must draw up an EU Declaration of Conformity for each product before placing it on the market. This is a product-specific legal declaration that the product meets the applicable CRA requirements, signed by an authorised representative. It is retained for ten years alongside the technical file.

Gap 4: Coordinated vulnerability disclosure policy and Article 14 reporting

This obligation is already active. As of 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting product security to their national CSIRT and ENISA via the CRA Single Reporting Platform. The reporting cadence is:

1. 24 hours: early warning notification
2. 72 hours: full notification
3. 14 days: final report (for actively exploited vulnerabilities, once a corrective measure is available)
4. 30 days: final report (for severe incidents, from the 72-hour notification)

Separately, Article 13(8) requires manufacturers to establish and publish a coordinated vulnerability disclosure (CVD) policy, including a public security contact. ISO 27001 A.6.8 covers information security event reporting internally. It does not establish a public CVD policy or wire into the ENISA Single Reporting Platform.

Gap 5: Product-specific conformity assessment records per risk class

Products classified as Class I or Class II under Annex III of the CRA face additional conformity assessment requirements, including third-party Notified Body involvement for Class II products. Risk classification is determined by the product's category and intended use. Manufacturers with multiple products in scope need a classification exercise for each one, with documented justification.

Key takeaway: Gaps 1 through 3 are pre-market requirements: no SBOM, no Declaration of Conformity, no CE marking means the product cannot legally be placed on the EU market from 11 December 2027. Gap 4 is already in force. Start there.

The goal is one evidence model: a single structure that links each CRA obligation to the ISO control that governs the process, the product artefact that satisfies the requirement, the owner responsible, and the review cadence. This prevents the most common failure mode, which is maintaining a separate CRA documentation effort that duplicates work already done in the ISMS.

The workflow has four steps.

Step 1: Run a gap assessment against your existing ISMS

Do not rebuild your ISMS. Start by mapping your current Statement of Applicability and control set against CRA Annex I. For each Annex I requirement, answer three questions:

1. Does an ISO 27001 control govern this process?
2. If yes, does the ISMS record constitute the evidence, or does the product need to supply its own?
3. If no ISO 27001 control applies, what new artefact or process is required?

This assessment will typically confirm that the majority of Annex I, Part I requirements have an ISMS process behind them, while the evidence gap is at the product level. Part II vulnerability-handling requirements will show a mix: some ISMS records are directly reusable, others need product-specific additions, and the CVD policy and Article 14 reporting workflow are net-new.

Step 2: Build the evidence register

For each in-scope product, create an evidence register that maps:

This register becomes the backbone of your technical file and the single source of truth for your CRA compliance programme. It also makes gap-closure visible: every row marked "net-new" is a workstream.

Step 3: Prioritise by deadline and market exposure

Not all gaps carry the same urgency. Prioritise in this order:

1. Article 14 reporting workflow (already required from 11 September 2026): assign a named owner, validate the 24-hour and 72-hour reporting process, and register on the ENISA Single Reporting Platform.
2. SBOM generation for each in-scope product: this is foundational for conformity assessment and ongoing vulnerability management.
3. Product risk assessments and technical file drafts for products with the earliest planned EU market dates.
4. CE marking and conformity assessment route per product: classify each product's risk tier under Annex III and determine whether self-assessment or a Notified Body is required.

Step 4: Integrate, do not duplicate

Where your ISMS already produces relevant records, link them into the technical file by reference rather than recreating them. Your vulnerability register, supplier assessment records, and secure development process documentation should appear in the technical file as referenced ISMS outputs, not as separate documents. This keeps your compliance programme maintainable and ensures that when the ISMS record is updated, the product evidence stays current.

For organisations managing multiple in-scope products, a connected compliance programme that links ISO controls, CRA obligations, product artefacts, and review cadences in one place is not a convenience. It is the only realistic way to maintain evidence across a product portfolio without multiplying effort across teams. SureCloud's four-framework comparison guide covers how organisations are approaching this across DORA, NIS-2, ISO 27001 and the CRA simultaneously.

Use this checklist to assess where your ISMS already contributes and where product-level work is required. It is a starting point for your gap assessment, not a substitute for it.

ISMS foundations (process evidence your ISMS should already produce)

1. Secure development lifecycle controls in place and documented (A.8.25 to A.8.28), covering security requirements, coding standards, and pre-release testing
2. Technical vulnerability management process active, with a maintained vulnerability register and remediation log (A.8.8)
3. Supplier security assessment process in place, with contractual security requirements for third-party components (A.5.19 to A.5.22)
4. Risk assessment methodology documented and applied to new products and significant changes (Clause 6.1)
5. Information security event reporting process in place internally (A.6.8)

Product-level evidence (required per product, not covered by ISMS audit)

1. Per-product cybersecurity risk assessment drafted and documented in the technical file (Article 13(2), Annex VII)
2. Product security test evidence generated and retained (penetration testing, fuzz testing, Annex I verification)
3. Annex VII technical file drafted for each in-scope product
4. Support period determined, documented, and stated at point of purchase (minimum five years, Article 13(8))
5. Security update delivery process in place and tracked per product

CRA-specific obligations (no ISO 27001 equivalent)

1. Machine-readable SBOM generated for each product, covering at least top-level dependencies (CycloneDX or SPDX format)
2. Article 14 reporting workflow validated and live: 24-hour early warning, 72-hour notification, final report cadence
3. Organisation registered on the ENISA CRA Single Reporting Platform (operational from 11 September 2026)
4. Coordinated vulnerability disclosure (CVD) policy published, including a public security contact (Article 13(8))
5. EU Declaration of Conformity drafted per product
6. CE marking process initiated, with conformity assessment route confirmed (self-assessment or Notified Body per Annex III risk class)
7. Evidence register in place linking ISO controls, CRA obligations, product artefacts, owners, and review cadence

If you can tick every item in the first section but have gaps in the second and third, your ISMS is doing its job. The work ahead is product-level, not organisational.

The case for starting with a gap assessment rather than an ISMS rebuild is straightforward: the CRA does not require you to change how you manage organisational information security. It requires you to produce product-level evidence you do not currently have. Rebuilding your ISMS wastes time and resources that should go towards closing the five gaps above.

The organisations that will be best positioned before December 2027 are those that treat their ISMS as the foundation it already is, map it honestly against CRA Annex I, and build the product-level evidence model on top of it rather than alongside it.

Article 14 reporting is not a 2027 problem. It has been live since 11 September 2026. If your organisation has products with digital elements on the EU market and has not yet validated its reporting workflow or registered on the ENISA Single Reporting Platform, that is the first action to take.

For everything else, the sequence is: gap assessment, evidence register, SBOM generation, product risk assessments, technical file drafts, conformity assessment route, CE marking. One step at a time, in one place, against one evidence model.

Assess your current controls, evidence and product-security obligations in one connected CRA compliance programme. SureCloud links your ISO 27001 controls, CRA obligations, product artefacts, owners and review cadence in a single platform, so your team can close gaps without multiplying effort. Talk to SureCloud about your CRA readiness.