**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.
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).
The alternative option 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 a last resort; testable on the product is better than a documentation requirement is better than a check-box requirement. In this case, the check box requirement could be turned into a documentation requirement by requiring the vendor to save the list of commits and who reviewed them.
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.
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:
> "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."
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 the MSAs generally prefer evaluating via transparency - reviewing the test output and documentation to evaluate whether a mitigation is implemented - over actually testing the product themselves.
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.
Mitigations are how a technical requirement can be satisfied. Mitigations must be tailored to the use case and take into account the user’s sophistication and the operational environment.
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.
Each mitigation is described with the following fields where necessary:
Format:
* Test: how to test that the mitigation is implemented
* Result: what result would indicate that the product passed the test
* Output: what output would should be saved
### 5.2.X **TR-XXXX**:
Optional:
#### 5.2.X.x Requirement
* False negative/positive prevention: if necessary, a way to prove that the test distinguishes between conformant and non-conformant products
* Requirements: features of the product as placed on the market necessary to run the test that aren't already required by some other technical requirement
* Documentation: any documentation the manufacturer must save for provision to the MSA in addition to the documentation required for every test
_Description of high-level requirement in “shall” format._
#### 5.2.X.x **MI-XXXX**:
_Description of mitigation implementing the requirement in "shall" format._
* Applicability: (for requirements that depend on a feature)
