A RAG Report (Red-Amber-Green Report) is a structured assessment document that uses a three-colour traffic-light system to communicate the compliance status of each individual requirement of an applicable EU directive or regulation against a product’s current design. It is a widely used deliverable format for hardware compliance gap analyses — not one prescribed by EU law — because it converts complex multi-directive technical evaluations into an executive-readable summary that can be used to prioritise remediation and justify engineering budget.
The Three RAG Classifications
| Colour | Meaning | Required Action |
|---|---|---|
| 🟢 Green | Requirement is fully met by the current design. Evidence is documented (test report, design review, material declaration, etc.) | None — document the evidence in the Technical File |
| 🟡 Amber | Requirement is partially met, or compliance is conditional / unverified. The design may be compliant but evidence is missing or an assumption needs validation. | Investigation required — either provide the missing evidence or redesign the flagged element |
| 🔴 Red | Requirement is not met by the current design. A concrete gap exists that cannot be resolved without a design change, component replacement, or process modification. | Remediation required — the gap must be closed before the product can lawfully carry the CE mark |
Structure of a Hardware Compliance RAG Report
For a connected hardware product subject to multiple directives, the RAG Report is typically structured as follows:
RAG Compliance Report — [Product Name] Rev. [X]
Prepared by: [Engineer name, qualification]
Reviewed by: [Senior security architect / compliance lead]
Date: [YYYY-MM-DD]
1. SCOPE
- Product description and intended use
- List of applicable directives and regulations assessed
- Assessment methodology and standards referenced
2. EXECUTIVE SUMMARY
- Summary table: total Green / Amber / Red per directive
- Overall compliance verdict
- Recommended remediation priority order
3. DETAILED FINDINGS — per directive
[For each applicable directive, a table of requirements:]
| Requirement | Article / Clause | RAG Status | Findings | Evidence / Recommendation |
|---|---|---|---|---|
| Confidentiality of stored keys and data | CRA Annex I Part I(2)(e) | 🔴 Red | MCU (STM32F4) has no Secure Element or TrustZone. Shared key stored in flash. | Replace MCU with STM32U5 (TrustZone-M) and add STSAFE-A110 Secure Element |
| Protection from unauthorised access (authentication) | CRA Annex I Part I(2)(d) | 🔴 Red | MAC address used as identity — cloneable. | Implement STSAFE-A110 device certificate provisioning at manufacturing |
| Integrity of software and secure update distribution | CRA Annex I Part I(2)(f), Part II(7) | 🟡 Amber | OTA mechanism exists but signing key stored in software. | Hardware key storage required — resolved once STSAFE-A110 added |
| Coordinated vulnerability disclosure policy and contact | CRA Annex I Part II(5)–(6) | 🟢 Green | security.txt present at product domain, PSIRT contact established | Document in Technical File |
4. COMPONENT RISK MATRIX
[BOM-level table identifying which components pass, fail, or require replacement]
5. REMEDIATION PLAN
- Prioritised list of changes required
- Estimated engineering effort (person-days)
- Estimated cost range
- Timeline to achieve full compliance
6. REFERENCES
- Directive and regulation references with publication dates
- Standards references with edition datesWhy RAG Reports Matter Beyond Compliance
The RAG Report format serves three audiences simultaneously:
For the engineering team: A precise, requirement-level specification of what must be changed and why — eliminates ambiguity between compliance intent and implementation.
For the CTO / engineering director: An evidence-based business case for redesign investment. The “total Red findings” count and the remediation cost estimate provide the data needed to justify budget, especially against a “firmware update will fix it” counterargument.
For the regulator: Market surveillance authorities ask for the technical documentation and the EU declaration of conformity, not for a RAG Report. A RAG Report can support that documentation by showing that the manufacturer assessed each requirement, identified gaps, and took corrective action.