What should a cyber incident response plan cover for cloud systems?

A cloud cyber incident response plan is a service-specific operating document that explains how an organisation will manage compromise or disruption within hosted infrastructure, cloud applications, identities, storage and connected services. It must account for the shared-responsibility model: the cloud provider may secure the underlying platform, while the customer remains responsible for areas such as account configuration, permissions, data, endpoints and many security controls.

The plan should be practical enough to guide decisions under pressure and detailed enough to support investigation afterwards. It should cover the following areas.

• Cloud environment and dependency mapping: Record the cloud tenants, subscriptions, accounts, regions, workloads, storage repositories, software-as-a-service applications, identity providers, network connections and critical data held in the environment. Map dependencies between services, including authentication, DNS, APIs, backup platforms, remote access tools and on-premises systems. This shows which components could be affected by a single compromised account or configuration change.
• Responsibility boundaries: Document which controls are operated by the cloud provider, which are managed by the organisation and which are delegated to a supplier. The plan should identify the provider’s security portal, support route, notification process and evidence available to the customer. This prevents an incident team from assuming that the provider will investigate or preserve information that only the customer can access.
• Incident definitions and decision criteria: Set out what constitutes a suspected event, a confirmed incident and a major incident. Include cloud-specific examples such as an unfamiliar administrator, a disabled security control, mass deletion of files, unusual data downloads, a newly created access key, an unexpected mailbox forwarding rule or changes to network security settings. Define the evidence needed to move between these classifications.
• Telemetry and log requirements: Identify which logs must be enabled, where they are stored and how long they are retained. Relevant sources can include identity and sign-in records, administrative activity, application audit logs, network flow data, endpoint alerts, storage access records and security-control changes. Logs should be sent to a location that an attacker with ordinary administrative access cannot alter or delete. The plan should also record time-zone conventions and clock synchronisation requirements so that events from different services can be compared accurately.
• Cloud-specific detection scenarios: Describe the indicators that should trigger investigation. These may include impossible-travel sign-ins, authentication from unfamiliar infrastructure, privilege elevation, use of dormant accounts, large-scale downloads, suspicious API calls, encryption activity, unusual workload creation or a security group being opened to the public internet. For each scenario, state the initial checks required and the threshold for escalation.
• Containment options: List the safest actions for each type of compromise, with their likely effects. Options may include disabling a user session, revoking tokens, rotating credentials and secrets, restricting an API key, isolating a workload, removing a malicious forwarding rule, blocking a network route or placing storage into a protected state. Actions should be ordered so that they limit further harm without destroying volatile evidence or interrupting dependent services unnecessarily.
• Privileged access safeguards: Specify how emergency administration is performed and recorded. The plan should identify approved break-glass accounts, require strong authentication where possible, define who can authorise their use and require passwords or keys to be changed afterwards. It should also explain how compromised service accounts, application secrets, certificates and machine identities are disabled or replaced without overlooking automated processes that rely on them.
• Data exposure assessment: Explain how to determine what information may have been viewed, copied, changed or deleted. The assessment should consider storage permissions, database queries, download activity, sharing links, mailbox access, API calls and synchronisation to other systems. Record the relevant data owners, retention requirements and contractual restrictions so that the investigation can distinguish between a technical compromise and a reportable loss of information.
• Forensic handling in hosted environments: Define what can be collected directly, what must be requested from a provider and what may disappear when a virtual machine or container is stopped. Possible sources include disk snapshots, memory where available, audit trails, identity records, application logs, configuration history and copies of affected files. Preserve original material, record who collected it and maintain a clear chain of custody. Avoid making changes to a compromised resource until the investigative consequences have been considered.
• Provider and supplier coordination: Include the information needed when raising a cloud security case, such as tenant identifiers, affected resources, event times, suspicious identities, relevant log references and actions already taken. Define how provider advice will be validated and recorded. Third-party applications should have named owners and documented permissions, because an incident may originate in an integrated service rather than in the primary cloud platform.
• Business impact and service decisions: Set criteria for deciding whether a workload should remain online, be isolated, be restored in a separate environment or be taken offline. Consider data integrity, customer access, regulatory obligations, operational dependencies and the risk of allowing an attacker to remain present. The plan should distinguish between restoring availability and proving that the restored environment is trustworthy.
• Recovery assurance: Describe how clean recovery points are selected and how restored systems are checked before returning to normal use. Checks should cover malware, unauthorised accounts, altered permissions, persistence mechanisms, exposed secrets, insecure configurations and unexpected outbound connections. Reconnect dependent services in a controlled order, monitor them for further suspicious activity and document any temporary controls that remain in place.
• Regulatory and contractual considerations: Record the circumstances that require consultation with legal advisers, insurers, regulators, customers, employees or contractual partners. Cloud hosting can involve multiple locations and subprocessors, so the plan should identify where relevant data is processed and who must be notified if that information changes. Do not assume that a provider’s incident notification automatically satisfies the organisation’s own obligations.
• Post-incident improvement: Require a structured review after each incident or exercise. Examine how the compromise occurred, which controls detected it, whether logs were sufficient, whether permissions were excessive, whether provider support met expectations and whether recovery assumptions were accurate. Convert findings into named actions with owners, priorities and review dates, then update the plan when the cloud architecture or suppliers change.

The document should include contact details, system owners, authority levels, decision records and concise runbooks for the most likely scenarios. Sensitive response information should be stored separately from the systems that may be affected, with controlled access and an offline or otherwise independent copy. A plan that exists only as an untested document may fail when cloud consoles, identity services or communications platforms are unavailable.

Cloud incident response also needs regular validation. Tabletop exercises can test decision-making, while technical simulations can confirm that logs are collected, access can be revoked, backups are usable and provider contacts understand the issue. Exercises should cover both loss of administrative control and compromise of an individual cloud application, because the available evidence and containment choices may differ substantially.

In practical terms, a strong plan connects cloud architecture with clear decisions: what to examine first, what can safely be changed, who has authority to act, how affected data will be assessed and what evidence is needed before services are trusted again. It should be reviewed whenever cloud services, permissions, integrations, suppliers or business-critical data locations change.