The most important quality of a technical requirement is that it should ideally be objectively testable on an instance of the product and the documentation that is required to be produced and saved by the manufacturer (and provided to the MSA on request).
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 document that they did a thing (“Did you have every commit code-reviewed by a second person? [x] Yes [ ] No”).
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.
We should prefer testable requirement to check-box requirements, but when a requirement isn’t testable, we can provide a decision tree where the vendor follows specific instructions to document why they have to use a check-box requirement (something that is documentation-only).
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 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.
