Logs are the evidence behind most other security controls. Access removal is proven by the identity provider's audit log. Privileged activity is proven by the cloud control plane log. An incident timeline is built from logs. When logging is incomplete, every control that depends on it becomes harder to prove.
Most teams have plenty of logs. What they often lack is the version a framework asks for: the right sources collected in one place, with enough detail in each event, kept for a defined period, protected from alteration, and stamped with consistent time.
This article covers what the frameworks require, which sources to collect, what each event needs, how long to keep it, how to protect it, and what an auditor will test. Turning logs into alerts is a separate control, covered in a later article on monitoring.
What the frameworks require
ISO 27001:2022 Annex A 8.15 requires logs recording activities, exceptions, faults, and other relevant events to be produced, stored, protected, and analyzed. Annex A 8.17 requires clocks to be synchronized to approved time sources.
SOC 2 CC7.2 covers monitoring system components for anomalies, which presumes the logs exist. Logging also supports CC6 (access) and CC8 (change) evidence.
PCI DSS v4.0 Requirement 10 is the most detailed. It specifies events to log, the content of each record, protection of logs, daily review, time synchronization, and retention.
The HIPAA Security Rule requires audit controls at 45 CFR 164.312(b): mechanisms that record and examine activity in systems containing ePHI. HIPAA technical safeguards for SaaS teams puts audit controls alongside the other technical safeguards.
NIST SP 800-53 Rev. 5 has the AU family, including AU-2 (event logging), AU-3 (content), AU-8 (time stamps), AU-9 (protection), and AU-11 (retention).
If you have card data in scope, design to PCI DSS Requirement 10 and the other frameworks are largely covered. Our PCI DSS overview covers the standard as a whole.
Which sources to collect
Collect from every system in scope where an event could show unauthorized access, a change to security settings, or access to sensitive data. In practice that means:
The identity provider. Sign-ins, failed sign-ins, MFA events, user and group changes, admin actions, policy changes.
Cloud control planes. Every API call that creates, modifies, or deletes resources or permissions, across every account and region in use.
Your production application. Authentication events, authorization failures, administrative actions, and access to sensitive records.
Databases. Administrative actions and, for sensitive tables, access by humans rather than the application.
Source control and CI/CD. Changes to repository settings, protection rules, secrets, and deployment pipelines.
Security tooling. Endpoint, malware protection, and vulnerability scanners.
Network edge. Load balancers, web application firewalls, VPN, DNS where relevant.
SaaS admin logs for tools holding customer data.
Start with the first two. They cover the most privileged activity, and they are what an auditor will ask about first. Privileged activity in particular is covered in managing privileged access.
What each event needs to contain
An event that cannot answer "who did what, to what, when, from where, and did it work" is of limited use in an investigation or an audit. PCI DSS Requirement 10.2.2 lists the elements explicitly: user identification, type of event, date and time, success or failure, origination, and the identity or name of the affected data, system component, resource, or service. NIST AU-3 asks for much the same.
Check this for your application logs in particular. Infrastructure logs from cloud providers usually carry these fields. Application logs written by your own code often record that something happened without recording who did it.
Logs also hold data you may not want there. User identifiers, IP addresses, and sometimes request bodies are personal data under GDPR. Do not log secrets, tokens, or full payment card numbers, and decide deliberately what personal data your logs need.
How long to keep logs
Retention is where frameworks differ most.
PCI DSS Requirement 10.5.1: at least 12 months, with at least the most recent three months immediately available for analysis.
SOC 2: no fixed period, but logs need to cover the observation period so the auditor can test against them. Keeping them for at least the length of the period plus the time to complete the audit is a practical floor.
ISO 27001: no fixed period; set one in your logging policy based on risk and legal requirements.
HIPAA: 45 CFR 164.316(b)(2) requires required documentation to be kept for six years. Whether that extends to specific system logs is something organizations interpret differently, so decide your position, write it down, and confirm it with counsel.
Tiered storage keeps cost manageable. Recent logs sit in a searchable system. Older logs move to cheaper archive storage, still retrievable when needed. Whatever the tiers, set retention in configuration rather than relying on manual deletion, and keep the configuration as evidence.
Protecting logs from alteration
A log that the people it records can edit is weak evidence. Annex A 8.15, PCI DSS Requirement 10.3, and NIST AU-9 all require logs to be protected.
The practical measures:
Ship logs out of the source system to a store in a separate account or project, so administrators of production cannot alter the copy.
Use write-once or object-lock storage for the archive tier where your platform supports it.
Restrict access to the log store to a small group, and log access to the logs themselves.
Alert when logging stops. Disabling a cloud audit trail or a log forwarder is a known attacker technique, and something an auditor will ask about.
Consistent time
Correlating events across systems needs every system to agree on the time. Use a consistent time source across your infrastructure, which managed cloud services usually provide, and record timestamps in UTC with the offset explicit. ISO 27001 Annex A 8.17 and PCI DSS Requirement 10.6 both require synchronized clocks. On managed infrastructure, the evidence is usually the provider's documentation plus your configuration of anything self-hosted.
What an auditor will test
Expect a request along the lines of "show me how security-relevant events are logged and protected." A complete answer includes:
- Not done:
Your logging policy, with sources, retention, and protection
- Not done:
Configuration showing logging enabled for each in-scope source
- Not done:
A sample event from each source, showing the required fields
- Not done:
Retention settings on the log store
- Not done:
Access permissions on the log store
- Not done:
The alert that fires if logging is disabled, and a test of it
The auditor may also pick an event they can see elsewhere, such as a leaver's access removal, and ask you to find it in the logs. If you can, it shows the pipeline works from source to store. If you cannot, it shows the logs exist only on paper.
How TrustLynce helps
TrustLynce continuous monitoring runs control checks against the cloud and identity systems you connect and routes failures to their owners. Evidence collection gathers configuration evidence from those systems on a schedule, timestamped and attributed, so logging settings are captured across the period.