enisaeu/enisa-sbd-playbook

What it is

The README of ENISA's Secure by Design and Default playbook set for SMEs. The 22 playbooks are grouped under four principle families. The page itself lists none of the 22 titles except two, so the actual checklists are in the repo's playbook files, not on this page.

• Secure by Design: Architectural Foundations (structural choices that make compromise hard) and Operational Integrity (human and procedural practices from development through retirement).
• Secure by Default: Default Hardening (the factory state is as restrictive as possible) and Guided Protection (mandatory setup steps, automation and clear feedback that keep users in a secure state).

How to adopt it

The page gives an adoption order, which the summary does not:

flowchart TD
  A[Context and prioritisation] --> B[Engineering baseline]
  B --> C[Broader implementation]
  P{Product traits} -->|Availability-sensitive| I[Pull in Incident response and recovery early]
  P -->|Reset, ownership transfer, decommissioning| S[Pull in Secure recovery and ownership life cycle early]
  I -.-> B
  S -.-> B

• Risk management comes first. It establishes what needs protecting, which threats matter and what residual risk is acceptable. The principles then turn that context into design decisions across the life cycle.
• The sequence is illustrative. Later playbooks are not less important, so reorder them to fit the product.
• Adoption can also be progressive within one playbook. Start with checklist items that address priority risks and applicable requirements, then strengthen coverage, evidence and automation over time.

What to do

• Triage your product against the two named exceptions above before settling on an order.
• For each playbook, treat the "Minimum evidence" and "Release gate" sections as the artifacts to produce and the criteria to check before shipping. Each playbook contains Principle, Objective, Checklist, Minimum evidence and Release gate.
• Intended readers are developers, technical product managers, SME security leads and system architects.

Caveats

• "Progressive adoption" is not permission to defer obligations. Applicable legal requirements, including under the CRA, are not deferrable and take precedence over this guidance.
• The page says it is a practical starting point, not an exhaustive or prescriptive framework, and it does not provide legal guidance. Adapt it to the product's intended use and risks.
• The page claims outcomes such as fewer recurring vulnerabilities and clearer evidence for customers, but gives no measurements.