Network security monitoring for ISO 27001 A.8.16

How network security monitoring meets ISO 27001 A.8.16

If your ISMS team is preparing for or maintaining ISO/IEC 27001:2022 certification, Annex A control A.8.16 Monitoring activities is one you will need to evidence with more than a running sensor. The control, in its technological controls theme, asks you to monitor networks, systems and applications for anomalous behavior and to evaluate potential information security incidents. ISO/IEC 27002:2022 describes that purpose, and it is one of 11 controls that were new in the 2022 revision. Annex A now holds 93 controls in four themes, down from 114 in the 2013 edition. ISO does not certify organizations. Accredited certification bodies assess your management system against the standard, so the question your auditor will ask is what you monitor, how you decided it, and what you did with the results.

Suricata and Zeek sensors produce the network-side monitoring data that A.8.16 depends on, including alerts, protocol logs and metadata. The short answer is that the sensors alone do not meet the control. Your ISMS needs a documented baseline of normal network behavior for the segments in scope, rules that define what counts as anomalous against that baseline, and a review cadence that someone owns. Each alert that is dismissed, escalated or tuned needs a triage record that links back to the baseline and to the related assessment under A.5.25. The sensor configuration, rule sources and tuning history are part of the same evidence set, and they should be version controlled so you can show how the monitoring changed over the certification cycle.

Start by confirming with your certification body which systems and network segments fall inside the ISMS scope, since that scope decides where sensors must see traffic. Then check how A.8.16 interacts with the neighboring controls you already operate, particularly A.8.15 Logging, A.8.17 Clock synchronization and the incident management controls in A.5.24 and A.5.25. Sensor timestamps that drift from your log sources will break the chain of evidence during an audit. Ask your certification body and your internal auditors how they expect baseline reviews and triage samples to be presented, because the form of that evidence varies between certification bodies and is not fixed by the standard itself. The ISO/IEC 27001:2022 standard page is the natural starting point for the control wording you will map against.

Mapping A.8.16 and related controls to sensor configuration

This table maps five Annex A controls to what the monitoring function must do, how to configure Suricata EVE output and Zeek logs, and how a Security Onion Distributed deployment supports the evidence. Read each row as a question an auditor is likely to ask, with the configuration that answers it. The main takeaway is that A.8.16 depends on the logging (A.8.15) and time (A.8.17) controls being right, because a sensor that drops events or has drifting clocks cannot support triage decisions under A.5.25.

Requirement	What the function must do	Sensor and platform configuration
A.8.16 Monitoring activities (anomaly detection scope)	Define which networks, segments and applications are monitored, baseline normal behavior, and detect anomalous activity against that baseline.	Place Suricata and Zeek sensors on agreed tap or span points. Enable EVE JSON for alerts, HTTP, DNS, TLS and file events. Document the scope and baseline in the monitoring register.
A.8.15 Logging (sensor and manager events)	Record sensor, manager and search node events, including rule changes, service restarts and failed ingestion, and protect those logs from alteration.	Forward Suricata EVE and Zeek logs through Security Onion Elastic Fleet to the manager. Log Console and detection rule changes. Confirm search nodes stop indexing if the manager is unreachable, and alert on that state.
A.8.17 Clock synchronization (sensors and search nodes)	Keep timestamps on all sensors, the manager and search nodes consistent so events can be correlated and sequenced in investigations.	Point every sensor, manager and search node to the same trusted time source. Check timestamps in EVE and Zeek logs against the manager during acceptance testing and record the results.
A.5.24 Incident management planning (monitoring feeds incident planning)	Define which network detections open incidents, who receives them and what playbooks apply, so monitoring output feeds the incident process.	Map Suricata alert categories and Security Onion detection groups to incident severities. Confirm the Distributed design delivers alerts to the SOC queue, with a tested fallback if the manager fails.
A.5.25 Assessment and decision on information security events	Assess each alert, record the decision (benign, false positive, incident or escalated) and the reason, and keep that record for later review.	Use the Security Onion Detections interface to tune and suppress NIDS rules with recorded reasons. Keep triage notes linked to the alert ID. Review suppression and threshold changes on a set schedule.

Baselining traffic before you can call anything anomalous

Anomalous behavior is defined against something. Before any alert is treated as meaningful, the organization needs a documented description of the traffic that its systems normally produce: which segments talk to which, which protocols and ports are expected, which external destinations are routine, and what volume and timing look typical. ISO/IEC 27002 describes the purpose of monitoring as detecting anomalous behavior and evaluating potential incidents, so the baseline is the reference point the auditor will ask you to explain. Agree on the observation window and record who approved the baseline.

Observation window: Record the start and end dates, the sensor locations and any business events (month-end, releases, backups) that shaped the traffic.
Asset and flow inventory: Map expected east-west and north-south flows to owners, so each deviation can be traced to a system and a person.
Approved baseline document: Store a versioned record with sign-off from the security and operations leads, and review it on a set schedule.
Known exceptions: List scheduled scans, vulnerability tools and backup jobs so they are not triaged as threats every time.
Change trigger: Define what forces a baseline update, such as a new application, a cloud migration or a new network segment.

Check that the baseline document can be produced on request, with the approval history and the reasons for each exception.

Which open-source platforms fit A.8.16 monitoring

A.8.16 asks for monitoring of networks, systems and applications for anomalous behavior, and the evidence is only as good as the tools that produce it. The platforms below cover sensing, analysis, bundling, log aggregation, triage and threat context, and each one leaves a different record for an auditor to review.

Suricata for detection and EVE records

Suricata inspects traffic with signatures and anomaly detection and writes every event and alert to EVE JSON, which gives you a structured record of what was seen and when. Decide early whether sensors run in IDS mode for monitoring or IPS mode for blocking, because that choice changes who owns the response. Check which ruleset sources you will load, such as the Emerging Threats Suricata ruleset or the VRT ruleset, and document how you update them. The current stable line is 8.0.7, and the 7 line has reached end of life.

Zeek for network analysis logs

Zeek turns traffic into protocol-level logs such as connections, DNS, HTTP and TLS records. These logs support baselining, which is the reference picture of normal behavior that makes anomaly detection meaningful under A.8.16. Zeek is distributed under a BSD-style license, which simplifies internal redistribution. Confirm which protocols your sensors must see, and test that logs are complete at your peak traffic rate before you rely on them as evidence.

Security Onion as the bundled console

Security Onion combines Suricata, Zeek, the Elastic stack and a console for detections, hunting and log management in one platform. Its Detections interface manages NIDS rules, Sigma rules and YARA rules, and it records tuning, which helps build the triage record an auditor asks for. Its repository is under the Elastic License 2.0, which is source-available rather than OSI-approved, so have legal review that license against your use. Version 3.0.0 supports only Oracle Linux 9, and 2.4 reached end of life on October 1, 2026.

Wazuh for EVE ingestion and alerting

Wazuh can read Suricata EVE JSON logs through its agent and analyze them on the Wazuh server, which connects network events with host telemetry in one alert pipeline. This matters for A.8.16 because alerts from applications and endpoints can be correlated with network activity. Wazuh's core repository is under GPL version 2, so confirm which components you deploy and their licenses. Confirm the agent placement on the sensor, since Suricata must run on the monitored endpoint for this integration.

Shuffle for triage workflow

Shuffle is a security automation platform licensed under AGPL-3.0 that can enrich alerts, route them and record each triage step. A.5.25 requires a documented assessment and decision for security events, and automated workflows give you a repeatable path from alert to decision. Define which alerts are auto-enriched and which go to an analyst, and keep the workflow version history. Confirm the connectors you need against your ticketing and SIEM tools before you commit to a design.

MISP or OpenCTI for threat context

MISP and OpenCTI store indicators, threat reports and sharing rules, so analysts can tell whether a Suricata alert matches a known campaign. MISP is licensed under AGPL-3.0, while OpenCTI ships a Community Edition under Apache 2.0 and an Enterprise Edition under a separate license, so check which features you need before choosing. Record which feeds you ingest and how often they update, since auditors ask how threat context stays current. Keep the decision on feed sources in your monitoring procedure.

Recording alert triage so every alert has an outcome

This sequence turns raw Suricata and Zeek detections into closed records, each showing what was decided, by whom, and why. An auditor reviewing A.8.16 can then trace any alert from sensor output to a documented outcome, incident link and rule change.

Generate and queue alerts from sensors
Suricata writes alerts to its EVE JSON output, and Security Onion or Wazuh forwards them to the analyst queue. The SOC lead confirms that every enabled rule source feeds the queue and that sensor health events are logged alongside detections. The check that closes this step is a test alert, injected on purpose, that appears in the queue with its timestamp, sensor ID and rule identifier intact.
Assign each alert to an analyst
A triage analyst takes ownership of each alert in the queue, and the platform records the assignment with a timestamp. Unassigned alerts past the team's agreed review window go to the shift lead. The closing check is a queue report showing no alert in an unowned state, which is the first evidence that monitoring is actively reviewed rather than only collected.
Enrich and classify the alert
The analyst checks the source and destination, the related Zeek connection, DNS, HTTP and TLS records, and any extracted files before assigning a disposition such as benign, false positive, suspicious or confirmed. The record must state the evidence reviewed, not only the label. The step closes when the disposition and evidence fields are complete in the record.
Tune or suppress with written justification
When an alert is a repeatable false positive, the analyst proposes a threshold, modification or suppression for the Suricata rule, and records the reason, scope (host, subnet or signature), and expiry or review date. A second reviewer approves the change before it is deployed. The closing check is a change entry linking the rule ID, the approver and the test that showed the noise was removed.
Escalate to the event assessment decision
Events that could be information security events are assessed against the organization's criteria to decide whether they are incidents. This is the A.5.25 decision point, and the record must show who made it, when, and on what basis. Events that are not classed as incidents are closed here with that rationale attached. The output is a decision entry that is never left blank.
Link confirmed events to incident records
Where the decision is that an incident exists, the alert IDs, sensor data and packet captures are attached to the incident ticket under the response procedure planned for A.5.24. Evidence is preserved with its original timestamps. The check that closes this step is that every incident record references at least one alert ID and every alert marked as an incident references a ticket.
Review rule changes and outcomes periodically
The security lead reviews a sample of closed alerts, suppressions and rule changes at a set interval, and checks for suppressions that have passed their review date or that hide a pattern now seen elsewhere. Findings feed the baseline update. The closing evidence is a dated review record listing what was sampled, what was changed, and who signed off. Confirm the review interval and sample method with your auditor before you commit to them.

Monitoring evidence auditors ask to see

This table lists the records a certification body is likely to ask for when it checks A.8.16 monitoring activities, which component produces each one, and what it shows. Read it as a checklist to confirm with your certification body before the audit, since the exact sample and format depend on the scope and the auditor. The main takeaway is that the evidence has to show the monitoring was designed, run, reviewed and improved, not just that sensors were installed.

Evidence item	What it shows	Produced by
Rule inventory and version records	Which NIDS rule sets are loaded, their sources and the versions in use over the audit period	Suricata rule files and Security Onion Console Detections
Sensor coverage map	Which network segments, links and hosts are monitored, and which are not, with the reason for each gap	Your network diagram, tap and span records, and sensor configuration
Monitoring baseline document	Normal traffic patterns and thresholds that define anomalous behavior for the organization	Zeek connection, DNS and protocol logs analyzed over a defined period, documented by the team
Triage log sample	How individual alerts were assessed, classified, escalated or closed, with timestamps and the analyst responsible	Security Onion alert records, Wazuh alerts and ticketing system records
Suppression and tuning history	Which alerts were suppressed or threshold-tuned, why, and who approved the change	Security Onion Console Detections history and change tickets
Review cadence records	That monitoring outputs were reviewed at the frequency the organization set, and by whom	Meeting minutes, SOC shift reports and ticketing records
Time synchronization evidence	That sensor, manager and log clocks agree, so events can be correlated across sources	NTP or time service configuration and sensor health checks (see A.8.17)
Internal audit findings	Whether the monitoring control was checked internally and what corrective actions followed	Internal audit reports and corrective action records

What sensors alone do not satisfy

A Suricata or Zeek sensor produces telemetry, but control 8.16 asks for monitoring that detects anomalous behavior and supports incident evaluation. The cards below cover the gaps that sit around the sensor: undefined baselines, unowned triage, blind spots, rule drift and outages. An auditor usually finds these gaps in the records, not in the hardware.

No defined baseline

Anomaly detection needs a reference for normal. Without a documented baseline of expected protocols, talkers, DNS patterns and outbound destinations for each segment, alerts on unusual behavior have nothing to be measured against. Before go-live, record traffic for an agreed period, document the expected flows per zone, and review the baseline whenever a new application or network change is approved. Ask who signs off the baseline and where it is stored.

No owner for triage decisions

Sensors raise alerts, but nothing in the control says who decides whether an alert is a false positive, an event to escalate or an incident. Assign a named role for each alert queue, define the closure categories, and record the reason for every dismissal. Auditors often ask for a sample of alerts and the decision trail behind each one, so unowned queues show up as gaps quickly. Confirm the triage workflow in your ticketing or SOC tooling before the first assessment.

Encrypted traffic blind spots

Much of today's traffic is TLS, so payload inspection stops at the handshake. Zeek and Suricata can still log TLS metadata, certificates and server names, but they cannot read encrypted content. Document which segments carry encrypted traffic, which metadata you retain for them, and where endpoint or application logging fills the gap. Ask your sensor partner to show which fields survive in your environment before you rely on them as evidence.

Application-layer gaps beyond the network

A network sensor cannot see a failed administrator login inside an application, a privilege change in a database or a suspicious API call that stays within an approved connection. Map which application, identity and host logs must feed the same monitoring process, and state which events the network sensors do not cover. Clause-level evidence is stronger when the monitoring scope is written down as a list of covered systems rather than assumed.

Unmanaged rule changes

Suricata rulesets and Security Onion detection settings change over time. Tuning that suppresses a signature or raises a threshold can silently remove coverage. Keep rule sources, versions and change approvals in version control, and log each suppression with a reason and an expiry. Security Onion's Detections interface records modify, suppress and threshold changes, so review that history on a fixed cycle rather than only during audits.

Sensor and manager outages

In a distributed Security Onion deployment, search nodes stop indexing when the manager is down because they cannot reach Redis. A monitoring gap can therefore look like a quiet network. Define health alerts for sensors, managers and search nodes, decide how long a gap is tolerable, and record each outage and its recovery. Receiver nodes add pipeline redundancy, so confirm whether your design needs them before the assessment.

How the certification cycle shapes monitoring evidence

Monitoring evidence has to exist before the auditor asks for it, because the certification cycle is built around recurring audits rather than one annual exercise. Under ISO/IEC 17021-1:2015, which accredited certification bodies apply, a management system certification cycle lasts three years, with at least one audit, either surveillance or recertification, in every calendar year. For a Suricata and Zeek deployment supporting A.8.16, that means the auditor will expect to see sensor coverage, alert triage records and tuning decisions from across the cycle, not only from the months before the visit. Confirm with your certification body how it plans its audit calendar and which periods it will sample.

Transition timing matters if any part of your certificate still reflects the 2013 edition. IAF MD 26:2023 required all ISO/IEC 27001:2013 certifications to expire or be withdrawn by 31 October 2025, the end of the 36-month transition period, so an organization still holding a 2013 certificate should already have moved to the 2022 controls, with A.8.16 mapped to its existing monitoring. Separately, IAF MD 29:2024 required accredited certification bodies to apply ISO/IEC 27006-1:2024 to all clients by 31 March 2026. Ask your certification body which version of its audit criteria it applies, and confirm that your monitoring records are reviewed against the current Annex A wording rather than an earlier numbering scheme.

Build the evidence continuously: a weekly or monthly review of Suricata EVE alerts, a documented baseline of expected traffic per sensor, and triage notes that record the decision taken on each alert. Keep the records in a form that survives an auditor's sampling, such as dated exports from Security Onion or Wazuh with the analyst's name and the disposition. To check that a certification body is accredited before you rely on its certificate, use the IAF CertSearch database, which ISO still points to, noting that since 1 January 2026 Global ACI has assumed the roles of IAF and ILAC. Ask your certification body to confirm its accreditation status in writing as part of the audit planning.

Questions buyers ask about ISO 27001 network monitoring

Do Suricata and Zeek alone satisfy ISO 27001 control A.8.16?

No single tool satisfies A.8.16 by itself. The control asks the organization to monitor networks, systems and applications for anomalous behavior, and ISO/IEC 27002:2022 describes the purpose as detecting anomalous behavior and evaluating potential information security incidents. Suricata provides signature-based detection, protocol logging and EVE JSON output, and Zeek adds network metadata that helps analysts see unusual behavior that signatures miss. Auditors will also look for the monitoring scope, the defined baseline, a triage process, and records showing that alerts were reviewed and decided. Those records come from your procedures and ticketing, not from the sensors. Confirm with your certification body how it expects A.8.16 to be evidenced for your scope, since it does not certify tools.

How much effort do baselining and alert triage take?

Effort depends on the size of the monitored network, how many sensors you run, how much of the traffic is already understood, and how many rules you load. Baselining means recording normal traffic patterns for each segment, including expected DNS, TLS, HTTP and administrative flows, then tuning rules to that baseline. Triage means assigning each alert an owner, a decision and a closing note. The biggest drivers are the number of asset owners who must confirm legitimate traffic, the volume of false positives in the first weeks, and whether your SOC has a documented escalation path. Ask any partner to estimate these effort drivers in writing against your scope, and to show how the work is tracked.

Can an in-house team run Suricata and Zeek monitoring for ISO 27001?

An in-house team can run it if it has Linux administration skills, time to tune rules, and staff who can review alerts on a defined schedule. Security Onion bundles Suricata, Zeek and the Elastic stack, and its Distributed deployment is the design the project recommends for production. The operational load falls on keeping sensors healthy, applying rule updates, handling packet capture storage, and running upgrades. Security Onion 2.4 reached end of life on October 1, 2026, so the upgrade path is a planning item for any team. Assess whether your team can sustain that work for three years, because the certification cycle needs monitoring evidence in every year of the audit cycle.

How long does it take to produce first monitoring evidence?

The time depends on the scope agreed, the state of your network documentation, and how quickly sensors can be placed and reviewed. Evidence usually starts with a documented monitoring scope, sensor placement records, and the first set of reviewed alerts with decisions. Auditors normally want to see that the process ran over a period, not a single snapshot, so the first audit cycle will be shorter in evidence than a mature program. DeployOpen does not publish timelines; a written scope and milestone plan will set the dates for your environment. Ask for the evidence list and the review cadence to be stated before work starts.

What does the client need to provide for the monitoring work?

The work needs accurate inputs before any sensor is placed. The main items are:

An asset inventory listing networks, systems and applications in scope, with owners
Current network diagrams showing segments, firewalls, and where taps or span ports can be placed
Change records for recent network and system changes, so that new traffic is not mistaken for an incident
The existing logging and incident procedures, and the names of staff who will triage alerts
Approval for packet capture and its retention, since captured traffic may contain sensitive data

If any of these are missing, baselining takes longer and the monitoring scope becomes harder to defend.

Which license fits: GPL, Elastic License 2.0 or Security Onion Pro?

Suricata is licensed under GPL-2.0, and Zeek uses a BSD-style license, so both can be deployed without a subscription. Security Onion is licensed under the Elastic License 2.0, which is source-available rather than an OSI-approved open source license, so your legal team should review its terms against your use. Security Onion Pro is a paid edition sold on 1 to 5 year terms that adds OIDC single sign-on, LUKS encryption, FIPS mode, OS STIG compliance and professional support. Choose Pro only if those features or support are required by your policies. Confirm current license terms directly with the publishers before committing.

What should a consultant scope for ISO 27001 monitoring include?

A useful scope lists the deliverables, the systems and segments covered, and the evidence produced. It should cover sensor placement and sizing, installation and hardening, rule sources and a tuning plan, baseline documentation, a triage procedure with roles, a monitoring review cadence, and a handover of runbooks. It should also state how upgrades, packet capture retention and rule updates are handled, and which items are excluded, such as SOC staffing or certification fees. Because DeployOpen works on fixed-scope engagements, the agreed scope and deliverables are written before work starts, and ongoing support is handled through separate retainers. Ask for the scope in writing with named acceptance criteria.

How DeployOpen scopes and delivers ISO 27001 monitoring evidence

DeployOpen plans, builds, documents and hands over self-hosted network monitoring with Suricata, Zeek and Security Onion inside your own infrastructure. We align the sensors, rules, alert records and evidence to the monitoring activities your ISMS already claims, so your team and your certification body can follow the trail from design to triage.

How we scope

Engagements are fixed-scope, with the monitored segments, sensor locations and protocols agreed in writing before work starts.
The written scope names the baselining method, alert triage workflow and evidence artifacts that map to A.8.16 for your organization.
We confirm which systems sit inside the ISMS boundary, so sensor coverage matches the networks your auditor will sample.

How we build

We deploy Suricata and Zeek sensors, with Security Onion where a distributed manager, sensor and search design fits your environment.
We load and tune detection rules, document each suppression and threshold change, and record the reason for every change.
We test sensor visibility and alert paths end to end, including whether events reach the team responsible for triage.

How we hand over

You receive configuration records, rule change logs, baseline documentation and triage procedures written for your team to run.
We prepare monitoring evidence packs that show what was monitored, how alerts were reviewed and how decisions were recorded.
Handover covers operating runbooks, upgrade steps and the list of open items that your ISMS owner must track.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so sensor and rule maintenance does not lapse.
We can review monitoring evidence ahead of your certification audit, flagging gaps in coverage or triage records for remediation.
Security testing of the monitoring stack itself is available, so you can confirm that detections fire as the documentation describes.

Network security monitoring for ISO 27001 monitoring activities