Technical planning decides what is migrated, when and how. The organisation identifies dependencies between cryptographic assets from the inventory and sets the order, keeping the post-quantum option optional until all related assets have moved so interoperability is kept; decides for each asset whether it is replaced, redesigned, retired or otherwise handled, based on its importance, the consequences of failure, its attack risk and resources, and picks a replacement that allows cryptography to be changed later. Assets stay protected during migration by keeping the existing protection until the new one is in place, or, failing that, by isolating them, accepting the loss of availability while isolated; the availability and deployment time of replacement hardware is built into the plan; and new hardware and software solutions are tested to confirm they work with the surrounding infrastructure and deliver the security they claim.
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.