Cloud security monitoring and logging is the combination of recording events across systems, networks and applications (logging) and continuously analyzing those records to spot anomalous behavior (monitoring). Together, they give security teams the visibility needed to detect incidents, investigate root causes and prove regulatory compliance.
For companies running on AWS, Azure or GCP, that visibility is not optional. Without centralized logs and active monitoring, an incident can go unnoticed for days or weeks, and the response required under regulations like Brazil's LGPD becomes much harder to demonstrate.
In short
- Logging records events; monitoring actively analyzes those records to detect anomalies. ISO/IEC 27001:2022 treats them as separate controls, A.8.15 and A.8.16.
- Annex A.8.15 of ISO 27001:2022 lists the events organizations should log: access attempts, configuration changes, elevated privilege use, security tool activation, and more.
- AWS, Azure and GCP each offer native detection stacks (CloudTrail, CloudWatch and GuardDuty on AWS, with equivalents on Azure Monitor and GCP Cloud Logging) that need to be combined for full coverage.
- Logs must be protected against tampering, ideally with append-only storage and cryptographic hashing, and follow a documented retention policy.
- LGPD does not set a technical log retention period, but Brazil's ANPD Resolution CD/ANPD No. 15/2024 recommends notifying incidents within 3 business days, which makes audit trails essential to demonstrate accountability.
What is cloud security monitoring and logging?
Cloud security monitoring and logging form the foundation of operational visibility: logs are the raw record of events (who accessed what, when and from where), while monitoring is the process of analyzing those records in real time or near real time, correlating signals to identify threats before they cause damage.
That distinction is not just conceptual. ISO/IEC 27001:2022 formally separates the two topics into different Annex A controls: A.8.15 (Logging) covers recording events, and A.8.16 (Monitoring Activities) covers the active analysis of those records. A.8.16 is actually a new control compared to the 2013 version of the standard, which reinforces that collecting logs alone is no longer enough. Organizations need to continuously analyze them to catch anomalous traffic, unusual resource usage, unauthorized access attempts and signs of attacks such as DDoS.
Without that combination, companies end up accumulating huge volumes of logs that nobody reviews, which cancels out much of the value of the security investment.
What should you log? A checklist based on ISO 27001
Annex A.8.15 of ISO/IEC 27001:2022 details the events an organization should record. This works as a practical checklist for any technical team structuring its logging strategy:
- Successful and failed access attempts to systems and applications.
- Access to critical data and resources.
- Changes to operating system and network configuration.
- Use of elevated privileges, such as administrator accounts.
- Use of system maintenance utilities and tools.
- Access, deletion or migration of files.
- Alarms triggered by access control systems.
- Activation or deactivation of security mechanisms, such as antivirus and firewalls.
- Identity administration actions (account creation, changes and removal).
- Changes to applications and their components.
Each record should include, at minimum, the user identification, the activity performed, the date and time, the originating device or location, and network data such as the IP address. That level of detail is what allows an investigation to reconstruct the timeline of an incident.
How does the detection stack work across public clouds?
In practice, cloud detection combines several native tools that together cover API call logging, infrastructure metrics, configuration history and threat analysis. No single tool delivers complete visibility on its own; it's the combination that closes the gaps.
The AWS Well-Architected Framework, in its Security pillar, recommends a detective controls architecture that repeats, under different names, across the other major providers:
| Function | AWS | Azure | GCP |
|---|---|---|---|
| API call logging | CloudTrail | Activity Log | Cloud Audit Logs |
| Metrics and alarms | CloudWatch | Azure Monitor | Cloud Monitoring |
| Configuration history | AWS Config | Azure Policy / Resource Graph | Security Command Center |
| Managed threat detection | GuardDuty | Microsoft Defender for Cloud | Security Command Center |
The CIS benchmarks for Azure and Google Cloud also dedicate specific sections to logging and monitoring, covering audit configuration and alerts for unauthorized API calls. It's worth using the current version of the relevant provider's benchmark as a baseline configuration reference, rather than relying on the native tools alone.
How should you retain and protect security logs?
Retaining and protecting security logs means storing them with integrity, for a period defined in an internal policy, while restricting who can alter or delete them. The goal is to keep the record trustworthy as evidence, even months after the original event.
ISO 27001:2022 (A.8.15) recommends storing logs so they cannot be altered or erased, ideally in append-only, read-only mode, with cryptographic hashing to prove integrity. When logs need to be shared with third parties, such as an incident response vendor, sensitive data like IP address, hostname and username should be masked before sending.
As for how long to keep logs, there is no single magic number. LGPD does not set a technical retention period for security logs; that's left to internal policy, aligned with sector-specific or contractual requirements where they exist. NIST itself is revising its log management guidance (still in draft, published for public comment in October 2023), precisely to guide organizations on generating, transmitting, storing, accessing and disposing of logs across physical, virtual and cloud environments.
A workable retention plan follows three steps:
- Classify which logs are critical for security and audit purposes, and which only have short-term operational value.
- Set different retention periods per category, documenting the rationale.
- Automate archiving and deletion once the period ends, avoiding indefinite data accumulation.
Logs as evidence of accountability under LGPD
Beyond supporting technical detection, security logs underpin the accountability principle in LGPD: the organization's ability to demonstrate, with evidence, that it acted diligently before, during and after an incident.
ANPD, Brazil's data protection authority, treats a security incident as a confirmed adverse event that compromises the confidentiality, integrity, availability or authenticity of personal data. Under Resolution CD/ANPD No. 15/2024, the recommended deadline to notify a relevant incident to the authority is 3 business days, and the controller must keep documentation of the internal assessment, the measures taken and the risk analysis. ANPD also publishes educational materials reinforcing the importance of structured incident response processes.
Without centralized logs, meeting that deadline consistently is nearly impossible. Teams end up manually reconstructing what happened instead of having the timeline ready for analysis.
Where cloud monitoring is heading
Lack of visibility remains a recurring challenge for companies running in the cloud, which is pushing log consolidation toward more modern SIEM platforms. Two trends stand out:
- Growing use of AI and UEBA (user and entity behavior analytics) to correlate security signals with performance signals, reducing false positives.
- Convergence between traditional SIEM and CSPM/CNAPP tools, aiming for unified visibility across multi-cloud environments (AWS, Azure and GCP at once).
These trends reinforce something already embedded in the standards: continuous monitoring is a prerequisite for Zero Trust architectures, not an optional add-on.
Building this visibility consistently, aligned with standards like ISO 27001 and with LGPD, is one of the areas where Cloud Minds Trusted supports companies that need reliable monitoring across AWS, Azure and GCP environments.
Frequently asked questions
What's the difference between logging and monitoring?
Logging is recording system events, such as access attempts and configuration changes. Monitoring is the active, continuous analysis of those records to identify anomalous behavior. ISO 27001:2022 treats them as separate controls, A.8.15 and A.8.16.
Does LGPD require a specific log retention period?
No. LGPD does not set a technical retention period for security logs. That period should be defined in the organization's internal policy, considering sector-specific or contractual requirements where applicable.
How long should I retain security logs?
There is no single number that fits every company. The recommended approach is to classify logs by criticality, set different retention periods per category, and document that policy, rather than keeping everything indefinitely or for too short a time.
What is Resolution CD/ANPD No. 15/2024?
It's the rule that guides the process of reporting security incidents to ANPD, recommending a 3 business day deadline to notify relevant incidents and requiring documentation of the internal assessment and the measures taken.
Do CloudTrail, CloudWatch and GuardDuty do the same thing?
No. CloudTrail logs API calls, CloudWatch collects metrics and triggers alarms, and GuardDuty is a managed threat detection service. They complement each other and together form the baseline recommended by the AWS Well-Architected Framework for detection.
Conclusion
Security monitoring and logging are not just another checklist item. They are the foundation that allows organizations to detect incidents in time, investigate with consistent evidence, and demonstrate accountability under LGPD and standards like ISO 27001. Deciding what to log, how to protect it, and how long to retain it is ongoing work that evolves alongside the cloud environment itself.
If your company needs to build or review this visibility across AWS, Azure or GCP, Cloud Minds Trusted can help design that strategy. Talk to our security, governance and cloud team to plan the next step.