Skip to main content

CRA Adoption Best Practices

Checklists & Templates

The SME Practical Implementation Toolkit: lightweight checklists and templates to tick online, print, or download into the tools you already use.

On this page

SME practical implementation toolkit

Reusable templates and practical guidance to help SMEs implement a proportionate and lifecycle-oriented approach to integrating FOSS components under the CRA. The tools are intentionally lightweight and scale with product criticality, exposure, and available resources.

Tick the checklists online (your progress stays in this browser), print them, or download the templates into the tool you already use: a spreadsheet, a wiki, or a Git repository.

Download all templates (.md)

A1.1 Checklist

Minimum Viable Compliance (MVC) checklist

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.

Download .md

A. Roles and ownership Who does what?

  • Assign an owner for:

Clear ownership prevents security responsibilities from becoming implicit or unassigned.

B. Component visibility Know what you use

    • Component name + version
    • Where it is used (module / product area)
    • Criticality (low / medium / high)
    • Exposure (internal / limited / public)
    • Update owner

Visibility is the foundation of risk-based management.

C. Basic due diligence Before integration

  • For each important component, confirm:

D. Vulnerability handling What you do when an issue appears

  • Have a basic internal process that answers:

E. Updates and lifecycle Keep it secure over time

  • Define a simple update policy:
  • Track at least:

F. Evidence Be able to show you did it

  • Keep lightweight evidence that can be shown if needed:

MVC principle

Start small, be consistent, and scale controls based on risk.

§5.4.5 Checklist

Quick due diligence checklist

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.

Download .md

Basic visibility

Vulnerability awareness

Supply chain transparency

Lifecycle considerations

Component handles sensitive functions or is exposed to the internet? Use the decision matrix to find the due diligence level it needs.

Open the decision matrix

A1.2 Template

FOSS component register

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.

Download .csv Download .md

Example (filled row)

Component nameVersionUsed inCriticalityExposureLicenseMaintainer activityLast vulnerability reviewUpdate ownerNotes
ExampleAuthLib2.4.1Authentication moduleHighPublicMITActive (monthly releases)12 Feb 2026CTOSecurity-sensitive. CVE-2025-XXXX patched in v2.4.1. Continuous monitoring enabled.
  • Criticality: Low / Medium / High
  • Exposure: Internal / Limited / Public

A1.3 Template

Open source component record

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.

Download .md

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

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

A1.4 Playbook

Vulnerability handling mini-playbook

A structured but lightweight, SME-sized vulnerability workflow, from the first alert to close-out.

Download .md

Intake How we receive alerts

  • Sources monitored:
  • Alert owner
  • Backup contact

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

Remediation Fix and verify

  • Action taken:
  • Owner
  • Target date
  • Validation performed e.g., testing / regression / deployment verification

Release and communication

  • Release notes updated Yes / No
  • SBOM updated Yes / No
  • Customer / internal communication required? Yes / No
  • If yes: channel and message owner

Close-out and learning

  • Closure date
  • What worked / what to improve next time 1–2 bullets

A1.5 Policy

Dependency update policy

A short-form policy defining how third-party dependencies are reviewed, updated, and retired. One page is enough.

Download .md

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

A1.6 Checklist

SBOM checklist for SMEs

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.

Download .md

What to capture Minimum

When to generate or update the SBOM

  • Minimum:
  • Recommended:
  • Always update when:

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

The OCCTET toolchain scans your source code and generates SBOMs automatically, helping you move from level 1 to level 3.

Discover the OCCTET toolchain

Back to the top