The rule pack

What an assessor will ask for — Show that the product's security measures follow from an assessment of its risks: the risk work exists, is written down, and the product's own security requirements and design trace back to it.

• Product context record Documentation · Annex VII(1)
  Describe the product the way the risk work sees it: its intended purpose and reasonably foreseeable use, the functions it provides, the environment it operates in, an architecture overview with its interfaces and dependencies (including any remote data processing), and who its users are.
  Check: The record exists and covers each of those elements; anything the risk assessment relies on is in it. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §6.2.3–6.2.5 (product context: requirement, output, assessment criteria); Annex VII(1)(a)–(b).
• Risk acceptance criteria and risk methodology Documentation · Annex VII(3)
  State how risk is defined and measured for this product and what level of risk you accept, taking into account regulatory and contractual factors, the nature of the risks, the users, the product itself, and the state of the art.
  Check: Both exist; the criteria are justified for the product and the methodology is applied consistently across its lifecycle. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §6.3.3–6.3.5; Art. 13(2).
• Asset, objective and threat lists Documentation · Annex VII(3)
  List the assets the product handles or affects, with the security objective for each, and for every asset the threats to it: what is targeted, which objective is compromised, and how.
  Check: The lists exist and are complete enough that every listed asset has its threats. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §6.4.2.4 and §6.4.3.4, with their assessment criteria; Art. 13(2).
• Risk estimates and evaluation Documentation · Annex VII(3)
  For each threat, the estimated likelihood and magnitude of loss, the resulting risk, and its evaluation against your acceptance criteria — including the justification for every residual risk you accept.
  Check: The list exists and follows the declared methodology; each accepted residual risk carries a justification consistent with the criteria. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §6.4.4.4–6.4.5.5; Art. 13(2).
• Risk treatment decisions Documentation · Annex VII(3)
  For each risk, the treatment chosen — avoid, mitigate, accept or transfer, in that order of preference — with its justification; and where an inherent risk is accepted, what the user is told and which mitigation you recommend.
  Check: A decision with justification exists per risk and follows the treatment methodology. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §6.5.3–6.5.5; Annex I Part I(2), chapeau.
• Risk information for users and integrators Documentation · Annex II
  The residual risks, the mitigations you recommend, the assumptions about the operating context, and what you expect of users and downstream integrators — in the form they actually receive it, usually inside the information and instructions to the user.
  Check: The documentation exists and gives the stakeholder enough to mitigate the risk. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §6.6.3–6.6.5; Annex II.
• Risk review regularity and triggered updates Process · Annex VII(3)
  How often the risk management is reviewed and why that regularity fits the product; the triggers for an unscheduled review (threat-landscape change, an incident, component obsolescence); and the updated documentation a triggered review produced.
  Check: The regularity is determined and justified; where a review was triggered, updated risk documentation exists. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §6.7.3–6.7.5; Annex I Part II(3) (regular reviews).
• Product cybersecurity plan Documentation · Annex VII(2)
  The plan for the security activities across the product's lifecycle: acceptance criteria and their rationale, the methodologies used, the support period and decommissioning plan, the recurring test-and-review schedule, update and component-obsolescence planning, and vulnerability response timescales.
  Check: The plan exists, is maintained, and contains each of those elements. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.2.3–7.2.5.
• Product cybersecurity requirements Documentation · Annex VII(2)
  The security requirements you derived for this product from the risk work and the regulation, each with its applicability, its technical specification, and the controls selected to fulfil it.
  Check: Documented, traceable to the risk assessment and treatment, and reviewed when the inputs change. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.3.3–7.3.5; Annex I Part I(2), chapeau.
• Secure implementation and development environment Process · Annex VII(2)
  How the product is built securely: the development environment and how it is protected from unauthorised access, the secure coding rules you apply, how cryptographic keys and certificates are managed, and how the vulnerability status of integrated components is confirmed before release.
  Check: The outputs of secure implementation exist and meet the requirement — including evidence of the activities you undertook, not only a description of them. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(1) — 'developed', mapped to §7.5 by Annex C Table C.1; prEN 40000-1-2:2025 §7.5.3–7.5.5 (secure implementation: requirement, output including evidence of the outcomes, assessment criteria).
• Secure production and distribution controls Process · Annex VII(2)(c)
  How the product is protected from tampering between the development team and the user: for software, how build artefacts and the hosting location are protected in transit and at rest and how their authenticity is assured; for hardware, the manufacturing controls over work instructions, installed software, keys and identifiers. Record which of the two applies to this product.
  Check: The output of secure production exists, and there is evidence it meets the requirement — the processes and their validation, which is what Annex VII(2)(c) asks for. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(1) — 'produced', mapped to §7.7 by Annex C Table C.1; prEN 40000-1-2:2025 §7.7.2.3–7.7.2.5 (secure digital production) and §7.7.3.3–7.7.3.5 (manufacturing); Annex VII(2)(c).

What an assessor will ask for — Show that the components in the released version were screened for known vulnerabilities, and that anything found was fixed or shown not to be exploitable in this product.

• Vulnerability screen of the released components Record · Annex VII(6)
  The screening result for the components in the released version: which sources were queried (the EU Vulnerability Database, CVE/OSV, vendor advisories), when, and what was found. The built-in SBOM scan produces this; an external scanner's report counts too.
  Check: A dated result exists for the released version and names its sources. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(a); prEN 40000-1-2:2025 §6.4.3.2 (known exploitable vulnerabilities as a threat input); §7.6.3 (verifying that known vulnerabilities have been subject to appropriate risk treatment), with the vulnerability-monitoring approach described in §7.6.1 (General — informative); prEN 40000-1-3:2025 §5.4.3 [RCP-2] monitored sources; Guidance C(2026) 5252 §9.2.2 paras 233–234.
• Disposition of each open finding Documentation · Annex VII(6)
  For every finding still open at release, the reasoning: fixed, not affected (and why), or not exploitable under the product's practical operating conditions — the Art. 3(41) test, applied and written down. The dispositions recorded against the scan in this assessment are this record.
  Check: Every open finding carries a documented conclusion; 'not exploitable' is argued, not asserted. Basis: Commission guidance C(2026) 5252. Sources: Art. 3(41); Guidance C(2026) 5252 §9.2.2; prEN 40000-1-3:2025 §5.5.2 [VRF-1] documentation on processing the vulnerability information.
• Component due-diligence record Documentation · Annex VII(2)
  Evidence that third-party and open-source components were checked against public vulnerability databases when they were selected and when they were integrated, as part of the due diligence on components.
  Check: The record shows the check for the components in this release. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.11.3–7.11.5; Art. 13(5).

What an assessor will ask for — Show that the shipped configuration is secure without the user doing anything, that the design chose that state deliberately, and that the product can be returned to it.

• Default configuration statement Documentation · Annex VII(2)(a)
  What the product's configuration is on first use — enabled interfaces and services, the default-credential policy, the update setting — which of those a user can change, and the reasoning that this state is secure for the intended use.
  Check: The design documentation describes the default state and why it is secure. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(b); prEN 40000-1-2:2025 §5.4 (secure by default) and §7.4.3 (the architecture considers §5.4).
• Out-of-the-box configuration test Verification · Annex VII(6)
  A test on a factory-fresh unit or clean install that records the actual default state and compares it with the statement above.
  Check: The observed state matches the documented default configuration. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.6.3–7.6.4 (verification output: test reports).
• Reset-to-original-state test Verification · Annex VII(6)
  Evidence that the reset function returns the product to its original secure state, including what it clears and what it does not.
  Check: The post-reset state equals the shipped default. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(b); prEN 40000-1-2:2025 §5.4.
• Agreement with the business user (tailor-made products only) Documentation · Annex VII(2)
  Where a different default was agreed with a business user for a tailor-made product, the agreement that records it. Mark this as not applying if the product is not tailor-made.
  Check: The agreement exists and names the deviation from the secure default. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(b); prEN 40000-1-2:2025 §6.3.2 (contractual agreements as an input to the risk acceptance criteria).

What an assessor will ask for — Show that vulnerabilities can be fixed in the field: an update mechanism exists, installs automatically by default where the product supports it, tells users, and lets them postpone or opt out.

• Update mechanism description Documentation · Annex VII(2)(a)
  How security updates reach the product: the channel, whether automatic installation is enabled by default, how users are told an update is available, and how they opt out or postpone.
  Check: The description covers the default setting, notification, opt-out and postponement. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(c); prEN 40000-1-2:2025 §5.4 (updates installed without undue delay, opt-out, postponement) and §7.8.3; prEN 40000-1-3:2025 §5.3.11 [PRE-10] distribution mechanisms.
• Update installation test Verification · Annex VII(6)
  A test showing an update is delivered and installed through the mechanism, with the default behaviour, the notification and the opt-out or postpone path exercised.
  Check: The test records delivery, installation and the user-facing behaviours. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.7.2.5 [RLS-1] evidence of implemented update mechanisms.
• Update timeframe policy Process · Annex VII(2)(b)
  The timeframe within which security updates are expected to be developed and installed, as planned in the security plan and the vulnerability handling policy.
  Check: A target schedule exists and is followed. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.2.3 (vulnerability response planning) and §7.8.3 (without undue delay); prEN 40000-1-3:2025 §5.3.2 [PRE-1-RQ-02] target schedule for remediation.

What an assessor will ask for — Show who can reach the product and how they prove who they are, that the design says so, that it was tested, and that unauthorised attempts are reported.

• Authentication and access-control design Documentation · Annex VII(2)(a)
  The interfaces that grant access, the mechanism on each (authentication, identity and access management), the roles and their permissions, and the credential policy, as designed.
  Check: The design exists and covers every access path listed in the product context. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(d); prEN 40000-1-2:2025 §7.4.3–7.4.5 (the architecture and design shall be established and evidenced), with secure interface design and authentication described in §7.4.1 (General — informative).
• Access-control test results Verification · Annex VII(6)
  Tests showing authentication is enforced on each access path and that unauthorised attempts are refused.
  Check: Results exist for every access path in the design. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.6.3–7.6.4.
• Reporting of possible unauthorised access Verification · Annex VII(6)
  How the product reports a possible unauthorised access — a log entry, an alert, a notification — and a test showing that it does.
  Check: The reporting path is designed and was exercised. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(d) (report on possible unauthorised access); prEN 40000-1-2:2025 §7.4 and §7.8 (Annex C mapping).

What an assessor will ask for — Show which data the product protects and how, and that the protection is in place on the product as shipped.

• Data protection design Documentation · Annex VII(2)(a)
  Which data the product stores, transmits or processes; how each class is protected at rest and in transit (algorithms, protocols, key lengths); and how keys and certificates are managed.
  Check: Every data class in the asset list has a stated protection, and the cryptography is state of the art. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(e); prEN 40000-1-2:2025 §7.4.3 and §7.5.3 (management of cryptographic keys and certificates).
• Confidentiality test results Verification · Annex VII(6)
  Tests or inspections confirming data is encrypted where the design says it is — protocol negotiation checks, storage inspection, configuration review.
  Check: Results correspond to the design's protection claims. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.6.3–7.6.4.

What an assessor will ask for — Show that data, commands, programs and configuration cannot be altered without authorisation, and that a corruption is detected and reported.

• Integrity protection design Documentation · Annex VII(2)(a)
  How stored, transmitted and processed data, commands, programs and configuration are protected from unauthorised modification — signing, checksums, secure boot, verified updates — and how a corruption is detected and reported.
  Check: The design covers data, commands, programs and configuration, and names the reporting path. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(f); prEN 40000-1-2:2025 §7.4.3; §7.7.2.3 (integrity and authenticity of distributed artefacts).
• Integrity and tamper test results Verification · Annex VII(6)
  Tests showing that modified firmware, configuration or data is detected and refused or reported — for example, a tampered image failing signature verification.
  Check: Results exist for each protected class. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.6.3–7.6.4.
• Corruption reporting demonstration Verification · Annex VII(6)
  A demonstration that the product reports a detected corruption to the user or operator.
  Check: The report is produced and visible. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(f); prEN 40000-1-2:2025 §7.8 (Annex C: report on corruptions).

What an assessor will ask for — Show that the product processes only the data its intended purpose needs.

• Data inventory with necessity justification Documentation · Annex VII(2)(a)
  The data the product processes, personal or other, each tied to the function that needs it, with the justification that nothing beyond what the intended purpose requires is collected or retained — and for how long.
  Check: Every data item maps to a purpose, and retention is bounded. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(g); prEN 40000-1-2:2025 §6.4.2.1 (data as assets) and §7.4 (Annex C mapping).
• Data-flow verification Verification · Annex VII(6)
  An inspection or test confirming the product transmits and stores only the inventoried data — a traffic capture, a storage inspection.
  Check: Observed flows match the inventory. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.6.3.

What an assessor will ask for — Show which functions are essential, how they keep working through an incident, and how the product resists denial of service.

• Essential functions and resilience design Documentation · Annex VII(2)(a)
  Which functions are essential or basic, how they keep working during and after an incident, and the measures against denial-of-service — rate limiting, resource bounds, failover.
  Check: Essential functions are named and each has a resilience measure. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(h); prEN 40000-1-2:2025 §7.4 (Annex C mapping).
• Stress and denial-of-service test results Verification · Annex VII(6)
  Stress or load tests showing the product's behaviour under resource exhaustion and after recovery.
  Check: Essential functions survive or recover as designed. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.6.1 (stress testing) and §7.6.4.

What an assessor will ask for — Show what the product does to the network around it, and that a misbehaving or compromised unit cannot degrade the services of other devices.

• Network behaviour description Documentation · Annex VII(2)(a)
  What the product sends to the network and when, what it can do to connected devices, and the limits designed in so a compromised or misbehaving unit cannot degrade the services others provide.
  Check: The description covers outbound traffic, connected-device interactions and the limiting measures. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(i); prEN 40000-1-2:2025 §7.4.
• Network impact test Verification · Annex VII(6)
  A traffic capture or test confirming the product's network behaviour matches the description, including under fault.
  Check: Observed behaviour stays within the designed limits. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.6.3.

What an assessor will ask for — Show every way in, that each one that is open is open for a reason, and that nothing else is exposed.

• Interface and attack-surface inventory Documentation · Annex VII(2)(a)
  Every external interface — network ports and services, physical ports, APIs, debug and management interfaces — whether it is enabled by default, and the justification for each one that is.
  Check: The inventory is complete against the architecture overview, and every enabled interface has a reason. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(j); prEN 40000-1-2:2025 §5.3.2 (attack surface minimisation), §6.2.1.5 (architecture overview: interfaces) and §7.4.
• Exposed-surface scan Verification · Annex VII(6)
  A port and service scan of the shipped product — and a check of physical and debug ports — compared with the inventory.
  Check: Nothing is exposed that the inventory does not list as enabled. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.6.3 (verifying external interfaces and protocols).

What an assessor will ask for — Show which techniques limit the damage an exploited vulnerability can do, and that they are actually switched on in the shipped build.

• Exploitation-mitigation techniques in use Documentation · Annex VII(2)(a)
  The techniques the product uses to limit the impact of an exploited vulnerability — non-executable memory, address-space randomisation, stack protection, sandboxing, privilege separation, memory-safe languages — and where each one applies.
  Check: The list is specific to the product's platform and components. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(k); prEN 40000-1-2:2025 §5.3.2 (defence in depth, secure coding, memory safety) and §7.4.
• Mitigation verification on the release build Verification · Annex VII(6)
  Build-configuration evidence or binary checks confirming the mitigations are enabled in the shipped build — compiler flags, hardening checks on the release artefact.
  Check: Each claimed mitigation is verified on the release artefact. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.6.3 (reviewing implementation artefacts against secure implementation rules) and §7.6.4.

What an assessor will ask for — Show what security-relevant activity the product records, where it goes, and that the user can switch recording off.

• Logging and monitoring design Documentation · Annex VII(2)(a)
  What security-relevant internal activity is recorded (access to and modification of data, services or functions), where the records go, how long they are kept, and how the user opts out.
  Check: The design names the events, the storage and the opt-out. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(l); prEN 40000-1-2:2025 §7.4 and §7.9.1 NOTE 1 (recording relevant internal activity with an opt-out).
• Logging test Verification · Annex VII(6)
  A test that triggers the designed events and shows they are recorded, and that the opt-out stops recording.
  Check: Recorded events match the design, and the opt-out works. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.6.3–7.6.4.

What an assessor will ask for — Show that a user can permanently remove their data and settings, transfer them securely where that is offered, and that the product is planned to be retired safely.

• Secure decommissioning plan Documentation · Annex VII(2)
  The plan for retiring the product: which confidential assets (user data, settings, keys) must be removed and where they live, how the user removes or exports their data, how the product leaves its environment, and how it is disposed of securely — including obligations that extend beyond the end of support.
  Check: The plan exists and covers each of those elements. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(m); prEN 40000-1-2:2025 §7.10.3–7.10.5.
• Data removal and transfer test Verification · Annex VII(6)
  A test showing the removal function leaves no recoverable user data or settings, and that a transfer to another product, where offered, is protected.
  Check: A post-removal inspection finds nothing, and any transfer is protected. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part I(2)(m); prEN 40000-1-2:2025 §7.6.3.
• User instructions for removal and export Documentation · Annex II
  The instructions users receive on removing or exporting their data, removing security assets and configuration, and what is deleted automatically and when.
  Check: The instructions exist in the information to the user. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.10.3 (user information and instructions on decommissioning); Annex II.

What an assessor will ask for — Show that every component is known and traceable, in a machine-readable bill of materials regenerated for each release, and that vulnerability information is matched against it.

• Product identification record Documentation · Annex VII(1)
  The information that identifies this product and version unambiguously — manufacturer, product name, hardware and software identifiers — recorded separately for hardware and software where the product has both.
  Check: The record exists with the identifiers. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.3.7 [PRE-6]; Annex VII(1)(b).
• Software bill of materials for the release Record · Annex VII(8)
  The SBOM for the released version in a machine-readable format (CycloneDX or SPDX), with author, version and timestamp, covering at least the top-level dependencies — each with producer, name, version, unique identifiers and dependency relationships. Regenerated for every new build or release.
  Check: The SBOM exists for this release, is machine-readable, and carries the required metadata and component fields. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part II(1); prEN 40000-1-3:2025 §5.3.8 [PRE-7-RQ-03 to RQ-07]; prEN 40000-1-2:2025 §7.5.3.
• Hardware component list Documentation · Annex VII(2)(a)
  For a product with hardware: the list of integrated hardware components with producer, name, identifier and firmware version. Mark this as not applying for software-only products.
  Check: The list exists and is complete against the architecture. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.3.9 [PRE-8].
• Monitored vulnerability sources Process · Annex VII(2)(b)
  The list of sources you monitor for vulnerability information — at least the EU Vulnerability Database and the reports you receive, plus your own regular testing and reviews — and the record of relevant information found.
  Check: The source list exists, and a record of relevant vulnerability information is kept. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.4.3 [RCP-2].
• Matching of vulnerabilities to components Record · Annex VII(6)
  Evidence that incoming vulnerability information is compared with the SBOM and the hardware list to identify potentially affected components. The built-in scan and its rescans produce this record for software.
  Check: Identification activity is evidenced, and potentially affected components are listed with the vulnerability information. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.4.4 [RCP-3] and §5.4.5 [RCP-4].

What an assessor will ask for — Show there is a working process from a vulnerability arriving to a fix shipping: policy, triage, decision, fix, test, release, follow-up.

• Vulnerability handling policy Process · Annex VII(2)(b)
  Your internal policy on handling vulnerabilities: responsibilities, measures against premature disclosure, the target schedule for remediation, and the test-and-review strategy — and evidence that its effectiveness is monitored.
  Check: The policy exists, covers the handling activities, and is monitored. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part II(2); prEN 40000-1-3:2025 §5.3.2 [PRE-1-RQ-01 to RQ-05] and its assessment criteria.
• Verification and prioritisation records Record · Annex VII(6)
  For vulnerabilities received or found: the assessment of validity and severity, the risk assessment and the priority assigned, and the communication with the reporter — including which cases were expedited.
  Check: Records show investigation, tracking, severity and priority for each case. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.5.2 [VRF-1] and §5.5.3 [VRF-2].
• Remediation decisions, plans and test reports Record · Annex VII(6)
  For each remediated vulnerability: the decision on how to fix it, the plan with its timeline, the fix produced, and the test showing the risk is mitigated without unacceptable impact on the product or its users.
  Check: Decision, plan, produced remediation and test report exist per case. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.6.2 [RMD-1], §5.6.3 [RMD-2] and §5.6.4 [RMD-3].
• Separation of security updates from function updates Documentation · Annex VII(2)(b)
  How security updates are delivered separately from functionality updates — or the technical reason they cannot be.
  Check: Either the separation is shown or the infeasibility is justified. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part II(2); prEN 40000-1-3:2025 §5.6.3 [RMD-2-RQ-02].
• Operational security for vulnerability information Process · Annex VII(2)(b)
  The measures that limit access to non-public vulnerability information on a need-to-know basis during handling and disclosure.
  Check: Documented security measures exist. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.3.4 [PRE-3].
• Post-release actions Record · Annex VII(6)
  Case maintenance and monitoring of released remediations, and the lessons captured for future development.
  Check: Post-release actions are documented and carried out. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.8.2 [PRA-1].

What an assessor will ask for — Show that testing and review are planned on the basis of risk, happen on that schedule, and feed back into the plan.

• Security test and review plan Process · Annex VII(2)(b)
  The risk-based plan with the schedule and frequency of tests and reviews, considering the product context, architecture, security requirements, risk assessment and test methodologies — and its updates from what the tests and reviews found.
  Check: The plan exists and is maintained from performed tests and reviews. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part II(3); prEN 40000-1-3:2025 §5.3.10 [PRE-9-RQ-01 to RQ-04]; prEN 40000-1-2:2025 §7.2.3 (recurring testing and review schedule).
• Security test results, as planned Record · Annex VII(6)
  The results of the tests the plan schedules — penetration tests, fuzzing, static analysis, vulnerability scans — with dates, showing they were performed as planned.
  Check: Tests were performed as planned and their results exist. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.4.7 [RCP-6]; prEN 40000-1-2:2025 §7.6.4.
• Security review results Record · Annex VII(6)
  The results of the reviews the plan schedules — of the threat landscape, the state of the art, vulnerabilities in similar products, conditions of practical use — including the at-least-yearly re-review of the risk assessment's assumptions and inputs, and any plan updates they caused.
  Check: Reviews were performed against the defined sources, and the risk assessment was reviewed at least annually. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.4.8 [RCP-7-RQ-01 and RQ-02]; prEN 40000-1-2:2025 §6.7.

What an assessor will ask for — Show that once a fix is out, users are told what was fixed, in enough detail to act, and that any delay was justified.

• Published information on fixed vulnerabilities Record · Annex VII(2)(b)
  The advisories published once a security update was available: description, identifier, identification of the affected product, impact, severity, remediation steps, release and update dates — human-readable, and machine-readable where the product's risk profile calls for it. Advisories published from this workspace count.
  Check: Published information exists per fixed vulnerability with the required elements. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part II(4); prEN 40000-1-3:2025 §5.7.3 [RLS-2-RQ-01 to RQ-03] and [RLS-2-RQ-03-RE] machine-readable advisories (CSAF).
• Rationale for any delayed publication Documentation · Annex VII(2)(b)
  Where publication was delayed because the security risks of publishing outweighed the benefits: the evaluation, the interim information users were given, and the disclosure date they were told. Mark this as not applying if nothing was delayed.
  Check: A rationale exists for each delay. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part II(4) (duly justified cases); prEN 40000-1-3:2025 §5.7.3 [RLS-2-PM-01].
• Publication to the EU Vulnerability Database Record · Annex VII(2)(b)
  Evidence that fixed vulnerabilities were made available on the EU Vulnerability Database, directly or through the CVE programme.
  Check: Evidence exists, where applicable. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.7.3 [RLS-2-RC-01].

What an assessor will ask for — Show that a disclosure policy is published, reachable, and actually followed.

• Published coordinated vulnerability disclosure policy Process · Annex VII(2)(b)
  The disclosure policy, published in an accessible format: the contact mechanisms (reachable through more than one sensory channel), the expectations for ongoing communication with reporters, and the disclosure and embargo approach.
  Check: The policy is published, followed, aligned with the internal handling policy, and its contact mechanisms are accessible. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part II(5); prEN 40000-1-3:2025 §5.3.3 [PRE-2-RQ-01 to RQ-03] and its assessment criteria.
• Reachable disclosure channel Verification · Annex VII(2)(b)
  Evidence that the published channel works: the security.txt file (RFC 9116) or the policy page as actually served, and where it is published.
  Check: The channel is publicly reachable. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.4.2 [RCP-1] (security.txt as an additional consideration).

What an assessor will ask for — Show that anyone who finds a vulnerability can report it, that the report is tracked and acknowledged, and that upstream suppliers are told about problems in their components.

• Reporting mechanism and contact address Process · Annex VII(2)(b)
  The publicly available, accessible means of reporting a vulnerability — the contact address, web form or tracker — and how reports are tracked with an identifier and acknowledged within the time the disclosure policy declares.
  Check: A public, accessible mechanism exists, and received reports are stored with tracking identifiers. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part II(6); prEN 40000-1-3:2025 §5.4.2 [RCP-1-RQ-01 to RQ-03].
• Secure communication option Documentation · Annex VII(2)(b)
  The secure means offered for sensitive reports — a TLS web form, encrypted email — and evidence it was used where reports came in.
  Check: The mechanism is documented and, where reports exist, was used. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.3.6 [PRE-5].
• Upstream stakeholder map Documentation · Annex VII(2)(b)
  The list of upstream suppliers and open-source projects behind the product's components, checked for completeness against the SBOM, and how vulnerabilities found in their components are communicated to them.
  Check: The list exists and is complete against the SBOM. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.3.2 [PRE-1-RQ-04] and its assessment criteria; prEN 40000-1-2:2025 §7.11.3 (discovered vulnerabilities disclosed to the third party).
• Fixes shared back to the component's maintainer Record · Annex VII(2)(b)
  Where you fixed a vulnerability in a third-party or open-source component yourself, evidence that you shared the fix — the code, or the documentation of it — with the person or entity that maintains that component. Mark this as not applying if you have never developed such a fix.
  Check: For each fix developed on a component you do not maintain, the share is evidenced: a pull request, a patch sent, an issue with the fix attached. Basis: Regulation (EU) 2024/2847. Sources: Art. 13(6), second sentence — the manufacturer shares the fix, or the documentation of it, with the person or entity maintaining the component.

What an assessor will ask for — Show that updates cannot be tampered with on the way to the product, that they arrive in time, and automatically where the product supports it.

• Secure distribution mechanism Documentation · Annex VII(2)(b)
  How updates are protected in distribution — signing for authenticity, integrity protection in transit and in storage, authenticated access to the hosting location — and the automatic distribution mechanism where the product supports one.
  Check: The mechanism ensures authenticity and integrity, and automatic distribution exists where applicable. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part II(7); prEN 40000-1-3:2025 §5.3.11 [PRE-10] and §5.7.2 [RLS-1-RQ-04]; prEN 40000-1-2:2025 §7.7.2.3–7.7.2.5 (secure digital production and distribution).
• Distribution evidence Verification · Annex VII(6)
  Evidence of a security update actually distributed through the mechanism, and of the installation instructions provided where distribution is not fully automated.
  Check: Distribution and instructions are evidenced. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.7.2.5 [RLS-1] assessment criteria.
• Expedited handling for critical vulnerabilities Process · Annex VII(2)(b)
  The rule that a vulnerability whose risk exceeds your threshold is resolved outside the normal update cycle, and a case where it applied if one exists.
  Check: The rule exists in the policy, and expedited cases are evidenced. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.5.3 [VRF-2-RQ-03]; Annex I Part II(7) (in a timely manner).

What an assessor will ask for — Show that security updates are free, go out without delay, and come with an advisory that tells users what to do.

• Security updates free of charge Documentation · Annex VII(2)(b)
  The statement, in your terms or user information, that security updates are provided free of charge — or the agreement with a business user for a tailor-made product that says otherwise.
  Check: The commitment, or the agreement, exists. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part II(8); prEN 40000-1-3:2025 §5.7.2 [RLS-1-RQ-01].
• Timely dissemination record Record · Annex VII(6)
  For released security updates, the dates from availability to distribution, showing dissemination without delay, and the advisory that accompanied each with the action users should take.
  Check: Dates and advisories exist per update. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Annex I Part II(8); prEN 40000-1-3:2025 §5.7.2 [RLS-1-RQ-02] and §5.7.3 [RLS-2].
• Installation instructions Documentation · Annex II
  The installation instructions provided with security updates where installation is not fully automatic.
  Check: Instructions exist for manual updates. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.7.2 [RLS-1-RQ-03].

What an assessor will ask for — Show that components from others were chosen with care, carried into the risk work, and are watched.

• Component selection justification Documentation · Annex VII(2)
  For each third-party component, why it was selected and what was checked: CE marking where available, known vulnerabilities in the EU Vulnerability Database or other public databases, secure-by-design indicators, patch availability, vulnerability handling, its own risk assessment, and its support period.
  Check: Documented due diligence exists for the selection and integration of third-party components. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Art. 13(5); prEN 40000-1-2:2025 §7.11.3–7.11.5 (due diligence applied to the selection; the selection justified and documented), with the list of things to check described in §7.11.1 (General — informative).
• Third-party components in the risk assessment Documentation · Annex VII(3)
  Evidence that third-party components and their integration were included in the risk assessment and treatment, securely integrated, verified, added to the SBOM and monitored over their lifecycle.
  Check: The risk assessment covers the components, and the other activities reference them. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.11.3; Guidance C(2026) 5252 §7.3.
• Supplier agreements (where responsibilities are shared) Documentation · Annex VII(2)
  Agreements with component or service suppliers that allocate security responsibilities between you and them — the cybersecurity supplier agreement pattern or an equivalent. Mark this as not applying where no responsibilities are shared.
  Check: Agreements exist where responsibilities are distributed. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 Annex B (informative).

What an assessor will ask for — Show that vulnerability handling is planned for the whole support period and that the product is actually being watched.

• Support-period commitment and plan Documentation · Annex VII(4)
  The support period as determined and its rationale, with the plan for vulnerability handling, updates and component obsolescence across that whole period.
  Check: The period is determined per Art. 13(8), and the plan covers all of it. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Art. 13(8); prEN 40000-1-2:2025 §7.2.3 (support period; update, upgrade and obsolescence planning); Guidance C(2026) 5252 §5.
• Product monitoring record Record · Annex VII(2)(c)
  Evidence that the product is monitored for security issues across its lifecycle, including the end of support of the third-party components it contains.
  Check: The monitoring output exists and is current. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-2:2025 §7.9.3–7.9.5; prEN 40000-1-3:2025 §5.4.3 [RCP-2-RQ-04].
• Effectiveness monitoring of vulnerability handling Record · Annex VII(2)(b)
  How the effectiveness of the vulnerability handling process is measured over time — time to remediate, cases per period — and the results.
  Check: Evidence of process monitoring exists. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: prEN 40000-1-3:2025 §5.3.2 [PRE-1-RQ-03].

What an assessor will ask for — Show that a security update, once issued, stays available for as long as the regulation requires.

• Update retention policy Process · Annex VII(2)(b)
  Your policy that each security update stays available for ten years after it is issued or for the rest of the support period, whichever is longer, and where retained updates are kept.
  Check: The policy exists and names the retention location. Basis: Regulation (EU) 2024/2847. Sources: Art. 13(9).
• Availability of past updates Record · Annex VII(6)
  Evidence that previously issued security updates remain retrievable — a listing of the update archive with issue dates.
  Check: Past updates are still available. Basis: Regulation (EU) 2024/2847. Sources: Art. 13(9).

What an assessor will ask for — Show that if a vulnerability is being exploited or a severe incident hits, the right person will file on the Single Reporting Platform inside the clocks, and users will be told.

• Article 14 reporting procedure Process · Annex VII(2)(b)
  The procedure for reporting an actively exploited vulnerability or a severe incident: who decides, who files on the Single Reporting Platform (with working EU Login access), and the 24-hour, 72-hour and final-report steps. The Article 14 panel in this assessment records the owner and the drills.
  Check: A procedure with named roles and the three stages exists. Basis: Regulation (EU) 2024/2847. Sources: Art. 14(1)–(5); Art. 16 (single reporting platform); Guidance C(2026) 5252 §9.1.
• Reporting rehearsal or filing record Record · Annex VII(6)
  A dated rehearsal of the reporting procedure, or the record of a real filing. The drill recorded in this assessment counts.
  Check: At least one dated drill or filing exists. Basis: Commission guidance C(2026) 5252. Sources: Art. 14; Guidance C(2026) 5252 §9.1.
• Informing users of an exploited vulnerability or incident Process · Annex VII(2)(b)
  How affected users are informed without undue delay, including any corrective measures they can take themselves.
  Check: The procedure includes user notification. Basis: Regulation (EU) 2024/2847. Sources: Art. 14(8).

What an assessor will ask for — Show that buyers can see the end of support before they buy, and that users are told when it arrives.

• End-of-support date at the point of purchase Documentation · Annex II
  Where the support end date is stated so that it is clear and accessible at the time of purchase — packaging, product page, user information.
  Check: The date is stated at purchase and matches the determination. Basis: Regulation (EU) 2024/2847. Sources: Art. 13(19); Guidance C(2026) 5252 §5.
• End-of-support notification Process · Annex VII(2)
  How users are notified when the support period ends and what the end means for continued use of the product, as planned in the decommissioning plan.
  Check: The notification method and its content are planned. Basis: prEN 40000 draft (CEN enquiry; not yet cited in the OJ). Sources: Art. 13(19); prEN 40000-1-2:2025 §7.10.1 and §7.10.3 (obligations that extend beyond the end of support).

What an assessor will ask for — Show the marking as it is actually affixed, and the declaration it stands on.

• CE marking as affixed Verification · Annex VII(1)(c)
  A photograph or screenshot of the CE marking as affixed to the product, its packaging or — for software — its documentation or accompanying information.
  Check: The marking is visible, legible and, where physical, indelible. Basis: Regulation (EU) 2024/2847. Sources: Art. 30(1)–(3); Regulation (EC) No 765/2008 Art. 30.
• Declaration behind the marking Documentation · Annex VII(7)
  The EU declaration of conformity the marking relies on — generated from this assessment once every requirement is met and signed.
  Check: A signed declaration exists for this version. Basis: Regulation (EU) 2024/2847. Sources: Art. 28; Annex V.