A.8.15 ISO 27001

ISO 27001 A.8.15: Logging

What This Control Requires

Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed.

In Plain Language

When a security incident happens, the first question is always: what exactly occurred, and how far did it spread? Without proper logging, the answer is "we have no idea" - and that is a terrible position to be in with regulators, customers, and your board.

Good logging covers the events that matter: authentication attempts, access to sensitive data, admin activities, configuration changes, application errors, network patterns, and security tool alerts. The logs need to be protected from tampering and kept long enough to be useful for investigations.

But collecting logs is only half the job. You also need to analyse them - either through a SIEM that correlates events and generates alerts, or through regular manual review. Logs sitting unread on a server are evidence you never knew you had, until you need it and cannot find what you are looking for.

How to Implement

Write a logging policy that covers what events to log, what each entry must contain, how logs are collected and stored, retention periods, and access controls on log data.

Define mandatory events for all systems: successful and failed authentication, access to sensitive data (reads and writes), privileged account usage, changes to user accounts and access rights, security configuration changes, system startup and shutdown, application errors and crashes, and security tool events (firewall blocks, malware detections, IDS alerts).

Every log entry needs at minimum: a synchronised timestamp (use NTP), source system identifier, event type, user or process identifier, action performed, target resource, outcome (success or failure), and source IP address or location. Incomplete log entries are almost as useless as no logging.

Centralise your log collection. Deploy a SIEM or log management platform that pulls logs from all critical systems. Use standard protocols - Syslog, Windows Event Forwarding, cloud logging APIs. Make sure the infrastructure is sized for your event volume, with headroom for growth.

Protect log integrity rigorously. Forward logs to the central system in near real-time so local copies cannot be tampered with. Use write-once storage or digital signing for critical logs. Restrict log access to authorised security and audit personnel. Crucially, system administrators should not be able to modify logs for systems they manage. Encrypt logs in transit and at rest.

Set retention periods based on regulations, business needs, and storage capacity. Most operational logs need 90 days to one year. Audit and compliance logs often need longer. Make sure your storage can handle the defined retention before you commit to it.

Analyse the logs you collect. Set up SIEM correlation rules, alerts, and dashboards. Monitor for known attack patterns, policy violations, and anomalous behaviour. Run regular reviews on critical systems even when no alerts fire.

Evidence Your Auditor Will Request

Logging policy defining events, content, retention, and protection requirements
SIEM or log management platform deployment and configuration records
Log source inventory showing all systems sending logs to the central platform
Log protection configuration (integrity, access controls, encryption)
Sample SIEM alerts and correlation rules for security event detection

Common Mistakes

Critical systems do not generate logs or logs are not collected centrally
Log entries lack sufficient detail for security investigation
Logs are stored locally where administrators could tamper with them
Log retention is insufficient for incident investigation or compliance requirements
Logs are collected but not analyzed for security events

Related Controls Across Frameworks

Framework	Control ID	Relationship
SOC 2	CC7.2	Equivalent
GDPR	Art.5(2)	Partial overlap
NIS2	Art.21(2)(b)	Related

Frequently Asked Questions

How long should we retain logs?

It varies by log type and regulation. As a rule of thumb: security event logs for at least one year, access logs for 90 days to one year, system logs for 90 days, and network logs for 30-90 days. Some regulations like PCI DSS mandate specific retention periods. If you are unsure, keep security-relevant logs for at least a year. Most incident investigations end up looking back further than anyone expected.

Do we need a SIEM?

If you have more than a handful of systems, yes. A SIEM gives you centralised collection, correlation, and alerting that you simply cannot replicate by reading log files manually. For smaller organisations, cloud-based SIEM services provide these capabilities without the overhead of running your own infrastructure. The alternative - logs scattered across systems with nobody watching them - means security incidents go undetected for months. Auditors will absolutely ask how you monitor your logs.

Track ISO 27001 compliance in one place

AuditFront helps you manage every ISO 27001 control, collect evidence, and stay audit-ready.

Start Free Assessment