Logging and Monitoring: What Auditors Actually Want to See
What logs auditors actually test, what "log review" needs to look like on paper, and the three gaps that fail companies who think they've already got this covered.
Your SIEM is running. CloudTrail is on. You've got alerts wired up for failed logins. Then the auditor asks a question that stops everything: "Can you show me evidence of your log review process from the past three months?" Most teams pause at that. They have logs. They did not realize they needed to prove they read them.
That gap — between having logging and demonstrating a working monitoring program — is where companies lose points on SOC 2 and ISO 27001 audits more than almost anywhere else. Here's how to close it.
What the criteria actually say
For SOC 2, logging and monitoring lives in the CC7 cluster of the Common Criteria — the section dealing with system operations. The requirement is that the organization monitors system components for anomalies and uses that monitoring to identify threats. It's deliberately vague. The AICPA doesn't specify which SIEM to run or how often to schedule reviews. They specify that detection needs to happen and that you can demonstrate it.
In practice, auditors read CC7 through three lenses: collection (are the right events reaching a central system?), retention (are they kept long enough to be useful?), and review (is someone actually analyzing the output?). You can pass two of those and fail the third.
ISO 27001 handles monitoring under its operational controls. The underlying expectations are similar — logs need to exist, be protected from tampering, and be regularly reviewed — though the documentation requirements tend to be more explicit.
What logs you actually need to collect
Not every log carries equal audit weight. The question worth working backward from is: if someone did something harmful in your environment, would you have a record of it? Auditors ask exactly that.
The event categories I focus on first:
- Authentication events. Successful logins, failed logins, MFA prompts, account lockouts. Every system with access to production data or customer records needs to be sending these somewhere central.
- Privileged account activity. What admins are doing, when, and from which location. Anomalies in this stream are the easiest to spot when you've already scoped access tightly — which is why the least privilege work and the logging work reinforce each other.
- Configuration and infrastructure changes. IAM policy updates, firewall rule modifications, cloud console changes, code deploys. Change management is a separate control, but the log trail is part of the evidence for both.
- API access and data operations. For SaaS companies this is often the most important category. Who accessed which customer records, via which endpoint, and when.
- Application errors and exceptions. Not every error is a security event, but unusual error patterns — spiking 403s, repeated bad-parameter requests, authentication errors at scale — can surface exploitation attempts that your perimeter missed.
Retention: the practical number
SOC 2 doesn't mandate a retention period. Neither do most other frameworks, with exceptions: HIPAA sets specific requirements and PCI DSS has its own. But what auditors reliably expect, across frameworks, is this: logs accessible for 90 days in the active system, and a longer archive (typically one year) available on request.
The two-tier approach exists for cost reasons. Keeping 12 months of logs hot in your SIEM adds up fast. Most teams retain 30–90 days in the active environment and push the rest to cold storage — S3 Glacier, Azure Blob, wherever makes sense for the stack. That's fine, as long as the policy is documented and you can actually retrieve archived logs when the auditor asks.
The number that matters most isn't the retention window itself — it's whether your written policy matches your running configuration. I've seen teams document "one year" in their retention policy while their SIEM is configured to 30 days. That mismatch, when discovered during fieldwork, is the finding. Check your actual settings against your policy every time you review or renew that document.
Log review is not the same as having logs
This is the piece most teams are missing. A SIEM with all the right sources connected and a clean dashboard is table stakes. What auditors probe is whether anyone reviews the output — and whether that review is documented.
"Documented review" doesn't mean a formal report every time, but it does mean something traceable. Some options that work: a weekly ticket in your issue tracker that someone closes after looking at the log summary; a shared doc with running notes and sign-offs from the responsible person; a recurring SIEM report emailed to an owner who marks it reviewed. The exact format is less important than the fact that a paper trail exists and covers the audit period consistently.
The way to think about the requirement: your auditor will ask for review records alongside the logs themselves. If your log review is a senior engineer who glances at CloudWatch when he remembers to, that's not auditable. If it's a formal task assigned to a named owner on a defined cadence, with a running record, that's what passes.
Practical steps: define the owner in your policy, set a formal cadence (weekly for alert-driven review, monthly or quarterly for broader pattern review), and make the evidence artifact a natural output of the process rather than something you reconstruct before the audit.
Alerting handles the gaps between reviews
A weekly review process won't catch an active credential stuffing attempt in real time. Alerting does. The two mechanisms serve different purposes — alerting is your immediate-response layer, structured review is how you catch the slow-burn and the subtle.
For alerting, the conditions I make sure are covered in every environment:
- Failed authentication above a threshold, per system or per account
- Login from an IP or geography outside normal patterns
- Privilege escalation or creation of admin accounts
- Cloud IAM policy changes
- Configuration changes outside a change management window
- Service health failures without a corresponding approved change
The thing alerts need to be useful is a response process. An alert that fires into a Slack channel nobody monitors isn't a control — it's noise that trains people to ignore signals. Each alert type should route to someone with a defined responsibility, trigger an investigation, and close with a documented outcome. That documentation — even a one-line ticket note — is what makes alerting auditable.
How alerts connect to your broader response workflow is something I covered in the incident response plan guide. The logging evidence and the IR process pull from the same record.
What the auditor actually asks for
When I prepare clients for a monitoring audit request, here's the documentation package I build:
- The log retention policy, with a current date, version, and named owner
- A list of active log sources feeding the central system, with the date each was connected
- Sample SIEM dashboards or saved searches showing event types being collected
- Review records covering the audit period — tickets, notes, sign-offs — not just the weeks before fieldwork started
- Alert configuration showing what conditions trigger notifications
- A sample of closed investigations from alerts that fired during the period
That last item is the one that surprises people. They expect auditors to count alerts. Auditors want to see that someone investigated and documented the outcome. Two well-documented investigations carry more weight than 50 closed tickets with no notes.
Three gaps that show up constantly
After watching enough of these audits, failures cluster in the same places.
The undocumented process. Logging is on, someone does review it, but there's no written procedure and no named owner. It exists as institutional knowledge. The fix is straightforward: write it down, assign it formally, and run it for at least one full quarter before your audit window opens. Auditors need to see the cadence applied over time, not just set up right before they arrive.
Alert fatigue with no triage record. The alert threshold is too sensitive, everything fires, and the team learns to ignore it. When the auditor asks about a specific alert from 10 weeks ago, there's no investigation record. Tune the thresholds to a level where alerts are actionable, and document every disposition — even when the investigation closes as a false positive. Especially when it closes as a false positive.
Retention policy drift. The policy says one year, the SIEM says 30 days, the cold storage bucket was deleted six months ago. Check your actual configuration against your documented policy on a regular schedule and every time your logging stack changes.
The access reviews guide covers the access-control side of this — how to close the loop between who holds privileges and what your logs are showing you about how they use them. The two controls audit better together than either does alone.