ISO 27001 and SOC 2 Logging and Monitoring Requirements: What Auditors Actually Ask For
Logging is where a lot of ISO 27001 and SOC 2 projects quietly come unstuck. The policy says logs are retained and reviewed. The auditor asks to see a month of review records, and there are none. Nobody was dishonest. The control was written, the tooling was bought, and then nobody owned the weekly half hour it needed.
This article covers what the two frameworks actually ask for, where they overlap, and what evidence an auditor will want in front of them. It is written for Australian organisations in the 20 to 500 employee range, which is where we do most of our certification work.
What ISO 27001 requires
ISO 27001:2022 handles logging and monitoring across a small group of Annex A controls:
- A.8.15 Logging. Logs recording activities, exceptions, faults and other relevant events are produced, stored, protected and analysed.
- A.8.16 Monitoring activities. Networks, systems and applications are monitored for anomalous behaviour, and appropriate action is taken to evaluate potential incidents.
- A.8.17 Clock synchronisation. Clocks are synchronised to approved time sources. This one looks trivial until you try to reconstruct an incident from three systems whose timestamps disagree.
- A.6.8 Information security event reporting. People have a way to report events they notice, and they know what it is.
- A.5.25 and A.5.26. Assessing and deciding on security events, and responding to incidents.
The important word in ISO 27001 A.8.15 is analysed. Collecting logs is not the control. A log store nobody looks at satisfies the first half of the sentence and fails the second, and that is the single most common finding we see on logging.
A.8.16 is also broader than people expect. It says networks, systems and applications. If your product is a SaaS platform, application-level events (failed logins, permission changes, bulk exports, admin actions) are in scope, not just the infrastructure underneath.
What SOC 2 requires
SOC 2 does not have an Annex A. It has the Trust Services Criteria, and logging and monitoring sits mostly in the CC7 series:
- CC7.1. Detection of configuration changes and new vulnerabilities, including the infrastructure and software in scope.
- CC7.2. Monitoring system components for anomalies that indicate malicious acts, natural disasters and errors, and analysing them to determine whether they represent a security event.
- CC7.3. Evaluating security events to determine whether they could or did result in a failure to meet objectives, and if so, acting.
- CC7.4. Responding to identified security incidents through a defined programme.
- CC7.5. Identifying, developing and implementing activities to recover from incidents.
CC4.1 and CC4.2 also matter, because they cover the monitoring of the control environment itself and the communication of deficiencies.
The practical difference between the frameworks is not what they want, it is how they test it. ISO certification auditors sample. A SOC 2 Type 2 auditor tests the operation of the control across the whole observation window, typically three to twelve months. If your log reviews stopped for six weeks in the middle of the period, a Type 2 will find it and a Type 1 will not.
Where the two overlap
Almost entirely. If you build one logging and monitoring capability properly, you can evidence it against both frameworks with the same artefacts. The mapping is roughly:
| What you build | ISO 27001 | SOC 2 |
|---|---|---|
| Centralised log collection | A.8.15 | CC7.2 |
| Alerting on defined conditions | A.8.16 | CC7.2 |
| Documented triage and escalation | A.5.25, A.5.26 | CC7.3, CC7.4 |
| Retention and tamper protection | A.8.15 | CC7.2, CC6.1 |
| Time synchronisation | A.8.17 | CC7.2 |
| Internal event reporting channel | A.6.8 | CC2.2, CC7.3 |
This is why we push clients to design the control once rather than run two parallel compliance exercises. The duplication is in the reporting, not the engineering.
Do you need a SIEM?
Not necessarily, and the honest answer depends on your size and the scope of your certification.
A SIEM platform such as Microsoft Sentinel, Splunk, Sumo Logic, Elastic or IBM QRadar gives you correlation across sources, retention, and a reporting surface that makes audit evidence easy to produce. For an organisation with a real production environment, multiple cloud accounts and a product that holds customer data, that is usually the right answer, and Sentinel in particular is hard to argue with if you are already on Microsoft 365 E5.
For a 25 person company whose entire scope is Microsoft 365, one AWS account and a single SaaS product, a full SIEM is often more tool than the control needs. What the auditor wants is logs that are collected centrally, retained for a defined period, protected from the people who could be the subject of them, reviewed on a defined cadence, and alerting on the conditions you said you would alert on. Native cloud logging plus Microsoft 365 audit logs plus a documented review routine can satisfy both frameworks.
What does not satisfy either framework is logging that only exists on the box that generated it, because an attacker with that box can edit it, and you cannot correlate anything.
What auditors actually ask to see
In our experience of Australian ISO 27001 and SOC 2 audits, these are the requests that come up:
- A list of in-scope log sources, and the justification for anything excluded. If you left something out, say why in advance rather than being asked.
- Retention configuration, shown in the tool. Not the policy saying twelve months. The setting.
- Evidence of review. Dated records showing who reviewed what and what they concluded, including the weeks where the conclusion was “nothing of note”. Those records are the control.
- A list of configured alerts, and the rationale. Why those conditions and not others.
- A walkthrough of one real alert from trigger to closure. This is the question that separates organisations that operate the control from organisations that documented it. If you have never had an alert fire, that is itself a finding, because it usually means the thresholds are wrong.
- Access controls on the log platform. Who can delete or modify logs, and why that list is as short as it is.
- Clock source configuration. Quick to show, awkward to be missing.
The failure modes we see most
Nobody owns the review. The fix is a named person, a calendar entry, and a template that takes ten minutes to fill in. Compliance that depends on someone remembering is compliance that lapses.
Alert fatigue, then alert silence. A deployment that fires forty alerts a day gets muted within a fortnight. Start with a small number of high-confidence detections and add to them.
Logs that stop at the infrastructure boundary. Application and SaaS administrative events are in scope and are frequently missed, particularly Microsoft 365 and identity provider audit logs.
Retention set to the tool default. Many defaults are 30 or 90 days. If your incident response plan assumes you can investigate something from last quarter, those do not agree with each other.
A gap in the SOC 2 observation window. Hire a contractor, change tools, go on leave, and six weeks of evidence disappears. Decide who covers the review when the owner is away, and write it down.
Australian considerations
Two things to keep in view beyond the frameworks themselves.
The Notifiable Data Breaches scheme under the Privacy Act 1988 requires you to assess a suspected eligible data breach within 30 days and notify the OAIC and affected individuals if it is one. That assessment is almost impossible to do credibly without logs. Organisations that cannot determine what was accessed tend to end up notifying more broadly than they needed to, because they cannot rule anything out.
If you are working toward the ASD Essential Eight as well, note that it treats event log monitoring as a separate concern from the eight mitigation strategies, with central retention and analysis appearing at higher maturity levels. An ISO 27001 or SOC 2 logging capability built properly will carry a lot of that work for you.
APRA-regulated entities have their own requirements under CPS 234 that sit on top of all of this.
Getting it in place
If you are starting from nothing, the order that works is: decide scope, turn on collection centrally, set retention deliberately, lock down access to the log platform, define a small set of alerts, then write the review routine and actually run it for a month before you book the audit. The last step is the one organisations skip, and it is the one that produces the evidence.
Our CERTIFY compliance package covers this as part of getting an organisation to ISO 27001 or SOC 2 certification, including the control design, the evidence set and the audit preparation. If you would rather test what you already have, a penetration test will tell you quickly whether your monitoring notices someone working inside your environment, which is a more useful answer than a policy review.
Siege Cyber’s CERTIFY packages take Australian businesses from gap analysis to certification with a fixed scope and a fixed price, for both ISO 27001 and SOC 2. Get a Fixed-Price Quote.