Implementing ISO 27001 Annex A 8.15 is a technical imperative for event logging and anomaly detection. It requires organizations to capture user activities, faults, and security events across all systems. This robust logging architecture ensures data integrity and forensic readiness, allowing security teams to reconstruct timelines and effectively respond to cyber incidents.
ISO 27001 Annex A Logging Implementation Checklist
Use this implementation checklist to achieve compliance with ISO 27001 Annex A 8.15. Compliance here is technical, not administrative; if your logs are stored locally on the compromised asset, you have merely provided the attacker with a scratchpad to delete.
1. Define the Event Logging Policy
Control Requirement: Production of logs recording user activities, exceptions, faults, and information security events.
Required Implementation Step: Create a technical standard that mandates exactly which events must be captured across all Operating Systems (e.g., Successful Logins, Failed Logins, Sudo escalation, File Permission changes). Do not leave this to default vendor settings, which are often insufficient.
Minimum Requirement: Explicitly define the “Who, What, Where, When” data schema for all critical assets.
2. Enable OS-Level Audit Trails
Control Requirement: Recording of system-level administrator and operator logs.
Required Implementation Step: Configure auditd on Linux and the ‘Advanced Audit Policy Configuration’ on Windows Servers. Specifically enable ‘Object Access’, ‘Privilege Use’, and ‘Account Logon’ auditing to capture granular events rather than just high-level noise.
Minimum Requirement: Disable “Success” logging for high-volume file reads to save disk space; focus on “Failure” and “Privilege Escalation”.
3. Configure Application and Database Logging
Control Requirement: Application-specific security events must be recorded.
Required Implementation Step: Edit the configuration files for your middleware (e.g., Nginx access.log, IIS Logging) and databases (e.g., SQL Server Audit Specifications). Ensure they capture injection attempts, schema changes, and access to sensitive tables.
Minimum Requirement: Default error logs are not enough; you must enable access/transaction logging.
4. Implement Centralised Log Forwarding
Control Requirement: Protection of log information against tampering and unauthorised access.
Required Implementation Step: Install log shippers (e.g., Filebeat, Windows Event Forwarding) on all endpoints to stream logs immediately to a separate, hardened Log Server or SIEM. This ensures evidence survives even if the endpoint is wiped.
Minimum Requirement: Logs must leave the source device within seconds of generation.
5. Enforce Immutable Storage (Write-Once)
Control Requirement: Logs must be protected from deletion and modification.
Required Implementation Step: Configure the destination log repository to use Write-Once-Read-Many (WORM) storage or append-only attributes (chattr +a on Linux archives). Ensure even the System Administrator cannot retroactively edit or delete log files.
Minimum Requirement: Segregation of duties; the person administering the server must not be able to wipe the logs.
6. Synchronise Log Timestamps
Control Requirement: Ensure accuracy of time to allow for event correlation.
Required Implementation Step: Hardcode the time format in your logging configuration (e.g., ISO 8601) and ensure the logging agent pulls the local system time, which is already synchronised via NTP (refer to Annex A 8.17). Mismatched time zones render forensic timelines impossible to construct.
Minimum Requirement: All logs must be normalised to UTC time at the point of ingestion.
7. Configure Automated Log Rotation and Retention
Control Requirement: Logs must be available for the required period to satisfy investigations.
Required Implementation Step: Configure logrotate or equivalent retention policies to compress and archive logs after 30 days, moving them to cold storage for the statutory period (typically 12 months). Ensure disk space alerts are set to prevent logging failure.
Minimum Requirement: “Disk Full” is not an acceptable excuse for missing security evidence.
8. Monitor the Logging Facility Itself
Control Requirement: Logging faults and interruptions must be detected.
Required Implementation Step: Set up a “Heartbeat” alert in your monitoring system. If a critical server stops sending logs for more than 15 minutes, trigger a high-severity ticket to investigate whether the logging agent has failed or been disabled by an attacker.
Minimum Requirement: You must know immediately if the “camera” stops recording.
9. Restrict Access to Log Data
Control Requirement: Prevent unauthorised access to sensitive log information.
Required Implementation Step: Implement strict Access Control Lists (ACLs) on the central log repository. Only the Security Operations team and Internal Audit should have read access; general IT staff should not be able to browse user activity logs casually.
Minimum Requirement: Logs often contain PII; treat the log server as a high-confidentiality asset.
10. Verify Log Integrity and Recoverability
Control Requirement: Regular review to ensure logs are actually recording effectively.
Required Implementation Step: Perform a quarterly “Sample Test.” Select a random date and specific user action, then retrieve the raw log file to verify it is readable, hasn’t been corrupted, and contains the required metadata (IP, User, Timestamp).
Minimum Requirement: A backup of a corrupt log file is useless; verify integrity hashes regularly.
ISO 27001 Annex A 8.15 SaaS / GRC Platform Implementation Failure Checklist
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Log Production | GRC tool asks: “Are logs enabled?” (Yes/No). | You clicked “Yes,” but the default logging level is “Error Only,” missing all successful intrusions and privilege escalations. |
| Tamper Protection | “We have a policy that says don’t delete logs.” | The attacker gained root access and typed rm -rf /var/log. Because logs weren’t shipped off-site, you have zero evidence. |
| Administrator Logging | “Admins are trusted employees.” | The insider threat (a rogue admin) simply disabled the logging service before stealing the database. No alert was triggered. |
| Retention Periods | Setting retention to “Default” (often 7 days). | The breach is discovered 90 days after it happened (industry average). Your 7-day logs are long gone. |
| Log Review | “We review logs annually.” | Logs are write-heavy data streams. If you aren’t using automated parsing, nobody is reading them. |
| Cloud/SaaS Logs | Assuming M365/AWS logs everything by default. | Many cloud providers charge extra for long-term log retention or detailed audit trails. If you didn’t pay/configure it, it doesn’t exist. |
| Time Synchronisation | Ignoring the timezone setting. | Server A is on EST, Server B is on UTC. Correlating an attack across them is manually impossible during a crisis. |
DO IT YOURSELF ISO 27001
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
About the author
