Each proposed change should be evaluated, and the evaluation kept as documented information; how far the evaluation goes depends on how complex the product or service is and on the change category. It should cover the technical benefits, the risks, the likely effects on the contract, the schedule and cost, and what would happen if the change were not approved. When working out the effects, the organization should also take into account legal and regulatory requirements, whether items remain interchangeable or need new identification, interfaces between items, methods of manufacture, test and inspection, inventory and purchasing, delivery activities, and what customer support will require.
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.