The functional, technical and information-processing risks that come with the enterprise's requirements, the assumptions behind them and the solution put forward are identified, recorded, ranked and reduced: requirements risk affecting quality, function and technology is found (for example users not involved enough, expectations that cannot be met, developers building features nobody asked for, assumptions that do not hold, and requirements left incomplete); a suitable response is chosen; and each risk is analysed by estimating how likely it is and how it would affect budget and schedule, with the cost of the responses evaluated.
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.