CRA vs ISO 27001: The Compliance Gaps Your ISMS Won't Cover

If your company is ISO 27001 certified, you might assume you are well-positioned for the Cyber Resilience Act (CRA). You are not. At least not without significant additional work.

ISO 27001 protects your organization's information assets. The Cyber Resilience Act (Regulation (EU) 2024/2847) requires that every product with digital elements you place on the EU market is secure by design, ships with a software bill of materials (SBOM), and is supported with security updates for its expected lifetime. These are product-level obligations, not organizational ones. Non-compliance carries fines up to EUR 15 million or 2.5% of global annual turnover (Art. 64). See the CRA penalties guide.

Article 14 reporting obligations start September 11, 2026. Full compliance is required by December 11, 2027. See the full CRA implementation timeline.

This guide on ISO 27001 vs CRA maps exactly where your ISMS helps, where it falls short, and what you need to add.

What Does ISO 27001 Cover vs What the CRA Requires?

What ISO 27001 Covers

ISO 27001 is an information security management system (ISMS) standard covering:

Organization-level controls:

• Information security policies
• Asset management
• Access control (to systems and data)
• Cryptography use
• Physical security
• Operations security
• Communications security
• Supplier relationships
• Incident management
• Business continuity
• Compliance management

Focus: Protecting your organization's information assets

What CRA Covers

CRA is a product regulation covering (Annex I):

Product-level requirements:

• Security-by-design in products
• No known exploitable vulnerabilities
• Secure default configuration
• Protection from unauthorized access (in product)
• Data protection (by product)
• Update capability (of product)
• Vulnerability handling and ENISA reporting (for product)
• SBOM for product components (Art. 13(5))
• Coordinated vulnerability disclosure policy (Art. 13(6))
• Public vulnerability contact (Art. 13(7))
• CE marking and conformity assessment

Focus: Ensuring products you sell are secure

The CRA classifies products into categories: default, Important Class I, Important Class II, and Critical (Annex III and IV). Each category carries different conformity assessment requirements. An Important Class II product requires mandatory third-party assessment by a notified body, regardless of your ISO 27001 certification status. See the CRA product classification guide.

The Fundamental Difference

ISO 27001 vs CRA SCOPE

ISO 27001:
"How does your ORGANIZATION manage security?"
+---------------------------------------------+
| Your Company                                |
| +---------+ +---------+ +---------+         |
| | Systems | | Data    | | People  |         |
| \---------+ \---------+ \---------+         |
| +---------+ +---------+ +---------+         |
| | Process | | Network | | Facilit |         |
| \---------+ \---------+ \---------+         |
\---------------------------------------------+

CRA:
"How secure are the PRODUCTS you sell?"
+---------------------------------------------+
| Your Products (sold to customers)           |
| +---------+ +---------+ +---------+         |
| |Product A| |Product B| |Product C|         |
| \---------+ \---------+ \---------+         |
|                                             |
| Each product must meet CRA requirements     |
\---------------------------------------------+

Where ISO 27001 Helps CRA and Where It Falls Short

Where ISO 27001 Helps CRA

Where ISO 27001 Falls Short

Gap Analysis Summary

Strong Foundation (ISO 27001 helps significantly):

• Security culture and awareness
• Risk management methodology
• Incident response capability
• Supplier security management
• Secure development lifecycle policies
• Access control framework
• Documentation practices

Partial Coverage (ISO 27001 helps but is not sufficient):

• Vulnerability management (organizational scope vs. product scope)
• Cryptography (policy vs. product implementation)
• Security testing (enterprise systems vs. product testing)
• Change management (IT change vs. product modification)
• SBOM (component awareness in A.8.26/A.8.28 vs. machine-readable SBOM format)

Gaps (CRA-specific, not covered by ISO 27001):

• SBOM generation and maintenance in a standardized format
• Product conformity assessment
• CE marking process
• Vulnerability reporting to national CSIRT via Single Reporting Platform (Art. 14)
• Product-specific technical file (Annex VII)
• Support period commitment (Art. 13(8))
• Secure default configuration verification
• Product update mechanism requirements
• Coordinated vulnerability disclosure policy (Art. 13(6))
• Public vulnerability reporting contact (Art. 13(7))

How to Leverage ISO 27001 for CRA

Use Your ISMS as Foundation

If you are ISO 27001 certified, you have strong foundations to build on. The key is extending existing processes toward product obligations rather than starting from scratch.

Extend existing processes:

New processes to add:

Practical Integration Steps

Step 1: Scope Extension

• Add product security to your ISMS scope
• Include product development in risk assessment
• Extend asset inventory to include product components

Step 2: Process Updates

• Update vulnerability procedure for product reporting to national CSIRT via the Single Reporting Platform
• Add SBOM to change management
• Include the 24h early warning, 72h initial notification, and final report cadence in your incident response process

Step 3: Documentation Additions

• Product technical files
• SBOM records
• Conformity assessment evidence
• Support period documentation

Step 4: Roles and Responsibilities

• Assign product security ownership
• Define CSIRT reporting responsibility
• Establish SBOM maintenance ownership
• Assign CVD policy ownership

ISO 27001 Annex A Controls and CRA

Most Relevant Controls

A.8.25 Secure development lifecycle

• ISO 27001: Policies for secure development
• CRA use: Foundation for product security requirements (Annex I, Part I)

A.8.26 Application security requirements

• ISO 27001: Security requirements in development
• CRA use: Basis for product essential requirements; partial foundation for SBOM component inventory

A.8.27 Secure system architecture

• ISO 27001: Secure architecture principles
• CRA use: Product security architecture

A.8.28 Secure coding

• ISO 27001: Secure coding practices including dependency tracking
• CRA use: Product code security; partial foundation for SBOM component awareness

A.8.8 Management of technical vulnerabilities

• ISO 27001: Organizational vulnerability handling
• CRA use: Extend to product vulnerabilities + reporting to national CSIRT via Single Reporting Platform (Art. 14)

A.5.19-22 Supplier relationships

• ISO 27001: Supplier security management
• CRA use: SBOM collection from suppliers, supply chain security

Control Implementation for CRA

EXTENDING ISO 27001 CONTROLS FOR CRA

A.8.8 VULNERABILITY MANAGEMENT EXTENSION:

ISO 27001 Requirement:
"Information about technical vulnerabilities of
information systems in use shall be obtained..."

CRA Extension (Art. 14):
- Monitor for vulnerabilities in YOUR PRODUCTS
- Maintain process for customer notification
- Report to national CSIRT via Single Reporting Platform:
  24h early warning, 72h initial notification,
  14-day final report (active exploit) or
  1-month final report (severe incident)
- Track vulnerability status per product
- Generate VEX documents

A.8.25-28 SECURE DEVELOPMENT EXTENSION:

ISO 27001 Requirement:
"Rules for the development of software and systems
shall be established and applied..."

CRA Extension:
- Include SBOM generation in build process (Art. 13(5))
- Verify "secure by default" configuration
- Test product security requirements
- Document for technical file (Annex VII)
- Maintain evidence for conformity assessment

Does ISO 27001 Certification Count Toward CRA Conformity Assessment?

Does ISO 27001 Certification Cover CRA Compliance?

Critical understanding:

• ISO 27001 certification shows organizational security maturity
• CRA compliance is a per-product regulatory requirement
• Having ISO 27001 does not exempt you from CRA
• ISO 27001 auditors do not assess CRA compliance

Article 14 reporting obligations start September 11, 2026. Full compliance is required by December 11, 2027. Non-compliance carries fines up to EUR 15 million or 2.5% of global annual turnover (Art. 64).

Using ISO 27001 in CRA Context

HOW TO REFERENCE ISO 27001 IN CRA DOCUMENTATION

IN TECHNICAL FILE:
"[Company] maintains an ISO/IEC 27001:2022 certified
Information Security Management System (Certificate
No. XXX, issued by [Certification Body]).

The ISMS provides the organizational foundation for
product security, including:
- Secure development lifecycle (A.8.25-28)
- Vulnerability management process (A.8.8)
- Supplier security requirements (A.5.19-22)

Product-specific CRA compliance is documented in
this technical file, building on these ISMS controls."

WHAT THIS SHOWS:
- Security management maturity
- Process foundation exists
- Not a substitute for product evidence

Audit Synergies

ISO 27001 surveillance audit:

• Annual assessment of ISMS
• Can include product security scope
• Evidence reusable for CRA

CRA conformity assessment:

• Product-specific evaluation
• References ISMS for process evidence
• Needs additional product evidence

Synergy opportunities:

• Align audit schedules
• Reuse evidence where applicable
• Integrated management system approach
• Single documentation repository

Three Common ISO 27001 + CRA Scenarios

Scenario 1: ISO 27001 Certified, Starting CRA

Advantages you already have:

• Risk methodology exists
• Security culture established
• Documentation practices in place
• Supplier management exists
• Incident response capability

What you still need to add:

• [ ] Product classification per CRA (Annex III/IV)
• [ ] SBOM generation capability (Art. 13(5))
• [ ] CSIRT reporting process (Art. 14)
• [ ] Product technical files (Annex VII)
• [ ] Conformity assessment process
• [ ] Support period management (Art. 13(8))
• [ ] Product-specific security testing
• [ ] CVD policy (Art. 13(6))
• [ ] Public vulnerability contact (Art. 13(7))

Approach:

1. Gap assessment against CRA requirements
2. Extend ISMS scope to include products
3. Add CRA-specific processes
4. Update documentation
5. Train relevant teams

Scenario 2: No ISO 27001, Approaching CRA

Option A: CRA only

• Implement CRA requirements directly
• Product-focused approach
• May miss organizational security benefits
• Faster path to CRA compliance

Option B: ISO 27001 + CRA

• Implement both frameworks
• Stronger overall security posture
• More work upfront
• Better long-term position

Recommendation: For product manufacturers, start with CRA requirements (the regulatory deadline is fixed) and build toward ISO 27001 over time. Align approaches from the beginning so work is not duplicated. See the CRA startups guide for a minimal-overhead path.

Scenario 3: Multiple Products, Central ISMS

Centralized (ISMS):

• Risk methodology
• Vulnerability handling process
• Supplier management
• Incident response
• Development standards

Per-product (CRA):

• Technical file
• SBOM
• Conformity assessment
• Product documentation
• Support period

Benefits:

• Efficient process reuse
• Consistent security approach
• Centralized expertise
• Product-specific compliance

How to Integrate CRA Into Your Existing ISMS

Governance Model

INTEGRATED GOVERNANCE MODEL

ORGANIZATIONAL LEVEL (ISO 27001):
+---------------------------------------------+
| Information Security Management System      |
|                                             |
| - Security policies                         |
| - Risk management framework                 |
| - Security organization                     |
| - Awareness and training                    |
\---------------------------------------------+
            |
            ▼
PRODUCT LEVEL (CRA):
+---------------------------------------------+
| Product Security Compliance                 |
|                                             |
| +---------+ +---------+ +---------+         |
| |Product A| |Product B| |Product C|         |
| |- Tech   | |- Tech   | |- Tech   |         |
| |  file   | |  file   | |  file   |         |
| |- SBOM   | |- SBOM   | |- SBOM   |         |
| |- DoC    | |- DoC    | |- DoC    |         |
| \---------+ \---------+ \---------+         |
\---------------------------------------------+

Documentation Structure

INTEGRATED DOCUMENTATION

ISMS DOCUMENTATION (ISO 27001):
+-- Information Security Policy
+-- Risk Assessment Procedure
+-- Statement of Applicability
+-- Secure Development Policy
+-- Vulnerability Management Procedure
+-- Incident Response Procedure
\-- Supplier Security Policy

CRA DOCUMENTATION (Per Product):
+-- Product Technical File (Annex VII)
|   +-- Product description
|   +-- Risk assessment
|   +-- Security architecture
|   +-- Test reports
|   \-- SBOM
+-- EU Declaration of Conformity
+-- User Documentation
\-- Support Period Statement

CROSS-REFERENCES:
- Technical file references ISMS procedures
- ISMS procedures include CRA requirements
- Records retained for 10 years or support period,
  whichever is longer (Art. 23(2))

Checklist: ISO 27001 Organization Adding CRA

Assessment:

• [ ] Review current ISMS scope
• [ ] Identify products with digital elements
• [ ] Classify products per CRA categories (Annex III/IV)
• [ ] Gap analysis: ISMS vs. CRA requirements

Scope Extension:

• [ ] Add product security to ISMS scope
• [ ] Update risk assessment to include products
• [ ] Extend Statement of Applicability

Process Additions:

• [ ] SBOM generation process (Art. 13(5))
• [ ] CSIRT reporting procedure (Art. 14)
• [ ] Conformity assessment process
• [ ] Support period management (Art. 13(8))
• [ ] Product technical file procedure (Annex VII)
• [ ] CVD policy (Art. 13(6))
• [ ] Public vulnerability contact setup (Art. 13(7))

Documentation:

• [ ] Technical file templates
• [ ] Product risk assessment template
• [ ] SBOM format and storage
• [ ] Declaration of Conformity template

Control Extensions:

• [ ] A.8.8: add product vulnerabilities and CSIRT reporting
• [ ] A.8.25-28: add product security testing
• [ ] A.5.19-22: add SBOM from suppliers

Roles:

• [ ] Assign product security owner
• [ ] Define CSIRT reporting responsibility
• [ ] Establish conformity assessment role
• [ ] Assign CVD policy owner

Training:

• [ ] CRA awareness for development teams
• [ ] SBOM tools training
• [ ] Conformity assessment training

Official ISO 27001 and CRA Resources

ISO 27001:

• ISO/IEC 27001:2022: Information security management
• ISO/IEC 27002:2022: Information security controls

CRA:

• Regulation (EU) 2024/2847: Cyber Resilience Act
• ENISA CRA requirements standards mapping (November 2024)

Complementary standards:

• ISO/IEC 27034: Application security (bridges ISMS and product security)
• IEC 62443: Industrial security (strong fit for OT/IoT manufacturers; strong candidate for CRA harmonized standard)
• ISO/SAE 21434: Automotive security

Next Steps

1. Run a gap analysis of your ISMS Annex A controls against CRA Annex I. Start with A.8.8, A.8.25-28, and A.5.19-22. These carry most of the weight.
2. Classify each product under Annex III and IV. The conformity assessment route depends on this, not on your ISO 27001 certification status.
3. Extend your ISMS scope statement to include product security. Update the Statement of Applicability so product obligations are visible to auditors.
4. Add SBOM generation (Art. 13(5)) to your change management process. CycloneDX or SPDX, machine-readable, tied to each release.
5. Create or update the CSIRT reporting procedure for Article 14: 24h early warning, 72h initial notification, final report within 14 days or 1 month depending on incident type.
6. Assign a product security owner and a CVD policy owner (Art. 13(6)/(7)). These cannot be the same ambiguous "security team" slot.
7. Schedule a combined internal audit covering both ISO 27001 surveillance and CRA technical file readiness. Reuse evidence where it applies.

Check CRA conformity assessment routes to confirm which module applies to each product. See the CRA implementation timeline for the September 2026 and December 2027 deadlines.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.