Edit EN-304-625.md

**See Annex C for more information.**

The most important quality of a technical requirement is that it should ideally be objectively testable on an instance of the product. If it cannot be tested on the product itself, it is a documentation requirement, in which the assessor documents the steps they took to implement the requirement (such as configuration files or written policies used by employees).

The most important quality of a technical requirement is that it should ideally be objectively testable on an instance of the product. If it cannot be tested on the product itself, it is a documentation requirement, in which the manufacturer documents the steps they took to implement the requirement (such as configuration files or written policies used by employees).

The alternative is “check-box” requirements, which only require that the vendor says that they did a thing (“Did you have every commit code-reviewed by a second person? [x] Yes [ ] No”). These are not acceptable and should be converted into testable requirements if possible and documentation requirements otherwise.

### C.2.1 List of risk factors

Risk factors determine which mitigation(s) satisfy each of the technical requirements in clause 5.2. The assessor of a product determines the level of each risk factor via the development of a threat model and risk profile based on the intended and foreseeable use and misuse of the operating system.

Risk factors determine which mitigation(s) satisfy each of the technical requirements in clause 5.2. The manufacturer of a product determines the level of each risk factor via the development of a threat model and risk profile based on the intended and foreseeable use and misuse of the network interface.

Risk factors may increase the likelihood of an incident, increase the impact of an incident, or both. As a result, different mitigation strategies may be more or less relevant to different risk factors.

### C.6.1 General

Security profiles are an informative resource to the assessor. Each security profile is associated with a collection of levels of risk factors. Security profiles will be mapped to specific mitigations for each security requirements necessary to treat the risk.

Security profiles are an informative resource to the manufacturer. Each security profile is associated with a collection of levels of risk factors. Security profiles will be mapped to specific mitigations for each security requirements necessary to treat the risk.

### C.6.2 Mapping of security profile to risk factors

### E.4.1 Vertical standards are optional

Using a CRA vertical standard to assess conformance with the CRA is optional. A product may be assessed for conformance using a variety of other options as outlined in the CRA. If the vertical standard does not fit a specific product, then the assessor has many other options for assessment.

Using a CRA vertical standard to assess conformance with the CRA is optional. A product may be assessed for conformance using a variety of other options as outlined in the CRA. If the vertical standard does not fit a specific product, then the manufacturer has many other options for assessment.

However, there are two advantages to using a vertical standard: (1) it allows self-assessment of Important Class II products, (2) it provides presumption of conformity. Note that all products consistently entirely of free and open source software as defined by the CRA can always self-assess, with or without a vertical standard.