Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.15 — Logging

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.15 ISO 27001ISO 27002BSI OPS.1.1.5

A security breach is discovered three months after the initial compromise. The forensic team asks for authentication logs from the affected server — but the logs were rotated after 30 days and no central copy exists. The investigation stalls. A.8.15 ensures that security-relevant events are recorded, retained and protected from tampering so they are available when you need them most.

Logs are the foundation of detection, investigation and accountability. Without them, you cannot detect breaches, reconstruct attack timelines or prove compliance. This control covers the entire lifecycle: what to log, how to protect logs and how long to keep them.

What does the standard require?

  • Define what to log. Specify which events are security-relevant and must be recorded: authentication, privilege use, data access, configuration changes, security alerts.
  • Include sufficient detail. Each log entry must contain: timestamp, user ID, event type, source system, success/failure indicator and affected resource.
  • Protect log integrity. Prevent unauthorized modification or deletion of logs through cryptographic hashing, append-only storage or write-once media.
  • Centralize log collection. Forward logs from all systems to a central location for correlation and analysis.
  • Define retention periods. Retain logs long enough to support investigations, compliance requirements and trend analysis.
  • Protect sensitive log content. Logs may contain personal data or security-sensitive information — apply appropriate access controls.

In practice

Deploy centralized log management. Use a SIEM (Splunk, Elastic SIEM, Microsoft Sentinel) or a simpler log aggregation platform (Graylog, Loki). Forward logs from all servers, network devices, applications and cloud services.

Standardize log formats. Use structured formats (JSON, CEF, syslog) to enable automated parsing and correlation. Consistent formats reduce the effort needed to write detection rules and search queries.

Protect logs from tampering. Write logs to an append-only storage system. Use separate credentials for the log infrastructure that are independent of the production systems being monitored. An attacker who compromises a server should not be able to delete its logs.

Review logs regularly. Automated alerting catches known patterns, but human review catches anomalies that rules miss. Assign regular log review tasks — daily for critical systems, weekly for others.

Typical audit evidence

Auditors typically expect the following evidence for A.8.15:

  • Logging policy — documented rules for what is logged, retention and access (see IT Operations Policy in the Starter Kit)
  • SIEM or log management dashboard — evidence of centralized collection
  • Log coverage report — percentage of systems forwarding logs to the central system
  • Log integrity measures — configuration showing tamper protection
  • Log review records — evidence of regular review activities

KPI

Percentage of critical systems with enabled and retained security logging

Measured as a percentage: how many critical systems actively forward security logs to the central log management system with retention meeting policy requirements? Target: 100%.

Supplementary KPIs:

  • Log ingestion volume trends (for capacity planning)
  • Mean time between security event and detection (measures log review effectiveness)
  • Percentage of log sources with standardized formats

BSI IT-Grundschutz

A.8.15 maps to BSI modules for logging and security monitoring:

  • OPS.1.1.5 (Logging) — the core module. Requires a logging policy, centralized collection, tamper protection and regular review.
  • DER.1 (Detection of Security Events) — uses log data as the primary input for security event detection.

Sources

Frequently asked questions

What events must be logged?

At minimum: successful and failed authentication attempts, privilege usage, access to sensitive data, system configuration changes, security events (malware alerts, firewall blocks), and user account lifecycle events (creation, modification, deletion).

How long should logs be retained?

ISO 27001 does not specify a retention period. Common practice is 90 days for operational logs and 1-3 years for security-relevant logs. Align with legal requirements (e.g., GDPR limits on personal data in logs) and your incident investigation needs.

Do we need a SIEM?

A SIEM (Security Information and Event Management) is the most effective way to centralize, correlate and analyse logs at scale. For small organizations, a centralized log server with basic alerting may suffice. For anything beyond 50 systems, a SIEM is practically necessary.