The EU Cyber Resilience Act (CRA) is now a concrete reality. Your organization needs clear processes to translate these regulatory obligations into actionable engineering tasks. This template provides a structured approach to developing a CRA compliance workflow that your team can implement effectively.
Purpose of the Template
This workflow template is designed to help your team integrate CRA requirements into your software development lifecycle. It enables you to:
- Map CRA obligations to specific engineering tasks
- Assign responsibility for compliance activities
- Create audit trails to demonstrate due diligence
- Integrate compliance checks into your existing CI/CD pipelines
The template is applicable if you're developing or maintaining software with digital elements for the EU market. This includes open source maintainers collaborating with commercial entities or manufacturers using FOSS components.
Prerequisites
Before customizing this template, ensure you have:
Organizational Clarity:
- A designated product owner for CRA compliance
- Identification of products under CRA scope (products with digital elements)
- Clarity on whether you're a manufacturer, importer, or distributor under CRA definitions
Technical Foundation:
- Capability to generate a Software Bill of Materials (SBOM) in CycloneDX or SPDX format
- A version control system with branch protection
- A basic CI/CD pipeline for automated testing
- A vulnerability scanning tool such as Trivy or Grype
Documentation Baseline:
- Current architecture diagrams
- A dependency inventory
- Existing security policies
You don't need a complete compliance program to start. This template will help you build one.
The CRA Compliance Workflow Template
# CRA Compliance Workflow v1.0
## Phase 1: Component Intake and Assessment
### 1.1 Dependency Review (Per Sprint/Release)
**Owner:** [Engineering Lead]
**Frequency:** Each dependency addition or major version update
- [ ] Generate SBOM for current build
- [ ] Compare against previous SBOM to identify changes
- [ ] For each new dependency:
- [ ] Check for known vulnerabilities (CVE database)
- [ ] Verify license compatibility
- [ ] Document intended use and data flow
- [ ] Assess criticality (user-facing, security-sensitive, data processing)
**Output:** Updated dependency registry with risk ratings
### 1.2 Vulnerability Baseline
**Owner:** [Security Team]
**Frequency:** Weekly automated scan + triggered on dependency changes
- [ ] Run automated vulnerability scan
- [ ] Triage findings by severity and exploitability
- [ ] Create tickets for vulnerabilities in:
- Critical components: 14-day remediation SLA
- High-severity: 30-day remediation SLA
- Medium-severity: 90-day remediation SLA
- [ ] Document accepted risks with business justification
**Output:** Prioritized remediation backlog
## Phase 2: Secure Development Controls
### 2.1 Code Review Checklist
**Owner:** [Development Team]
**Trigger:** Every pull request
- [ ] SBOM regenerated and diff reviewed
- [ ] No new critical or high vulnerabilities introduced
- [ ] Security-relevant changes reviewed by a second engineer
- [ ] Input validation added for user-supplied data
- [ ] Authentication/authorization checks present where required
- [ ] Secrets scanning passed (no hardcoded credentials)
**Output:** Approved merge with compliance metadata
### 2.2 Release Readiness Gate
**Owner:** [Release Manager]
**Trigger:** Pre-release (minimum 48 hours before deployment)
- [ ] All critical vulnerabilities remediated or risk-accepted
- [ ] SBOM generated and stored in artifact repository
- [ ] Security testing completed (SAST/DAST results reviewed)
- [ ] Documentation updated (API changes, configuration requirements)
- [ ] Incident response contacts verified
- [ ] Rollback plan documented
**Output:** Release approval or block with remediation requirements
## Phase 3: Vulnerability Response
### 3.1 Disclosure Handling
**Owner:** [Security Team]
**Trigger:** New CVE affecting your dependencies OR external security report
**Within 24 hours:**
- [ ] Assess whether vulnerability affects your product
- [ ] Determine exploitability in your deployment context
- [ ] Assign severity based on actual risk (not just CVE score)
- [ ] Notify product owner and engineering lead
**Within 7 days (for actively exploited vulnerabilities):**
- [ ] Patch available: Deploy to production
- [ ] No patch: Implement compensating controls
- [ ] Document mitigation in security advisory
**Output:** Updated vulnerability status and mitigation evidence
### 3.2 Coordinated Disclosure (If You Discover a Vulnerability)
**Owner:** [Security Team]
**Process:**
- [ ] Verify the vulnerability is reproducible
- [ ] Assess impact and scope
- [ ] Contact upstream maintainer through security contact (not public issue)
- [ ] Provide 90-day disclosure timeline
- [ ] Prepare patch if maintainer is unresponsive
- [ ] Coordinate public disclosure with affected parties
**Output:** Responsible disclosure with upstream community
## Phase 4: Documentation and Audit Trail
### 4.1 Compliance Artifacts (Per Release)
**Owner:** [Compliance Manager]
**Storage:** Immutable artifact repository
Required artifacts:
- [ ] SBOM (machine-readable format)
- [ ] Vulnerability scan report with remediation status
- [ ] Security test results summary
- [ ] Risk acceptance documentation for unpatched issues
- [ ] Release notes with security-relevant changes
- [ ] Support and security contact information
**Retention:** Minimum 10 years post-product lifecycle
### 4.2 Continuous Monitoring
**Owner:** [DevOps Team]
**Frequency:** Automated daily checks
- [ ] Dependency vulnerability monitoring active
- [ ] SBOM drift detection enabled
- [ ] Security advisory subscriptions current
- [ ] Incident response contacts tested quarterly
**Output:** Alert on compliance drift or new risks
## Escalation Path
**Tier 1:** Engineering lead handles routine vulnerabilities within SLA
**Tier 2:** Security team handles exploited vulnerabilities or disclosure coordination
**Tier 3:** Product owner + legal for regulatory reporting or major incidents
---
## Integration Points
**Jira/Linear:** Create ticket templates for vulnerability remediation with required compliance fields
**GitHub/GitLab:** Add branch protection rules requiring SBOM generation and vulnerability scan pass
**Slack/Teams:** Configure security advisory notifications to dedicated compliance channel
**PagerDuty/OpsGenie:** Set up escalation for critical vulnerabilities outside business hours
## Metrics to Track
- Mean time to remediate (MTTR) by severity
- Percentage of releases with zero critical vulnerabilities
- SBOM generation success rate
- Vulnerability disclosure response time
Customizing the Template
Start with your current maturity level. If you lack automated SBOM generation, begin with Phase 1.1 as a manual quarterly review. Add automation incrementally.
Adjust SLAs to your risk profile. The 14/30/90-day remediation windows are starting points. If you handle sensitive data, tighten these timelines. If your product has a limited attack surface, you might extend medium-severity timelines.
Map to your existing tools. Replace generic references with your actual toolchain:
- For SBOM: Syft, CycloneDX CLI, or built-in language tools
- For scanning: Trivy for containers, Snyk for application dependencies, or GitHub Dependabot
- For tracking: Use your current issue tracker
Customize ownership roles. In small teams, one person may cover multiple roles. Make it explicit who handles what when that person is unavailable.
Add your product-specific risks. If you're building embedded systems, include hardware attestation checks. If you're a SaaS platform, include tenant isolation verification. The template covers common requirements; extend it for your architecture.
Validation Steps
Week 1: Dry run a single component. Pick one dependency and walk through Phase 1.1 manually. Can you generate an SBOM? Can you identify its vulnerabilities? If this takes more than 30 minutes, improve your tooling before scaling.
Week 2: Test the escalation path. Simulate a critical vulnerability disclosure. Who gets notified? How long does it take to reach the person who can authorize a hotfix? If it's more than 4 hours, document your after-hours process.
Month 1: Run a full release cycle. Execute the complete workflow for one release. Track how long each phase takes. Identify bottlenecks and opportunities for automation.
Month 3: Audit your artifacts. Can you produce a complete compliance package for a release from 60 days ago? If not, fix storage and access controls before your first audit.
Quarterly: Review and refine. Track where engineers bypass steps (those steps are probably too manual) and where you catch issues late (you need earlier gates). Update the template based on what actually works.
The CRA requires documented, repeatable processes to manage security risks systematically. This template provides that foundation. Customize it for your needs and start implementing it.
