EU Cyber Resilience Act — Guide for Chief Operating Officer (COO)

The CRA places legal obligations on the manufacturer — the legal entity that places a product on the market or has it placed under its name. As COO, you are operationally responsible for ensuring the organisation has the processes, resources, and governance to meet these obligations continuously, not just at market launch.

Key operational obligations that fall under COO oversight:

• Article 13: the organisation must maintain a documented secure development lifecycle, produce and update SBOMs, and keep the technical file current throughout the product's support period
• Article 14: the organisation must operate a vulnerability disclosure and incident notification process capable of meeting strict timelines — 24 hours for early warning, 72 hours for notification to ENISA and the national CSIRT
• Article 13(8): the organisation must deliver security updates for the duration of the stated support period — this is an operational commitment with resource implications that must be planned and funded
• Market surveillance cooperation (Article 13(13)): the organisation must cooperate with national market surveillance authorities and be operationally ready to produce technical file documentation on request

The COO should establish a CRA Programme Office or equivalent governance function with a named programme lead, defined accountability matrix, and quarterly board reporting.

CRA compliance spans Engineering, Security, Legal, Product, and Operations — making cross-functional programme coordination the COO's most critical contribution to the compliance effort.

Effective CRA programme governance includes:

• Named function owners: designate a CRA lead in each affected function (Engineering, Security, Legal, Product, Operations) with defined deliverables and escalation paths to the COO
• Programme cadence: establish a monthly CRA steering meeting covering open gaps, remediation progress, and upcoming milestone deadlines — particularly the CRA application date for products in scope
• Dependency tracking: maintain a programme-level dependency map showing which workstreams block others — for example, the SBOM cannot be finalised until Engineering completes dependency inventories
• Gap register: maintain a centralised register of identified compliance gaps with severity, owner, target close date, and escalation status
• Declaration of Conformity coordination: the Declaration of Conformity (Annex IV) must be signed by a person authorised to commit the legal entity — the COO or CEO typically signs, making awareness of what is being attested to legally essential

The programme governance structure should be documented and included as an organisational reference in the technical file.

Annex I §10 requires manufacturers to address supply chain security, and Article 13(6) requires SBOM coverage of all components including those sourced from third parties. The COO, working with the Supply Chain Manager and Legal, must ensure procurement processes operationally enforce these requirements.

Operational supply chain controls the COO should establish:

• CRA-compliant supplier contracts: all contracts with suppliers of hardware components, firmware, software SDKs, and cloud services integral to regulated products must include CRA-aligned obligations — prompt CVE disclosure, SBOM provision, security incident notification, and patch delivery timelines
• Supplier onboarding process: add a security assessment checkpoint to supplier onboarding for all suppliers of components that will be included in regulated products
• SBOM collection process: establish an operational process to collect and maintain SBOM data from key suppliers — this cannot be a one-time request; it must be continuous as suppliers release new component versions
• EOL component tracking: operate a process to identify when key components approach end-of-life, trigger replacement qualification before EOL, and avoid placing products with EOL components on the market without a documented mitigation

Supply chain compliance gaps are among the most common findings in CRA readiness assessments — prioritising this area early in the programme is operationally prudent.

Article 14 imposes three time-bound notification obligations that require operational machinery to execute under pressure:

• 24-hour early warning to ENISA and the relevant national CSIRT: filed within 24 hours of the manufacturer becoming aware of an actively exploited vulnerability
• 72-hour notification: full technical details of the vulnerability, affected products, and remediation plan — filed within 72 hours
• 14-day final report: complete incident analysis with remediation status and lessons learned

Meeting these timelines operationally requires preparation well before any incident occurs:

• Runbook: a documented incident response runbook for Article 14 notifications specifying who is notified internally, who drafts the submission, who signs it, and which regulatory contacts to use
• Contact registry: maintain current contacts for ENISA and the relevant national CSIRT(s) in all markets where products are sold — update contacts quarterly
• Authority for notification: designate who has authority to submit notifications to ENISA — waiting for board approval during an incident will cause a breach of the 24-hour deadline
• Tabletop exercises: conduct at least one Article 14 tabletop exercise per year, simulating discovery of a critical vulnerability and running through the notification process in real time

Operational readiness for Article 14 should be treated as a standing operational obligation, not a one-time setup.

Practical first steps for COOs building CRA operational readiness:

• Appoint a CRA Programme Lead with cross-functional authority and a direct reporting line to the COO — do not distribute ownership without a coordination point
• Conduct a product portfolio scoping exercise to identify which products are in scope, their likely classification (standard/Class I/Class II under Annex III), and the conformity assessment route each requires
• Audit supplier contracts for CRA-relevant obligations — identify contracts that need renegotiation before the CRA application date
• Build the Article 14 runbook: draft the internal escalation process, regulatory contact list, and notification template before any incident occurs
• Schedule a CRA programme kickoff with all function leads, assign gap owners, and establish the monthly steering cadence
• Commission a CRA Readiness Score via CVD Portal to establish an independent baseline of where the organisation stands against Annex I and Article 14 obligations
• Present a CRA programme plan to the Board with a risk register and resource ask — the Board needs to understand the legal exposure of non-compliance before the CRA application date