Aim: show that the processes and outputs give software of the defined integrity level that meets its requirements and suits its intended application, by analysis or testing that every requirement is specified, implemented, tested and met and by judging the safety criticality of every anomaly and non-conformity. The Validator, independent as 5.1 requires, develops, performs and evaluates validation, documented at least in a Software Validation Plan and Report. The plan justifies the strategy for the integrity level in terms of manual or automated, static or dynamic, analytical or statistical techniques, real or simulated environments, and any other role a validator holds; it sets the steps that show each software specification fits the System Requirements Specification and that the Overall Software Test Specification adequately tests the Software Requirements Specification. The report records the results, confirms verification is complete, identifies exactly which software baseline was validated, and names known deficiencies and their effect on use. The Validator can require or carry out extra audits, reviews, analyses and tests, and no software goes into operation without the Validator's authorisation. Simulation and modelling may supplement validation. Table A.7 and the detailed tables it cites give the techniques.
This control maps to 4 controls across 3 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 4 it maps to, and the evidence behind each claim, over MCP and REST.