ISO 27001 SIEM Implementation: Logging and Monitoring

Security Information and Event Management (SIEM) is one of the most effective technical controls an organisation can deploy to detect, investigate, and respond to cybersecurity incidents. Under the ISO 27001:2022 standard, SIEM directly addresses several Annex A controls, particularly those relating to logging, monitoring, and incident response. Yet many organisations treat SIEM as a bolt-on tool rather than an integrated component of their Information Security Management System (ISMS). This approach limits its value and, more critically, exposes gaps that auditors will identify.

This guide provides a practical, ISO 27001-aligned approach to SIEM implementation. You will learn the specific Annex A requirements that drive SIEM adoption, how to scope log collection, how to evaluate SIEM tools against your control objectives, how to develop meaningful use cases and alert rules, and how to integrate SIEM output into your incident response workflow. Whether you are implementing SIEM for the first time or seeking to align an existing deployment with ISO 27001, this article covers everything you need.

SIEM Requirements Under Annex A.12.4

ISO 27001 Annex A.12.4 is the primary control family governing logging and monitoring. It contains three controls that together form the compliance basis for SIEM implementation:

Beyond A.12.4, several other Annex A controls create related obligations. A.16.1 (incident management) requires that security events be detected and escalated. A.13.1 (network security) and A.8.9 (asset management) generate logs that SIEM ingests. A.18.2.1 (independent review of information security) requires evidence that monitoring controls are effective, which SIEM reporting outputs can provide.

An effective SIEM implementation does not simply satisfy A.12.4 in isolation. It weaves together logging, monitoring, alerting, and response into a single operational capability that the ISMS auditor can examine as evidence of a functioning “Detect” and “Respond” capability.

Log Collection: Scope and Sources

The first step in SIEM implementation is defining the scope of log collection. ISO 27001 does not require that every device in the organisation feeds the SIEM. It requires that logging covers the information assets and processes identified as critical in the ISMS risk assessment and statement of applicability.

Priority Log Sources

Based on typical ISO 27001 risk assessments, the following log sources should be prioritised for SIEM ingestion:

• Identity and access systems – Active Directory, Azure AD, LDAP: authentication successes, failures, privilege escalations
• Network devices – firewalls, routers, switches: denied connections, policy violations, anomalies in traffic patterns
• Servers and endpoints – Windows Event Log, Syslog from Linux hosts: system events, process creation, file integrity changes
• Cloud services – AWS CloudTrail, Azure Monitor, Office 365 audit logs: API calls, resource changes, data access events
• Security tools – antivirus, EDR, vulnerability scanners: malware detections, scan results
• Database activity – SQL Server audit logs, Oracle audit trails: query activity, permission changes
• Physical access controls – badge reader logs: after-hours access, unauthorised entry attempts

The log collection architecture must ensure that each log source includes an accurate timestamp (enabled by A.12.4.4 clock synchronisation via NTP) and that logs are transmitted to the SIEM using a secure, authenticated protocol such as TLS-encrypted Syslog or HTTPS API ingestion.

Log Storage and Protection

Annex A.12.4.2 requires that log information be protected against tampering and unauthorised access. This has direct implications for SIEM architecture and operational procedures.

Log protection is not solely a technical control. The organisation must also document its log protection policy, define log retention schedules in line with regulatory requirements (e.g., GDPR, NCA, PDPL), and include log integrity checks as part of the internal audit programme.

SIEM Tools Comparison

Choosing the right SIEM platform for ISO 27001 alignment depends on your organisation’s size, budget, technical capability, and threat landscape. The table below compares the leading SIEM tools used in ISO 27001-compliant environments.

Whichever platform you select, the key ISO 27001 requirement is that the SIEM can demonstrate adequate logging coverage, log integrity, and auditability. A well-configured Wazuh deployment can satisfy Annex A.12.4 as effectively as Splunk in a smaller organisation. The tool is secondary to the control objective.

Use Case Development

Use cases translate the generic requirement to log and monitor into concrete detection logic aligned with your risk assessment. Each use case should map to one or more Annex A controls and to assets identified in the ISMS scope.

Common ISO 27001 SIEM use cases include:

• Brute-force detection – Multiple failed logins from a single source IP across multiple accounts within a defined window (maps to A.9.4.2).
• Privilege escalation – A standard user account added to a Domain Admin or local Administrator group (maps to A.8.2.3, A.9.2.3).
• Malware outbreak – Multiple antivirus alerts for the same signature within a short timeframe (maps to A.8.7).
• Data exfiltration – Large outbound data transfer from a sensitive server to an external IP (maps to A.8.12, A.13.1.3).
• Anomalous logon behaviour – A user logging in from a geographic location they have never used before (maps to A.8.24, A.9.4.2).
• Configuration drift – Unauthorised change to a firewall rule or security group (maps to A.8.9, A.12.6.1).

Each use case should be documented in a standardised template that includes: the use case name and ID, the log sources required, the detection logic, the severity and priority, the response procedure, and a reference to the relevant Annex A control. This documentation becomes part of the ISMS evidence base.

Alert Rules and Tuning

A poorly tuned SIEM generates alert fatigue, where the security team becomes desensitised to notifications and critical events are missed. ISO 27001 does not mandate a specific false-positive rate, but it does require that the logging and monitoring process be effective. Effectiveness implies that alerts are acted upon, not ignored.

Best practices for alert rule tuning under ISO 27001 include:

1. Start with a small set of high-fidelity rules covering critical assets only. Expand coverage gradually.
2. Classify alerts by severity (Critical, High, Medium, Low) and map each severity level to a defined SLA for triage.
3. Implement suppression rules for known benign activity (e.g., authorised vulnerability scans) to reduce noise.
4. Review false-positive rates monthly. Any rule with a false-positive rate above 95 per cent should be suspended or re-engineered.
5. Include alert rule changes in the change management process (A.8.32).
6. Regularly test alert rules using tabletop exercises or red-team simulations to validate that detection logic works as intended.

Alert rules should never be static. As the organisation’s risk landscape evolves, rules must be updated to reflect new threats, new applications, and changes in the IT architecture. The SIEM rule maintenance schedule should align with the ISMS management review cycle.

Incident Response Integration

The SIEM is not a standalone tool; it is the detection engine of the incident response process defined in Annex A.16 (incident management). Every alert that reaches a confirmed security incident must feed into the organisation’s incident response plan.

Integration between SIEM and incident response should cover:

• Automated ticket creation – SIEM alerts at Critical and High severity should automatically generate a ticket in the incident management system (e.g., ServiceNow, Jira).
• Playbook automation – SOAR capabilities within the SIEM (or connected via API) can execute predefined response actions such as isolating an endpoint or blocking a suspicious IP.
• Evidence preservation – The SIEM must log all actions taken during incident response to preserve a forensic chain of custody.
• Post-incident review – SIEM data supports root-cause analysis and lessons-learned documentation, which feed back into the ISMS continual improvement process (Clause 10.1).

The auditor will look for evidence that SIEM-generated incidents are handled according to documented procedures, that response times meet SLA targets, and that lessons learned result in control improvements. This closed-loop approach distinguishes a compliant SIEM deployment from a mere log repository.

Frequently Asked Questions

1. Is SIEM mandatory for ISO 27001 certification?

No. ISO 27001 does not prescribe specific technologies. However, Annex A.12.4 requires event logging, log protection, administrator logs, and clock synchronisation. A SIEM is the most common and effective way to satisfy these controls, particularly in medium-to-large organisations, but a well-structured manual log review process could theoretically meet the requirement for very small organisations.

2. How long should logs be retained for ISO 27001 compliance?

ISO 27001 does not specify a mandatory retention period. The organisation must determine retention periods based on legal, regulatory, and business requirements, document them in the log retention policy, and apply them consistently. Typical minimum retention is 6–12 months for operational security logs and 3–7 years for logs that support legal or compliance obligations.

3. Can we use an open-source SIEM for ISO 27001 compliance?

Yes. Open-source SIEM platforms such as Wazuh, ELK Stack, and OSSIM can fully satisfy Annex A.12.4 requirements when configured correctly. The certification auditor will evaluate the effectiveness of the controls, not the licence cost of the tool.

4. What is the difference between SIEM and SOAR in an ISO 27001 context?

SIEM focuses on log collection, correlation, and alerting (Annex A.12.4). SOAR extends SIEM with automated response actions (Annex A.16.1). While not mandatory, SOAR integration strengthens the “Respond” capability and is increasingly expected in mature ISMS implementations.

5. How often should SIEM rules be reviewed?

SIEM rules should be reviewed at least quarterly as part of the regular monitoring and measurement review cycle. Additionally, rules must be reviewed after any significant change to the IT environment, such as the deployment of a new application, a network segmentation change, or the adoption of a new cloud service.

6. Does the SIEM need to be in scope for the internal audit?

Yes. The SIEM platform itself is a control supporting Annex A.12.4 and should be included in the internal audit programme. The auditor will verify log coverage, log integrity, access controls on the SIEM, and evidence that alerts are being reviewed and acted upon in accordance with documented procedures.

How Bitrixme Can Help

Implementing SIEM in alignment with ISO 27001 requires technical expertise, a deep understanding of the standard’s control framework, and a systematic approach to use-case development and rule tuning. Bitrixme’s ISO consultants and security engineers help organisations design, deploy, and operate SIEM solutions that satisfy both the letter and the spirit of Annex A.12.4.

Get in touch with Bitrixme to schedule an ISO 27001 readiness assessment and SIEM scoping workshop.