A.8.15
Logging
Technological controlsCheckpoints 6Evidence 6Cases 6
Control objective
Logging requires that events arising from information systems, applications, network/security devices, and user activity be recorded so that the evidence and accountability needed to detect, investigate, and respond to security incidents are available. Because logs underpin the identification of anomalous behavior, root-cause analysis of incidents, and compliance with legal/regulatory requirements, the organization must define clearly what is recorded, at what level of detail, and for how long it is kept. Logs themselves can be a target for tampering, deletion, or unauthorized viewing, so the objective extends beyond producing records to protecting the integrity and confidentiality of the logs.
Key checkpoints
- Are the systems in scope for logging and the event types to record (login, privilege change, data access, configuration change, error, and so on), together with the level of detail, defined in a logging policy/procedure?
- Is each log configured to include the fields needed to reconstruct events (event timestamp, subject identifier, target, action, success/failure result, and so on), plus the source where the event or platform provides it?
- Are protective measures such as access control, tamper prevention, encryption, and central collection applied to preserve the integrity and confidentiality of logs?
- Is the log retention period defined in line with legal/regulatory/internal requirements, and are logs stored without loss for that period?
- Are the activities of privileged/administrator accounts logged separately, with separation of duties/controls so that a log administrator cannot conceal their own actions?
- Is there a procedure to detect and respond to conditions that undermine logging reliability, such as collection failures, storage exhaustion, and unsynchronized time?
Implementation guidance
- Select the systems, event types, and level of detail in scope for logging based on asset criticality and risk assessment results, and document them in a logging policy/standard.
- Record the time, actor, type, target, and result needed to reconstruct events, with a source address where available. Do not invent fields unavailable for an event or platform; make time zones and field meanings explicit.
- Forward logs to a remote central store (log server/SIEM) so that original records survive even if an individual system is compromised, and encrypt the transmission path.
- Minimize log read/write privileges and protect records through modification/deletion restrictions, separate storage, or append-only storage. When using hashes/signatures for integrity checks, protect reference digests and verification keys against alteration alongside the logs.
- Exclude authentication secrets such as passwords, reusable tokens, and secret API keys from logs. Record only necessary personal data, with masking/filtering and access control. Encryption of the log store does not justify unnecessary recording of secrets.
- Define log rotation, retention, archiving, and disposal rules, and continuously monitor storage capacity and collection status.
- Keep privileged/administrator activity logs separate from ordinary user logs, and separate the log-management role from the system-operations role so that mutual oversight is possible.
Evidence
- Logging policy/standard (systems in scope, events recorded, mandatory fields, retention periods defined)
- Log configuration screens or configuration files for key systems/security devices, plus samples of actually collected logs
- Central log store (SIEM/log server) architecture diagram and log forwarding/collection status
- Log access-permission list and evidence of integrity protection (hashing/signatures/append-only)
- Log retention and disposal history, and monitoring records for storage capacity/collection status
- Privileged/administrator activity logs and evidence of separation of duties for log management
Nonconformity examples
- Logging is disabled on key servers/security devices, or critical events (privilege changes, access failures, and so on) are not recorded.
- Clocks are not synchronized across systems, making log correlation and time-based tracing impossible during an incident.
- Administrators can arbitrarily delete/modify logs on individual servers, so log integrity is not assured.
- The log retention period falls short of a legal requirement (for example, a mandatory access-record retention period) or logs are deleted prematurely.
- Reusable authentication secrets or unnecessary sensitive personal data are logged, creating disclosure risk.
- A collection failure or storage exhaustion goes undetected, leaving logs missing for a considerable period without anyone noticing.