Logging

What the control asks

Logs recording activity, exceptions, faults and other events of interest are to be generated, kept, protected and analysed. Purpose: record events, produce evidence, keep log information intact, block unauthorized access to it, spot security events that could become incidents and support investigations. Guidance: a topic-specific logging policy documents why logs are created, what is collected and any protection and handling requirements. Each log entry should, as applicable, contain user IDs, system activities, dates, times and details of events such as log-on and log-off, device and system identifiers and location, and network addresses and protocols. Events to consider logging include successful and rejected attempts to access systems and to access data or other resources; system configuration changes; use of privileges; use of utilities and applications; which files were accessed and how, including removal of important files; alarms from access control systems; switching security systems such as anti-virus or intrusion detection on or off; creating, changing or deleting identities; and user transactions in applications, including those run by third parties. Synchronized time sources (8.17) are essential for correlating logs. Protection: nobody, including privileged users, should be able to delete or disable logs of their own activity; because administrators can tamper with logs on systems they control, logs must be protected and reviewed to keep them accountable. Protect against changes to what message types are recorded, editing or deletion of log files, and failure to record or overwriting of old entries when storage fills, using techniques such as cryptographic hashing, append-only read-only files or public transparency logs. Some logs must be archived for retention or evidence purposes (5.28). Before sending logs to a vendor for troubleshooting, de-identify usernames, IP addresses, hostnames or the organization name where possible (8.11), and protect PII in logs (5.34). Analysis: interpret events to find unusual or anomalous behaviour that may indicate compromise, considering the skills needed, a defined analysis procedure, the attributes each security event needs, exceptions flagged by predefined rules (SIEM, firewall, IDS, malware signatures), comparison of known patterns and normal traffic with anomalies (user and entity behaviour analytics), trend and pattern analysis, and threat intelligence. Support this with monitoring such as reviewing access attempts on protected resources such as name servers, portals and shared folders; checking DNS logs for outbound connections to malicious servers such as botnet controllers; examining provider usage reports and invoices for unusual activity; including physical entry and exit logs; and correlating logs. Suspected and actual incidents, such as malware infection or firewall probing, are investigated further (5.25). Other information: filtering tools help find significant events in voluminous logs; logging underpins automated monitoring (8.16); SIEM tools store, correlate, normalize and analyse logs and need careful source selection, rule tuning and use-case development; transparency logs help detect tampering; cloud logging responsibilities are shared (ISO/IEC 27017).

Purpose in the standard’s terms, in our words: Records events, generates evidence, protects log integrity, identifies security events and supports investigations.

Attribute values in one line: Detective; Confidentiality, Integrity, Availability; Detect; Information security event management; Protection, Defence.

The five attribute values

These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.

Evidence an auditor asks for

The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.

• The topic-specific logging policy defining purposes, events to be logged, fields captured, retention and protection
• Log source inventory showing which systems send which event types to central logging or SIEM
• Configuration evidence that logs are tamper-protected (append-only storage, hashing, restricted deletion) and that administrators cannot erase their own activity
• SIEM correlation rules, use cases and alert tuning records, and evidence of regular log review
• Investigation records for suspicious events identified from logs
• Procedures for de-identifying logs before sharing with vendors and protecting PII in logs

Where audits commonly find gaps

• Critical systems or cloud services are not sending logs to central collection
• Administrators can delete or disable logging on systems they manage
• Logs overwrite themselves when storage fills, losing evidence
• Logs are collected but nobody analyses them until after an incident

What ISO/IEC 27028 changes for this control

It carries a single control type, detective, which sets what the evidence has to prove. Its earlier numbering (12.4.1, 12.4.2) is kept in the register so an older audit file can still be traced. It serves more than one security domain, which is why a domain count taken by row understates the view.

The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.

Controls that share its values

• 8.16 Monitoring activities
• 8.7 Protection against malware
• 5.25 Assessment and decision on information security events

Read the five attributes All 93 controls