An organization moved its core ERP system to a cloud provider and restructured its IT team last year. Its incident response and recovery plans were last tested two years ago. What should concern the security manager MOST?

Incident response and recovery plans should be tested at planned intervals and whenever significant change occurs in the environment, organization or threat landscape. Moving a core system to a cloud provider changes dependencies, contacts, recovery mechanisms and shared responsibilities, and restructuring the IT team changes who holds each role. A plan untested since before those changes may reference systems, people and procedures that no longer exist, so management has no evidence that it would work in a real incident. That uncertainty is the most significant concern because it directly affects the organization's ability to respond and recover. An external auditor's review is an assurance activity, not a readiness control; its absence matters far less than an untested plan. Lapsed professional certifications are a personnel matter and do not indicate whether the plan reflects the current environment. Retention of old test results is a records issue; even perfectly retained results would describe an environment that no longer exists. Exam caveat: when a stem pairs stale testing with a major change, the answer centres on the validity of the plan, not on documentation or audit artefacts. Operational check: confirm the testing schedule includes triggers for major change and that the next test covers the cloud provider's role.