Clarify and re-number section 5.1

# 5 Requirements specifications

## 5.1 Notes on the structure of requirements

## 5.1 Notes on the structure of the Requirements

**IMPORTANT:** Not all requirements are necessary for all products. The mapping tables at the end of each requirement shows which risk factors and use cases determine which requirements are necessary for the product. See Annex C for more information.

**EDITOR'S NOTE:** The CRA requires the manufacturer to keep all the documentation necessary to show that the tests were conducted. In Article 13 Rec. 22, MSA's are granted the right to request "all the information and documentation, in paper or electronic form, necessary to demonstrate the conformity of the product with digital elements and of the processes put in place by the manufacturer with the essential cybersecurity requirements set out in Annex I." The objective of these requirements is to provide manufacturers with sufficient guidance to consistently satisfy such requests from the market authorities. 

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

### 5.1.1 Necessity of Requirements

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.

Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.

The CRA requires the manufacturer to keep all the documentation necessary to show that the tests were conducted. In addition, the CRA explicitly grants the MSA the following rights in Article 13 Rec. 22:

### 5.1.2 Types of Technical Requirements

> "Manufacturers shall, upon a reasoned request from a market surveillance authority, provide that authority, in a language which can be easily understood by that authority, with all the information and documentation, in paper or electronic form, necessary to demonstrate the conformity of the product with digital elements and of the processes put in place by the manufacturer with the essential cybersecurity requirements set out in Annex I. Manufacturers shall cooperate with that authority, at its request, on any measures taken to eliminate the cybersecurity risks posed by the product with digital elements which they have placed on the market."

**Testable Requirements:** The essential quality of technical requirements is their capability to be verified by testing an implementation of the product. This verification ensures that the requirement can be assessed in an objective manner. If such verification is not practicable, the requirement is instead classified as a documentation requirement. 

The goal is that when the MSA does a “sweep” or otherwise decides to verify a product’s conformance with the CRA, it has enough information that it can do its own independent testing without unnecessary barriers that could be solved by vendor documentation (e.g., does not have to reverse-engineer how to attach a serial console and read logs). Note that it is easer for an MSA to evaluate conformance via transparency - reviewing the test output and documentation to evaluate whether a mitigation is implemented - over actually testing the product themselves.

**Documentation Requirements:** For documentation requirements, the manufacturer shall provide supporting documentation, including but not limited to configuration files and documented organizational policies to ensure that compliance with the standard can be demonstrated even when direct product testing is not feasible.

A few assumptions that we are making:

**NOTE:** Simple process requirements (e.g., a statement that something has been done, without supporting evidence) are not acceptable and should be converted into technical requirements whenever possible and documentation requirements otherwise.

* Manufacturers are already required to provide the ability to enable testing and collect output on the product as placed on the market, and will supply instructions for enabling and collecting test data.

### 5.1.3 Assumptions Regarding Requirements

* The MSA can and will request source code if desired.

#### 5.1.3.1 Testability

Mitigations are how a technical requirement can be satisfied. Mitigations should be tailored to the use case and take into account the user’s sophistication and the operational environment.

Manufacturers are already required to provide the ability to enable testing and collect output on the product as placed on the market, and will supply instructions for enabling and collecting test data.

Some risks may be transferred partially or fully to other components of the system or the user of the product. When that is the case, migitations that transfer the risk will be included as an option to fulfill a technical requirement, depending on the use case and risk factors.

#### 5.1.3.2 Source Code 

Format:

The market authorities may request source code access as part of a verification process, if necessary.

#### 5.1.3.3 Mitigations

Mitigations are the technical means by which a technical requirement is satisfied. Mitigations should be tailored to the use case and take into account the foreseeable and expected skill level of the product's users, appropriate for the expected operational environment, and proportional to the foreseeable risk.

### 5.1.3 Risk Transferral

Some risks may be transferred partially or fully to other components of the final product, or to the user of the product. When that is the case, migitations that transfer the risk will be included as an option to fulfill a technical requirement, depending on the use case and risk factors.

## 5.2 Technical security requirements specifications