Dana Whitfield found out about the breach from a journalist.
Dana was VP of Engineering at Larkspur Health Analytics, a 340-person healthtech company in Columbus that processed claims data for a dozen regional insurers. On a Tuesday morning in March, a reporter from a healthcare trade publication emailed asking for comment on "the Larkspur patient data appearing for sale on a dark web forum." Dana had never heard of it. Neither had the CISO. Neither, as it turned out, had anyone else at the company — despite the fact that the attacker had been inside Larkspur's network for ninety-four days.
The forensic timeline, reconstructed three weeks later at a cost north of $600,000 in incident response fees, was almost embarrassing in its simplicity. A contractor's VPN credentials were phished in December. The attacker logged in from an unfamiliar country, at an unusual hour, using a device that had never been seen on that account before — three textbook indicators, all captured cleanly in the VPN concentrator's logs. Over the following weeks the attacker moved laterally, authenticated against a domain controller using a dormant service account that hadn't logged in for eleven months, and began querying a claims database in patterns no legitimate application ever used. Every one of those events was logged. None of them was reviewed. Larkspur had turned on logging because a prior audit had flagged its absence — but nobody had built a way to look at the logs, and nobody had asked what "normal" looked like so that "abnormal" would stand out.
By the time Larkspur's outsourced IT provider noticed unusual outbound data volume — accidentally, while investigating a bandwidth complaint from a different department — 1.8 million patient records had already left the building. The final bill: $2.6 million in breach notification and credit monitoring, $900,000 in regulatory penalties and legal fees, a $400,000 client contract cancellation, and an unquantifiable dent in Larkspur's ability to win new business in a market where prospective clients now asked pointed questions about security in every sales call. Call it $4.2 million, conservatively, for a breach that the organization's own logs had recorded, in real time, from day one.
This is the story ISO 27001 Controls 8.15 (Logging) and 8.16 (Monitoring activities) exist to prevent. Logging without monitoring is a black box recorder nobody ever plays back after the crash. Monitoring without logging is watching a blank screen. Together, they are the backbone of detection — the pair of controls that determines whether an information security incident is caught in minutes or discovered, as Larkspur's was, from a stranger's email.
Who this is for
This article is written for the person who owns detection: a CISO, security engineering lead, SOC manager, or IT director building or maturing logging and monitoring for an ISO 27001 certification effort, an internal audit finding, or simply because leadership finally asked "how would we know if we'd been breached?" You should already have a rough inventory of your systems (informed by asset management under ISO 27001) and a sense of your incident response process. What you'll walk away with is a concrete logging standard (what to log, how to protect it, how long to keep it), a monitoring and alerting approach that doesn't drown your team in noise, and the specific evidence an ISO 27001 auditor will want to see for both controls.
Controls 8.15 and 8.16 at a glance
Both controls sit in the Technological Controls theme of Annex A, alongside the other 32 controls covered in our Technological Controls Overview. Control 8.16 is one of the eleven controls new to the 2022 revision — a deliberate acknowledgment by the standard's authors that logging alone, without active review, had become a compliance theater exercise at too many organizations. Table 1 lays out the core distinction.
Table 1: Control 8.15 vs. Control 8.16 — core distinction
Attribute | Control 8.15 — Logging | Control 8.16 — Monitoring activities |
|---|---|---|
Status in ISO 27001:2022 | Carried over from 2013 (merged/renumbered) | New control in 2022 |
Core requirement | Produce, store, protect, and analyse logs of activities, exceptions, faults, and other relevant events | Monitor networks, systems, and applications for anomalous behaviour and act on potential incidents |
Primary question it answers | "Did we capture what happened?" | "Did we notice what happened — and did we do anything about it?" |
Typical owner | IT operations / infrastructure engineering | Security operations (SOC), internal or outsourced |
Failure mode without it | No record exists to investigate after the fact | A record exists, but nobody looks at it until it's too late |
Related control | 8.17 Clock synchronization (log correlation depends on accurate, consistent timestamps) | 5.24–5.28 Incident management (monitoring feeds the incident pipeline) |
Evidence auditors expect | Logging policy/standard, sample logs, retention configuration, access restrictions on log stores | Monitoring use cases, alert tuning history, escalation records, SOC/SIEM architecture diagram |
Larkspur had 8.15 in the loose, technical sense — logs existed — and effectively nothing of 8.16. That gap, not a missing firewall or an unpatched server, is what turned a phishing email into a $4.2 million incident.
"Logs are not a control. Logs are raw material. The control is what happens between the log entry being written and a human — or a rule engine acting on a human's behalf — deciding it matters." — Marcus Yeboah, Detection Engineering Lead, Sentrywell Security
Control 8.15: Logging — what "produced, stored, protected, and analysed" actually means
ISO 27001 Control 8.15 packs four distinct obligations into one sentence, and organizations routinely satisfy the first and skip the last three. "Produced" means the events are generated and captured. "Stored" means they persist somewhere durable. "Protected" means they can't be altered or deleted by the people whose actions they record. "Analysed" means someone — or something — actually looks at them with intent, which is the bridge into Control 8.16. A logging program that only produces and stores is halfway done at best.
What to log
The single most common gap I find in initial gap assessments is not "we don't log enough" — it's "we log everything from three systems and nothing from the twelve that actually matter." Table 2 is the baseline event catalogue I use with clients building a logging standard from scratch; it is deliberately not exhaustive, because every environment has systems that deserve bespoke log requirements, but it covers the categories ISO 27002's guidance for 8.15 calls out explicitly: authentication events, privileged actions, system and configuration changes, and access to sensitive data.
Table 2: Baseline logging catalogue — what to capture by category
Category | Specific events to log | Why it matters for detection |
|---|---|---|
Authentication | Successful and failed logins, password resets, MFA challenges and failures, account lockouts | Foundation of anomaly detection — impossible travel, brute force, credential stuffing all show up here |
Privileged access | Every use of an administrative or privileged access account, elevation requests, sudo/root sessions | Privileged accounts are the highest-value target; session logging is required evidence for Control 8.2 |
Account and access changes | User creation/deletion, group membership changes, permission grants, role changes | Detects privilege escalation and unauthorized access provisioning |
System and configuration changes | OS and application configuration changes, security control disabling (firewall, EDR, logging itself) | Attackers routinely disable logging or security tooling as a first move; this must be logged elsewhere too |
Data access | Access to classified or regulated data stores, bulk exports, database query patterns | Detects exfiltration and insider misuse; ties to data classification under asset management |
Network activity | Firewall allow/deny, VPN connections, DNS queries, proxy/web filtering events, unusual outbound volume | Detects command-and-control, lateral movement, and exfiltration |
Application events | Application errors and exceptions, business-logic anomalies (e.g., unusual transaction volumes), API authentication failures | Surfaces application-layer attacks and fraud that infrastructure logs miss |
Malware and endpoint | Detections, quarantines, and disabled protections from endpoint tooling | Directly supports protection against malware |
Physical-to-digital correlation | Badge access tied to system logon location/time where feasible | Detects impossible scenarios — a badge swipe in Ohio and a login from overseas minutes apart |
Faults and exceptions | System crashes, service restarts, capacity thresholds breached, backup job failures | Availability incidents and early indicators of tampering or resource exhaustion attacks |
A note on scope discipline: I have watched organizations try to log every field of every packet on the network "to be safe," and drown their storage budget and their analysts in noise within a quarter. Log what maps to a use case — authentication, privilege, change, sensitive access, and exceptions — and expand deliberately from there, not reflexively.
Log protection: making logs tamper-evident
The Larkspur postmortem turned up a detail that should worry every reader: the attacker, once they'd escalated privileges, deleted the local Windows event logs on two of the three servers they touched. It was a trivial extra step, and it worked, because those logs existed only on the local machine, writable by the same administrative account the attacker had compromised. Control 8.15 explicitly requires protection against alteration and unauthorized access — logs need to be treated as evidence from the moment they're created, not as an afterthought you protect only once an investigation begins.
Table 3: Log protection controls, from basic to mature
Maturity level | Protection mechanism | What it defends against |
|---|---|---|
Baseline | Logs shipped off the originating host to a centralized log server or SIEM in near real time | Attacker deleting local logs after compromising the host |
Baseline | Write-once or append-only storage for the centralized log repository | Retroactive tampering with the aggregated record |
Intermediate | Role-based access restricting who can read, export, or purge logs — separate from system administrators | Administrators covering their own tracks |
Intermediate | Cryptographic hashing or chaining of log batches to detect gaps or edits | Silent deletion or modification going undetected |
Advanced | Immutable/WORM storage tier or blockchain-style log integrity for high-assurance environments | Insider or supply-chain tampering with the log pipeline itself |
Advanced | Separate administrative domain for the logging/SIEM platform (different credentials, different privileged access tier) | A single compromised admin account granting access to both production and the evidence trail |
The segregation-of-duties principle matters more here than almost anywhere else in the standard: the people with the technical ability to do something log-worthy should not be the same people with the ability to edit or delete the record of having done it.
"The question I ask every client during a maturity assessment is simple: if your most trusted systems administrator went rogue tomorrow, could they erase their own tracks? If the answer is yes, you don't have logging — you have a diary the suspect is allowed to edit." — Priya Ramaswamy, CISO, Coldharbor Financial
Retention: how long is long enough
Retention is where I see the widest spread of practice, because it sits at the intersection of storage cost, regulatory obligation, and a genuinely hard forensic question: how far back would you need to look? Larkspur's VPN logs, which would have shown the very first suspicious login in December, had already rotated out of the 30-day retention window by the time anyone thought to check — the breach wasn't discovered until March.
Table 4: Illustrative log retention benchmarks by log type
Log type | Common minimum retention | Driver |
|---|---|---|
Authentication and access logs | 12 months (hot/searchable: 90 days) | Typical dwell-time investigations, audit sampling |
Privileged access/session logs | 12–18 months | Insider threat and privileged misuse investigations often surface months later |
Firewall/network logs | 6–12 months | Balances storage cost against lateral-movement reconstruction needs |
Application/database access logs | 12 months (longer for regulated data) | Data breach investigations frequently require reconstructing months of query history |
Security tool logs (EDR, IDS/IPS, DLP) | 12 months | Correlates with SIEM retention for full incident timelines |
Logs relevant to a specific regulatory regime | Per regulation (e.g., PCI DSS requires at least 12 months, with 3 months immediately available) | Contractual/regulatory obligation, independent of internal risk appetite |
None of these figures are prescribed by ISO 27001 itself — the standard requires that you define and justify a retention period based on risk, legal/regulatory obligation, and storage feasibility, and that you can show an auditor the rationale. "We kept it as long as the disk allowed" is not a rationale; "we retain authentication logs for twelve months based on our incident dwell-time analysis and our cyber insurance policy's evidentiary requirements" is.
Clock synchronization: the quiet dependency underneath every log
None of this works if your timestamps lie. Control 8.17 (Clock synchronization) — a short, easy-to-overlook control — is the load-bearing wall underneath 8.15 and 8.16 both. If your web server's clock is four minutes fast, your firewall's clock is drifting by seconds a day, and your domain controller is on a different time zone setting than your SIEM's ingestion pipeline, you cannot reliably reconstruct the order of events across systems during an investigation. I've sat in incident reviews where thirty minutes were lost solely to reconciling which of three "5:14 PM" log entries actually happened first.
The fix is unglamorous — a common, authoritative time source (typically NTP synced to a small number of trusted upstream servers) applied consistently across every log-producing system, monitored so that drift itself generates an alert. If your organization hasn't formally documented this dependency, log it now as a companion topic: NEW — Clock Synchronization: Control 8.17 deserves its own detailed treatment, and every logging standard should reference it explicitly as a prerequisite, not a footnote.
Privacy of log data
Logs are, by their nature, surveillance data about the people who use your systems — employees, contractors, and sometimes customers. A logging standard that captures every keystroke, every URL visited, and every email subject line "just in case" creates its own information security and privacy risk, and in jurisdictions with strong employee-privacy protections (much of the EU, for instance), can create a legal exposure independent of any breach.
Table 5: Privacy-conscious logging principles
Principle | Practical application |
|---|---|
Collect what serves a defined security purpose | Log authentication and administrative actions broadly; log content of communications only where a specific, documented risk justifies it |
Restrict log access on a need-to-know basis | HR-sensitive investigations (e.g., logs implicating a specific employee) restricted beyond standard SOC access |
Apply retention limits even to security logs | Security logs are not exempt from data minimization principles just because they serve a security purpose |
Be transparent with the workforce | Acceptable use and monitoring policies disclosed to employees before monitoring begins, not discovered after a disciplinary action |
Consider pseudonymization for analytics | Where feasible, tie behavioral baselining to account/role identifiers rather than raw personal names in dashboards viewed by a wide SOC team |
"I've had more pushback from a works council over broad DLP content logging than from any regulator over a breach. Privacy and security logging are not opposites, but they do require the same discipline: collect the minimum necessary to do the job, and be able to say why you collected it." — Dr. Susan Ilic, Data Privacy Officer, Coldharbor Financial
Control 8.16: Monitoring activities — from logs to detection
Control 8.16 is where Larkspur's story pivots from "avoidable" to "actually painful," because this is the control that was almost entirely absent. Monitoring is the discipline of continuously watching what your logs (and other telemetry) are telling you, comparing it to an expectation of "normal," and acting — quickly — when something deviates. ISO 27002's guidance for 8.16 is explicit that this includes networks, systems, and applications, and that the output should feed directly into incident evaluation under incident management.
Three things have to exist before monitoring produces any value: a baseline of what normal looks like, a set of detection use cases tied to real risks, and an alerting/escalation path that gets a human decision made quickly. Skip any one of the three and you get exactly what Larkspur had — logs sitting in a system nobody queries, generating no alerts because nobody defined what should trigger one.
Baselining: you can't detect "anomalous" without defining "normal"
The word "anomalous" appears directly in the control's wording, and it is doing a lot of work. An anomaly is only meaningful relative to an established baseline — the typical login times for your finance team, the typical data volume a given application transfers overnight, the typical set of servers a given service account touches. Without a baseline, every detection rule degenerates into either constant false positives or, worse, a threshold set so loose it never fires.
Table 6: Building a monitoring baseline — practical starting points
Baseline dimension | What to establish | Example anomaly it later reveals |
|---|---|---|
User behaviour | Typical login hours, locations, and devices per role | Login from a new country at 3 a.m. for an account with no travel history |
Service account behaviour | Which systems a service account normally touches, and at what volume | Service account suddenly authenticating to a system it has never accessed |
Data movement | Normal daily/weekly outbound data volume by application and user group | A 40x spike in outbound transfer from a single workstation overnight |
Privileged session frequency | How often and for how long admin accounts are typically used | A privileged session lasting six hours starting at midnight on a weekend |
Network traffic patterns | Normal internal-to-internal and internal-to-external traffic flows | New, unexplained internal server-to-server connections (lateral movement) |
Application transaction patterns | Typical volume/value of business transactions (e.g., claims processed, payments issued) | A burst of high-value transactions from one account outside business hours |
Baselining is not a one-time exercise. Business change — a new product launch, a seasonal spike, a merger — shifts what "normal" looks like, and a monitoring program that never revisits its baseline will either alert constantly on legitimate new behaviour or quietly stop catching real anomalies as the gap between the stale baseline and reality widens.
Detection use cases: turning logs into tripwires
A "use case" in monitoring parlance is a specific, documented scenario: the log sources it draws from, the logic that flags it, the severity it warrants, and the response it should trigger. Organizations that jump straight to buying a SIEM without first defining use cases end up with an expensive log warehouse and no better detection than Larkspur had — the tool is not the control, the use case is.
Table 7: Starter detection use case library (vendor-neutral)
Use case | Log sources needed | Typical severity | Related control/theme |
|---|---|---|---|
Impossible travel / geographically implausible login | Authentication logs, VPN/SSO logs | High | 5.15–5.18 Access control |
Brute-force or credential-stuffing pattern | Authentication logs (failed attempts, rate) | Medium–High | 8.5 Secure authentication |
Privileged account used outside normal hours or from unusual host | Privileged/admin session logs | High | 8.2 Privileged access rights |
Dormant account reactivated | Account lifecycle logs, authentication logs | High | 5.18 Access rights |
Security control disabled (EDR, firewall, logging agent) | Endpoint/EDR management logs, configuration change logs | Critical | 8.7 Malware; 8.9 Configuration management |
Mass file access or bulk data export | File server/DLP/database access logs | High | 8.12 Data leakage prevention |
Unusual outbound data volume to external destination | Firewall/proxy/network flow logs | Critical | 8.20–8.23 Network security |
Malware detection with no automatic remediation confirmed | Endpoint protection logs | Critical | 8.7 Malware |
New/unauthorized software installation on servers | Configuration/change management logs | Medium | 8.19 Installation of software |
Lateral movement indicators (unusual internal authentication chains) | Domain controller logs, network flow logs | Critical | 8.22 Segregation of networks |
Repeated access-denied events against sensitive systems | Access control/application logs | Medium | 8.3 Information access restriction |
Web application anomalies (parameter tampering, injection patterns) | Web application firewall/application logs | High | 8.26 Application security requirements |
Many mature security teams organize this library around an external threat-behaviour framework (a widely used industry reference maps adversary tactics and techniques to help prioritize which use cases matter most) — that's a practitioner tool, not an ISO 27001 requirement, but it's a genuinely useful way to make sure your use case library isn't just "the twelve things our last SIEM vendor demoed."
"Every client asks me which SIEM to buy before they've written down a single detection use case. That's backwards. Buy the platform after you know what you're trying to detect — otherwise you're paying enterprise licensing fees to store logs nobody queries." — James Okafor, Director of IT, Ferrowright Industries
Alerting: designing for signal, not noise
The fastest way to sabotage a monitoring program is to alert on everything a use case could theoretically detect and let the SOC analyst sort it out. Alert fatigue is not a minor annoyance — it is a direct security failure mode, because an analyst triaging four hundred low-value alerts a day will, provably and predictably, miss the one that matters. I ask every client to map severity to a defined response time and channel before a single rule goes live.
Table 8: Alert severity and response mapping
Severity | Example trigger | Target acknowledgement time | Escalation path |
|---|---|---|---|
Critical | Security control disabled; confirmed malware with active C2 traffic; mass exfiltration pattern | Immediate (minutes), 24/7 | Auto-page on-call responder; parallel notification to incident commander |
High | Impossible travel login; dormant privileged account reactivated | Within 30–60 minutes during business hours, 2 hours off-hours | SOC analyst triage, escalate to incident management if confirmed |
Medium | Repeated access-denied events; unusual but explainable data volume | Within 4–8 business hours | Queued for analyst review, daily triage huddle |
Low / informational | Policy exceptions logged for awareness, minor configuration drift | Reviewed in weekly/periodic reporting | No individual escalation; trend reporting only |
Two tuning habits separate mature monitoring programs from noisy ones: reviewing false-positive rates on every rule at a fixed cadence (monthly is typical) and retiring or rewriting any rule whose false-positive rate has drifted past an agreed threshold — I use 90% as a rough ceiling before a rule gets flagged for rework. A rule nobody has looked at in a year is not a control; it's a museum piece.
The logging-to-incident pipeline
Controls 8.15 and 8.16 don't stand alone — they are the front two-thirds of a pipeline that ends in your incident management process. The diagram below is the one I sketch on a whiteboard in almost every detection-maturity workshop, because it's the fastest way to show a leadership team exactly where Larkspur's pipeline broke (between "collect" and "monitor," with a second break between "alert" and "triage").
flowchart LR
A[Log sources<br/>endpoints, servers, network,<br/>applications, cloud, identity] --> B[Collect<br/>centralized aggregation /<br/>SIEM ingestion]
B --> C[Protect & retain<br/>tamper-evident storage,<br/>access-restricted, retention policy]
B --> D[Monitor & detect<br/>baselining + use cases,<br/>correlation rules]
D --> E[Alert<br/>severity-tiered,<br/>tuned for signal]
E --> F[Triage<br/>SOC analyst / on-call<br/>reviews and validates]
F --> G[Incident response<br/>Controls 5.24-5.28]
C -.evidence for.-> GEvery stage on that diagram has an owner, and every gap between stages is where real incidents slip through. Larkspur's pipeline had A and C — logs existed and were, eventually, retained — but nothing at D, E, or F. No baseline, no use cases, no alert, no triage. The incident wasn't a technology failure; it was a pipeline with three missing links.
SIEM, SOC, and the build-vs-buy-vs-MSSP decision
Once the use cases and alerting model are defined, the platform question becomes much easier, because you now know what you're buying capability for rather than shopping by feature list. The three broad paths — build an in-house SOC, buy a SIEM platform and staff it internally, or outsource detection to a managed security service provider (MSSP) — trade off cost, speed to maturity, and control very differently. If you're heading down the "buy" path, PentesterWorld's best SIEM platforms comparison is a practical way to shortlist vendors against the use cases you've already defined, rather than starting from a demo.
Table 9: Build vs. buy vs. MSSP — decision factors
Factor | In-house SOC (build) | SIEM platform, internally staffed (buy) | Managed detection (MSSP/MDR) |
|---|---|---|---|
Typical time to initial operating capability | 9–18 months | 4–9 months | 4–8 weeks |
24/7 coverage cost | Highest (multiple analyst shifts, on-call rotation) | High (still requires internal 24/7 staffing) | Included in service fee, generally lower marginal cost |
Institutional/business context retained | Highest — analysts know the business intimately | High | Lower initially; improves as relationship matures |
Best fit | Large organizations with sustained security investment and headcount | Mid-size organizations with an existing security team wanting more control | Small-to-mid organizations without the headcount for 24/7 coverage |
Key risk | Analyst burnout, retention, use-case stagnation | Tool underutilization if use cases aren't maintained | Vendor lock-in, generic detection not tuned to your environment |
ISO 27001 audit consideration | Full internal evidence chain, easiest to demonstrate | Internal evidence chain with vendor licensing/config records | Requires supplier oversight evidence per supplier relationship security — the MSSP does not remove your accountability for 8.16 |
The detail that trips up organizations choosing the MSSP path: outsourcing monitoring does not outsource the control. ISO 27001 still holds the certified organization accountable for Control 8.16 being effective — an auditor will ask how you oversee the MSSP's performance, how alerts are escalated back to your internal incident owner, and how you validate that the MSSP's use cases actually match your risk profile, not just their standard package.
"We moved to an MDR provider after two failed attempts at building an internal SOC. The mistake the first time was thinking outsourcing meant we could stop thinking about it. It didn't — we still own the risk, we still own the incident, and now we also own a vendor relationship we have to actively manage." — Elena Vasquez, SOC Manager, Larkspur Health Analytics
Feeding threat intelligence into what you monitor for
A detection use case library built purely from internal incident history is always looking backward. Pairing it with external threat intelligence — indicators of compromise, tactics currently being used against your sector, and known-bad infrastructure — lets monitoring catch novel attack patterns before they become internal incident history. In practice this looks like feeding threat intelligence feeds directly into SIEM correlation rules (so a login from a newly reported malicious IP range fires automatically) and reviewing sector-specific advisories on a set cadence to ask, deliberately, "do our current use cases cover this technique?" Larkspur's own sector — healthcare claims processing — had been publicly flagged as a high-value target for credential-based attacks for over a year before its breach; that intelligence existed and was never connected to a detection rule.
Metrics and KPIs that actually tell you something
Dashboards full of "logs ingested per day" or "alerts generated" measure activity, not effectiveness. The metrics worth tracking are the ones that tell you whether the pipeline in the diagram above is actually working end to end.
Table 10: Logging and monitoring KPIs worth tracking
Metric | What it tells you | Illustrative healthy benchmark |
|---|---|---|
Log source coverage | Percentage of in-scope systems actively sending logs to central collection | 95%+ of systems in the asset inventory |
Mean time to detect (MTTD) | How long between an event occurring and it being flagged | Hours, trending down quarter over quarter |
Mean time to acknowledge (MTTA) | How long between an alert firing and an analyst engaging with it | Under 15 minutes for critical severity |
Mean time to triage/escalate | How long between acknowledgement and a decision (false positive vs. real incident) | Under 1 hour for critical/high severity |
False-positive rate per use case | Whether a detection rule is still worth keeping as-is | Under 90% (rules above this reviewed/retired) |
Alert-to-incident conversion rate | Proportion of alerts that become confirmed incidents | Tracked per use case, not in aggregate — some low-conversion rules are still worth keeping for high-severity risks |
Log retention compliance | Percentage of log sources meeting the defined retention policy | 100% — this is a binary audit finding, not a trend |
Use case review cadence adherence | Whether the detection library is actually being revisited on schedule | 100% of use cases reviewed within the defined cycle (e.g., quarterly) |
These same metrics double as the reporting line item that lets a CISO answer the board's inevitable question — "are we actually watching?" — with numbers instead of reassurance.
Evidence for auditors: what to have ready
An ISO 27001 auditor assessing 8.15 and 8.16 is not going to take "we have a SIEM" as a satisfactory answer for either control. They will sample, and they will ask you to walk them through a specific event from log generation to disposition. Table 11 is the evidence pack I help clients assemble before a Stage 2 audit or a surveillance audit touching these controls.
Table 11: Audit evidence checklist for Controls 8.15–8.16
Evidence item | What it demonstrates |
|---|---|
Logging standard/policy defining what is logged, by system category | Deliberate scope, not ad hoc logging |
Log source inventory mapped to the asset inventory | Coverage — nothing material is unmonitored by omission |
Log retention schedule with rationale (risk-based, regulatory) | Defined, justified retention rather than storage-driven decisions |
Access control list/configuration for the log repository or SIEM | Log protection and segregation of duties |
Sample of actual log entries (redacted as needed) across at least three system types | Logging is operating in practice, not just on paper |
Documented monitoring use case library with severity and response mapping | Monitoring is deliberate and risk-based, not reactive |
Alert-to-resolution records for a sample of recent alerts | The full pipeline — detection through triage — functions |
Evidence of at least one drill, tabletop, or real incident where logs/monitoring were used | Practical effectiveness, not theoretical capability |
SOC/MSSP oversight records, if outsourced | Accountability retained despite outsourcing |
Statement of Applicability entry for 8.15 and 8.16 with justification | Documented decision to include (or, rarely, justified exclusion) — see our guide to building the Statement of Applicability |
Clock synchronization configuration/monitoring records | Supports log correlation integrity across the sampled evidence |
Auditors reward organizations that can produce a specific, recent example unprompted — "here's an alert from six weeks ago, here's the triage note, here's why we closed it as a false positive, here's the rule we tuned afterward" — far more than a polished policy document with no operational trail behind it. If you're assembling this evidence pack for the first time, our Internal Audit Checklist is a practical way to confirm you have every item in Table 11 ready before an auditor asks.
Common mistakes I see in the field
Table 12: Common logging and monitoring mistakes and their fix
Mistake | Why it happens | Fix |
|---|---|---|
Logging is enabled but nobody reviews it (Larkspur's core failure) | Logging was implemented to satisfy a prior audit finding, not to enable detection | Assign explicit ownership for review; define use cases and SLAs before declaring the control "done" |
Retention set by default storage limits, not risk | Nobody revisits the vendor default when data volume grows | Define retention by log type based on investigation needs and regulatory obligation, budget storage to match |
Administrators can read, edit, and delete the logs of their own actions | Logging bolted onto existing infrastructure without segregation of duties | Centralize logs outside the reach of the systems' own administrators; restrict log-store access separately |
Alert rules never tuned after go-live | No owner assigned to ongoing detection engineering, treated as a one-time project | Schedule recurring use case review; track false-positive rate per rule |
Monitoring stops at alert generation, with no defined escalation to incident management | 8.16 treated as a standalone technical control instead of a feed into 5.24–5.28 | Document and test the handoff from SOC triage to incident response formally |
Clock drift across log sources silently corrupts timeline reconstruction | Treated as an IT hygiene issue, not a security dependency | Formalize NTP synchronization and monitor for drift under Control 8.17 |
Outsourcing monitoring is treated as outsourcing accountability | MSSP contract signed without defining internal oversight responsibilities | Retain a named internal owner for 8.16 regardless of who operates the tooling |
Privacy concerns block logging entirely instead of shaping it | Legal/HR veto without security and privacy collaborating on scope | Apply the data-minimization principles in Table 5 rather than an all-or-nothing decision |
How this compares across frameworks
If your organization is pursuing more than one framework — a common situation for SaaS vendors serving enterprise customers, or payment processors — it helps to know that logging and monitoring is not an ISO-specific idea; it's one of the most consistently required control areas across every major framework, just phrased differently.
Table 13: Logging and monitoring across frameworks
Framework | How it frames the requirement |
|---|---|
ISO 27001 (this article) | Controls 8.15 (Logging) and 8.16 (Monitoring activities) — produce/protect/analyse logs; monitor for anomalous behaviour |
Addressed under the Security (Common Criteria) and Availability criteria — requires monitoring of system components to detect anomalies and security events | |
Requirement 10 mandates logging and monitoring of all access to cardholder data and system components, with daily log review for critical systems | |
The Detect (DE) function is built almost entirely around "Anomalies and Events" and "Security Continuous Monitoring" categories |
The practical upshot: a well-built logging and monitoring program satisfying ISO 27001 8.15–8.16 will satisfy the large majority of what PCI DSS Requirement 10 or a SOC 2 monitoring criterion demands, with framework-specific tweaks (PCI's daily review requirement for certain log types being the most concrete example) rather than a rebuild. Our ISO 27001 vs NIST, SOC 2, and PCI DSS comparison goes deeper on where the frameworks align and diverge more broadly.
Case study: Larkspur Health Analytics — from blind spot to backbone
After the breach, Larkspur's board mandated a full detection-maturity rebuild, with Elena Vasquez brought in as SOC manager six weeks into the recovery. The team didn't start with a SIEM purchase — they started by rebuilding the logging catalogue against Table 2's categories, discovering in the process that four of their twelve business-critical applications weren't sending logs anywhere centralized at all. Within four months they had centralized log collection from 96% of in-scope systems, a documented use case library of eighteen detection rules mapped to their highest-risk scenarios (privileged account misuse and data exfiltration first, given the breach history), and a 24/7 coverage model built on a hybrid: an internal detection engineering team of two, backed by an MDR provider for off-hours alert triage.
The result, measured a year later: mean time to detect for a simulated red-team exercise dropped from "not detected at all" (the actual outcome of the real breach) to fourteen minutes. Larkspur's cyber insurance premium, which had spiked 60% at renewal immediately post-breach, was renegotiated downward the following year once the insurer's own security assessment confirmed the monitoring program was operational, not aspirational. Elena's team now reviews false-positive rates monthly and retires or rewrites roughly two rules a quarter — a small, unglamorous habit that is, in her words, "the actual difference between a program and a project."
Case study: Ferrowright Industries — catching lateral movement in a converged IT/OT environment
Ferrowright, a mid-market industrial equipment manufacturer, came to a gap assessment with a common blind spot: strong logging on the corporate IT side, and almost none on the operational technology (OT) network running its factory floor, connected to corporate IT for reporting purposes more tightly than anyone had mapped. During use-case design, we flagged unusual internal authentication chains — service accounts crossing from IT into OT segments — as a scenario worth a dedicated detection rule, informed by the segmentation principles behind network security controls.
Four months after that rule went live, it fired for real: a compromised vendor VPN account, used originally for remote maintenance, authenticated against a historian server on the OT network at 2 a.m. — a system that account had never touched in eighteen months of historical logs. The SOC escalated within twenty-two minutes, the account was disabled, and forensic review confirmed the intrusion had not yet reached programmable logic controllers on the production line. James Okafor estimated the realistic alternative cost — a production-halting OT incident during a peak order quarter — at $1.1 million in lost output alone, against a detection engineering investment of roughly $140,000 for the year.
Case study: Coldharbor Financial — audit-ready evidence without a headcount increase
Coldharbor, a 90-person fintech lender, faced a specific problem heading into its first ISO 27001 Stage 2 audit: a lean IT team with no capacity to staff an internal SOC, but a regulator-adjacent business that made "we don't really monitor" an unacceptable answer. Rather than building internally, Coldharbor selected an MDR provider, but — learning from peers' experience — insisted contractually on a defined internal escalation owner, monthly detection use case reviews conducted jointly with the vendor, and quarterly reporting mapped directly to Table 10's KPI set.
At audit, the lead auditor sampled three alerts from the preceding quarter and asked Coldharbor's CISO, Priya Ramaswamy, to walk through each end to end — log source, detection logic, triage note, and disposition. All three were produced within the same meeting, pulled directly from the joint reporting dashboard. The audit closed 8.15 and 8.16 with zero findings, in an area the CISO had privately expected at least a minor nonconformity given the small internal team. "The auditor wasn't grading us on doing it ourselves," Ramaswamy noted afterward. "She was grading us on being able to prove someone was watching, and that we still owned the outcome."
"Small teams keep telling me they can't afford monitoring. My answer is always the same: you can't afford an unmonitored breach either, and the second one is a lot more expensive than the first." — Tom Achterberg, Lead Internal Auditor, Baseline Assurance Partners
The strategic close: detection as a business differentiator, not a cost center
Every organization I've worked with initially treats logging and monitoring as a compliance line item — something to check off for the audit, sized to the minimum an assessor will accept. The organizations that get real value flip that framing: detection capability is now something customers, insurers, and boards actively ask about, and being able to answer with specifics — mean time to detect, a tested escalation path, a named owner for monitoring — is a genuine competitive differentiator in any sales cycle involving a security questionnaire. Larkspur's board didn't fund the rebuild because ISO 27001 demanded it; they funded it because the alternative was explaining a second breach to the same journalist.
If you're building or maturing this capability, start where this article started: define what you actually need to log against real risk, protect it so nobody can quietly erase their own tracks, retain it long enough to matter, and then — the step Larkspur skipped — actually watch it, with baselines, use cases, and a clear path from alert to incident response. Our Annex A — All 93 Controls at a Glance cheat sheet is a useful companion for seeing how 8.15 and 8.16 sit alongside the rest of your Statement of Applicability, and if you're earlier in the journey, our Complete ISO 27001 Implementation Guide eBook walks through sequencing this work against everything else your ISMS needs. For terminology that trips up teams new to this space, our ISO 27001 Glossary of Terms defines SIEM, MTTD, and the rest of the acronyms this article leaned on.
Ready to see exactly where your logging and monitoring program stands against Controls 8.15 and 8.16 — and the rest of Annex A? PentesterWorld's assessment and advisory teams have walked more than 200 organizations through exactly this gap, from a first-pass maturity review to full Stage 2 audit preparation. Reach out to start with a focused review of your detection pipeline, or work through our ISO 27001 Gap Analysis Tool to get an immediate baseline before you talk to anyone.