Why log management is audit-critical
Log management is one of the most heavily tested compliance areas at SOC 2 and ISO 27001 audits — and one where SaaS companies routinely fall short. SOC 2 CC7.2 is sampled in every Type II report. ISO 27001 A.8.15 (Logging) is always inspected. If your logs are inconsistent, missing, or stored where the application team can edit them, you fail.
Beyond compliance, logs are the foundation of incident detection. Without comprehensive logging, you cannot detect breaches in progress, cannot investigate after the fact, and cannot produce the audit trail regulators expect. The Verizon DBIR consistently shows that organisations with comprehensive logging detect breaches in days; those without detect them in months — if at all.
What SOC 2 CC7.2 requires
SOC 2 Common Criteria CC7.2 (System Monitoring) requires the entity to:
- Monitor system components and the operation of those components for anomalies indicative of malicious acts, natural disasters, and errors
- Configure detection policies and procedures that identify the source and circumstances of an anomaly
- Implement procedures to analyse the impact of identified anomalies
- Communicate detected anomalies to appropriate personnel for follow-up
CC7.2 is closely linked to CC7.1 (Threat & Vulnerability Management). The control narrative auditors expect to see covers: what is logged, how alerts are configured, who reviews them, escalation to incident response, and evidence that this happens consistently — not just on audit days.
ISO 27001 A.8.15, A.8.16, A.8.17 breakdown
ISO 27001:2022 splits logging across three Annex A controls:
| Control | Requirement | Audit Focus |
|---|---|---|
| A.8.15 Logging | Logs of user activities, exceptions, faults, and information security events shall be produced, kept, and regularly reviewed | Log source inventory; sample log review records |
| A.8.16 Monitoring activities | Networks, systems, and applications shall be monitored for anomalous behaviour and appropriate actions taken | SIEM rules; alert response; incident integration |
| A.8.17 Clock synchronisation | Clocks of all relevant information processing systems shall be synchronised to approved reference time sources | NTP configuration on all systems; drift monitoring |
What must be logged per A.8.15:
- User activities (logins, logouts, privileged actions)
- Exceptions (authentication failures, access denials)
- Faults (system errors, crashes)
- Information security events (alerts, IDS detections, malware findings)
- Use of administrative privileges
- System changes (config, software installs, user/role changes)
A.8.17 (Clock Sync) is silently failed often. Auditors will sample logs from 2–3 systems and check that timestamps align within seconds. If your application server says 14:23:01 UTC and your firewall says 14:25:47 UTC for the same event, you cannot correlate. Run NTP on every system, monitor drift, and document the reference source.
Log retention by regulation
| Framework | Minimum Retention | Specific Requirement |
|---|---|---|
| SOC 2 | No explicit period; align with policy commitments | 12 months is standard practice and supports Type II reporting periods |
| ISO 27001 A.8.15 | Determined by risk assessment; "appropriate" retention | Most certified orgs use 12 months; longer for security events |
| HIPAA §164.312(b) + §164.316(b)(2) | 6 years for documentation of audit controls | Logs themselves: organisation-defined but must support §164.312(b) audit purpose |
| PCI DSS Req 10.5.1 | 12 months total; 3 months immediately accessible | Applies to CDE logs specifically |
| GDPR Art. 32 | Proportionate to security purpose; not excessive | Logs containing personal data should be minimised and time-limited |
| NIS2 Art. 21 | Implementation defined by national authority | Generally aligned with ISO 27001 expectations |
| FedRAMP / NIST SP 800-92 | 1 year online, 3 years archival (moderate baseline) | AU-11 control specifies retention |
Pragmatic default for SaaS: 12 months hot/queryable, archive beyond that. Adjust upward for HIPAA (ePHI access logs) and downward for low-risk operational logs that don't carry compliance weight.
8 mandatory log sources for SaaS
At a minimum, your SIEM must ingest:
- Authentication & access logs — SSO/IdP (Okta, Auth0, Google), MFA events, admin console logins. Capture: user, IP, MFA result, geolocation, success/failure, user agent.
- Cloud infrastructure — AWS CloudTrail / GCP Audit Logs / Azure Activity Logs. Capture every IAM, configuration, and resource change.
- Database access — query type, user, table, row counts, schema changes. Privileged queries flagged.
- Admin/privileged actions — sudo, role changes, account creation/deletion, permission grants.
- Network logs — VPC flow logs, WAF rule matches, firewall denies, load balancer access logs.
- CI/CD pipeline — pipeline runs, deployment events, secret access, merges.
- Application/API — request metadata, errors (sanitised), API key usage, response codes.
- Third-party integrations — OAuth grants, webhook events, SaaS admin actions (e.g. Slack/GitHub admin events).
If a log source isn't in your SIEM, you cannot alert on it. Audit gap.
SIEM alerting threshold guidance
| Event | Threshold | Severity | Why It Matters |
|---|---|---|---|
| Failed logins (brute force) | 10 fails / 5 min / user; 50 fails/min system-wide | High | Account compromise attempt |
| Privilege escalation | Any sudo/role-assume to admin outside change window | Critical | Unauthorised admin access |
| New privileged user created | Any new admin/root user | Critical | Persistent backdoor; common post-compromise step |
| Admin activity off-hours | Admin console 22:00–06:00 or weekend | High | Likely compromised account if not pre-approved |
| Unusual data export | >3x baseline OR >10K records single query (non-batch) | High | Exfiltration in progress |
| Firewall / security group change | Any change outside change window | High | Attacker opening egress / lateral movement path |
| Outbound data transfer anomaly | >5x baseline to non-approved destinations | Critical | Active exfiltration |
| Logging config change | Any modification to log forwarding / retention / SIEM rules | Critical | Attacker covering tracks |
Tune ruthlessly. Alerts no one looks at are worse than no alerts — they create alert fatigue and miss the real signal.
Log integrity controls
Logs are only useful if you can trust them. Required controls:
- Immutable / append-only storage — S3 Object Lock, Azure immutable blob, or WORM storage. An attacker with admin on the app should not be able to delete log evidence.
- Separation of log access from application access — the team that operates the app does not have delete rights on the log archive. Security team or audit role owns log retention.
- Clock synchronisation — NTP from authoritative source on every system; max drift <1 second; drift monitored and alerted.
- Tampering detection — alerts on log gap (no events received from a critical source for X minutes), on logging config changes, on storage policy modifications.
- Separate environment — ship logs to a separate AWS account / GCP project / Azure subscription from the production environment. Compromise of production should not destroy the audit trail.
PCI DSS Req 10 specifics
If you process cardholder data, PCI DSS Req 10 has hard rules:
- 10.2: Log all access to the cardholder data environment (CDE) including individual user access, root/admin actions, audit log access, invalid logical access attempts, identification & authentication changes.
- 10.5.1: Retain audit log history for at least 12 months, with at least the last 3 months immediately available for analysis.
- 10.4: Real-time review of CDE logs; daily review of security event logs.
- 10.3: Secure audit logs to prevent unauthorised modifications.
The 3-months-immediately-accessible requirement trips up many founders who push everything to cold storage to save money. Keep at least 3 months hot.
HIPAA §164.312(b) audit controls
HIPAA Security Rule §164.312(b) requires "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."
Practically that means: every system handling ePHI must produce logs of who accessed what, when, and how. You must "examine" — not just collect — these logs. Combined with §164.316(b)(2), the documentation of those audit activities must be retained for 6 years.
For SaaS dealing with covered entities, the BAA you sign typically obligates you to provide log evidence on request, including for breach investigation.
Audit evidence auditors ask for
| Auditor Ask | Evidence Format | Where to Find It |
|---|---|---|
| Log source inventory | Spreadsheet / SIEM source list | Security team documentation |
| Sample logs from N production systems | Raw log export covering a sample date range | SIEM / log storage |
| Evidence of log review | Reviewer-signed dashboard screenshot OR ticket history | SIEM dashboards; ticketing system |
| Alert response sample | Alert with linked IR ticket showing triage to resolution | SIEM + ticketing |
| Retention policy enforcement | Lifecycle policy config + sample old log proving deletion | Cloud storage console |
| NTP / clock sync evidence | System time config export from N hosts | Configuration management |
| Logging change control | PR / change ticket for last logging config change | Git / change management |
5 common log management failures
- No SIEM — logs live in 10 different places. Auditors expect centralised review. CloudWatch + Splunk + Datadog + raw S3 files isn't a monitoring programme.
- Logs deleted before retention period. Lifecycle policy too aggressive; or app team has delete rights and used them.
- Clock drift across systems. Some hosts running on default OS clock, not NTP. Correlation broken; audit evidence questionable.
- No alerting on privileged access. Admin actions logged but not alerted. Breach goes undetected for months.
- App team has full access to its own logs. No segregation; tampering possible. SOC 2 CC6.1 failure.
Minimum viable log management programme
- ☐ Centralised SIEM or log management platform receiving all 8 mandatory sources
- ☐ NTP configured on all systems; drift monitored
- ☐ 12-month minimum retention with immutable storage
- ☐ At least 8 alerts configured (see threshold table above)
- ☐ SIEM integrated with incident response platform (auto-ticket or pager)
- ☐ Weekly log review documented (or continuous SOC monitoring)
- ☐ Separate log storage from production environment (different account/project)
- ☐ Documented log management policy reviewed annually
Related generators
Get started: Log Management & Monitoring Policy Generator, Information Security Policy, Incident Response Plan, Vulnerability Management Policy, Secure SDLC Policy, SOC 2 Gap Assessment, SOC 2 Evidence Pack.
Related reading: SOC 2 Evidence Collection Guide, Penetration Testing Guide, Secure SDLC Policy Guide.
⚠️ This guide is for informational purposes only and does not constitute legal or security advice. Specific log retention and monitoring requirements vary by framework, jurisdiction, and audit scope. Consult a qualified security professional for implementation tailored to your environment.