A.8.16 Monitoring activities: requirements and evidence

What A.8.16 monitoring activities asks for and why audits fail it

A.8.16 asks the organization to monitor its networks, systems and applications for anomalous behavior, and to evaluate and act on what the monitoring finds. The control is about the loop, not the tooling: something must watch, a person or process must judge what it sees, and the result must lead to a documented response. ISO/IEC 27002:2022 describes the purpose the same way, as detecting anomalous behavior and evaluating potential information security incidents. The control is one of the 11 controls that were new in the 2022 revision of Annex A, so many teams are meeting it for the first time under the current edition. A.8.15 Logging is different: it requires that activity records are produced, protected and retained. A.8.17 Clock synchronization keeps those records comparable across systems. Monitoring sits on top of both, and an auditor will look for the link between them, not treat each control as a separate box.

Audits usually fail A.8.16 on three points. The first is scope: the organization cannot show which assets, data flows and cloud accounts are monitored, or why others are excluded. The second is baselines: there is no documented description of normal behavior for key systems, so nobody can say what anomalous looks like or whether a detection rule is tuned to the environment. The third, and the most common, is proof of review. A monitoring platform that generates alerts but has no record of who triaged them, what was decided and which alerts were escalated gives the assessor nothing to test. Before any assessment, confirm which systems are in monitoring scope and why, document a baseline for each, and check that the review and escalation steps leave a trail that someone outside the team can follow.

Which systems, data and teams A.8.16 monitoring covers

Monitoring under A.8.16 is only as complete as its scope. The decisions below determine which events reach the monitoring platform, who must act on them, and what evidence an assessor will ask to see. Each scope choice must match the ISMS scope and the Statement of Applicability, or the monitoring control will not line up with the rest of the certification.

Production, identity and control planes

Start with the systems whose compromise would hurt most: production workloads, directory services, single sign-on, and the administrative consoles of cloud accounts and hypervisors. Identity and cloud control plane events (sign-ins, role changes, policy edits) are often the first sign of an intrusion, so they belong in scope even when the workloads behind them are small. Check that each in-scope system actually forwards events and that the list of sources can be produced for an auditor.

Applications that handle sensitive data

Applications that store or process personal, financial or other sensitive information need monitoring of authentication failures, privilege use, bulk data access and configuration changes. Application logs differ from host logs, so confirm that each application writes security-relevant events and that someone has defined which events trigger an alert. A reasonable test is whether a reviewer could detect a single account exporting an unusual volume of records.

Network devices and endpoints

Firewalls, VPN gateways, load balancers and user endpoints show traffic patterns and malware activity that application logs miss. Endpoints are usually the largest source of volume, so decide which event types are worth retaining and which are noise. Document the decision, because an assessor will expect to see why some devices or event types were excluded from monitoring.

Third-party and cloud services that send events

SaaS platforms and managed cloud services often hold your data and produce audit trails you do not host. Decide whether each provider's logs reach your monitoring platform, which provider is responsible for retention, and how you obtain the records when an investigation starts. Confirm these terms in the supplier contract and the provider's documentation, since export options and retention periods differ between services.

Teams who own alert response

A monitoring control fails if alerts reach no one with the authority to act. Name the team that triages alerts, the escalation path to incident response, and the out-of-hours cover for each in-scope system. Responsibility should map to the incident management and event assessment controls, so that an alert can be traced from detection to decision. Record who reviewed which alerts and when.

How an assessor tests A.8.16 monitoring activities

This table walks through each area an assessor examines for A.8.16, from the monitoring scope through alert handling and incident linkage. Read each row as a question the assessor will ask, the records they will request, and the gaps that most often produce findings. The main takeaway is that configured monitoring alone does not pass: the assessor needs proof that someone looked at what was detected and acted on it.

Test area	What the assessor does	Evidence requested	Common findings
Monitoring scope against the ISMS scope	Compares the systems, networks, cloud accounts and applications inside the certified ISMS scope with the list of systems that feed monitoring tools.	Scope statement, asset inventory, data source list showing which hosts, network devices and cloud services send events to monitoring.	In-scope systems missing from monitoring, such as a cloud account or a SaaS admin console never onboarded.
Definition of anomalous behavior and baselines	Checks that the organization defined what counts as anomalous for its environment and how normal activity was established.	Written monitoring requirements, baseline reports or documented thresholds, and records of when baselines were last reviewed.	Default vendor rules deployed without any documented tuning or link to the organization's own risk assessment.
Alert configuration and coverage of key systems	Reviews detection rules, thresholds and alert routing for critical systems, including administrator and privileged activity.	Rule or detector exports, alert routing configuration, and a mapping of key systems to the rules that apply to them.	Rules exist but are disabled, or alerts route to a mailbox nobody monitors after staff changes.
Evidence that alerts are triaged	Samples alerts over the audit period and follows each one to a recorded disposition, such as closed as benign or escalated.	Alert queue history, triage tickets or case records with timestamps, owners and dispositions for the sampled alerts.	Alerts accumulate unreviewed, or dispositions are recorded without any reasoning or reviewer name.
Escalation and response	Traces sampled alerts that were escalated to confirm the escalation path was followed and the outcome was recorded.	Escalation procedure, on-call or duty roster for the period, and records showing notification and resolution times.	Escalation procedure exists on paper, but the on-call roster in force during the period is missing or outdated.
Linkage to incident management (A.5.24 and A.5.25)	Checks that monitoring findings feed the incident process and that events are assessed and decided upon as information security events.	Incident register entries traceable to monitoring alerts, event assessment records and the criteria used to decide incident status.	Monitoring and incident tools are not connected, so confirmed events never reach the incident register.
Monitoring of the monitoring	Verifies that the monitoring platform itself is protected, healthy and not silently failing, including logging of changes to its rules.	Health or heartbeat records for log sources, change records for detection rules, and access controls on the monitoring console.	Log sources stop sending for weeks with no alert, and nobody notices the gap until the audit.
Periodic review of monitoring effectiveness	Looks for evidence that the organization reviews whether monitoring still matches its scope, threats and recent incidents.	Review minutes or management review inputs, tuning change records and updates after significant incidents or system changes.	Monitoring rules unchanged for the whole cycle despite new systems, new cloud services or new incidents.

Implementing A.8.16 monitoring step by step

This sequence turns A.8.16 from a policy statement into a working monitoring service with a defined scope, known normal behavior, tested detection rules, named owners for alerts and a record of every review decision that an assessor can follow.

Define monitoring scope from the asset inventory
Start from the asset inventory maintained under the asset management controls and mark which systems, networks, cloud accounts and applications produce security-relevant activity that must be watched. Record the systems in scope, the systems excluded and the reason for each exclusion, and have the control owner approve the list. The output is a scope statement that names each monitored system class, its owner and the log or telemetry source it produces. The step is complete when every in-scope asset maps to at least one telemetry source and the scope statement is signed off.
Establish baselines of normal activity
For each system class in the scope statement, document what normal looks like: typical login times and sources, administrator activity, data transfer volumes, service accounts, scheduled jobs and expected network flows. Engineering and operations staff usually provide this knowledge, and the security team validates it against a sample of recent records. The output is a baseline record per system class, with the date it was captured and the person who reviewed it. Baselines are reviewed whenever the system changes materially, so the record should state when it must be refreshed.
Select detection sources and rules
Choose the detection sources that feed the monitoring platform, such as host, network, identity and cloud logs, and select the detection rules that match the threats relevant to each system class. Open-source options such as Wazuh and OpenSearch Security Analytics ship with rule libraries that can be extended with custom rules, and each rule should be traced to the baseline or threat it addresses. Confirm each platform's current rule library and supported log types with the vendor before committing to a design. The output is a versioned rule set with a rationale for each rule, and the check is that every telemetry source in scope has at least one active rule.
Set alert routing and ownership
Decide which alerts go to which people, how severity maps to response times and which channel carries each alert, such as a ticketing queue, a chat channel or email. Assign a named owner for each system class and a backup for out-of-hours coverage, and define when an alert becomes a security event that feeds incident management under the incident planning and assessment controls. The output is a routing matrix showing rule group, severity, recipient, channel and escalation path. Test the routing with sample alerts and record the result, because an alert that reaches nobody does not satisfy the control.
Run a documented review and tuning cycle
On a schedule set in the monitoring procedure, the owners review alert volumes, false positives, missed detections and changes to the baseline, then adjust rules and routing. Every change, including every decision to suppress, exclude or downgrade an alert, is written into a review log with the date, the requester, the reason and the approver. An assessor will ask why a particular alert was suppressed, so the log must answer that question for any entry. The output is a review log that shows the cycle ran and that tuning decisions were made deliberately, with evidence that changes flowed back into the baseline and rule set.

Evidence that passes an A.8.16 audit

An auditor testing A.8.16 Monitoring activities looks for a traceable chain: what is monitored, what normal looks like, which detections run, what they produced, and what the organization did about it. The six artifacts below link those steps, and each one needs a routine update so the record stays true between audits.

Monitoring scope and asset coverage record

A register stating which systems, networks, cloud accounts and applications feed the monitoring platform, which are excluded, and why. Assessors compare it against the asset inventory to find sources that exist but send no events. Keep it current by reconciling it against asset changes at each review and recording the reason for every exclusion. Confirm with your own asset owners which sources are in scope before the first sample.

Documented baselines and anomaly definitions

The written description of normal activity for key systems, such as typical login times, data transfer volumes and privileged actions, and the thresholds that make a deviation worth investigating. Without it, an auditor cannot judge whether alerts are sensible. Update the baseline after significant changes to a system, and keep dated versions so you can show what was in force when an event occurred.

Detection rule inventory with change history

A list of every detection rule, decoder and correlation rule in use, with its owner, purpose, log source and severity. Platforms such as Wazuh ship large built-in rulesets, and OpenSearch Security Analytics uses Sigma rules, so the inventory must show which rules are vendor-supplied and which are custom. Tie each change to a ticket that records the reason, approver and test result.

Alert and finding records with triage outcome

Each alert or finding should carry a timestamp, source, rule, severity and a recorded disposition such as closed as benign, escalated or confirmed. Assessors sample these records to see whether alerts were actually reviewed rather than left to accumulate. Confirm that your platform retains alert records for the period your policy sets, and that every alert in the sample has a named reviewer and an outcome.

Review and tuning records

Evidence that people periodically review monitoring performance: which rules fired most, which produced false positives, which were disabled or adjusted, and which gaps were found. A review log with a named reviewer, a date and the decisions taken shows the control is operating, not just configured. Set the review frequency in your own policy and keep the log consistent with it, since an auditor will check that the stated cadence was followed.

Escalation records linking alerts to incidents

Records showing that a confirmed anomaly moved into the incident process, with a reference from the alert to the incident ticket and then to the outcome. This links A.8.16 to A.5.24 and A.5.25, where events are assessed and decided. Test the chain by picking an incident and tracing it back to the alert that started it, then confirm the link exists in both directions.

What meeting A.8.16 monitoring costs in money and effort

This table breaks down the cost and effort components of running A.8.16 monitoring, who is paid for each one, whether it recurs, and what drives it up or down. No fee figures were available for this page, so use the last column to build the written breakdown you request from any implementer, platform vendor or auditor. For self-hosted open-source platforms, the main shift is from license spend to infrastructure and staff time.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Monitoring platform licenses or self-hosted infrastructure	Infrastructure is recurring; setup is one-time	Event volume, retention period, number of hosts and cloud accounts, high availability design. Self-hosted tools such as Wazuh and OpenSearch remove per-seat license fees but add servers, storage and patching	Itemized list of compute, storage, backup and network costs, plus any commercial license or support tier and who pays for each
Scope and baseline work	One-time, with periodic review	Number of systems in the ISMS scope, how many business-critical applications need behavioral baselines, how much normal activity must be documented first	Named deliverables for the asset inventory, scope statement and baseline report, with the number of workshops and reviewers included
Engineering time to onboard log sources and write rules	One-time for initial sources, recurring for each new system	Number of log sources, vendor format quirks, custom decoders, and whether prepackaged rules such as Sigma rules or ruleset content are tuned or written from scratch	Count of log sources in scope, a per-source effort estimate, and whether rule tuning after the first month is included
Analyst time for triage and review	Recurring	Alert volume, false positive rate after tuning, shift coverage, and how fast alerts must be closed. Tuning rules early reduces this	Expected alert volume assumptions, triage roles, response times the implementer will commit to in writing, and who owns escalation
Evidence upkeep	Recurring	How often reviews are recorded, whether alert records and review sign-offs are exported automatically, and how many periods the auditor samples	Evidence calendar showing what is produced each month or quarter, where it is stored, and who signs off each review
External testing or review of detection coverage	Recurring or periodic	Number of attack scenarios tested, whether tests run against production or a lab, and whether results feed back into rule changes	Test scope, method, number of test cycles per year, report format and remediation support, stated separately from any certification fee
Auditor sampling effort	Recurring with each audit cycle	Number of monitored systems in scope, number of sampled alerts and reviews the auditor selects, and how well records are organized before the visit	The certification body's audit day estimate and sampling approach, confirmed in writing before the audit plan is agreed

Open-source tools that produce A.8.16 evidence

A.8.16 asks for evidence that activity is monitored and that anomalies are acted on. The tools below generate the raw records, detections and audit trails that an assessor will sample. None of them decides what normal looks like, who reviews alerts or how incidents are handled; those remain the organization's responsibility.

OpenSearch Security Analytics

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match becomes a finding that records the rule, log type and severity, and alerts can go to Slack or email. The correlation engine links findings across log types in a correlation graph. Confirm the Apache-2.0 release you deploy, which log sources are onboarded, and that detector coverage matches the monitoring scope you documented. Findings are only evidence if someone reviews and closes them.

Wazuh ruleset and alerts

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write. Matching alerts are written to alerts.log and alerts.json and forwarded to the Wazuh indexer for review in the dashboard. Alerts are mapped to MITRE ATT&CK, which helps show coverage. Confirm the GPL-2.0-only version in use, which rules are disabled or tuned, and how alert files are retained. Disabled rules are gaps an assessor will ask about.

Nextcloud admin_audit log

The admin_audit app, shipped with Nextcloud under AGPL-3.0-only, records additional event information to audit.log in the data directory, or to a path set with logfile_audit. For A.8.16 this file is a source of administrator and user activity that you can forward to your monitoring platform. Confirm the app is enabled, the log path sits on protected storage, and that events you consider significant, such as permission changes and sharing, are actually captured in your version. Test that entries appear before you rely on them.

OpenBao audit devices

OpenBao audit devices write a detailed JSON log of every API request and response, including errors, under MPL-2.0. Most sensitive values are hashed with HMAC-SHA256 so the log can show what happened without exposing secrets. This gives you a complete record of secret and key access to feed into detection. Confirm at least one audit device is enabled, that the device cannot fail silently in a way that blocks requests without your knowledge, and that logs are shipped to storage outside the Vault host. A disabled audit device is a gap that an assessor will test.

Who owns A.8.16: your team, a partner and the auditor

Your organization owns A.8.16. The control is about what you decide to watch, who responds, and whether the monitoring still fits your risks, so those decisions cannot be handed to a vendor or a partner. Your security and operations staff set the scope of monitored systems, approve the baselines of normal behavior, and decide what counts as an anomaly worth an alert. They also own triage, escalation and the periodic review that shows the monitoring is working.

Scope and baselines: Decide which hosts, network segments, cloud accounts and applications feed monitoring, and approve what normal activity looks like for each.
Alert ownership: Name an accountable owner and a backup for every alert channel, so no alert goes unassigned.
Triage and escalation: Define severity levels, response timeframes you can actually meet, and the handoff into incident management under A.5.25.
Review and tuning: Approve rule changes, suppressions and threshold adjustments, and record why each change was made.
Periodic review: Schedule and sign off reviews of monitoring coverage and of alerts that were closed without action.

Before an audit, check that each decision above has a named person, a dated record and a documented reason.

Common gaps that fail A.8.16 and how to close them

Most A.8.16 findings are not about missing tools. They come from monitoring that was set up once and never owned, tuned or connected to incident handling. The cards below pair each common gap with a closing action that one named person can assign and an assessor can check.

Sources collected but not monitored

Logs from endpoints, identity providers and firewalls reach the SIEM, but no detector or rule evaluates them. An assessor will ask which sources feed which detectors and what they produced last quarter. Close it with a source-to-rule matrix that lists each ingested log type, the detector or ruleset that reads it, and the person who reviews its findings. Any source without a matching rule is either given one or removed from scope with a recorded reason.

No documented baseline

Teams cannot say what normal looks like, so alerts are either noisy or silent. A.8.16 expects anomalous behavior to be detectable against something, so the organization needs written baselines for authentication volumes, privileged activity, outbound traffic and batch jobs. Assign an engineer to capture two to four weeks of normal activity per system class, record the thresholds in the monitoring standard, and review them at each change to the environment.

Alerts with no named owner

Alerts reach a shared mailbox or channel that everyone can see and nobody acts on. Ownership is the first thing an assessor checks when reviewing alert handling. Name a primary and a backup owner for every detector, define the response time expected from each, and record who triaged each alert and what they decided. A weekly review of unacknowledged alerts, with the reviewer's name on the record, shows the control operating.

Suppressed rules without recorded reasons

Rules get muted during tuning, sometimes permanently, and the suppression leaves no trace. A silenced rule can hide the exact activity the control exists to catch. Require a ticket for every suppression that states the rule, the reason, the scope, the approver and an expiry date. Export the suppression list each quarter and check that every entry still has a valid reason. Rules disabled without a ticket should be treated as a finding.

No link between alerts and incident records

A detector fires, someone investigates, and the outcome lives only in chat. A.5.25 and A.5.24 expect events to be assessed and fed into incident handling, so an auditor will trace a sample of alerts into tickets. Configure the case or ticketing workflow so each alert that is escalated gets an incident identifier, and each incident references the alerts and the decision made. Closing an alert as a false positive should still require a recorded rationale.

Cloud and SaaS sources missing from scope

Monitoring covers the data center and the core network, but cloud accounts, identity-as-a-service, email and business SaaS applications are not connected. These sources often hold the most sensitive activity. Build an inventory of cloud accounts, subscriptions and SaaS tenants, confirm which audit logs each one can export, and add them to the monitoring scope document. Ask the vendor or cloud provider to confirm the log types and retention each service offers, since these vary by product.

Questions buyers ask about A.8.16 monitoring

How much effort does A.8.16 take for a small team?

The effort depends on how many systems and cloud accounts are in scope, how many log sources they produce, and how much alert triage the team can absorb. A small team with a few cloud accounts and a handful of production services usually needs a named owner for monitoring, a short list of detection use cases, and a recurring review of alerts and their outcomes. The work is mostly ongoing rather than a one-time build. Ask any provider to break the effort into initial setup, rule tuning, alert handling and periodic review, and to state which of those the organization must staff itself. No duration is supplied for this work, so treat any figure you hear as something to verify against your own environment.

Are open-source tools enough to meet A.8.16?

Open-source tools can run the technical side of monitoring, but the standard asks for an organization-defined process, not a particular product. A platform such as Wazuh or OpenSearch Security Analytics can collect events, match them against rules and raise alerts. The organization still has to decide what is monitored, what counts as anomalous, who reviews alerts, and how findings lead to action. Confirm with your certification body how it expects you to evidence that process, and confirm that the tool you choose supports the log sources and alert channels you need.

What must our own staff do for A.8.16?

Several parts of A.8.16 cannot be handed to a tool or a partner. Your organization must decide the scope of monitoring, define the baselines against which normal behavior is judged, and assign people to review alerts and act on them. Management must also approve the approach and keep records of reviews, tuning decisions and incidents raised from monitoring. An implementation partner can build and document these steps, but the organization owns the controls and must be able to explain them to an auditor.

Can an implementation partner run monitoring for us?

An implementation partner can plan, deploy, configure and document a self-hosted monitoring stack inside your own cloud accounts, data center or air-gapped network, and it can prepare the evidence an assessor will ask for. DeployOpen works this way: it prepares systems, controls and evidence but does not issue audit reports or certifications, and it works to a fixed scope agreed in writing. Ongoing alert triage and continuous monitoring can be arranged as a retainer if your scope needs it. Be clear about who is accountable for alert decisions before signing, because the organization keeps responsibility for the control.

How long does A.8.16 preparation take?

Preparation time depends on the scope and the environment. The main drivers are the number of systems, cloud accounts and network segments in scope, how much logging already exists, how mature your incident and alert processes are, and whether monitoring must cover customer-facing services or regulated data. No duration is supplied for this work. Ask any provider for a timeline that is tied to a written scope, and ask which steps depend on your own staff's availability, such as approving baselines or reviewing alerts.

How does A.8.16 differ from A.8.15 logging?

A.8.15 Logging asks you to produce, protect and analyze logs of activities, exceptions and faults. A.8.16 Monitoring Activities builds on those logs by asking you to watch networks, systems and applications for anomalous behavior and to act on what you find. In practice, logging is the evidence base and monitoring is the detection and response loop on top of it. An organization can have excellent logs and still fail A.8.16 if nobody reviews them or acts on alerts, and a monitoring tool cannot satisfy A.8.15 without retaining and protecting the underlying logs. Both controls are closely related to A.8.17 clock synchronization, which keeps events comparable across systems.

How DeployOpen scopes and evidences A.8.16

DeployOpen plans, implements and documents the self-hosted monitoring platforms that run A.8.16 inside your own infrastructure, so your team can show what is watched, what is alerted and how alerts were acted on. Your organization owns the control, and an independent certification body decides whether the evidence meets the standard.

How we scope

Engagements are fixed-scope, with the systems to monitor, log sources and alert channels agreed in writing before work starts.
The written scope names which networks, hosts, applications and cloud services fall inside the monitoring boundary for the ISMS.
Scope also records who reviews alerts, how often, and which events must be escalated under A.5.25 and A.5.24.

How we build

Deploy self-hosted detection components such as Wazuh or OpenSearch Security Analytics inside your cloud accounts, data centers or air-gapped networks.
Configure detectors and custom rules against the agreed log sources, and document baselines for normal behavior per system.
Connect alerts to ticketing and messaging channels, and test that each alert type reaches a named owner.

How we hand over

Deliver monitoring runbooks, rule inventories and alert review procedures that your staff can run without DeployOpen.
Provide evidence packs such as rule configurations, sample alert records, review logs and tuning change history for the auditor.
Walk your team through the Statement of Applicability entry for A.8.16 so the documented control matches the running system.

How we support

Ongoing support, upgrades and continuous testing of the monitoring stack are available as retainers.
Retainers can cover periodic rule tuning, baseline reviews and checks that alerts still fire after system changes.
Confirm with DeployOpen in your quote which evidence and review tasks recur each year and which are one-time setup work.