A TrustTroiAI resource · CRA board perspective

Board Assurance Checklist.

The fifteen governance controls your board needs for a Cyber Resilience Act audit, in language it can answer.

The Cyber Resilience Act (CRA) requires manufacturers of digital products to demonstrate cybersecurity across the whole product lifecycle. This checklist translates the CRA's governance requirements into fifteen concrete board questions with clear evidence patterns.

Area 01

Risk management and security by design

Whether your product is developed CRA-compliant is not decided in the conformity assessment, but in the design phase. The three controls of this area check whether risk thinking exists before the code.

1.1

Documented Risk Assessment

Board question

Can you produce the cybersecurity risk assessment for your most important product within five minutes, with date, owner, and trigger rules?

Evidence pattern

Version-controlled document in repository or wiki, with process description, trigger catalogue, and ownership assignment.

CRA Article 13(2)

1.2

Threat Modelling as Release Gate

Board question

Is threat modelling a release gate that cannot be skipped, or a recommendation that gets dropped under time pressure?

Evidence pattern

Release checklist with threat modelling item and documented exceptions with approver and expiry date.

CRA Annex I, Part 1

1.3

Supply Chain Risk Register

Board question

In the case of a critical CVE, do you know within 24 hours which of your products are affected?

Evidence pattern

SBOM per release, automatically matched against CVE feeds, with an owner for triage.

CRA Annex I, Part 2 (PT2.1)

Area 02

Governance and documentation

Technical documentation under Annex VII must be kept for ten years. The three controls of this area check whether this documentation is alive, or whether it collapses as a facade at the first audit.

2.1

Current Technical File

Board question

Does your technical file reflect the currently shipped product version, or the version from three releases ago?

Evidence pattern

Version-controlled document with timestamp of last update, linked to the current release tag.

CRA Article 31, Annex VII

2.2

Named Cyber-Compliance Owner

Board question

Who at your company makes the Article 14 reportability decision within 24 hours if a zero-day appears tonight?

Evidence pattern

Named person with documented deputy arrangement, access to the ENISA reporting platform already set up and tested.

CRA Article 14, applies from 11 September 2026

2.3

Board-Level Risk Integration

Board question

Is product cybersecurity on the agenda of your regular executive review, or does it exist in parallel in a tools team?

Evidence pattern

Minutes of the last three executive sessions with cybersecurity agenda item, cybersecurity risks in the enterprise risk register.

CRA Article 13(1), Article 64 (penalties)

Area 03

Vulnerability and patch management

Vulnerability management is the domain where compliance becomes visible in real time. The three controls of this area check whether you are operational in an emergency.

3.1

Public Vulnerability Disclosure Policy

Board question

Can external security researchers reach you, or do they have to go through the general support inbox?

Evidence pattern

Published CVD policy on the product website, security.txt file on the public domains, documented test report of at least one real submission.

CRA Annex I, Part 2 (PT2.5, PT2.6)

3.2

Vulnerability SLA Tracked and Met

Board question

Do you know your own time from vulnerability report to patch release, and does it fall within your SLA more often than outside?

Evidence pattern

Vulnerability tracking board with severity, owner, target dates, and actual remediation time, trend analysis of the last three months.

CRA Annex I, Part 2 (PT2.2, PT2.7)

3.3

Article 14 Reporting Playbook Tested

Board question

Has your reporting process been tested at least once on a real security event, or is it a paper process?

Evidence pattern

Documented reportability decision for at least one event, with timestamp and rationale, also for non-reportable cases.

CRA Article 14, applies from 11 September 2026

Area 04

Product lifecycle

The support period is the longest contractual obligation in the CRA. The three controls of this area check whether you can back this obligation with resources and processes.

4.1

Support Period Decision Record

Board question

Is the end date of the support period visible at the time of purchase for each of your products, and is the choice justified?

Evidence pattern

Support Period Decision Record per product with justification of the duration, end date visible on product page or datasheet.

CRA Article 13(8), Article 13(19)

4.2

Secure Update Mechanism

Board question

Are your security updates cryptographically signed, securely distributed, and delivered with rollback capability, or are they a simple file replacement?

Evidence pattern

Documented update process with signing, integrity check, rollback test case from the last release cycle.

CRA Annex I, Part 1 (PT1.2.c), Part 2 (PT2.7, PT2.8)

4.3

End-of-Life Communication Plan

Board question

Do your users know what happens when the support period ends, and is there a migration path?

Evidence pattern

End-of-life plan template with communication timeline, migration guidance, and documented past EOL communications.

CRA Article 13, Annex II

Area 05

Awareness and skills

Without a competent team, all other controls remain paper. The three controls of this area check whether the people who should produce the conformity have the prerequisites for it.

5.1

Secure Coding Baseline Enforced

Board question

Does a secure-coding standard exist for your primary stack, is it enforced in the CI pipeline, and is it actually followed?

Evidence pattern

One-page baseline file in the repository, SAST rules that match the banned patterns, PR checklist with reference to the baseline.

CRA Annex I, Part 1 (PT1.2.a), Part 2 (PT2.3)

5.2

Peer Review for Security-Sensitive Changes

Board question

Can security-relevant changes to authentication, cryptography, or external interfaces go to production without a second pair of eyes?

Evidence pattern

CODEOWNERS file with security-relevant paths, protected branches with PR review requirement, evidence of enforcement in the last release.

CRA Annex I, Part 2 (PT2.3)

5.3

Continuous Learning Loop

Board question

When an incident happens, is the finding fed back into design and process, or does it stay in the memory of those involved?

Evidence pattern

Post-incident review template, at least one backlog item from a review in the last quarter, update of the risk assessment documented.

CRA Recital 15, Annex I Part 2 (PT2.3)

From checklist to work-piece.

When a control is not yet in place, Inspector spots the gap directly in your Jira and delivers the signed template through Cronos.

Install Inspector for Jira