ISO 27001 A.8.15 Logging: Which Logs Do You Actually Need to Keep?
A.8.15 asks you to produce, protect and analyse logs of relevant events. Decide which sources and events matter for your risks, and how long and how well each tier is kept.
/Autenix/10 min read
An administrator account signs in at 3 a.m. and changes a permission on a production database. Two weeks later someone asks what happened, and the answer depends on whether the relevant log still exists, whether anyone could have edited it, and whether you can find it. Any one of those three can fail.
A log you cannot find or cannot trust is an opinion, not evidence.
What A.8.15 asks for
A.8.15 is an Annex A control. You select it through risk treatment and record the decision in your Statement of Applicability (SoA).
Its intent is that logs recording activities, exceptions, faults and other relevant events are produced, stored, protected and analysed. ISO/IEC 27002 gives recommended guidance on what to capture (who, what, when, where), on protecting logs from tampering, and on handling personal data that logs may contain. Specific retention periods and event lists are your risk-based decisions, not ISO prescriptions.
Boundary: A.8.15 covers producing, storing, protecting and analysing the log record. A.8.16 (Monitoring activities) covers watching systems for anomalous behavior and deciding to act on it.
Depends on: A.8.17 (Clock synchronization), because logs from different systems can only be correlated if their timestamps agree.
Decide your scope for A.8.15 logging
The question is not "should we log?" but "which sources, which events, and at what depth?" Scope follows your risk assessment and environment.
| Profile | What is in scope | How the log source register changes | When to review scope |
|---|---|---|---|
| Cloud-native SaaS, single cloud provider | Identity provider, cloud control-plane audit log, production database access, application authentication and authorization events | Short register; most sources are managed services, so the protection column focuses on log-store permissions | New cloud account, new data store holding customer data, or new identity provider |
| Hybrid: cloud plus on-premises servers and network devices | All of the above, plus directory services, firewalls/VPN, servers, and privileged-access tooling | Longer register; owners differ by site, so the owner and reviewed-by columns matter most | Network redesign, acquisition, or a new site |
| Environment that processes data for customers or handles regulated data | All of the above, plus customer-data access trails and administrative actions by support staff | Adds a column for personal data handling, and tiers are stricter for sources touching customer data | New customer commitments, new regulation, or a change in what the product stores |
What to exclude, minimize, or deprioritize
- Minimize: debug-level application logs in production. They are voluminous and can contain secrets or personal data. Enable them temporarily and with justification rather than permanently.
- Minimize payloads: full request and response bodies. Log identifiers and outcomes instead of payloads when the payload carries personal data.
- Deprioritize: high-volume, low-risk events (for example, successful health checks), where excluding them is documented in the register and the risk assessment supports it.
- Do not exclude authentication, authorization changes, privileged actions, and access to your most sensitive data on in-scope systems. If you exclude a system entirely, record the risk-based justification in your risk treatment and SoA decisions.
What good looks like
A. A copyable artifact: the log source register
Adapt this to your environment. All values are illustrative.
| Log source | Tier | Owner | Events recorded | Protection | Retention (illustrative) | Reviewed by / how |
|---|---|---|---|---|---|---|
| Identity provider | 1 (critical) | IT lead | Sign-ins, failures, MFA changes, role and group changes | Write-restricted log store; log admins separate from IdP admins | 12 months | Security lead; weekly review of privileged events |
| Cloud control-plane audit log | 1 | Platform lead | Administrative API calls, policy changes, key use | Forwarded to a separate account or store | 12 months | Platform lead; alert-driven plus monthly sample |
| Customer-data database | 1 | Engineering lead | Privileged access, schema and permission changes, bulk exports | Exported off-host; access to logs restricted | 12 months | Security lead; monthly sample |
| Production application | 2 (routine) | Service owner | Authentication, authorization failures, errors | Central store, role-based access | 90 days | Service owner; on incident or alert |
| Corporate endpoints | 2 | IT lead | Security tool events, admin elevation | Central store | 90 days | IT lead; on alert |
| Network edge / VPN | 2 | IT lead | Connection events, denied traffic | Central store | 90 days | IT lead; on alert |
A document alone does not prove implementation. The register becomes evidence only when configuration exports and review records back every row.
B. Bad vs. good
| Weak | Effective |
|---|---|
| "All systems log everything and keep it for a year." | Tier 1 sources log privileged and security events and are kept longer and protected more strongly. Tier 2 sources are kept for a shorter, justified period. |
| No owner. Logs sit in each system's local storage. | Each source has a named owner, a central destination, and a documented reviewer. |
| Nobody can say what is missing. | The register names every in-scope source, and exclusions are recorded with a reason. |
The weak version feels thorough but cannot be defended: it is unaffordable to sustain, impossible to verify, and unreviewed. The effective version is narrower and provable.
C. Measures and evidence
| Measure | Why it matters | What sufficient looks like (illustrative) | Evidence that proves it |
|---|---|---|---|
| Source coverage | Missing sources mean missing events | Tier 1 sources in the register forward to the central store, and gaps are recorded as owned exceptions; Tier 2 coverage is documented | Log source register; log configuration export |
| Event content | Logs without who/what/when/where cannot support an investigation | Tier 1 logs let you reconstruct actor, action, target, time and outcome; Tier 2 meets a lower bar justified by risk | Log configuration export; test event trace |
| Protection from alteration | Evidence is worthless if it can be edited | Write access to Tier 1 logs is restricted and separate from the systems being logged; authorized exceptions are approved and recorded | Log configuration export; log access review record |
| Retention | Investigations need history | Retention per tier is set by risk, legal and contractual needs, and the oldest record matches the register | Log source register; log configuration export |
| Review and analysis | Unread logs do not protect anything | Tier 1 has a defined review or alert path with a named owner; Tier 2 is reviewed when triggered | Log review record |
| Time consistency | Cross-system correlation depends on it | Timestamps from Tier 1 sources can be correlated (see A.8.17 for how the clocks are controlled) | Test event trace |
The example values are starting points, not requirements specified by ISO.
Design evidence vs. operational evidence: the log source register and any logging standard are design evidence. The log configuration export, log access review record, log review record, and test event trace are operational evidence. Auditors and your own leadership will want both.
D. How to validate it yourself
- Coverage check. Pick one Tier 1 source from the register and perform a harmless privileged action, such as a test role change. Search the central store for it. Success: the event appears with actor, action, target and time. Record: test event trace. This confirms coverage for that source, not for all sources.
- Protection check. Review who can modify or delete a Tier 1 log store compared with who administers the logged system. Success: write and delete rights are restricted, and any exceptions are approved and accountable. Record: log access review record. This shows the design; it does not show whether tampering has occurred.
- Retention check. Locate the oldest available record for a Tier 1 source. Success: it matches the retention in the register. Record: log configuration export.
- Review check. Take one log review record and trace an observation to a decision or a closed ticket. Success: an owner reviewed it and acted or documented why not. Record: log review record.
These checks show a sample works, not that the whole program is effective. Independent review or additional expertise adds value when you cannot easily judge your own blind spots, when an audit is approaching, or when your environment changes significantly.
Common A.8.15 implementation mistakes
- Logs everywhere, ownership nowhere. Your central log platform ingests everything, but nobody owns the alerts. Why it matters: events accumulate unread, so the control is operating on paper only. Fix: give each Tier 1 source in the register a named owner and a defined review path.
- Logs stored where the attacker can reach them. The logs live on the same host, or under the same admin credentials, as the system being logged. Why it matters: whoever compromises the system can alter its logs. Fix: forward Tier 1 logs to a separate store with restricted write and delete rights.
- Verbose logging that captures secrets or personal data. Debug logging is left on in production and tokens or personal data end up in log lines. Why it matters: the log store becomes a sensitive data store that needs its own protection and may raise privacy obligations. Fix: disable debug logging in production by default, log identifiers rather than payloads, and review log content periodically.
- A policy that says "log everything" and nothing proves it. The policy exists, but you cannot show a configuration export or a review record. Why it matters: a document without operational evidence does not demonstrate implementation. Fix: pair each register row with its configuration export and, for Tier 1, a review record.
If you would like help keeping the register, policies and supporting evidence current across your whole ISO 27001 scope, see how Autenix's managed compliance service works.
If you have one afternoon
- Draft the log source register with your Tier 1 sources only, and fill in owner, events and retention. Produces: a first log source register.
- Run the coverage and protection checks on one Tier 1 source (the first two checks above). Produces: a test event trace and a log access review record.
- Pick one Tier 1 source and fix its most obvious gap from the mistakes above, such as moving logs to a separate store or assigning a reviewer. Produces: an updated log configuration export.
An afternoon will not complete the control, but it gives you a defensible starting point and the evidence to build on.
How Autenix helps
Platform: Autenix Compliance
Autenix Compliance is a continuous-compliance platform. It supports ISO 27001 among 35+ frameworks. These capabilities map to the artifacts in this article:
- Automated evidence collection. The platform connects to AWS, Azure, GCP, Kubernetes, M365, GitHub and other tools without agents, and collects evidence from them. This can reduce the manual effort of refreshing operational evidence, such as configuration exports. Which log settings it captures depends on what you connect, so map each row of your log source register to a connected source before relying on it.
- Control-drift alerts. Real-time alerts tell you when a monitored control moves away from its expected state. They are useful once you have decided which settings your register depends on.
- Audit Readiness module. It provides an audit trail and version history, and lets you share evidence with auditors. That suits the register and your review records, which need to stay versioned and retrievable.
- Policy Generator. Customizable policy templates with version control and change tracking can host your logging policy excerpt, the design-evidence side of the register.
None of this replaces the logging and monitoring tooling that produces, stores and protects your logs, and it does not make the control effective on its own. You still own the scope, tier and retention decisions, the log review, and the validation checks.
Service: Compliance as a Service
Autenix delivers the platform as a managed service, with setup and training included. It starts with a Discover step that maps your current systems, frameworks and gaps, followed by platform setup (identities, policies, integrations, frameworks), then continuous running. This is optional help with the unresolved work of working out which sources belong in scope, wiring evidence in, and keeping it current. You still run the checks, decide risk acceptance, and review the logs. The service runs on the platform, so the two are one offering at different levels of hands-on help.
Take the checklist into a demo
If you completed the afternoon plan, you have a draft register, one tested source and one fixed gap. Bring them to a demo to see where Autenix Compliance's evidence collection and audit-readiness features would sit alongside the rest of your ISO 27001 controls.