ISO 27001 Log Management: Collection, Storage and Analysis

Log management sits at the heart of ISO 27001 compliance. Without reliable logs, you cannot detect incidents, demonstrate controls, or satisfy an auditor. Logs provide the evidence that your security controls are operating effectively, they enable incident response teams to investigate security events, and they support forensic analysis after a breach. This article covers Annex A.12.4 requirements, the types of logs you need, collection and storage strategies, log protection techniques, analysis methods, SIEM integration, and exactly what auditors expect to see.

Annex A.12.4 Requirements

ISO 27001 Annex A.12.4 (Logging and Monitoring) is the primary standard for log management. It comprises three controls that every organisation must address, and each control has specific requirements that an auditor will test. Understanding these requirements in detail is the first step toward building a compliant log management programme.

Additionally, A.12.4.4 (Clock synchronisation) supports log management by requiring that all systems synchronise clocks to a single reference time source (typically NTP). Without accurate timestamps, log correlation between different systems becomes unreliable, and an auditor will flag this as a finding. All systems in scope should synchronise to the same NTP server, and clock skew should be monitored and maintained within acceptable limits (typically 1 second or less).

The relationship between A.12.4 and other Annex A controls is important. A.12.4 supports A.16 (incident management) by providing the log data needed for incident detection and investigation. It supports A.9 (access control) by logging authentication and authorisation events. It supports A.13 (communications security) by logging network connections and data transfers. When designing your log management programme, consider how log data will support each of these areas.

Log Types: System, Application, Security and Network

ISO 27001 does not prescribe a specific list of log types, but the auditor will expect coverage across four domains. Each log type serves a distinct purpose and supports different controls. The table below maps each log type to the specific events you should capture and the Annex A controls they support.

Each log entry must contain, at minimum: timestamp (with timezone), user or system identifier, event type, source IP address, affected resource or system, and outcome (success or failure). For security logs, additional fields such as device name, process ID, and geographic location (for network connections) are recommended to support incident investigation and threat hunting.

Organisations should document which log sources are in scope, which events are captured from each source, and the retention period for each log type. This documentation should be maintained as part of the ISMS and updated whenever new systems are added or log sources change. A log source inventory matrix is a useful tool for this purpose and is something auditors will ask to see.

Log Collection

Collecting logs from diverse sources requires a structured approach. The goal is to centralise logs into a secure platform where they can be stored, protected, and analysed effectively. The collection architecture should be designed for reliability, scalability, and security.

• Agent-based collection – Install a log collector agent on each source system. Suitable for servers, databases, and critical applications. Agents can buffer logs locally if the central server is unavailable, ensuring no data loss during network interruptions. Popular agents include Winlogbeat, Filebeat, and fluentd.
• Agentless collection – Pull logs via Syslog (RFC 5424), SNMP traps, or API calls from the central platform. Suitable for network devices, firewalls, and cloud services. Avoids the overhead of managing agents on every device but may lack the buffering capability of agent-based collection.
• Cloud log collection – For cloud services (AWS CloudTrail, Azure Monitor, Google Cloud Logging, Office 365 audit logs), use native log export to your SIEM or a centralised logging platform via event hubs, log sinks, or API integrations. Cloud logs should be collected in real time where possible to support security monitoring.
• Push vs pull – Prefer push-based collection (agents or Syslog forwarders) over pull-based for real-time visibility. Pull-based collection (e.g. periodic API polling at 15-minute intervals) introduces latency and misses transient events that occur between polling cycles.
• Log source inventory – Maintain an inventory of all log sources, the collection method, the log format, and the collection status (collecting, not collecting, degraded). This inventory is essential for demonstrating log completeness to auditors.

Your log collection policy must define which systems are in scope (typically all systems handling information assets), the collection interval (real-time for security, batch for less critical systems), the retention of logs at the source before forwarding, and the procedure for adding new log sources to the collection infrastructure. Any system that is out of scope should be documented with a justification (e.g. low risk, isolated network).

Network bandwidth is a practical consideration for log collection. Centralising logs from multiple sites can consume significant bandwidth, particularly for verbose log sources like firewalls and web servers. Consider log compression, filtering of low-value events at the source, and dedicated log collection networks to manage bandwidth consumption. Bandwidth requirements should be assessed during the design phase and monitored continuously.

Storage and Retention

Log retention is a balancing act between compliance obligations and storage costs. ISO 27001 requires logs to be retained for a defined period, but does not specify a universal duration. Your retention periods should be determined by a combination of regulatory requirements, business needs, and operational constraints. The key is that your retention policy is documented, justified, and consistently applied.

Log storage architecture should use tiered storage to balance cost and query performance. Hot storage (high-performance SSDs or in-memory databases) for the most recent 30–90 days where logs are queried frequently for investigations. Warm storage (standard hard drives or lower-cost cloud storage) for 90–365 days where query volume is lower but moderate-speed queries are still needed. Cold or archive storage (tape, Amazon S3 Glacier, Azure Archive Storage) for 1–5 years where logs are retained only for compliance and forensic purposes. Archive storage must remain queryable, at least at the metadata level, to support e-discovery requests and regulatory inquiries.

Data compression is essential for managing storage costs. Logs compress exceptionally well, typically achieving compression ratios of 5:1 to 10:1. Implementing compression at the source or at the collector reduces both storage costs and network bandwidth consumption. Deduplication can further reduce storage requirements, but care should be taken not to deduplicate security-relevant events where multiple occurrences are significant.

Log Protection

Annex A.12.4.2 requires that log information be protected against tampering and unauthorised access. This is non-negotiable and often a focus area during audits. If an attacker can modify or delete logs, they can cover their tracks and evade detection. Log protection is therefore critical for both compliance and security effectiveness.

• Immutable storage – Write-once, read-many (WORM) storage prevents logs from being modified or deleted after they are written. Object locking in AWS S3 (Object Lock with retention mode), Azure Blob Storage immutability policies (time-based retention), or dedicated log management platforms provide this capability. Immutable storage is the single most important log protection control.
• Access controls – Restrict log access to authorised personnel only on a need-to-know basis. The principle of least privilege applies: security analysts need read access for their scope of responsibility; only log administrators need write/delete permissions, and they should not have access to production systems or security event logs (separation of duties). Use role-based access control (RBAC) specifically.
• Encryption at rest and in transit – Logs must be encrypted during transmission (TLS 1.2+) from source to central storage and at rest using AES-256 or equivalent. Encryption keys should be managed centrally and rotated at least annually. Key management practices should be documented and auditable.
• Integrity verification – Use cryptographic hashing (SHA-256) to generate hash chains for log entries. Timely log integrity checks (e.g. daily hash verification) should be automated and the results logged. Any integrity failure should trigger an alert and incident response process. Digital signing of log files at regular intervals provides stronger integrity guarantees than simple hashing.
• Separation of duties – The team that manages systems (system administrators) should not manage logs for those systems. This prevents cover-ups of unauthorised activity. If the same team manages both, compensating controls such as dual-authorisation for log access and regular independent reviews should be implemented.

Auditors frequently test log protection by attempting to modify or delete archived log entries. If the logs can be altered without authorisation or without leaving evidence of the modification, this will be raised as a non-conformity. Similarly, if the auditor finds that service accounts or shared credentials have access to log repositories, this will be flagged.

Log Analysis

Collecting logs is pointless if you do not analyse them. Annex A.12.4.1 implicitly requires that logs be reviewed, and A.16.1 (incident management) requires that security events be identified and escalated. Your log analysis programme should define what events to look for, how frequently to review logs, and how to escalate findings.

• Real-time alerting – Critical events (multiple failed logins in 5 minutes, admin account use outside working hours, firewall rule changes, malware detection) should trigger immediate alerts via email, SMS, or SIEM dashboard. Alert thresholds should be tuned to minimise false positives while ensuring that genuine threats are not missed.
• Daily review – The security team reviews the previous day’s logs for anomalies. Prioritise admin and operator logs (A.12.4.3), authentication failures, outbound connections to known-bad IP addresses, and unexpected configuration changes. Daily reviews should be documented and signed off.
• Weekly review – Trend analysis: are authentication failures increasing globally? Are specific systems generating more errors than normal? Is there a pattern in firewall denies that suggests reconnaissance activity? Weekly reviews should produce a brief report for the security manager.
• Monthly review – Compliance reporting: generate log analysis reports for management review and audit evidence. Include metrics on incident detection, response times, log source coverage, and trends in security events. Monthly reports should be presented to the ISMS management review meeting.
• Threat hunting – Proactive search for indicators of compromise (IoCs) that did not trigger automated alerts. Use known attack patterns (MITRE ATT&CK framework) as a guide for hunting activities. Threat hunting should be conducted at least quarterly by experienced security analysts.

All log analysis activities should be documented with standard procedures that define the scope, frequency, escalation path, and documentation requirements. The procedures should be reviewed at least annually and updated in response to new threats or changes to the environment. Evidence of log analysis (signed review checklists, SIEM dashboards, incident tickets) must be retained as audit evidence.

SIEM Integration

A Security Information and Event Management (SIEM) system is not mandatory for ISO 27001 compliance, but it is strongly recommended for any organisation beyond the smallest size. A SIEM centralises log collection from across the organisation, automates correlation between different log sources, and provides the audit trail that auditors expect. For organisations with 50 or more employees or those handling sensitive data, a SIEM is considered best practice and is increasingly expected by auditors.

• Log ingestion – Your SIEM must ingest all in-scope log sources. Common integrations include Syslog, Windows Event Forwarding (WEF), and API connectors for cloud services (AWS CloudTrail, Azure Monitor, GCP Audit Logs). The SIEM should normalise logs from different sources into a standardised format (e.g. Common Event Format or JSON schema) for consistent analysis.
• Correlation rules – Define rules that link events across different log sources to identify attack patterns. Example: failed login on Windows AD followed by a successful VPN connection from a new geographic location within 5 minutes equals a potential account compromise. Correlation rules should be based on the organisation’s threat model and industry best practices.
• Alert tuning – False positives will overwhelm your security team. Tune alerts continuously by adjusting thresholds, whitelisting known-good behaviour, and excluding noise sources. Document the reason for each tuning change and who approved it. Alert fatigue is a real operational risk that undermines the effectiveness of your log monitoring programme.
• Dashboards for management – Build dashboards for management review and audit evidence. Key metrics: number of security events detected, mean time to detect (MTTD), mean time to respond (MTTR), log source coverage percentage, and alert-to-incident conversion rate. Dashboards should be reviewed at the ISMS management review meeting.
• Playbook integration – Link SIEM alerts to incident response playbooks. When a suspicious log pattern is detected, the playbook should guide the analyst through investigation, containment, and remediation steps. Playbooks should be documented, tested, and updated regularly based on lessons learned from incidents.

Popular SIEM solutions that meet ISO 27001 requirements include Microsoft Sentinel (cloud-native, strong Azure integration), Splunk Enterprise Security (market-leading analytics), Elastic Security (open source core with commercial features), Wazuh (fully open source), and IBM QRadar. Whatever platform you choose, ensure it supports immutable log storage, provides role-based access control appropriate to your organisation’s structure, and can meet your scalability requirements.

Audit Requirements

An ISO 27001 auditor will test your log management controls thoroughly. Log management is one of the most frequently cited areas of non-conformity in ISO 27001 audits, so preparing thoroughly is essential. Here is what they typically look for:

• Log management policy or procedure – A documented policy that defines what is logged, how long logs are retained, who has access to logs, how logs are protected, and how log reviews are conducted.
• Log completeness – Evidence that all in-scope systems are generating logs and that logs are being collected centrally. The auditor may sample systems from the asset inventory and ask to see logs from those systems.
• Timestamp accuracy – Verification that all systems use NTP and that clock skew is within acceptable limits (typically 1 second). The auditor may ask to see NTP configuration on a sample of systems.
• Access control – Review of log access permissions. Only authorised personnel should have access, and a log of who accessed the logs and what actions they performed must exist.
• Immutable storage – Verification that logs cannot be modified or deleted before the retention period expires. The auditor may ask for a demonstration of the immutability controls.
• Log review evidence – Records of daily, weekly, and monthly log reviews, including any actions taken in response to findings. The auditor will look for consistency between the review schedule and the actual evidence.
• Incident correlation – Evidence that log analysis feeds into the incident management process (A.16.1) and that incidents identified through log analysis are tracked to resolution.

Common non-conformities in this area include incomplete log coverage (some in-scope systems not logging or not feeding into the central platform), inadequate protection of log data (logs accessible to unauthorised staff, no immutable storage, no encryption), failure to review administrator logs (A.12.4.3 is one of the most commonly cited controls), and insufficient retention periods that do not meet business or regulatory requirements. Address these before your Stage 1 or Stage 2 certification audit.

Frequently Asked Questions

How long must logs be retained for ISO 27001 compliance?

ISO 27001 does not specify a mandatory retention period. Your retention policy must be justified by business and regulatory requirements and must be applied consistently. Most organisations retain security logs for 12–24 months, application logs for 2–3 years, and archive logs for up to 5 years. Your retention policy must be documented in the log management procedure and approved by management.

Is a SIEM mandatory for ISO 27001?

No. SIEM is not a mandatory requirement in the standard. However, for any organisation with more than 50 employees or one that handles sensitive data, the auditor will expect some form of centralised log management and automated correlation. A SIEM is the most practical way to achieve this, but a well-structured centralised logging platform with manual review processes (supported by documented procedures and evidence) can suffice for smaller organisations with a limited number of systems.

What happens if a log source stops sending logs?

Your monitoring system should detect log source failure (absence of expected log events within a defined window) and trigger an alert to the security team. The incident response process should investigate why the source stopped logging and restore it within an SLA (typically 2–4 hours for security-critical log sources, 24 hours for system and application logs). The failure and restoration should be documented in the incident management system.

Can we store logs in the public cloud and be ISO 27001 compliant?

Yes, provided the cloud platform is itself ISO 27001 certified and your contract includes a data processing agreement (DPA) that addresses the requirements of Annex A.12.4. AWS, Azure, and Google Cloud Platform all hold ISO 27001 certification. You must ensure that logs are stored in an immutable format (AWS S3 Object Lock, Azure Blob immutability), encrypted at rest (AES-256), and accessible only to authorised personnel. You must also ensure that the cloud region where logs are stored meets any data localisation requirements applicable to your organisation.

Do we need to log every single user action?

No. ISO 27001 requires logging of user activities relevant to information security. Focus on authentication events (logins, logouts, failed attempts), access to sensitive data, privileged actions, system configuration changes, and security-relevant exceptions. Excessive logging (logging every click, keystroke, or API call) creates noise that obscures meaningful events, increases storage costs, and makes incident investigation more difficult. Define a clear logging specification for each system that identifies which events are in scope.

How often must we review administrator logs?

Annex A.12.4.3 requires regular review of administrator and operator logs. For critical systems (Active Directory, firewalls, database servers, cloud management consoles), daily review is expected. For less critical systems, weekly review is acceptable. All reviews must be documented with sign-off by the reviewer and the information security manager. Automated review where SIEM alerts flag anomalous admin activity can supplement manual reviews but should not replace them entirely.

Build Your ISO 27001 Log Management Framework

A robust log management programme is one of the most effective controls you can implement, both for ISO 27001 compliance and for real-world security operations. It provides visibility into your environment, supports incident detection and response, and gives auditors the evidence they need to certify your ISMS. Our ISO 27001 specialists can help you design and implement a log management framework that satisfies auditors and gives your security team the visibility they need to protect the organisation. We offer log management assessments, SIEM implementation support, policy and procedure development, and auditor preparation services.