8.15 Logging
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).
Source: ISO/IEC 27002:2022, 8.15. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.
ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
- The topic-specific logging policy defining purposes, events to be logged, fields captured, retention and protection · SIEM / log platform
- Configuration evidence that logs are tamper-protected (append-only storage, hashing, restricted deletion) and that administrators cannot erase their own activity · SIEM / log platform
- SIEM correlation rules, use cases and alert tuning records, and evidence of regular log review · SIEM / log platform
periodic reviewEvidence produced at each review
- Investigation records for suspicious events identified from logs · SIEM / log platform
governing documentDocuments that govern the control
- Log source inventory showing which systems send which event types to central logging or SIEM · Policy repository / GRC workspace
- Procedures for de-identifying logs before sharing with vendors and protecting PII in logs · Policy repository / GRC workspace
First move
Common gaps auditors find
- 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
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet8.14 Redundancy of information processing facilities · 8.16 Monitoring activities