Logging and monitoring for ISO 27001 (A.8.15 and A.8.16)
Logging means your systems automatically record who did what and when. Monitoring means you actively review that data so you spot unusual behaviour in time. In ISO/IEC 27001:2022 these are two separate controls from Annex A: A.8.15 “Logging” and A.8.16 “Monitoring activities”. A.8.16 is new in the 2022 version.
The NCSC (Netherlands National Cyber Security Centre) stresses that without log information you cannot find out what happened after a cyberattack. Logging is therefore the foundation of your incident management. In healthcare, stricter rules apply to logging access to patient records under NEN 7513.
Short answer: for ISO 27001 A.8.15 you record which events you log, protect the logs against changes and keep them as long as your risks require. For A.8.16 you actively review those logs for deviations and follow up on alerts. The standard does not set a fixed retention period. You choose that yourself and justify it.
What is the difference between A.8.15 and A.8.16?
The two controls are often mentioned together, but they ask for different things. Logging is recording. Monitoring is looking and acting.
| A.8.15 Logging | A.8.16 Monitoring activities | |
|---|---|---|
| Purpose | Keep traces for investigation and accountability | Detect attacks and deviations in time |
| What you do | Switch on logs, store them centrally, protect them | Set up alert rules, assess notifications |
| Evidence | Log overview, settings, retention periods | Overview of alerts and follow-up |
| Key question for the auditor | Can you see afterwards what happened? | Would you notice now if something went wrong? |
A.8.17 “Clock synchronisation” belongs here too. If the clocks of your systems do not match, you cannot link logs from different systems to each other.
What should you log for ISO 27001?
ISO 27002:2022 gives examples of events you should log. In practice they come down to: who signs in, who changes access rights or settings, who accesses sensitive data, and what the security systems themselves do.
A useful log entry contains at least six elements. The Dutch government has made these mandatory in BIO2 (Baseline Information Security Government, the Dutch government standard), and the list is a good benchmark outside government too:
| Element | Meaning | Example |
|---|---|---|
| Actor | Who or which process started the action | j.devries@bedrijf.nl |
| Action | What happened | Admin rights granted |
| Object | What the action affected | Account p.jansen@bedrijf.nl |
| Result | Succeeded or failed | Succeeded |
| Origin | From which device or network | IP 203.0.113.24, laptop LT-0412 |
| Timestamp | Date and time, synchronised | 2026-05-12 14:03:51 CEST |
Do not log passwords or other data that would let someone bypass security. Also remember that logs contain personal data themselves. They show what employees do.
Example log overview for ISO 27001
Start with an overview of which systems log what, where the logs are stored and how long you keep them. This example is for a SaaS company with 25 employees.
| Source | What is logged | Storage | Retention period | Monitoring |
|---|---|---|---|---|
| Identity platform (Entra ID) | Sign-ins, MFA, changes to roles | Central log storage | 1 year | Alert on sign-in from an unusual country or a spike in failed attempts |
| Microsoft 365 | Audit log: mail forwarding, file sharing | Central log storage | 1 year | Alert on a new forwarding rule to an external address |
| Production platform | Admin actions, database exports | Central log storage, immutable | 2 years | Alert on an export larger than 10,000 records |
| Firewall and VPN | Connections, blocked traffic | Central log storage | 6 months | Weekly review of top deviations |
| Endpoint security | Malware detections, disabled protection | Vendor console | 90 days | Immediate notification to IT on detection |
| Backup system | Successful and failed backups | Backup console | 1 year | Daily report |
The figures are choices, not requirements of the standard. Why one year and not three months? Because attackers are sometimes inside for months before you notice. Record that trade-off in your risk assessment.
How long must you keep logs for ISO 27001?
ISO 27001 does not set a period. You weigh two interests. Keeping logs for a long time helps investigate incidents that are discovered late. Keeping them short fits the GDPR (AVG, the Dutch name for the GDPR) better, because logs contain personal data. The NCSC points to the same trade-off.
Some sectors have a legal minimum. In healthcare you keep logs of access to patient records for at least five years, see NEN 7513. Government organisations set their retention period under BIO2 based on risk, with the scenario that an attacker has been inside for a long time without being detected.
Set up monitoring without your own SOC
A Security Operations Center (SOC) is a team that watches logs day and night. For most small and medium-sized businesses that is too much. You can also implement A.8.16 on a smaller scale:
- Start with the built-in alerts of your cloud platform, such as suspicious sign-ins or mass deletion of files.
- Set up no more than ten rules that really matter, and assign one person to follow up on each rule.
- Outsource it to a managed detection service if you have no capacity of your own. The NCSC explicitly lists this as an option.
- Record the follow-up. Each alert gets a short note: false alarm, or escalated as an incident.
What does the auditor ask for as evidence for A.8.15 and A.8.16?
During the ISO 27001 audit you can expect these requests:
- The log overview with sources, storage and retention periods.
- A live example: “Show who received admin rights yesterday.”
- How logs are protected against changes or deletion, including by administrators.
- A list of recent alerts and how they were followed up.
- How the clocks of systems are synchronised.
The most common finding: logging is switched on, but nobody looks at it. If you cannot show a single alert that was followed up, you do not meet A.8.16.
Common mistakes with logging and monitoring
Logging is off by default. Many systems do not log by themselves, or only keep logs for a few days. Check every source.
Administrators can delete their own traces. Store logs in a separate environment where the same administrators have no write access.
Logging everything and finding nothing. More data is not better. Choose what you need to answer the questions from your risk assessment.
Forgetting SaaS. With cloud services, the logs sit with the vendor. Record in your supplier management which logs you can request and how long they exist.
Frequently asked questions about logging and monitoring
Is a SIEM required for ISO 27001?
No. A SIEM (Security Information and Event Management) is software that collects and analyses logs centrally. It helps, but you can also meet A.8.15 and A.8.16 with the built-in logging and alerts of your cloud platform.
Must I inform the works council about logging?
Logging employee activity affects privacy. If you have a Dutch works council (ondernemingsraad), consult it about the purpose of the logging and who may view the logs. Record that in your logging policy.
How often should I review logs?
Follow up on alerts as soon as they come in. In addition, a periodic review makes sense, for example weekly for admin actions. Record the frequency and keep a record that the review took place.
More information
- Annex A: all 93 controls, including A.8.15 to A.8.17
- Incident management: from alert to resolved incident
- Vulnerability management and patching: the other basic technical control
- NEN 7513 logging: logging requirements in healthcare
- Access rights matrix: who may do what, so you can spot deviations
- ISO 27002:2022 : the implementation guidance for A.8.15 and A.8.16