EU Cyber Resilience Act Documentation: What Manufacturers Should Have Written Down Now

Short answer: The EU Cyber Resilience Act (CRA) expects manufacturers of products with digital elements to handle vulnerabilities in a documented, repeatable way and to report actively exploited vulnerabilities on a deadline. The fastest way to be ready is one set of policies, standards and procedures that covers vulnerability handling, reporting and secure development, mapped to a common control set so it also supports ISO 27001, Network and Information Security Directive 2 (NIS2) and SOC 2 work.

What just happened that makes CRA documentation urgent?

On 21 October 2026, the European Commission, ENISA, CERT-EU, Europol EC3 and the CSIRTs network issued a joint statement on two critical PHP vulnerabilities. The statement also reminded manufacturers that, from 11 September 2026, actively exploited vulnerabilities must be reported through the CRA Single Reporting Platform, and that the main CRA requirements apply from 11 December 2027.

In other words, the reporting obligation is already live, and the broader product requirements are about a year away. Teams that wait for the 2027 date will be writing procedures while they are also trying to report.

Which CRA documents should a manufacturer have now?

Think in terms of viewing documentation through a Hierarchical Cybersecurity Governance Framework, policy sets intent, standards set measurable rules, procedures describe how people do the work, and records prove it happened. For CRA readiness, that means:

• Product security and vulnerability handling policy: management commitment to identify, fix and disclose vulnerabilities across the support period.
• Coordinated vulnerability disclosure standard: how outside researchers report issues, who triages them and the expected response targets.
• Exploited vulnerability reporting procedure: who decides a vulnerability is actively exploited, who submits the report, and the internal clock that starts when you become aware.
• Software Bill of Materials (SBOM) standard: which components are tracked, format, and how often the SBOM is refreshed.
• Secure development procedures: threat modeling, code review, security testing and release approval.
• Security update standard: how fixes are delivered, how users are notified and how long updates are provided.
• Records: vulnerability register, report submissions, update history and decisions on risk acceptance.

The CRA is not a compliance check box exercise, since the documentation component must reflect practices that are operational in the production environment.

Why build CRA documentation on a multi-framework set instead of a separate binder?

Most manufacturers that fall under the CRA already have other obligations: ISO 27001 certification, SOC 2 reports for customers, NIS2 duties for some EU entities, or NIST-based requirements from US customers. A separate CRA binder creates duplicate policies that drift apart over time.

The alternative is one document set mapped to a common control catalog. The Secure Controls Framework (SCF) publishes crosswalk mappings between its controls and many laws and frameworks, and its mapping library includes the EU Cyber Resilience Act. ComplianceForge's SCF-based content is mapped to the SCF, which the premium GRC content page describes as mapping to over 200 cybersecurity and data privacy laws, regulations and frameworks.

When your vulnerability management standard maps to SCF controls, one review cycle updates the language that supports CRA, ISO 27001 and SOC 2 at the same time. That content is also structured to load into the GRC platform you already use, so control owners see one requirement instead of three.

How should you sequence the work?

1. Write the exploited vulnerability reporting procedure first, because that obligation is already in effect.
2. Update your vulnerability management standard with severity ratings, remediation targets and exception approval. The Vulnerability & Patch Management Program covers this ground.
3. Document secure engineering practices for the development lifecycle. See the Secure Engineering & Data Privacy Program.
4. Map each document to SCF controls so the same text supports CRA and your other frameworks.
5. Assign owners and set a review schedule tied to product releases.

EU CRA Frequently Asked Questions (FAQ)

Does the CRA apply to software as well as hardware?

The CRA covers products with digital elements, which includes many software products. Scope has exclusions and special categories, so confirm your products against the regulation text.

What is the first CRA obligation to prepare for?

Reporting actively exploited vulnerabilities, which the ENISA joint statement says has applied since 11 September 2026.

Can our ISO 27001 policies cover the CRA?

Partly. ISO 27001 policies address many management system controls, but CRA adds product-specific duties such as vulnerability reporting and security updates. A mapped, multi-framework set lets you add those duties without duplicating everything else.

Do we need a GRC platform to manage CRA documentation?

No, but a GRC platform helps you assign owners and track reviews. What matters most is that the policies, standards and procedures inside it are complete, mapped and maintained.