Assessment evaluates that the lifecycle processes and their products make the software fit for the application it is meant for at the defined software safety integrity level. The assessor is independent of the design team (and, per 5.1, of the project), has access to the design and development work and to every project document, assesses that the software and system respond correctly to the safety matters that follow from the system safety requirements specification, decides to the extent the SIL requires whether appropriate methods were selected and applied at each phase, agrees where required the scope and contents of the validation plan and states whether present during testing, and may request further verification and validation. For Basic Integrity the assessor need only confirm that the level is appropriate (or the level is agreed between supplier and user at ordering). Software already carrying an assessment report from another assessor is not re-assessed in full: the second assessor checks that it is at the required level and fit for the intended application and target computer. The assessor produces a software assessment plan and a report for each review; the final report states the level achieved where the software is fit, and where it is not fit or has not achieved the level, reports only the non-conformities and gives no technical solution (6.4.4 to 6.4.9).
This control maps to 1 controls across 1 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 1 it maps to, and the evidence behind each claim, over MCP and REST.