Assessment domain
Logging & monitoring
Logging and monitoring is the difference between catching an incident while it is happening and learning about it from a customer, a regulator, or a ransom note. In the cloud, the record of who did what lives in provider audit trails that are easy to leave switched off, easy to under-scope, and easy for an attacker to erase. We assess whether the trail exists everywhere it needs to, whether it survives tampering, and whether anyone would actually notice the events that matter.
Why it matters
Where the risk lives
You cannot investigate, contain, or prove an incident you never recorded — and in a cloud breach the logs are usually the only evidence there is. Gaps concentrate in exactly the wrong places: new accounts spun up without audit logging, detection findings that fire into an inbox nobody watches, and short retention that ages out the data before an investigation begins. Auditors, cyber insurers, and incident responders all check for this first, which is why logging findings map directly to SOC 2, PCI-DSS Requirement 10, HIPAA audit controls, and CIS monitoring benchmarks.
What we assess
The checks inside logging & monitoring
Each area below is a focused review with its own findings, per-cloud detail, and remediation.
Audit log coverage
Control-plane audit logs record every API call that creates, changes, or deletes cloud resources — the primary source of truth for an investigation. Coverage tends to drift as the estate grows: a new account, region, or project gets stood up and the trail is never enabled, leaving silent blind spots. We measure whether audit logging is on everywhere and captures the event types that matter, not just a sample.
What we look forRetention & log integrity
Logs are only evidence if they are still there and provably unaltered when you need them. Default retention windows are often far shorter than an investigation or an audit period, and logs stored in the same account they record can be deleted by the very identity that was compromised. We check how long logs are kept and how hard they are to tamper with.
What we look forThreat detection & alerting
Collecting logs is not detecting threats — someone or something has to turn events into a signal a human acts on. Each provider ships native detection, but it is frequently left disabled, or its findings route nowhere and quietly pile up. We assess whether detection is enabled across the estate and whether its output actually reaches a responder.
What we look forIncident reconstruction & forensics
When something goes wrong the question is always the same: what did they touch, when, and from where. Answering it requires that the right logs existed before the incident, are correlated across accounts, and can be pieced into a defensible timeline. We assess whether you could actually rebuild an incident rather than assuming the data is there.
What we look forAcross your clouds
AWS, Azure & Google Cloud
AWS
CloudTrail (management and data events) delivered to a dedicated logging account with log-file validation and S3 Object Lock; GuardDuty for threat detection and Security Hub for aggregation; CloudWatch and VPC Flow Logs for detail and retention.
Azure
Activity logs and resource Diagnostic settings exported to a Log Analytics workspace or immutable storage; Microsoft Defender for Cloud for detection; Microsoft Sentinel for SIEM routing, correlation, and alerting across subscriptions.
Google Cloud
Cloud Audit Logs (Admin Activity always on; Data Access to be enabled) exported via log sinks to a separate project or bucket with retention locks; Security Command Center for detection and findings aggregation.
Example finding
Audit logging disabled in two of five production accounts, with 90-day retention on the rest
Risk: Two accounts would leave no reconstructable trail of an incident, and the others age their evidence out before a typical breach is even discovered.
Fix: Enable organization-wide audit logging to a central, access-controlled account with log-file validation, and extend retention to cover the longest audit and dwell-time window you answer to.
Questions
What if we already have a SIEM?
Good — a SIEM is the right destination. We assess whether the right sources actually reach it across every account and region, whether coverage has gaps, and whether the alerts that fire map to events a responder would act on.
Do you need to read our log contents to assess this?
No. The review is read-only and focused on configuration — whether logging is enabled, how long it is retained, how it is protected from tampering, and where detection routes. We confirm the trail exists and is sound without mining what is in it.
How does logging map to compliance?
Logging findings map directly to PCI-DSS Requirement 10, SOC 2 monitoring criteria, HIPAA audit controls, and the CIS monitoring benchmarks — so the same coverage, retention, and integrity work also produces the audit evidence your assessors ask for.
See where you stand on logging & monitoring
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domains
The rest of the health check
One read-only assessment covers all six domains — here's where else exposure tends to hide.
