Every software system is placed in a safety class according to the worst hazardous situation it could lead to, on the assumption that the software fails with certainty. Class A applies where the system cannot lead to a hazardous situation, or where controls outside the software bring the risk to an acceptable level; class B where, after those outside controls, the possible harm is injury that is not serious; and class C where it is death or serious injury. Further outside controls (hardware, a separate independent software system, healthcare procedures, a changed system architecture) may be added and the class then reassigned. The class is recorded in the risk management file. A software item takes the class of the item it was decomposed from unless a documented rationale shows how it is segregated so it can be classed on its own, and any differing class is recorded. Where a process covers a group of items, the highest class in the group applies unless the file justifies a lower one, and class C requirements apply until a class has been assigned.
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.