Annex A 8.15: Logging

Annex A 8.15 sits in the “technical controls” section of ISO/IEC 27001:2022 and expects you to run logging as an operational capability, not as a set of scattered system defaults. In practice, auditors and customer security teams use logging to answer basic questions fast: What happened? When did it happen? Who did it? What systems were touched? What did you do about it?

If you own a security program, GRC, or compliance operations, your job is to turn “we have logs” into a repeatable requirement you can defend. That requires choices: which event types are mandatory, where logs are aggregated, who can access them, how long they are kept, and how reviews and alerts are executed. You also need to show that logging supports incident investigation and that logs are protected from tampering.

This page gives requirement-level implementation guidance you can apply quickly: a logging control card, a step-by-step build sequence, evidence to retain, common audit hangups, and an execution plan that turns logging into a control that operates continuously. Source references are limited to publicly available ISO framework summaries (ISO/IEC 27001 overview; ISMS.online Annex A control index).

Regulatory text

Framework reference: ISO/IEC 27001:2022 Annex A control 8.15 (Logging). ¹

Provided excerpt (summary-level): “ISO/IEC 27001:2022 Annex A control 8.15 implementation expectation (Logging).” ¹

What the operator must do (requirement interpretation):

• Define which security-relevant events must be logged across your environment (users, admins, apps, infrastructure, network/security tooling, and critical business systems).
• Ensure logs are collected reliably, protected from alteration and unauthorized access, and retained for a defined period aligned to investigation and business needs.
• Review and/or alert on logs with a consistent process so suspicious activity is detected and acted on.
• Keep evidence that logging is configured as intended and that reviews/alerts are operating.

Plain-English interpretation of the requirement

Logging is your organization’s “flight recorder.” Annex a 8.15: logging requirement expects you to (1) capture meaningful security events, (2) store them somewhere you can trust, (3) keep them long enough to investigate, and (4) actually look at them or alert on them.

A practical standard: if an auditor picks a critical system and asks, “Show me admin activity and authentication events for last week, and show me your review/alert handling,” you should be able to produce logs plus the operational trail (alerts, tickets, analysis notes, and closure).

Who it applies to (entity and operational context)

Applies to:

• Organizations implementing or certified against ISO/IEC 27001:2022 with Annex A controls in scope. ²
• Service organizations running customer-facing platforms, internal enterprise systems, and cloud environments where access and change activity must be attributable. ²

Operational contexts where auditors focus:

• Identity and access: SSO, MFA, privileged access, directory services.
• Cloud control planes: AWS/GCP/Azure activity logs, Kubernetes audit logs, SaaS admin logs.
• Core infrastructure: endpoints, servers, EDR, VPN, firewalls, WAF.
• Business-critical apps and data stores: production applications, databases, object storage, payment or order systems.
• Third party services: managed hosting, SOC providers, SaaS tools that administer customer data.

What you actually need to do (step-by-step)

1) Create a logging control card (your “runbook”)

Document the control so it can run without tribal knowledge:

• Objective: detect, investigate, and provide evidence of security events through logging.
• Owner: Security Operations (primary) + GRC (oversight) + IT/App owners (log sources).
• Scope: in-scope systems, environments (prod/non-prod as applicable), and key third parties.
• Trigger events: new system onboarding, major releases, IAM changes, incident response events, quarterly control health checks.
• Execution steps: collection, normalization, alerting, review, exceptions.
• Exceptions: what can be excluded, who approves, and compensating controls.

This aligns with common audit expectations: ownership, cadence, and evidence mapping. ²

2) Define your minimum log event taxonomy (what must be logged)

Write a one-page “minimum required events” standard that includes:

• Authentication: success/failure, MFA events, account lockouts, session creation.
• Privileged activity: role changes, admin actions, key management activity.
• System and application changes: deployments, configuration changes, policy changes.
• Data access signals for sensitive stores: reads of sensitive records, exports, permission changes (where feasible).
• Security tool signals: EDR alerts, firewall denies, WAF events, DLP alerts (as applicable).

Keep it simple: mandatory events for all systems plus additional events for high-risk systems.

3) Inventory log sources and map them to the taxonomy

Build a “log source register” (table works) with:

• System name, owner, environment, data classification.
• Log types produced and where they are generated.
• Collection method (agent, API, syslog, native integration).
• Alerting/review coverage (which rules/detections apply).
• Retention and storage location.
• Gaps and remediation ticket links.

This becomes your single pane of accountability: what’s in scope, what’s working, what’s missing.

4) Centralize collection and normalize access

Operational requirement: logs must be accessible for investigation and protected from tampering.

• Choose a central repository (SIEM, log analytics platform, managed SOC portal) and standardize ingestion paths.
• Restrict admin access to the logging platform, and separate duties where you can (log admins vs. investigators).
• Encrypt logs in transit and at rest using platform capabilities and key management practices aligned to your ISMS policies.

5) Set retention, integrity, and time synchronization expectations

Document decisions, then configure them:

• Retention standard: define how long logs are kept based on investigation needs and contractual/regulatory constraints.
• Integrity controls: write-once settings where supported, immutability buckets, or restricted deletion permissions with monitoring.
• Time sync: require consistent time sources across systems so investigations can correlate events.

Auditors commonly test whether you can correlate events across systems; time drift is a recurring failure mode.

6) Implement detection and review workflows that create evidence

You need two operating motions:

• Alerting (near real-time): for high-risk events (privilege escalation, impossible travel, key access, mass deletes, disabled security controls).
• Periodic review: for systems where alerting is limited or as a backstop (admin actions, access to sensitive data stores, log ingestion failures).

Attach each alert/review to a ticketing workflow:

• Triage notes (what was observed).
• Evidence captured (log excerpts, screenshots, query links).
• Outcome (benign/true positive), containment steps, and closure approval.

7) Add control health checks (logging can silently fail)

Build a repeatable health check that answers:

• Are critical sources still sending logs?
• Did ingestion volume drop unexpectedly?
• Are detections still enabled after platform changes?
• Are retention settings intact?

Track findings to closure with owners and due dates. ²

8) Operationalize third party logging dependencies

If a third party (SaaS, managed service, cloud provider) holds key logs:

• Confirm what logs you can access (admin/audit logs, API access logs).
• Confirm retention and export options.
• Ensure your offboarding plan preserves logs needed for investigations.

Required evidence and artifacts to retain

Keep an “8.15 evidence bundle” that is easy to hand to an auditor:

Governance artifacts

• Logging policy/standard (minimum events, retention, access).
• Logging control card/runbook with owner, cadence, and exceptions.
• Log source register (system inventory mapped to logging coverage).

Technical configuration evidence

• Screenshots/exports of SIEM/log platform settings: retention, role-based access, ingestion status dashboards.
• Sample logs for key sources (redacted as needed).
• Time sync configuration evidence for representative systems (NTP/tenant settings).

Operational evidence

• Alert queue samples with tickets: triage, investigation notes, closure.
• Periodic review checklists and sign-offs.
• Control health check results and remediation tracking.

Exception handling

• Approved exclusions with compensating controls and review date.

Common exam/audit questions and hangups

1. “Show me that logs can’t be altered.” Expect scrutiny on who can delete or modify logs in the platform and whether deletion is monitored.
2. “Prove the control operates.” Auditors often reject “we have a SIEM” without review records, alert tickets, and closure notes.
3. “What’s your coverage?” Be ready to show your log source register and explain gaps with a plan.
4. “Can you investigate an incident?” They may pick a user and ask for authentication and admin actions across systems within a time window.
5. “Do third parties provide audit logs?” If key processing is in SaaS, they will ask how you get those logs and how long you keep them.

Frequent implementation mistakes and how to avoid them

• Mistake: logging everything, reviewing nothing. Fix: define “must-log” events and “must-review/alert” events, then align staffing and workflows.
• Mistake: no ownership. Fix: name a control owner and require system owners to onboard log sources during provisioning.
• Mistake: relying on default retention. Fix: set explicit retention standards and verify config.
• Mistake: logs accessible to too many admins. Fix: least-privilege roles for log search vs. log administration; monitor privileged actions.
• Mistake: no proof of routine operation. Fix: ticket-based reviews, health checks, and saved queries with timestamps.

Enforcement context and risk implications

No public enforcement cases were provided in the approved source catalog for this requirement, so this page does not cite enforcement actions.

Risk-wise, weak logging increases breach impact and investigation cost: you may be unable to reconstruct events, prove customer impact boundaries, or demonstrate timely detection. For ISO audits and customer diligence, the practical risk is a major nonconformity if logging exists but is not demonstrably monitored and protected.

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign a control owner and publish the logging control card (objective, scope, cadence, exceptions). ²
• Write the minimum required event taxonomy and retention/access standard.
• Build the log source register for your highest-risk systems and key third parties.
• Confirm central log platform access controls and identify who can delete logs.

Days 31–60 (implement and prove operation)

• Onboard remaining critical sources into the central platform; document gaps with remediation tickets.
• Create a baseline set of detections/alerts and a periodic review checklist.
• Implement the ticket workflow for alerts and reviews; require investigation notes and closure.
• Run the first control health check; record results and remediation tracking.

Days 61–90 (harden and audit-proof)

• Tighten integrity protections (immutability where supported, deletion monitoring, privileged access reviews).
• Validate time synchronization across representative systems and cloud tenants.
• Run a tabletop incident scenario using logs (pick a user/admin and reconstruct actions).
• Assemble the 8.15 evidence bundle in a single audit-ready folder with a short index.

Where Daydream fits naturally If your issue is evidence sprawl, Daydream can help you standardize the “control card + evidence bundle + health check” pattern across logging and related controls so auditors see consistent ownership, execution, and traceability (without rebuilding the same tracking sheets each cycle).

Frequently Asked Questions

Do we need a SIEM to meet annex a 8.15: logging requirement?

ISO 27001 does not mandate a specific technology, but you need centralized access, protection, and review/alerting that you can prove. Many teams meet this with a SIEM or a managed logging platform because it simplifies evidence and investigation.

What log sources are auditors most likely to test?

Identity systems (SSO/MFA), cloud control plane logs, and privileged admin activity come up repeatedly because they show who did what. They also test a production application path if it processes sensitive data.

How do we handle logging for SaaS third parties where we can’t install agents?

Use the provider’s audit/admin logs and export options, then document access method, retention, and responsible owner in your log source register. If export is limited, document the limitation as an exception and add compensating monitoring.

What retention period is required?

ISO 27001 expects you to define and follow retention based on business, legal, and investigative needs; the standard does not publish a single fixed duration in the provided sources. Pick a retention standard you can operate and justify, then configure systems to match it.

How do we prove logs are reviewed, not just collected?

Keep tickets or review records that include timestamps, what was checked (saved queries or dashboards), findings, and closure. Auditors accept sampled evidence if it is consistent and traceable.

Can we exclude low-risk systems from centralized logging?

You can scope logging by risk, but document exclusions explicitly with approval, rationale, and review date. Auditors respond better when you show a risk-based decision plus a plan for future coverage.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview