Requirements management keeps the changing requirements together with their context and history, and lays down how requirements baselines are set, controlled and issued at each level. Because a significant share of requirements will change, through analysis errors or shifts in the acquirer's environment or market, change is expected and managed: requirements expected to change are flagged to acquirers and engineers, a stable core may be fixed early, any newly proposed requirement is judged for its effect on what the baseline intends and accepted by the acquirer, and every change request goes through a set sequence of impact assessment, review and approval supported by requirements tracing and version management, so that uncontrolled change does not cause requirements creep, overruns, design errors or cancellation.
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.