# 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.

---

_Based on OCCTET deliverable D2.3 – CRA Adoption Best Practice Document (v1.0, March 2026), licensed under CC BY 4.0._

<https://occtet.eu/best-practices/checklists-and-templates/>