Before a process for an examination is designed, a proper requirement set is produced, agreed with the client and recorded to good practice, derived from the requirements of the whole investigation and covering functional and non-functional needs. Each statement is necessary, free of any implementation choice, clear in meaning, complete, single in subject and consistent with the rest. Requirements can be grouped by type: functional (tasks, inputs and outputs), performance (extent, quality and conditions), interface (interaction with outside systems and between parts, people included), process (local law, procedure and administration) and non-functional (portability, reliability, maintainability, security, safety, efficiency, wellbeing). The set also states the operating limits expected for the evidence and processes (for example largest file size, fewest and most input values). Because a fresh set may be needed per case, reusable predefined atomic stages that take case parameters are preferred to monolithic designs, so that case-specific validation is confined to the parameters (a keyword filter is validated once; the choice of keywords, and the variants they miss, is what each case must check). The incident and the limits of the investigation are defined, the evidence sources and questions to answer identified, and risks to the investigation, people and systems identified; the team then derives requirements for each examination, analysis and process (see ISO/IEC 27042).
This control maps to 2 controls across 2 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 2 it maps to, and the evidence behind each claim, over MCP and REST.