A reused or reusable software element must come with a safety manual describing its functions, constraints and evidence precisely enough to assess any safety function relying on it; the supplier's documentation may serve if it meets Part 2 Annex D and this annex. The manual carries the Part 2 Annex D content relevant to the element; identifies the element and its instructions for use; documents the element, run-time and build configuration, the recommended configuration to be used in safety applications, and every assumption the justification depends on; and covers integrator competence, the reliance that may be placed on the element (certification, independent assessment, design integrity and standards, constraints the integrator must implement, including requirements only meetable at integration such as response time), installation, reason for release, outstanding anomalies and their mitigation, backward compatibility, compatibility with other systems and build standard (compiler and tool versions), configuration identity and version, change request route, requirements not met, design safe state, interface constraints, security measures against listed threats, and configuration methods. Every claim is justified by supporting evidence held separately; if that evidence cannot be made available for assessment, the element is unsuitable for safety use.
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.