The organisation structures technology, processes and policy so cryptography can be updated, changed or replaced with minimal effort and downtime. Technically: a current inventory, (partly) automated creation, distribution and retirement of keys and certificates, calls to cryptographic functions abstracted in code, cryptographic tests in CI/CD pipelines, awareness that supporting several algorithms invites downgrade, and checks that hardware has capacity for heavier algorithms. In processes: agility written into procurement (new components updatable, agility claims reviewed and tested), software development and release, change management (who owns which cryptography and how the whole organisation changes together) and incident response (for example rapid retirement of a compromised key). In policy: agility measures mandated for new systems, periodic inventory updates and named responsibilities, testing of the agility processes, vendor obligations to adopt new PQC algorithms within a set time, and room for more than one algorithm or parameter set without obsolete options. The organisation chooses the forms it needs (migration, compliance, implementation or platform agility, the others only with full understanding), designs agility into new products, and tests whether the time a change takes fits its risk appetite.
This control maps to 3 controls across 3 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 3 it maps to, and the evidence behind each claim, over MCP and REST.