Pour les ChampionsPour le RSSIPour le DPOPour les responsables conformitéPour les StartupsPour les fabricants
CRA Quick-CheckBoard Assurance ChecklistRequired Core ArtefactsAtelier
TarifsÀ proposContactEssayer gratuitement
Langue
DEENFR
trusttroiai
Commencer gratuitement
Cette ressource est actuellement présentée en anglais. La version française suivra.
A TrustTroiAI resource · CRA Annex VII perspective

Required Core Artefacts.

The fourteen artefacts that carry your Cyber Resilience Act technical documentation across five project phases.

The Cyber Resilience Act (CRA) requires technical documentation under Annex VII as evidence of conformity. This overview lists the fourteen mandatory artefacts across five project phases, each with purpose, content, location and refresh trigger.

Phase 01

Design

The design phase lays the foundation for all later conformity evidence. Three artefacts must exist here, otherwise the technical documentation has no basis.

1.1

Product Security Context Note

Purpose
Defines the scope, assumptions, and security objectives of the product. Basis for every subsequent risk assessment.
Content
Intended use, deployment environments, user and admin roles, data types and sensitivity, key external dependencies.
Location
`docs/security/product-context.md` in the repository or wiki page.
Refresh trigger
New intended use, substantial change of deployment environment, new critical dependency.
CRA Annex VII (points 1 and 2)
1.2

Architecture and Trust-Boundary Diagram

Purpose
Shows the system structure with trust boundaries, data flows, and attack surfaces. Basis for threat modelling.
Content
Main components, external entities, data stores, entry points, trust boundaries.
Location
`docs/architecture/trust-boundaries.md` with embedded diagram or wiki page with Draw.io reference.
Refresh trigger
New interface, new dependency, major architecture change.
CRA Annex I, Part 1 (PT1.1, PT1.2.d, e, f, j)
1.3

Top Threats and Mitigations List

Purpose
Prioritised list of the most important threats with assigned mitigations and verification tests.
Content
Five to ten top threats with priority (H/M/L), assigned mitigation, verification test, refresh trigger.
Location
`docs/security/top-threats.md` or Jira board with a dedicated label.
Refresh trigger
New threat modelling cycle, new incident, new vulnerability in similar products.
CRA Annex I, Part 1
Phase 02

Development

During development, the artefacts arise that show cybersecurity is anchored in the code itself, not only in the documentation. Three artefacts make this anchoring visible.

2.1

Secure Coding Baseline

Purpose
One-page standard for secure coding in the primary stack, plus list of banned patterns.
Content
Rules on input validation, auth checks, error handling, crypto usage, logging. Banned patterns like string-based SQL, `eval`-like functions, TLS verification disabling.
Location
`docs/security/coding-baseline.md` and `.gitattributes` or similar repo configuration.
Refresh trigger
New tech-stack version, new banned patterns from incident learnings.
CRA Annex I, Part 1 (PT1.2.a), Part 2 (PT2.3)
2.2

CODEOWNERS or Equivalent

Purpose
Enforces peer review for security-relevant changes through protected branches.
Content
File with mapping of paths (auth, crypto, update mechanism, external interfaces) to responsible reviewers.
Location
`.github/CODEOWNERS` or equivalent file in the repository root.
Refresh trigger
Team change, new sensitive modules.
CRA Annex I, Part 2 (PT2.3)
2.3

SBOM per Release

Purpose
Machine-readable inventory of all software components in a release, basis for vulnerability response.
Content
SPDX or CycloneDX format, all direct and transitive dependencies with version and licence.
Location
As a build artefact in the release folder, linked from the release notes page.
Refresh trigger
Every release build, automatically from the build pipeline.
CRA Annex I, Part 2 (PT2.1, explicit SBOM requirement)
Phase 03

Verification

Verification is the point at which evidence emerges. Two artefacts turn tests and reviews into audit-ready proof.

3.1

Release Security Checklist

Purpose
Standard pre-release checklist with pass/fail criteria and documented exceptions.
Content
SAST scan result, dependency scan result, threat model updated, negative tests passed, vulnerability triage completed.
Location
`.github/pull_request_template.md` or release ticket template.
Refresh trigger
New verification category, change of release cadence.
CRA Annex I, Part 2 (PT2.3)
3.2

Known Issues and Residual Risk Log

Purpose
Registers known vulnerabilities not remediated in the current release, with justification and expiry date.
Content
Vulnerability ID, severity, reason for non-remediation, compensating control, owner, review date.
Location
`docs/security/residual-risk-log.md` or dedicated Jira board with a label.
Refresh trigger
Every newly identified risk that cannot be immediately remediated.
CRA Annex I, Part 2 (PT2.2)
Phase 04

Deployment

Deployment is the transition from build to operation. Three artefacts must accompany the transition so that users and board know what they are engaging with.

4.1

Support Period Decision Record

Purpose
Documents the defined support period per product with justification.
Content
Product name, support start date, support end date (month and year), justification based on expected use, review date.
Location
`docs/lifecycle/support-period-{product}.md` or product management system.
Refresh trigger
Product roadmap change, market development.
CRA Article 13(8), Article 13(19)
4.2

Secure Update Process Description

Purpose
Describes the end-to-end process for delivering security updates.
Content
Signing process, distribution mechanism, integrity check, rollback procedure, user notification.
Location
`docs/lifecycle/update-process.md`.
Refresh trigger
Change of update mechanism, new signing requirement.
CRA Annex I, Part 1 (PT1.2.c), Part 2 (PT2.7, PT2.8)
4.3

User Information and Instructions

Purpose
Security-relevant information and instructions accompanying the product (per Annex II).
Content
Security configuration guide, end-of-life date, secure decommissioning, reporting contact for vulnerabilities.
Location
As accompanying documentation with the product or on the product support page.
Refresh trigger
Change of security default configuration, end of support.
CRA Annex II
Phase 05

Maintenance

After release, the longest part of the product life begins. Three artefacts carry compliance through the support period.

5.1

Vulnerability Handling Process

Purpose
Intake-to-fix workflow for vulnerabilities, with SLAs per severity.
Content
Reporting channels (CVD, internal scans, customer reports), triage owners, SLA matrix (Critical/High/Medium/Low), escalation path.
Location
`docs/security/vulnerability-process.md`.
Refresh trigger
Change of SLAs, new reporting channels.
CRA Annex I, Part 2 (PT2.2, PT2.5, PT2.6, PT2.7, PT2.8)
5.2

Article 14 Reporting Playbook

Purpose
Action guide for the 24-hour early warning, 72-hour notification, and the final report to ENISA.
Content
Decision tree for reportability, templates for the three notifications, access credentials for the ENISA reporting platform, owners.
Location
`docs/security/article14-playbook.md` with reference to a protected credential store.
Refresh trigger
Change of reporting platform, findings from a real incident.
CRA Article 14, applies from 11 September 2026
5.3

Security Changelog

Purpose
Public register of all security-relevant changes with CVE references and impact statements.
Content
Release version, date, fixed vulnerabilities (CVE IDs), affected product versions, remediation guidance.
Location
Security advisories page on the product website, plus advisory mailing list.
Refresh trigger
Every release with security impact.
CRA Annex I, Part 2 (PT2.4, PT2.8)

From artefact to work-piece.

When an artefact is missing, Inspector spots the gap directly in your Jira and delivers the signed template through Cronos.

Install Inspector for Jira