Zabbix for ISO 27001 monitoring and logging controls

The point of A.8.16 Monitoring activities is to detect anomalous behavior in networks, systems and applications and to evaluate potential information security incidents. ISO/IEC 27002:2022 frames monitoring around those two purposes, so the question an auditor asks is not whether you run a monitoring tool, but whether monitoring is pointed at the behavior that could indicate a security problem. Zabbix can collect the signals and raise the alerts, but it cannot decide what matters. That decision belongs to your organization and should be written down before any template is imported.

The control is organizational work. Someone must decide which systems, signals and thresholds matter for your risk, who owns each decision, and how often the decisions are reviewed. For example, a team might decide that authentication failures on the identity provider, unexpected changes to firewall rule sets and sustained high outbound traffic from database hosts are in scope, while a printer's free disk space is not. Zabbix then executes that decision through items, triggers, host groups and actions. If the decision is missing, a well-configured Zabbix instance still produces evidence of nothing in particular.

Reviewers usually ask about a set of asset categories: servers and virtual machines, network devices such as firewalls, routers and switches, identity and authentication services, databases, business applications, endpoints where your policy requires them, and the monitoring and logging infrastructure itself. They also ask whether cloud control planes and security tools are covered where they hold sensitive data or grant access. Treat this list as a prompt for discussion, not a checklist to copy. Each category should be justified by a reference to the organization's own risk assessment, with the owner and the reason recorded beside it.

The scope has to come from your own risk assessment, the one required by the ISMS clauses of ISO/IEC 27001:2022. Start by listing the information assets and processes in scope for the ISMS, then identify the threats and vulnerabilities that would show up as anomalous behavior, and only then select monitored assets and signals. Confirm with your certification body how it expects this traceability to be shown, because the evidence format is their call, not ours. A useful check before go-live is to pick three high-impact risks and trace each one to a monitored asset, a Zabbix item or trigger, and a named responder.

The control question is whether a monitored signal can be traced to a person who responded to it and to the closure of the event. In Zabbix, that chain runs from an item value, to a trigger expression that evaluates to a problem, to an event, to an action that sends a notification, to a human acknowledgement and then to recovery. Each hop needs its own record because an auditor will ask what was detected, when it was detected, who was told, what they did and when the condition cleared. Before you write the procedure, map each hop to a screen, export or log entry your team can produce on request.

Every alert route needs a named owner. The artifacts that define a route are the action, the user groups and users it notifies, and the media assigned to them. Record which host groups or tags each action covers, who maintains its operations and escalation steps, and who approves changes to it. In Zabbix, escalations are defined as steps inside an action, each with its own timing and recipients, so the escalation design is itself a reviewable configuration. Document on-call handoffs as dated changes to group membership, with the rota kept in your scheduling tool and referenced from the change record. Problem acknowledgements store the author and any message, which gives you the response record. Confirm which acknowledgement, update and manual close options your Zabbix version provides, and decide in advance which of them your procedure requires.

Alerts are evidence only if the components that generate them keep running, so monitoring continuity is a control concern in its own right. Zabbix server supports a native high availability cluster in which several nodes share one database, one node is active and the others stand by. Failover occurs when the active node exceeds a configurable failover delay, which can be set from 10 seconds to 15 minutes. From Zabbix 7.0 onward, proxy groups redistribute monitored hosts between proxies when a proxy goes offline. Treat the failover delay, proxy group membership and redistribution behavior as control settings: set them deliberately, test a node and a proxy failure, and keep the test results. Also monitor the monitoring itself, using internal items and alerts for node status, proxy availability and queue growth, so that a silent gap is itself recorded.

Notification channels must be confirmed for the Zabbix version in use before you describe them in a procedure. Confirm which media types are built in, how webhook and script media are configured and tested, and whether delivery failures are logged and where those logs are kept. Test each route end to end with a controlled problem, then retain the test notification, the event record and the acknowledgement as a sample of the control working. Confirm also how long events, actions and acknowledgements remain in the database under your housekeeping settings, and set retention with the auditor's sample period in mind. If a channel depends on an external service, record that dependency and its owner, because a failure there breaks the evidence chain even when Zabbix behaves correctly.

A.8.15 Logging asks that logs recording activities, exceptions, faults and other relevant events are produced, stored, protected and analyzed. Zabbix covers a useful part of this through item history, triggers and problem events for the hosts it monitors, but those records describe the health and availability of systems. They do not replace the authentication records, privileged activity trails, application audit events and system logs that an auditor will ask you to produce. Before you rely on Zabbix as evidence for this control, build a log source inventory for each host, application and network device, record who owns each source, and mark which sources Zabbix does not collect at all.

Graylog Open is the log platform most often placed beside Zabbix for this gap. It ingests messages over inputs such as syslog, GELF and Beats, routes them through streams and processing pipelines, and provides search and dashboards. Streams let you separate authentication and privileged-access logs from high-volume application output, so each set can have its own access rules and retention. Event definitions raise alerts from real-time or historical searches, and Graylog Open's product page lists PagerDuty, Slack and email as notification targets. Index rotation can be set by message count, size or time, and retention deletes the oldest indices. Set these values from your written logging retention period, then test that a sample index is removed when it should be.

Graylog runs as Graylog server nodes that use MongoDB for configuration and metadata, with Graylog Data Node or self-managed OpenSearch holding the log data. For Graylog 7.0 to 7.2, the compatibility matrix lists MongoDB 7.x up to 8.2.x and OpenSearch 1.1.x up to 3.7.x, and Graylog Security needs OpenSearch 2.0 or later. OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0, so Data Node is the safer choice for a new build. Graylog's multi-node guide recommends three Graylog and MongoDB nodes with MongoDB as a replica set, three Data Nodes on their own cluster, a load balancer, and is_leader set to false on follower Graylog nodes. For storage, the system architecture guidance is daily ingest multiplied by retention days multiplied by 120 percent, with the message journal sized at 3 to 5 times daily ingest on SSDs. Confirm all of these against the release you intend to install.

The licensing decision comes before the build. Graylog has licensed Graylog Open under the Server Side Public License version 1 (SSPL-1.0) since Graylog 4.0, replacing GPL v3 for earlier releases. SSPL-1.0 is not approved by the Open Source Initiative, so ask your legal team to review whether its terms fit how your organization will run and offer the platform internally or to customers. Commercial tiers change the cost picture: Graylog's pricing page lists Enterprise from 15,000 US dollars per year and Security from 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data without per-user or per-device fees. Budget for the infrastructure under MongoDB, Data Nodes and the load balancer, plus setup and support work, and ask any quote to state how it measures your daily ingest.