Data returned from the item processes to support system-level work include: item-level derived requirements that could affect function or safety above the item; a description of the implemented item architecture showing the independence and failure containment achieved (for example hardware segregation, software partitioning); evidence of any system or item verification done at item level; for use in the SSA, the hardware failure rates, how much of each failure is detected, common cause points and latency intervals; problem and change reports that might affect requirements at system or item level, or the safety analyses; any limitations of use, configuration constraints or performance, timing or accuracy characteristics; data to help integrate items into the system such as installation drawings, schematics and parts lists; and details of item verification activities proposed for system-level verification. Evidence is also made available that the activities required for the assigned IDAL were carried out, including any assurance obtained through tools.
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.