Cloud environments have sped up delivery, but they have also changed how security incidents unfold and how teams need to respond to them. A well-designed cloud incident response plan shortens containment time, protects the people behind the data, and helps organizations operating in Brazil meet legal deadlines. This guide walks through the practical phases, what changed with NIST SP 800-61 Revision 3, and the LGPD and ANPD obligations that apply locally.
Why cloud environments need a different approach
According to the Unit 42 report from Palo Alto Networks, covering investigations from 2024, 29% of the incidents analyzed involved cloud or SaaS environments. The most common entry vector was not new malware, but compromised credentials, often enabled by misconfiguration and over-permissioned accounts.
That finding points to a central idea: in the cloud, identity and access management, or IAM, sits on the front line of security. Teams that treat cloud incident response as a simple extension of their on-premises plan, without adjusting for roles, API keys, and ephemeral resources, tend to take longer to contain a problem.
From the classic model to NIST SP 800-61 Revision 3
For years, the industry reference was the four-phase model described in Revision 2 of NIST SP 800-61: Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity. That cycle is still widely used across the industry and referenced in cloud provider guides, but it is worth noting that Revision 2 was officially withdrawn in April 2025.
In its place, NIST published Revision 3, which aligns incident response with the NIST Cybersecurity Framework (CSF) 2.0. In practice, this means:
- Detect, Respond, and Recover become the direct core of incident response.
- Govern, Identify, and Protect are treated as broader risk management activities that support response, not isolated checklist steps.
- Continuous improvement stops being just a final lessons-learned meeting and becomes something that runs through the whole cycle.
For technical teams, the four-phase model is still useful as common language, which is why this guide uses it below, but the thinking behind Revision 3 is a useful reminder that preparation, governance, and improvement are not isolated steps. They feed into the response the whole time.
The incident response phases in practice
Detection and analysis
The starting point is knowing what normal behavior looks like in the environment. That includes establishing an IAM activity baseline and setting up alerts for unusual API calls, new role assumptions, and access patterns outside the expected norm.
Native tools help correlate these signals in real time: AWS CloudTrail and GuardDuty, Azure Monitor and Microsoft Sentinel, and Google Cloud Logging. Multicloud teams typically centralize these logs in a single SIEM platform to avoid blind spots between providers.
Containment
Once an incident is confirmed, the goal is to limit its scope without destroying evidence. In the cloud, that usually involves:
- Isolating or quarantining suspicious resources such as instances, containers, or functions.
- Revoking credentials and restricting the IAM permissions tied to the compromised account.
- Moving affected workloads to another zone or region, when that is an option.
Eradication
Eradication means removing the root cause, not just the symptom. That could be an infected container image, a compromised account, or an exposed configuration. Typical actions include revoking tokens, rotating credentials, and validating that configuration changes actually fixed the original flaw.
Recovery
Recovery validates the integrity of services before returning to normal operation. That includes applying pending patches, restoring from clean backups, and closely monitoring the exploited vectors to confirm there is no repeat incident.
One technical point that matters in the cloud: containers, serverless functions, and autoscaling resources are ephemeral. Forensic evidence can disappear within minutes when an instance is automatically terminated. Having a forensic sandbox ready in advance, able to capture snapshots and logs before resources get recycled, makes a real difference in investigation time.
Legal obligations in Brazil: LGPD and the ANPD regulation
Beyond the technical response, companies operating in Brazil need to track legal deadlines. Article 48 of the LGPD, Brazil's data protection law, sets out the controller's duty to report security incidents to the National Data Protection Authority, known as ANPD, and to the affected data subjects.
The ANPD detailed that duty through Resolution CD/ANPD No. 15/2024, which established the Security Incident Communication Regulation, known by its Portuguese acronym RCIS. The key points for security and legal teams to track:
- Reporting deadline to the ANPD and to data subjects: 3 business days from when the incident becomes known, with the option to add further information within up to 20 business days.
- Small-scale data processing agents get double that deadline.
- Reports to the ANPD are filed through the SUPER system.
- Risk criteria: reporting is required when the incident could cause relevant risk or harm to data subjects, such as exposure of sensitive data, data belonging to children, teenagers, or older adults, financial data, authentication credentials, legally privileged information, or large-scale incidents.
- Records and documentation about personal data incidents must be kept for at least 5 years.
Enforcement has become more active: in 2025, the ANPD received 362 security incident reports, close to one a day on average. That is a clear sign that an incident response plan connected to the legal team, not just the technical team, is no longer optional.
Lessons learned as an ongoing process
One mindset shift brought by NIST SP 800-61 Revision 3 is treating improvement as continuous, not as a one-off meeting after an incident is closed. In practice, that means:
- Reviewing IAM controls and exposed configurations as soon as an incident is contained, without waiting for the final report.
- Updating response playbooks based on every new incident, no matter how small.
- Aligning technical findings with the team responsible for LGPD compliance, so deadlines and risk criteria are assessed from the start, not only when the case is closed.
This approach also lines up with established frameworks: ISO/IEC 27001:2022, in controls A.5.24 through A.5.28 of Annex A, treats incident management as part of the information security management system, and ISO/IEC 27035, parts 1 and 2, from 2016, details the incident management process in complementary depth.
A preparation checklist to reduce containment time
Much of what makes incident response effective is decided before the incident happens. A basic cloud preparation checklist includes:
- Centralized logging active across every provider in use, with a minimum retention of 90 days.
- An IAM behavior baseline, with alerts configured for deviations.
- Incident response playbooks built specifically for the cloud, not just adapted from an on-premises plan.
- A forensic environment prepared in advance, ready to capture evidence from ephemeral resources.
- Hardening aligned with recognized benchmarks, such as the CIS Benchmarks for AWS, Azure, and Google Cloud Platform, which reduce the incident surface and support compliance with Annex A of ISO/IEC 27001:2022.
Conclusion
Cloud incident response combines technical discipline, like IAM-based detection and fast containment of ephemeral resources, with attention to concrete legal deadlines, like the ones set by the ANPD. Companies that treat preparation and continuous improvement as part of everyday work, rather than isolated steps, reach containment faster and reduce the impact on the people behind the data.
If your company wants to review or build out its cloud incident response plan, aligned with the LGPD and international frameworks, Cloud Minds Trusted can help put that process into practice.