The CRA does not prescribe a particular organisational chart or RACI model. A cross-functional responsibility matrix is nevertheless useful because Article 13 duties span planning, design, development, production, delivery, maintenance, vulnerability handling, technical documentation and conformity. The strongest model separates legal accountability from operational ownership and connects every assigned task to evidence that can be maintained throughout the product lifecycle.
Internal Allocation Does Not Change the Legal Manufacturer Role
Internal allocation does not change the legal manufacturer role. A manufacturer can assign work to product managers, engineers, security specialists, compliance staff, contractors and other teams, but the CRA obligations assigned to the manufacturer remain with the manufacturer as the relevant legal entity. Internal delegation should therefore explain who performs each task without implying that the statutory obligation itself has moved to an employee or department.
The CRA Does Not Require a Particular RACI Model
The CRA does not require a particular RACI model or organisational chart. A responsibility matrix is an implementation tool rather than a statutory form. It can nevertheless help a manufacturer demonstrate that cybersecurity risk assessment, Annex I implementation, technical documentation, vulnerability handling, conformity, reporting and post-market corrective work have clear operational owners.
Legal and Compliance Should Own the Regulatory Interpretation Layer
Legal and compliance teams should coordinate the interpretation of CRA scope, economic-operator roles, product classification, applicable conformity routes, regulatory deadlines and changes in guidance. They should also ensure that product teams understand which CRA obligations apply. Legal and compliance should not become the sole owner of technical evidence that only engineering or product security can create.
Product Management Should Own Product-Boundary and Lifecycle Decisions
Product management is well placed to maintain the intended purpose, product boundary, supported functionality, planned release lifecycle and customer-use assumptions that feed the cybersecurity risk assessment. Product management should also coordinate support-period decisions and flag changes in intended purpose, architecture or market model that can require renewed CRA scope, risk or conformity analysis.
Engineering Should Own Secure Design and Implementation Evidence
Engineering teams should implement the technical controls needed to satisfy the applicable Annex I essential cybersecurity requirements. They should maintain architecture, design decisions, test results, dependency information and implementation evidence that supports the cybersecurity risk assessment and technical documentation. Engineering is responsible for performing much of the technical work, but the legal manufacturer remains responsible for ensuring the product complies.
Product Security Should Coordinate the Cybersecurity Risk Assessment
Product security should normally coordinate the cybersecurity risk assessment with engineering and product management. That work should identify relevant threats, assets, attack surfaces, reasonably foreseeable use, security assumptions and residual risk. Product security should also connect the assessment to vulnerability handling, security testing, component monitoring and post-market risk review.
Procurement Should Control Third-Party Component Evidence
Procurement and supply-chain teams should support the Article 13 due diligence required for integrated third-party components. Their process should preserve supplier identity, component versions, security information, contractual vulnerability-notification duties and access to technical evidence. Procurement should work with engineering and product security rather than treating cybersecurity as a commercial supplier questionnaire only.
Quality and Release Teams Should Gate Market Placement
Quality, release or product-compliance teams should maintain a release gate that confirms required CRA evidence is complete before market placement. That gate can include the cybersecurity risk assessment, technical documentation, test evidence, conformity-assessment result, EU declaration of conformity, CE marking, Annex II information, manufacturer identification and support-period information where applicable.
Technical Documentation Needs a Named Evidence Owner
Technical documentation is inherently cross-functional. Engineering may provide architecture and testing evidence, security may provide risk and vulnerability records, product management may provide intended-purpose information, and compliance may maintain conformity records. One function should nevertheless be assigned responsibility for ensuring that the complete technical documentation set remains current, internally consistent and retrievable.
Vulnerability Management Needs a Clear Operational Owner
A designated product-security or vulnerability-management function should operate the process for receiving vulnerability reports, triaging them, identifying affected product versions, coordinating remediation and tracking security updates. Engineering, suppliers and support teams can participate, but the process should have one clear operational owner and defined escalation routes.
Article 14 Reporting Needs a Separate Regulatory Escalation Path
Article 14 reporting should have a defined escalation path from technical detection to regulatory decision and submission. Product security or incident response may determine the technical facts, while legal or compliance may help assess the reporting condition and required content. The manufacturer remains the reporting party under Article 14 even when contractors or internal teams perform parts of the workflow.
Customer Support Should Connect Users to Product Security
Customer support should know how to route vulnerability reports and security complaints to the designated product-security contact without unnecessary delay. Support teams should also have reliable information about supported versions, security updates and the end of the support period so that customer communications remain consistent with the manufacturer's CRA commitments.
Executive Governance Should Own Unresolved Compliance Risk
Senior product or compliance governance should provide escalation for unresolved cybersecurity risk, release exceptions, supplier evidence gaps, delayed remediation and disagreements over conformity. This does not mean every CRA decision requires executive approval. It means material issues that could cause a non-compliant product to be placed or remain on the market should have a defined accountable escalation path.
Keep Legal Accountability Separate From Operational Ownership
A useful CRA responsibility matrix should contain at least the legal economic operator, operational owner, supporting teams, required evidence, approval point and review trigger for each obligation. This prevents a common governance error in which a department is labelled responsible and the organisation loses sight of the manufacturer or other economic operator that remains legally accountable.
Use Review Triggers Across the Product Lifecycle
The responsibility model should include review triggers for new product versions, substantial modifications, new third-party components, architecture changes, new markets, supplier changes, changes in intended purpose, newly discovered vulnerabilities, serious security events and the approach of end of support. These review triggers help ensure that internal ownership and supporting evidence remain aligned as the product changes.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.