ISO 27001:2022 handles logging and monitoring mainly through three Annex A controls: 8.15 (logging), 8.16 (monitoring activities) and 8.17 (clock synchronization). Together they ask you to record security-relevant events, protect those records, watch your systems for abnormal behavior and keep timestamps trustworthy. Auditors do not want a tool name. They want proof that you decided what to log, that someone looks at it, and that you act on what they see.
This guide explains each control in plain terms, shows the evidence an auditor typically asks for, and gives a rollout order that works for a small security team in the US.
TL;DR
- Control 8.15 is about producing, protecting and reviewing logs. Control 8.16 is about actively watching for anomalies. Passing one does not pass the other.
- Define scope first: which systems, which events, who reviews, how often, and how long you keep records. Write it down, then show it running.
- Centralize logs and keep clocks aligned (8.17), or you cannot reconstruct an incident across systems.
- Separate duties where you can: the people who administer a system should not be the only ones reviewing its logs.
- Budget the effort early. Logging tooling and review time are real cost lines in an ISO 27001 project.
Table of Contents
- How the three controls fit together
- Control 8.15: logging that survives an audit
- Control 8.16: monitoring that catches something
- Control 8.17: the quiet one that breaks investigations
- Evidence an auditor will ask to see
- A rollout order that works
- Industry notes: finance and payment data
- Common mistakes
- Our perspective
- Estimate the effort before you commit
- FAQ
- Sources
How the three controls fit together
Think of a pipeline. Control 8.15 creates and protects the raw material. Control 8.17 makes the timestamps on that material comparable. Control 8.16 turns it into detection.
| Control | What it asks for | Typical evidence |
|---|---|---|
| 8.15 Logging | Produce, store, protect and analyze logs of activities, exceptions, faults and other relevant events | Logging standard, sample logs, retention settings, access restrictions on log stores |
| 8.16 Monitoring activities | Monitor networks, systems and applications for anomalous behavior and respond appropriately | Alert rules, review records, tickets opened from alerts, escalation path |
| 8.17 Clock synchronization | Keep clocks of information processing systems aligned to approved time sources | NTP configuration, a screenshot or export showing consistent time across systems |
A common audit finding is a company that logs everything but reviews nothing. Logs sitting in a bucket are evidence of 8.15 at best. As one way to remember it: logging answers “what happened,” monitoring answers “is something wrong right now.”
Control 8.15: logging that survives an audit
Start from risk, not from the tool. Your risk assessment should tell you which systems matter, and your logging standard should follow from that.
What to log
A defensible baseline covers:
- Authentication events: successful and failed logins, MFA changes, password resets.
- Privileged activity: admin actions, role changes, use of break-glass accounts.
- Access to sensitive data and changes to access rights.
- Changes to systems: configuration changes, new services, deployments.
- Security tool output: endpoint protection, firewall, intrusion detection, vulnerability scanner results.
- Faults and exceptions: failed backups, service crashes, unexpected shutdowns.
You do not have to log every system at the same depth. A customer database and a printer should not carry the same logging burden, and an auditor will expect to see that reasoning in your risk treatment.
Protect the logs themselves
Logs are only evidence if nobody can quietly edit them. Practical steps:
- Ship logs to a central store away from the system that generated them.
- Restrict write and delete rights to a small group, and log access to the log store.
- Use immutable or write-once storage for high-value logs where your platform supports it.
- Set a retention period that matches legal, contractual and investigative needs, and document why you chose it.
- Treat logs containing personal data as personal data: limit who sees them and avoid capturing more than you need.
Retention: choose, justify, apply
ISO 27001 does not hand you a number of days. You choose, based on your obligations. In the US that may include sector rules or customer contracts, so check what your own agreements say before settling on a period. Then apply it consistently. An auditor will compare your written policy with the actual settings on your log platform, and a mismatch is an easy nonconformity to avoid.
Control 8.16: monitoring that catches something
Monitoring is where many first-time implementers fall short. The control expects you to watch for anomalous behavior and to evaluate potential incidents. That needs defined use cases, an owner and a response path.
Start with a short list of alerts
Ten well-tuned alerts beat two hundred ignored ones. Good first candidates:
- Repeated failed logins followed by a success.
- A new account added to an administrator group.
- Login from an unusual country or impossible travel between locations.
- Disabling of endpoint protection or logging agents.
- Large outbound transfers from a sensitive system.
- Access to production data outside normal hours by someone who does not normally do it.
For each alert, write down who receives it, how fast they should look, and what counts as an incident. That last point links monitoring to your incident process. Our guide to the five incident controls auditors test shows how an alert turns into a recorded event and an assessed incident.
Make alerts usable for response
CISA’s lessons learned from an incident response engagement frames logging as a test of whether responders can use it. Generating an alert is not enough: the team needs to move from the alert into correlated identity, endpoint and cloud records to reconstruct events, which is where a centralized SIEM helps. You can borrow that test for your own program. Pick a recent alert and ask whether someone could, within an hour, trace the account involved across your identity provider, the affected laptop and your cloud console.
For teams that want a deeper architecture view, CISA’s Logging Reference Architecture describes logging that supports timely detection, threat hunting, incident response and forensics, not just collection and retention. It is written for federal agencies, but the principles transfer to private companies.
If you run custom applications, application-level monitoring matters too. This overview of application monitoring practices is a useful companion for engineers who need to connect error and performance monitoring with security alerts.
Independence of review
Separation of duties applies to monitoring. The FFIEC IT Examination Handbook, written for financial institutions, says staff who administer systems or security should not be the same people who monitor the activity logs of those systems. ISO 27001 is not a banking rule, but the logic is the same for any company: if the administrator can both act and review, misuse can go unseen.
Small teams often cannot fully separate these roles. In that case, document the compensating control. For example, a second person, a manager or an outsourced provider receives a periodic summary of privileged activity. The FFIEC guidance on managed security service providers describes event log management and alerting as a service that can be outsourced, which is one option for lean teams. If you do outsource, remember that supplier controls come into your scope; see our explanation of ISO 27001 supplier management.
Control 8.17: the quiet one that breaks investigations
Clock synchronization looks trivial until you try to line up a firewall log, a laptop log and a cloud audit trail that disagree by several minutes. Point systems at agreed time sources (usually NTP), standardize on one time zone for security logs (many teams choose UTC), and keep a record of the configuration. Include a check for drift. Auditors usually accept a screenshot or configuration export from a sample of systems.
Evidence an auditor will ask to see
Prepare a folder, physical or digital, with these items before the Stage 2 audit:
- Logging and monitoring policy or standard, approved by management.
- A list of log sources in scope, with owners.
- Retention settings, matched to the policy.
- Access list for the log platform, with a recent review.
- Alert rules and the reasoning behind them.
- Proof of review: dated review records, ticket exports or a monitoring dashboard report.
- At least one example where an alert led to an investigation, and its outcome.
- Time synchronization configuration for a sample of systems.
- Management review minutes that mention monitoring results.
Item 7 matters most. If you have had no real incident, run a tabletop or a test alert and record it. A control that has never fired is hard to prove.
A rollout order that works
Weeks 1 to 2: decide and document
List your critical systems from the asset register and risk assessment. Decide log sources, minimum events, retention and reviewers. Keep the policy short enough that people read it.
Weeks 3 to 6: collect and protect
Turn on audit logging in your identity provider, cloud accounts, endpoints and key SaaS tools. Forward them to one central location. Lock down access and fix clock settings.
Weeks 7 to 10: detect and respond
Build the first ten alerts, assign owners and test them. Connect them to your incident ticket workflow.
Ongoing: review and improve
Schedule a recurring review, feed findings into management review and adjust alert rules after every incident or near miss. For the wider schedule around this work, see our ISO 27001 implementation timeline. The sequence above is a planning example, not a fixed requirement. Your own pace depends on tooling, staff and the maturity you start with.
Industry notes: finance and payment data
Financial firms face extra expectations because regulators and examiners read logs as evidence of control. If you also handle card data, PCI DSS has its own logging requirements, and a single capability can often serve both programs. Our article on mapping PCI DSS v4.0.1 into ISO 27001 shows how to cut duplicate audit work. For breach scenarios, the data breach response guide for finance and the banking incident response guide show where logs feed the response.
Common mistakes
- Logging everything, reviewing nothing. Volume is not control. Scope what you can actually review.
- Keeping logs on the same host. An attacker with admin rights can erase them.
- Unwritten retention. Settings that differ from policy are an easy finding.
- No named owner for alerts. An alert sent to a shared inbox is often an alert nobody reads.
- Treating the SIEM as the control. The tool supports the control. The process of reviewing and responding is the control.
- Ignoring SaaS and cloud. Many incidents begin in an identity provider or a cloud console, not a server.
If you want a pattern for documenting how a vendor describes its own security practices, a page such as WorldEye’s security overview shows how a service can present its protective measures publicly. Use that kind of page as a prompt for what your own customers might ask about your log handling.
Our perspective
We build cost and effort estimates for ISO 27001 projects, and logging and monitoring is the line that surprises people most. The license for a log platform is rarely the big number. The time is: tuning alerts, writing the review routine, and having someone own it month after month. Teams that budget only for the tool end up with an expensive store of unread logs.
Our advice is to size this control by people-hours first. Ask how many systems you will connect, how many alerts someone can realistically triage per week, and whether you need an outside provider to cover nights and weekends. Then compare your figures with model reference comparisons, so you know whether you are planning too lean or too heavy. A first-time team in a regulated industry should expect to spend more here than a ten-person software startup, because the evidence bar and the number of systems are higher.
We also think auditors reward honesty. A small, working set of alerts with dated review records beats an ambitious design that exists only on a slide.
— Martin
Estimate the effort before you commit
If you are planning an audit and want to see how logging, monitoring and the other Annex A controls affect cost and timeline, try the ISO 27001 cost calculator. It gives estimates by company size, industry and security maturity, and you can start without signing up. Not sure where you stand? The free 2-minute readiness check gives a quick first read, and the full readiness assessment goes domain by domain. When you are building your full plan, the 80-step certification checklist helps you place logging work among the other tasks.
FAQ
Is logging mandatory for ISO 27001 certification?
Yes in practice. Annex A control 8.15 covers logging, and if you exclude it in your Statement of Applicability you need a solid justification, which is hard to give for any organization with IT systems. Auditors expect to see logs for the systems in your scope.
What is the difference between control 8.15 and 8.16?
Control 8.15 is about producing, protecting and analyzing logs. Control 8.16 is about monitoring networks, systems and applications for abnormal behavior and responding. You need both: the first gives you the record, the second gives you detection.
Do I need a SIEM to meet ISO 27001?
The standard does not name a tool. A SIEM or a managed detection service makes correlation and review much easier, and CISA’s guidance points to centralized correlation as helpful for response. A smaller company can meet the controls with centralized logs, a few reliable alerts and documented reviews.
How long should I keep logs?
ISO 27001 sets no fixed period. Choose a retention time based on legal duties, customer contracts and how long you need to investigate incidents, write it in your policy and make your platform settings match it.
Can one logging setup satisfy both ISO 27001 and PCI DSS?
Often yes, when it is designed with both in mind, since both ask for logged and reviewed activity. Map the requirements side by side and confirm the details with your assessor. Our PCI DSS and ISO 27001 mapping article explains the approach.
Sources
- CISA: lessons learned from an incident response engagement
- CISA: Logging Reference Architecture
- FFIEC IT Handbook: computer and network operations supporting funds transfer
- FFIEC IT Handbook: managed security service providers