# Checklists & Templates The SME Practical Implementation Toolkit: lightweight checklists and templates to tick online, print, or download into the tools you already use. --- ## Minimum Viable Compliance (MVC) checklist (A1.1) A one-page baseline of practices that most SMEs can implement to support CRA-aligned integration of open source components. Designed for limited time and resources; strengthen it proportionally based on risk. ### A. Roles and ownership — Who does what? Assign an owner for: - [ ] Dependency selection and approval - [ ] Vulnerability monitoring - [ ] Security updates / patching - [ ] Release documentation (what changed, what was updated) > Clear ownership prevents security responsibilities from becoming implicit or unassigned. ### B. Component visibility — Know what you use - [ ] Maintain a simple FOSS component register including: - Component name + version - Where it is used (module / product area) - Criticality (low / medium / high) - Exposure (internal / limited / public) - Update owner - [ ] Generate an SBOM (at least for major releases) or maintain an equivalent dependency list > Visibility is the foundation of risk-based management. ### C. Basic due diligence — Before integration For each important component, confirm: - [ ] It is actively maintained (recent activity / release signals) - [ ] Known vulnerabilities are reviewed - [ ] License compatibility is checked - [ ] A security contact or disclosure path exists (when applicable) ### D. Vulnerability handling — What you do when an issue appears Have a basic internal process that answers: - [ ] How do we receive vulnerability alerts? - [ ] Who triages? - [ ] How do we decide urgency? - [ ] How do we patch and release? - [ ] How do we communicate changes (release notes)? ### E. Updates and lifecycle — Keep it secure over time Define a simple update policy: - [ ] How often do we review updates? (e.g., monthly + urgent patches as soon as possible) - [ ] How do we handle end-of-life components? - [ ] Who approves dependency upgrades? Track at least: - [ ] Date of last dependency review - [ ] Date of last security update / patch release ### F. Evidence — Be able to show you did it Keep lightweight evidence that can be shown if needed: - [ ] Component register + SBOM - [ ] Update policy (1 page is enough) - [ ] Vulnerability handling notes (process + at least one example log entry) - [ ] Release notes referencing dependency / security updates > **MVC principle** — Start small, be consistent, and scale controls based on risk. --- ## Quick due diligence checklist (§5.4.5) Twelve questions to ask before integrating a FOSS component. It does not replace a structured risk assessment, but offers an accessible and proportionate entry point for SMEs with limited resources. ### Basic visibility - [ ] Is the project actively maintained? - [ ] Is version history transparent? - [ ] Is a security contact publicly available? ### Vulnerability awareness - [ ] Are vulnerabilities documented? - [ ] Are fixes released in a structured manner? - [ ] Is there evidence of responsiveness? ### Supply chain transparency - [ ] Is the component included in the SBOM? - [ ] Are dependencies visible? - [ ] Is versioning consistent? ### Lifecycle considerations - [ ] Is there evidence of ongoing maintenance? - [ ] Are updates communicated clearly? - [ ] Is end-of-life status defined? --- ## FOSS component register (A1.2) A simple register of the open source components integrated into your product. It supports traceability, due diligence, and lifecycle monitoring, and can be maintained in a spreadsheet, SharePoint, Git, or any internal tool. | Component name | Version | Used in | Criticality | Exposure | License | Maintainer activity | Last vulnerability review | Update owner | Notes | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | ExampleAuthLib | 2.4.1 | Authentication module | High | Public | MIT | Active (monthly releases) | 12 Feb 2026 | CTO | Security-sensitive. CVE-2025-XXXX patched in v2.4.1. Continuous monitoring enabled. | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - **Criticality:** Low / Medium / High - **Exposure:** Internal / Limited / Public --- ## Open source component record (A1.3) For medium and high criticality components, or any publicly exposed component. It complements the component register by documenting why the component was selected and what monitoring is in place. ### Component - **Component name**: - **Version / range used**: - **Repository / reference link** (optional): - **Used in** (module / feature): - **Functional criticality** (Low / Medium / High): - **Exposure** (Internal / Limited / Public): - **License**: ### Selection rationale — Why this component? - **Why was it chosen?** (e.g., feature fit, stability, performance, ecosystem) - **Alternatives considered** (if any): ### Basic due diligence performed - [ ] Maintainer activity reviewed - [ ] Vulnerability history reviewed - [ ] Security contact / disclosure method available (if applicable) - [ ] License compatibility confirmed - [ ] Included in SBOM ### Known risks / notes - **Known limitations / concerns**: - **Dependency depth concerns** (if relevant): ### Monitoring and ownership - **Update owner / responsible person**: - **Vulnerability monitoring source(s)** (e.g., advisories, CVE feeds, repository alerts): - **Review frequency** (e.g., monthly + urgent alerts as needed): - **Last review date**: - **Next planned review date**: --- ## Vulnerability handling mini-playbook (A1.4) A structured but lightweight, SME-sized vulnerability workflow, from the first alert to close-out. ### 1. Intake — How we receive alerts Sources monitored: - [ ] Project advisories - [ ] CVE databases - [ ] Dependency scanning tool - [ ] Customer reports - [ ] Internal testing - **Alert owner**: - **Backup contact**: ### 2. Triage — Decide severity and urgency For each vulnerability, record: - **Affected component and version(s)**: - **Is it used in our product?** (Yes / No) - **Exposure context** (Internal / Limited / Public): - **Functional criticality** (Low / Medium / High): - **Exploitability indicators** (if known): - **Proposed response priority** (Low / Medium / High): Decision rule (simple): - High criticality + public exposure → treat as urgent - Medium risk → planned fix - Low risk → track and fix in the next planned cycle ### 3. Remediation — Fix and verify Action taken: - [ ] Upgrade to fixed version - [ ] Apply patch - [ ] Mitigation / configuration change - [ ] Temporary workaround - **Owner**: - **Target date**: - **Validation performed** (e.g., testing / regression / deployment verification): ### 4. Release and communication - **Release notes updated** (Yes / No): - **SBOM updated** (Yes / No): - **Customer / internal communication required?** (Yes / No) - **If yes: channel and message owner**: ### 5. Close-out and learning - **Closure date**: - **What worked / what to improve next time** (1–2 bullets): --- ## Dependency update policy (A1.5) A short-form policy defining how third-party dependencies are reviewed, updated, and retired. One page is enough. ### Scope Applies to third-party dependencies, including FOSS components. ### Principle Dependencies are maintained in a risk-based and lifecycle-oriented manner. Update actions are proportional to criticality, exposure, and impact. ### Update cadence - **Routine dependency review** (e.g., monthly / quarterly): Security updates are applied based on risk classification: - **High risk:** as soon as possible - **Medium risk:** planned fix within the next release cycle - **Low risk:** tracked and resolved during normal maintenance ### Decision ownership - **Dependency upgrade approval owner**: - **Emergency security fix approval owner**: ### End-of-life dependencies If a dependency becomes unsupported or end-of-life, we: - Record the risk - Evaluate alternatives - Plan migration or compensating controls - Document the decision and timeline --- ## SBOM checklist for SMEs (A1.6) What to capture in a Software Bill of Materials, and when. An SBOM supports transparency and traceability for products using FOSS components, and SBOM practices can be adopted progressively. ### What to capture — Minimum - [ ] Product name + version (release identifier) - [ ] Component name + version - [ ] Direct and transitive dependencies (as available) - [ ] License information (where feasible) - [ ] Unique identifiers (when available, e.g., package URL / hashes) ### When to generate or update the SBOM Minimum: - [ ] For major releases (e.g., version 1.0, 1.1, 2.0) Recommended: - [ ] For every release that changes dependencies Always update when: - [ ] A security patch requires a dependency upgrade - [ ] A critical / high exposure component changes version - [ ] A vulnerability remediation is implemented ### SBOM maturity levels #### Level 1 — Foundational - Structured dependency list - Major release updates - Linked to release documentation #### Level 2 — Structured - Automated SBOM generation (where possible) - Direct + transitive dependencies - License capture - SBOM stored with release artifacts #### Level 3 — Advanced - CI/CD-integrated SBOM generation - Continuous dependency monitoring - Hash verification - Historical SBOM version tracking - Rapid impact analysis for CVEs --- _Based on OCCTET deliverable D2.3 – CRA Adoption Best Practice Document (v1.0, March 2026), licensed under CC BY 4.0._