# A two-page cybersecurity risk assessment under Article 13 Canonical: https://craguard.eu/blog/two-page-risk-assessment-article-13 Language: en Last updated: 2026-09-02 - [CRAguard](https://craguard.eu/)/ - [Blog](https://craguard.eu/blog)/ - A two-page cybersecurity risk assessment under Article 13 27 Aug 2026 · CRAguard Summary Article 13 of Regulation (EU) 2024/2847 requires a cybersecurity risk assessment that feeds into the design, development and maintenance of the product and is part of the technical documentation (Annex VII). For a small company a two-page document suffices: identify assets and data, list threats, rate likelihood and impact, assign measures from Annex I, and record what you don't address and why. Update it on major changes. The phrase "risk assessment" sounds like a weeks-long project, but for a small company it's a **two-page document** you write once and then just maintain. The Cyber Resilience Act requires it in **Article 13**: the cybersecurity risk assessment must drive how you design, develop, deliver and maintain the product, and it's part of the technical documentation (Annex VII point 3). Here's a simple method you can handle without a consultant. ## What it's for (and what it isn't) A risk assessment isn't paper for paper's sake. It's a tool that tells you **where to focus effort**: which parts of the product to protect most, and which Annex I requirements are relevant to you. The CRA doesn't want a universal "maximum" product — it wants you to choose security measures **proportionate to the risks** of your specific product. That's exactly what the risk assessment evidences. ## The two-page method Work in five steps. Each is a few lines, not a chapter: - **Describe the product and its boundaries.** What it is, what it does, what it talks to (networks, APIs, files, devices), what data it processes. This is the context for everything else. - **List assets and data.** What has value or is sensitive: user data, login secrets, configuration, the integrity of the product itself. - **Identify threats.** For each asset: what could go wrong? Unauthorised access, data leak, a spoofed update, exploitation of a vulnerable component, DoS. It needn't be exhaustive — it must be honest. - **Rate likelihood and impact.** A simple scale (low/medium/high) is enough. The product gives you an order: what to address first and what's marginal. - **Assign measures.** For each significant risk, write what you do about it — and tie it to a concrete **requirement from Annex I Part I** (e.g. secure authentication, data encryption, attack-surface minimisation, secure update distribution). Finally, add a short line for each risk you **knowingly don't address** — and why (out of the product's boundaries, negligible impact). A conscious decision documented beats a silent gap. Scope-checker ### Find out whether the CRA applies to you Six questions, two minutes, no account. Get your product class and first steps. [Start the scope-checker](https://craguard.eu/checker) ## A mini-example on one line What does one line of such an assessment look like? Say a desktop app that stores login tokens: - **Asset:** a login token stored locally. - **Threat:** another process or user on the same machine reads the token. - **Likelihood × impact:** medium × high → prioritise. - **Measure:** encrypt the token and store it in the OS keychain; tied to the "protection of data confidentiality" requirement in Annex I Part I. You'll easily have ten to fifteen such lines across two pages. It's not about volume, but about there being, for each significant risk, a **decision tied to a requirement**. That's exactly what the Article 13 risk assessment wants from you — and what later eases the [technical documentation](https://craguard.eu/blog/self-assessment-module-a-technical-documentation) too. ## Wiring it to the rest The risk assessment doesn't stand alone. Its output feeds into: - **Design and development** — the measures from step 5 are what you actually build into the product (the secure-by-design properties of Annex I Part I). - **Vulnerability handling** — the "vulnerable component" risk leads you to an SBOM and monitoring (Annex I Part II). - **Technical documentation** — the document itself is point 3 of Annex VII, see the [self-assessment article](https://craguard.eu/blog/self-assessment-module-a-technical-documentation). ## Maintaining it Article 13 expects you to **update the assessment where necessary** — not monthly for nothing, but on major product changes, a new integration or a new type of threat. In practice, review the two pages at each major release and revise what changed. Date the versions so it's visible the document is alive. ## When to revise it A risk assessment isn't "once and done". Article 13 expects it to be updated where necessary — that is, on events that change the risk picture: - **a major product change** (a new feature that opens a new attack surface), - **a new integration** (connecting to a foreign system, a new input type), - **a new class of threat** or a significant vulnerability in a component you use, - **a change in how it's deployed** (e.g. from on-prem to network-accessible). In practice, review the two pages at each major release and revise what changed. Dating the versions shows the document is alive — which is more credible to an authority and a customer than a neat but year-old paper. ## FAQ - **Does a security expert have to do it?** No. An honest two pages from the dev team beats an expensive document nobody understands. - **How detailed should it be?** Proportionate to the product's risk (Art. 13). An ordinary app doesn't need hundreds of pages — it needs clear decisions on the significant risks. ## Bottom line A risk assessment under Article 13 isn't an academic exercise — it's a tool that tells you where to focus effort and evidence that you chose security measures **proportionate to your product's risks**. It fits on two pages in five steps: describe the product and its boundaries, list assets and data, identify threats, rate likelihood and impact, and tie each significant risk to a measure from **Annex I Part I**. Record the risks you knowingly don't address too — a reasoned decision beats a silent gap. The document is point 3 of your technical documentation and stays alive through revisions at major changes. The liveliest branch — "vulnerable component" — is covered by ongoing SBOM monitoring, so that part of the assessment is always current and evidenced. ## Key point A risk assessment under Article 13 isn't an academic exercise — it's a tool that tells you where to focus, and at the same time evidence that you chose security measures **proportionate to the risks** of your product. It can be done in two pages in five steps: describe the product and its boundaries, list assets and data, identify threats, rate likelihood and impact, and for each significant risk assign a measure tied to a requirement from **Annex I, Part I**. Risks you knowingly don't address, write down too — a conscious, justified decision beats a silent gap. The document is point 3 of your technical documentation and stays alive through reviews at major changes. The liveliest branch — "a vulnerable component" — is covered by continuous SBOM monitoring, so that part of the assessment is always current and evidenced. ## How CRAguard helps One of the liveliest parts of the risk — "vulnerable component" — CRAguard holds for you: it compares your SBOM against databases daily and gives a clear verdict, so this branch of the risk assessment is always current and evidenced by an audit trail. The rest of the two pages we guide with a template. [Find out whether the CRA applies to you](https://craguard.eu/checker), or [join the waitlist](https://craguard.eu/#waitlist). *This article is informational and not legal advice. It is based on Regulation (EU) 2024/2847 (Art. 13, Annex I Part I, Annex VII) and the European Commission's guidance of 27 July 2026.* Scope-checker ### Find out whether the CRA applies to you Six questions, two minutes, no account. Get your product class and first steps. [Start the scope-checker](https://craguard.eu/checker) ## Sources - [EUR-Lex — Regulation (EU) 2024/2847 (Cyber Resilience Act)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) - [ENISA — Single Reporting Platform](https://www.enisa.europa.eu/) --- Source: CRAguard — https://craguard.eu