Most of the organization's critical applications moved to cloud services over the past year, but the incident response plan still describes only on-premises systems and contacts. What should the information security manager do?
Select an answer to reveal the explanation.
Short Explanation
Your plan is a map of a house you've moved out of. When the environment changes significantly, the plan has to change too, and then you test it to make sure the new map works. Leaning on the cloud provider's process is the trap; they handle their side, not yours.
Full Explanation
An incident response plan must reflect the environment it protects. A large move to cloud services changes where logs and evidence reside, who can take containment actions, which provider contacts must be engaged and how responsibilities are divided between the provider and the organization. The plan should be updated to cover these elements and then tested, for example through a cloud-focused tabletop exercise, to confirm the revised procedures work. Relying on the providers' own processes ignores the shared responsibility model: providers respond to incidents in their own infrastructure, but the organization remains responsible for its data, identities, configurations and its own incident decisions. Waiting for the annual review leaves the organization with an inaccurate plan for months after a significant change, which is precisely the situation that should trigger an out-of-cycle update. A separate cloud plan written in isolation creates inconsistent roles, escalation paths and communication, the same problem that misaligned plans create in a major incident. Exam caveat: significant change, whether technical, organizational or regulatory, is a standard trigger for plan review. Operational check: confirm the updated plan lists provider support contacts, log sources, and the specific actions the organization can take in each cloud service.