Luca BertonThe CRA requires a technical file for every product: risk assessment, design description, test results, SBOM, vulnerability handling policy, and more. Manually compiling this for each product is a multi-month effort. Automating it from your development pipeline turns it into a continuous, living document.
What the Technical File Must Contain
- General product description and intended purpose
- Design and development description
- Cybersecurity risk assessment
- How essential requirements are addressed
- Test and validation results
- SBOM (Software Bill of Materials)
- Vulnerability handling and disclosure policy
- EU Declaration of Conformity
Automation Strategy
Auto-Generated Sections
- SBOM — Generated at build time from dependency analysis
- Test results — Extracted from CI/CD pipeline: unit tests, integration tests, security scans, penetration test reports
- Design description — Generated from architecture-as-code (C4 models, infrastructure diagrams from Terraform/Kubernetes manifests)
- Component list — Auto-cataloged from the build system
- Version history — Extracted from git history and release notes
Template-Driven Sections
- Risk assessment — Template with product-specific inputs; threat modeling framework (STRIDE/LINDDUN) pre-populated with common threats for the product category
- Essential requirements mapping — Checklist template mapping each CRA requirement to specific technical controls
- Vulnerability handling policy — Organization-wide template customized per product
Kubernetes Recipes
A practical guide for container orchestration and deployment by Grzegorz Stencel & Luca Berton (Apress).
Watch on Skillshare →The Living Technical File
Instead of a static PDF compiled before launch, the technical file becomes a continuously updated document. Every code change, every dependency update, every security scan result flows into it automatically. When a notified body or market surveillance authority requests it, you generate the current version in minutes — not months.