Turning Raw Events into Something You Can Actually Use
ISO 27001 Control 8.15 Logging is about making sure you’re not flying blind.
If something goes wrong – a suspected breach, a strange login, a database change nobody remembers authorising – your logs are often the only way to work out what really happened and how far it went.
This control expects you to:
- Capture the right events
- Store logs securely and reliably
- Protect logs from tampering and unauthorised access
- Actually review and use them for detection, investigation and compliance
This guide walks through what ISO 27001 Control 8.15 really expects and how to build a logging approach that’s practical, auditable, and genuinely useful when you need it.
What ISO 27001 Control 8.15 Actually Requires
In plain English, ISO 27001 Control 8.15 – Logging expects you to:
- Decide which events you log, from which systems, and why
- Make sure logs are accurate, time-synchronised and complete enough to support investigations
- Store logs in a way that preserves integrity and confidentiality
- Retain logs for a defined period, based on legal, regulatory and business needs
- Regularly review and analyse logs to spot suspicious activity or system issues
It ties directly into:
- Incident detection and response
- Access control and privileged activity monitoring
- Forensic readiness
- Compliance and audit trails
The key point: logging is not just “turning on verbose logs everywhere”. It’s a designed control, not a by-product.
Step 1 – Decide What You Need to Log (and Where)
Start with risk and usefulness, not “log everything”.
For ISO 27001 Control 8.15, focus first on systems that:
- Process or store sensitive information
- Provide authentication and authorisation
- Expose services to the internet
- Are part of your security stack (firewalls, IDS/IPS, EDR, proxies, VPNs, etc.)
From these systems, you typically want logs for:
- Authentication and access
– Successful and failed logins
– MFA challenges, password resets, account lockouts
– Privilege escalations and role changes - Administrative and configuration changes
– New accounts, group changes, permission changes
– Firewall rule changes, VPN config changes
– Changes to logging itself (e.g. disabling audit trails) - Data access and changes
– Creation, modification and deletion of sensitive records or files
– Bulk exports or unusual queries
– Changes to security or privacy settings in applications - System and security events
– Service restarts, crashes, kernel or system errors
– Anti-malware detections, IDS/IPS alerts, WAF events
– Suspicious or blocked network connections - Application events (for key business systems)
– Login and session events
– High-impact transactions (e.g. payment actions, approvals, changes to key configurations)
You don’t need the same depth everywhere, but you do need a clear rationale: what’s logged where, and why.
Step 2 – Create a Logging Standard and Policy
ISO 27001 Control 8.15 is much easier to evidence if you have a logging standard that vendors, admins and developers can all follow.
Your logging policy/standard should cover:
- Scope
– Which systems and applications must generate logs
– Minimum logging requirements for any new system going live - Event coverage
– The classes of events to log (auth, admin, data access, errors, security events)
– Requirements for timestamping, user IDs, source IP, and system identifiers - Time synchronisation
– All systems using a common, reliable time source (e.g. NTP) to keep timestamps consistent for investigations - Retention periods
– How long logs are kept (by system type or severity)
– How older logs are archived and eventually deleted - Access control
– Who can view logs
– Who can administer logging systems
– Who, if anyone, can delete logs (and how that’s audited) - Format and structure
– Preference for structured logs (JSON, key–value) where possible
– Basic field requirements to make search and correlation easier
This gives you a repeatable pattern: whenever you add or change a system, you can ask, “Does it meet our ISO 27001 Control 8.15 logging standard?”
Step 3 – Centralise and Protect Your Logs
Scattered logs on individual servers aren’t much help during an incident. ISO 27001 Control 8.15 expects logs to be available, searchable and protected.
Good practice:
- Centralised log collection
– Forward logs to a central log server, SIEM or logging platform.
– Include infrastructure, apps, databases, cloud services and security tools. - Redundancy and availability
– Ensure log storage is resilient – you don’t want to lose logs during an incident.
– Consider separate storage or regions for critical security logs. - Protection against tampering
– Make production logs append-only where feasible.
– Use hashing or integrity checks to detect changes to log files.
– Restrict write/delete permissions tightly; admins should not be able to silently erase evidence. - Encryption and confidentiality
– Encrypt logs in transit (e.g. TLS for log forwarding).
– Encrypt logs at rest if they include sensitive data or PII.
– Segregate particularly sensitive logs (e.g. authentication and HR-related systems) with stricter controls. - Segregation of duties
– Ideally, those who administer production systems should not be able to quietly manipulate central log storage.
– Security or audit functions should have independent visibility of logs.
That’s the level of control an auditor will expect to see for ISO 27001 Control 8.15.
Step 4 – Analyse Logs and Use Them for Detection
Capture is only half the story. ISO 27001 Control 8.15 also expects you to review and act on logs.
Practical approaches:
- Use a SIEM or central analytics tool
– Aggregate logs from key systems.
– Apply correlation rules and detection use cases (e.g. multiple failed logins followed by a success, unusual geolocation, high-volume data exports). - Define alerting thresholds
– Decide which events should generate real-time alerts (e.g. admin account creation, repeated failed logins on privileged accounts).
– Avoid alert fatigue by prioritising truly high-risk events and tuning rules over time. - Regular log review
– Schedule periodic reviews (daily/weekly) of key logs or SIEM dashboards.
– Tie this into your security operations or internal audit routines. - Use logs in investigations
– Make logs a standard part of your incident response playbooks.
– Ensure responders know where logs live, how to query them, and what “normal” looks like. - Measure and improve
– Track useful metrics: number of alerts, true positives/false positives, time to detect suspicious activity.
– Use this feedback to refine logging and detection rules.
This operational aspect is central to demonstrating that ISO 27001 Control 8.15 is actually adding value, not just generating noise.
Step 5 – Handle Privacy and Compliance in Logging
Logs often contain personal data, which means ISO 27001 Control 8.15 sits alongside privacy obligations.
You should:
- Minimise sensitive content
– Don’t log full passwords, full card numbers, or other secrets.
– Mask or truncate sensitive fields (e.g. last 4 digits only where needed). - Classify log data
– Treat logs that contain PII or confidential data with appropriate classification and protections.
– Make sure retention aligns with privacy requirements (don’t keep logs longer than justified). - Restrict access
– Limit who can see logs that contain personal or confidential data.
– Use role-based access with strong authentication. - Anonymise or pseudonymise where possible
– For long-term analytics or sharing with third parties, remove or pseudonymise identifiers.
– Ensure there’s a clear legal basis for any sharing. - Document your approach
– Be able to explain how your logging under ISO 27001 Control 8.15 fits with GDPR or other data protection laws (purpose, necessity, retention, security).
That way, logging strengthens your security posture without undermining your privacy commitments.
Step 6 – Maintain, Test and Improve Your Logging
As systems and threats evolve, your logging must evolve with them.
For ISO 27001 Control 8.15, you should:
- Review coverage regularly
– When new systems are introduced, confirm they meet your logging standard.
– After incidents or near misses, check whether logs were sufficient or need improving. - Test logging as part of changes
– For major releases or infrastructure changes, verify that key events are still logged correctly.
– Don’t let application updates silently disable or degrade logging. - Align with other controls
– Make sure logging supports your incident response, access control, data leakage prevention and monitoring controls.
– Add new detection rules when you add new security tools or business processes. - Housekeeping and performance
– Monitor log storage capacity and ingestion rates.
– Archive or prune logs as per retention rules, and ensure this doesn’t break investigations or compliance.
This ongoing tuning is what keeps ISO 27001 Control 8.15 relevant and effective instead of slowly decaying.
Quick Implementation Checklist for ISO 27001 Control 8.15
Use this as a quick sense-check:
- ISO 27001 Control 8.15 (Logging) is covered by a logging and log management policy/standard.
- You’ve identified which systems are in scope for detailed logging (auth, critical apps, security tools, infrastructure, cloud).
- Key events are logged: logins, admin changes, data access, security events, system errors.
- Systems use synchronised time so events can be correlated across platforms.
- Logs are centralised, with appropriate redundancy, and can be searched efficiently.
- Access to logs is restricted and auditable, and logs are protected against tampering.
- Log retention is defined and implemented in line with legal, regulatory and business requirements.
- There is active log monitoring and analysis (e.g. via SIEM), with alerts for high-risk events.
- Logs are routinely used in incident investigations, and lessons learnt feed back into logging improvements.
- Privacy is considered: sensitive values are masked or minimised, and access to PII in logs is controlled.
Bringing It All Together
ISO 27001 Control 8.15 – Logging – is what turns your environment from a black box into something you can understand, defend and explain.
If you:
- Decide what to log based on risk and usefulness,
- Standardise and centralise your logging,
- Protect logs as valuable security assets, and
- Actually use them for detection, investigation and improvement,
you’ll have a logging approach that satisfies ISO 27001 Control 8.15 and, more importantly, gives you the visibility you need when things get difficult.
Explore the ISO 27001 Control Group Purposes