A development assurance level states how much rigor goes into keeping the chance of safety-relevant development errors acceptably low, and it covers the interfaces with related functions or items too. Levels follow how severe the top-level failure condition is, with credit for independence between development processes: for a catastrophic condition that a single development error could cause, level A; where it needs a combination of errors in two or more independent members, either one member at level A or two at no less than level B, the others no lower than level C, and the process that substantiates the independence stays at level A. For hazardous conditions the corresponding levels are B (single error), and either one at B or two at C with the rest no lower than D (combination), independence substantiated at B. For major conditions, C, or one at C or two at D, independence at C. For minor conditions, D (single error) and at least one at D (combination). Where the condition has no safety effect, level E may be 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.