Eighteen months after a disaster recovery plan was approved, the application it covers was re-architected from virtual machines into containers managed by an orchestration platform. The plan still describes restoring virtual machine images. What should happen next?

BC and DR plans must be maintained through change management: a significant change to architecture, dependencies, providers or staff is a trigger for review, not something that waits for the calendar. Moving from virtual machines to containers changes almost everything the recovery procedures rely on, including how workloads are rebuilt, where configuration and secrets live, how persistent data is stored and replicated, and which platform components must be restored first. The plan should be updated to reflect the new architecture and its dependencies and then retested, because an untested procedure cannot be assumed to meet the RTO and RPO. Waiting for the annual review leaves the organization depending on instructions that no longer match reality, even though the business requirements are the same. Container orchestration does restart failed containers and reschedule them on healthy nodes, but that is high availability within a cluster; it does not recover from loss of the cluster, the region, the data or the provider account. Declaring containers out of scope while testing obsolete procedures produces false assurance about a system that no longer exists. Exam caveat: plan maintenance and version control are part of the BC/DR lifecycle, alongside testing. Operational check: confirm the change process includes a DR impact question, and that the plan's revision history records this update and the retest result.