ISO 27001 A.8.15 - Logging

Requirement

“Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed.”

Plain-language meaning

The organization should collect useful logs, protect them from tampering, keep them long enough, and review or analyse them so security-relevant events can be detected and investigated.

Logging is not useful if nobody reviews it, if privileged administrators can edit it, if storage overwrites it silently, or if logs lack enough detail to identify what happened, when, where, and who was involved.

Why this matters

Logs support incident detection, investigation, accountability, fault analysis, corrective action, and evidence. They help reconstruct events before and during an incident.

Modern systems generate too much data for manual review alone. Automated tooling such as SIEM, alerting, correlation rules, and dashboards may be needed to identify meaningful events from noisy logs.

Implementation guidance

1. Define loggable events

Logging should cover risk-relevant activities such as:

• privileged user activity;
• failed logins and access attempts;
• configuration changes;
• use of system utilities;
• security tool alerts;
• faults and exceptions;
• data access or transfer events where needed;
• changes to logging configuration;
• administrative actions in cloud or managed services.

2. Define minimum log content

Useful logs should normally identify:

3. Protect logs

Logs should be protected against unauthorized editing, deletion, redirection, logging shutdown, event-level modification, and silent overwrite. A strong pattern is to send logs quickly to a location outside the control of administrators of the source system.

4. Analyse logs

Log analysis should be risk-based. High-risk systems and privileged activity may require frequent review, automated correlation, and alerting. Lower-risk logs may be reviewed less frequently.

5. Link alerts to incident and corrective action

Alert review should determine whether security has been compromised. If yes, the event should feed incident management. Fault trends should feed corrective action and root cause analysis.

Audit guidance

Auditors should verify:

• logging policy or standard;
• loggable event definitions;
• log content and timestamp quality;
• retention requirements;
• protection against tampering and deletion;
• privileged user log coverage;
• SIEM or log analysis tooling coverage;
• alert rules linked to risk assessment;
• log review frequency and ownership;
• separation of duties in log review;
• sample alerts and corrective actions;
• supplier/cloud logging levels where managed services are used.

Auditors should sample logs and check whether they include sufficient detail to support investigation.

Evidence examples

Strong evidence

• Logs include user, event, date/time, source, and action detail.
• Privileged activity is logged and independently reviewed.
• Logs are sent to protected central storage.
• Logging changes/deletions require authorization and records.
• Alerts are reviewed and escalated to incident management where needed.
• Fault trends produce corrective action.

Weak evidence

• Logs exist but are never reviewed.
• Logs are stored only on the system being monitored.
• Administrators can delete or edit their own activity logs.
• Retention is too short for investigation needs.
• SIEM rules are generic and not linked to risk.
• Alerts are ignored due to volume.

Common failures

Exam traps

Related controls and concepts

• A.8 Technological Controls MOC
• A.8.2 Privileged Access Rights
• A.8.3 Information Access Restriction
• A.8.9 Configuration Management
• A.5.25 Assessment and Decision on Information Security Events
• A.5.26 Response to Information Security Incidents
• A.5.27 Learning from Information Security Incidents
• A.5.28 Collection of Evidence
• A.5.36 Compliance with Policies, Rules and Standards for Information Security
• Risk Assessment
• Statement of Applicability
• Logging and Monitoring Standard
• Log Source and Retention Register
• Log Review and Alert Triage Record
• Log Integrity and Access Review Checklist
• A.8.15 Audit Evidence Pack
• A.8.15 Audit Checklist

KB-ready summary

• Define loggable events from risk.
• Capture enough detail to investigate.
• Protect logs against modification and deletion.
• Review and analyse logs with assigned responsibility.
• Escalate security alerts and trend faults into corrective action.

Templates and checklists

• Logging and Monitoring Standard
• Log Source and Retention Register
• Log Review and Alert Triage Record
• Log Integrity and Access Review Checklist
• A.8.15 Audit Checklist