Skip to main content

Clause 6.3 — Risk acceptance criteria

Subclause 6.3 specifies requirements to define risk acceptance criteria under FprEN 40000-1-2:2026. Acceptance criteria determine whether identified risks require active treatment or can be accepted.

What Clause 6.3 requires​

Requirements​

  • [RMA-02-RQ-01]: Define, justify, and document risk acceptance criteria for the product context (6.2), including:
    • Relevant regulatory factors (safety and privacy legislation).
    • Supply chain considerations (contractual agreements, downstream integrators, risk sharing).
    • Nature of known risks (user health and safety, impact severity, inherent functional risks).
    • State of the art.

Outputs and Assessment​

  • Output: Documented product cybersecurity risk acceptance criteria (C6.3-OUT-01) and applied methodology (C6.3-OUT-02).
  • Assessment Criteria: PASS assigned when documented criteria exist, align with the product context, and cover all required factors.

How CVD Portal supports compliance​

CVD Portal provides structured risk criteria documentation, evaluable acceptance rules, and deterministic artifact generation:

  • Evaluable acceptance rules: Define ordered acceptance rules with condition triggers (impact, likelihood, interface restrictions, user capabilities, access restriction, and a cause limited to initial misconfiguration) and mandatory justifications.
  • BSI TR-03183-1 baseline: "Load BSI TR-03183-1 baseline rules" adds the six acceptance criteria of TR-03183-1 v1.0.0 section 5.14.3, one rule each, in the guideline's order. Two cover local attacks, two cover network attacks, and two cover an initial misconfiguration of the product. The guideline's "high" impact is "major" here. The guideline calls these criteria a starting point to tailor to your product and sector, so each rule stays editable.
  • Baseline on many products: On the Risk page, an admin can load the baseline on every product that has no rules yet, or only the earlier BSI rules, in one step. A review panel lists the products before anything is saved. Products with rules that a person wrote are never changed, and a product with a reviewed technical file changes only when the admin includes it. See "Risk across products" on the products and compliance workspace page.
  • Threat cause: When a rule is limited to initial misconfigurations, each threat shows a "Cause" selector (attack or initial misconfiguration). Until the threat has a cause, the rule cannot be checked and the risk stays undecided.
  • Proposed causes: "Generate threats" asks the AI for the cause of each threat. A threat is an initial misconfiguration when it exists only because the product is set up insecurely at first use, for example a default password left in place. The AI leaves the cause empty when the product context does not tell. A proposed cause shows "proposed by AI" next to the selector, and the acceptance verdict uses it at once. To keep it, click Accept cause or confirm the threat. To change it, pick another value. An MCP agent that saves threats can also propose a cause, but it never replaces a cause that a person picked or accepted.
  • Earlier baseline: Before October 2026 the baseline added three rules that cited section 5.14.3 without matching it. A product that still holds them shows a notice. Load the baseline again to replace them. A retired rule whose justification you rewrote is yours, and stays.
  • Automated acceptance decisions: Evaluate risks against configured rules to determine whether a risk is acceptable, not acceptable (naming the triggering rule), or undecided. A risk is undecided when no rules are configured, or when no rule matched but a rule could not be checked because the data it needs is not recorded. Examples are a risk with no impact or likelihood, a network rule on a product with no recorded interfaces or with an interface that has no restriction, a local-attack rule on a product with no access restriction, or a misconfiguration rule on a threat with no recorded cause. Missing data never makes a risk acceptable.
  • What an undecided risk needs: A line next to each "Undecided" verdict names the data to record, for example "Record the product interfaces to check the acceptance criteria". The name links to the field in the Product context panel. The risk register shows one such line for all its undecided risks, and the risk detail page shows it for its risk.
  • Interfaces from the asset register: The acceptance rules read the interface list in the Product context panel, and the asset register does not count. When the interface list is empty and the asset register holds confirmed network assets, the list offers "Add N interfaces from the asset register". It adds one interface for each asset, with the asset's name and no restriction. Choose the restriction of each interface. The restriction decides which rules apply, so CVD Portal never chooses it for you, and until you choose it the risk stays undecided. "Add interface" also starts with no restriction.
  • Standard 5x5 scoring grid: Score each risk from its likelihood (1 to 5) and impact (1 to 5) into Low, Medium, High, or Critical bands on a fixed 1 to 25 scale.
  • Six-factor basis (6.3.3): Record the six required factors (regulatory requirements, contractual obligations, known risks, user nature, product nature, state of the art) in the assessment data.
  • Risk criteria documentation (C6.3-OUT-01): Generate the product risk acceptance criteria document from the standard scoring scales, the six-factor basis, and the evaluated acceptance rules.
  • Standardized risk methodology (C6.3-OUT-02): Generate the CRA risk assessment and treatment methodology document automatically.
  • Enforced treatment justifications: Enforce written justifications for any risk marked as accepted or transferred during validation.