Crypto-agility is often described as an architecture property: the ability to replace algorithms without rebuilding the system. In regulated infrastructure, that definition is incomplete. A platform is not agile until the operations team can change cryptographic policy in a controlled, testable, and auditable way.
Define the control points
The runbook should identify where algorithm policy is enforced: TLS gateways, service mesh configuration, HSM profiles, certificate authorities, signing pipelines, VPN concentrators, package repositories, and client libraries. Each control point needs a named owner, change window expectations, dependency list, and emergency contact path.
Test before policy changes
Before a new post-quantum or hybrid profile is enabled, teams should run implementation test vectors, interoperability checks, handshake-size checks, certificate-chain profiling, and representative latency measurements. The runbook should define which tests are mandatory and what evidence must be attached to the change record.
Plan rollback without hiding failure
Rollback rules need to be explicit. A classical-only fallback can be acceptable during migration if it is logged, time-bounded, and tied to remediation ownership. Silent fallback is dangerous because it makes coverage metrics look better than the actual protection level. The runbook should treat fallback as an exception path, not a success path.
Keep evidence close to operations
Auditors and regulators will not only ask which algorithms were selected. They will ask how the organisation knows those algorithms are deployed, monitored, and maintained. Keep evidence close to the systems that produce it: scan outputs, configuration snapshots, HSM firmware records, certificate inventories, SIEM events, and change approvals should all map back to the same crypto-agility runbook.