ISO 27001 Logging: Control A.8.15 Design and Audit Evidence

ISO/IEC 27001 logging is not satisfied by proving that systems produce files called logs. Annex A control 8.15 becomes useful when recorded events can support security monitoring, investigation and accountability, and when the organisation can show that the arrangement works across the systems that matter.

Good control design begins with risk and investigation needs. It then defines which events to record, how records are protected, how long they remain usable, who reviews them and what happens when the logging service fails.

Place A.8.15 in its control context

Control A.8.15 addresses the production, storage, protection and analysis of logs concerning events and relevant activities. It interacts closely with monitoring activities under A.8.16 and clock synchronisation under A.8.17. Identity, privileged access, network security, incident management, privacy and legal requirements also shape the design.

ISO/IEC 27001 does not prescribe a particular logging platform, retention period or list of events for every organisation. Those choices should follow risk, obligations, system capability and operational need. The Annex A control lookup helps teams examine A.8.15 alongside its supporting controls.

Define the purpose before collecting data

Collecting every available event can increase cost and noise without improving detection. Start with the questions the records must answer:

• Who or what performed an action?
• Which resource, account or record was affected?
• What occurred and what was the result?
• When did it occur in a consistent time reference?
• Where did the request originate and where was it processed?
• Which correlation, request or transaction identifier connects related activity?
• Can investigators distinguish an attempted action from a successful one?

Map these questions to risk scenarios and response procedures. For example, a privileged-account misuse scenario may require authentication events, role changes, administrative commands and access to sensitive data. A service-availability scenario may need capacity, health, deployment and network events.

The incident management evidence guide explains how logs fit into triage, investigation, response and learning.

Build a risk-based logging specification

For each important system or service, document the expected event sources and handling requirements. A practical specification can record:

Decision	What to define	Evidence of operation
Event coverage	Required security, administrative and business-relevant events	Enabled source settings and sampled records
Content	Required fields and prohibited sensitive content	Event schema and redacted sample
Transport	How records reach their destination and handle interruption	Agent or service configuration and delivery health
Protection	Access, integrity and deletion restrictions	Roles, storage policy and change history
Retention	Online and archive periods, disposal and legal hold	Lifecycle rule and dated retained sample
Review	Automated detections, manual reviews and frequency	Alert rules, review records and assigned tickets
Resilience	Capacity, backlog, failure and recovery behaviour	Health alert, failover or recovery test

The specification may be central or system-specific. What matters is that owners can explain why the selected events and periods are sufficient for the relevant risks.

Select events that support decisions

Commonly useful events include successful and failed authentication, account and privilege changes, administrative activity, security-policy changes, access to sensitive resources, software deployment, configuration change, security-tool alerts and significant service failures.

The exact population depends on the system. A customer platform may require transaction and consent events. A cloud control plane may require identity, resource and policy changes. A database may need privileged queries and changes to audit configuration.

Record enough context to investigate without placing secrets, authentication material or unnecessary personal information in the log. If sensitive values are needed, limit fields and access based on a documented purpose. Logging itself creates information that needs classification, protection and disposal.

Protect integrity and restrict access

An attacker or administrator under investigation should not be able to alter the evidence without detection. Separate log administration from routine system administration where risk justifies it. Forward important records to controlled storage, restrict deletion, monitor changes to logging configuration and use integrity features appropriate to the platform.

Access to logs should follow need. Security analysts may require broad search access, while developers may need only records for their services with sensitive fields masked. Review privileged access and emergency access to the logging platform.

The access-control governance guide provides a model for connecting access decisions, technical enforcement and review evidence.

Make time trustworthy

Events cannot be correlated reliably when system clocks disagree. Define approved time sources, expected synchronisation, timezone handling and monitoring of drift or synchronisation failure. Record timestamps in a consistent form and preserve the context needed to interpret legacy or local-time records.

Clock synchronisation does not make an event true; it makes timelines more dependable. Investigators should still consider buffering, delayed delivery, device limitations and application-generated timestamps.

Test time quality by comparing related events from several sources. A login, application request, database action and alert should form a plausible sequence. Large or unexplained gaps indicate an evidence problem even when each system reports itself as synchronised.

Set retention from use and obligation

There is no universal ISO 27001 retention duration for logs. Decide periods using investigation windows, threat-detection needs, customer and regulatory obligations, storage cost, system capability and privacy principles.

Avoid treating retention as one number. High-volume diagnostic data, privileged-access records and business transaction evidence can justify different periods. Define what remains searchable, what moves to archive, who can place a legal hold and how records are securely disposed of when the approved period ends.

Verify actual behaviour. A policy saying twelve months is weak evidence if a storage rule deletes records after thirty days or if older archives cannot be searched within incident-response needs.

Turn records into monitoring and action

Logs provide value when review can identify something requiring a decision. Define detections from risk scenarios and known misuse paths. Establish owners, severity, routing, response targets and escalation. Tune noisy rules through controlled changes rather than disabling them informally.

Manual reviews can be appropriate for low-volume systems, but the review should have a defined scope and evidence of completion. A signed statement saying “logs reviewed” does not show which period, sources or anomalies were considered. Preserve queries, reviewed reports, decisions and resulting tickets.

The firewall governance guide shows how configuration, change, traffic and review evidence can be combined for a network control.

Cover cloud and supplier boundaries

For hosted platforms and software services, identify which logs the provider creates, which the customer must enable, how records are exported and what happens when the contract ends. Confirm that the selected service tier exposes the fields and retention required by the risk decision.

Supplier assurance should not stop at receiving a general security report. Test that the organisation can obtain relevant records promptly, correlate them with internal events and preserve them during an investigation. Assign responsibility for changes to provider logging features and interfaces.

Test configuration and operating evidence

Control testing should combine inspection, sampling and a safe functional test.

1. Select systems using risk, technology and ownership, including a cloud service and a privileged platform where relevant.
2. Compare required event sources with enabled configuration.
3. Generate or identify a known event and trace it through collection, storage, detection and retention.
4. Inspect access restrictions and changes to logging settings.
5. Sample alerts or reviews and follow them to triage, closure or escalation.
6. Examine health monitoring, capacity and the response to an interrupted source.

Do not rely only on screenshots. Exported configuration, system queries, immutable change records and timestamped samples generally provide stronger evidence.

Useful audit questions include:

• Which risk scenarios determined the selected events?
• How are missing sources, delayed delivery and storage pressure detected?
• Can administrators erase or suppress records without independent visibility?
• How was the retention rule verified against actual data?
• Who owns an alert after it fires, and how is closure challenged?
• Are time sources monitored, and has cross-source correlation been tested?

Rate the result consistently

A pass is supported when risk-based requirements exist, sampled systems produce complete and protected records, time and retention operate as intended, and review leads to traceable action.

A partial result may be appropriate when central logging exists but a material source is missing, retention differs from the approved decision, alert ownership is unclear or evidence of review is inconsistent.

A fail is likely when important systems lack security events, administrators can alter evidence without oversight, collection failures are invisible, or nobody acts on the records.

Use the ISO 27001 readiness checker to connect logging gaps with incident response, access management, supplier assurance and improvement.

Maintain the control as systems change

New services, architecture changes and provider migrations can silently remove visibility. Add logging acceptance criteria to onboarding and change processes. Reassess event coverage after incidents and exercises, and test the control after changes to agents, pipelines, storage or alert logic.

The official ISO/IEC 27002 overview identifies the standard as guidance on information-security controls. NIST SP 800-92 provides complementary guidance on establishing log-management infrastructure and processes; apply it according to organisational context rather than treating it as an ISO requirement.

A mature logging control makes claims testable. It shows not only that events exist, but that the right records remain trustworthy and usable when the organisation must detect, explain and respond to security activity.