Event logging

ISO/IEC 27017 Clause 12.4.1 requires you to produce, keep, and regularly review event logs for cloud services that capture user activities, exceptions, faults, and information security events. To operationalize it, define log scope and owners, enable logging across control planes and workloads, protect log integrity, set retention, and run documented, recurring reviews. ¹

Key takeaways:

• You need logging plus proof of routine review, not just “logs exist.”
• Cover four categories explicitly: user activity, exceptions, faults, and security events.
• Integrity, access control, and retention are exam focal points because logs are investigation evidence.

Event logging is one of those requirements that looks simple until you try to prove it in an audit. ISO/IEC 27017 Clause 12.4.1 is explicit: for cloud services, you must produce event logs, keep them, and regularly review them. The logs must cover user activities, exceptions, faults, and information security events. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as an end-to-end “logging lifecycle” control: define what must be logged, ensure logs are generated across relevant cloud layers, protect the logs as controlled records, and run a repeatable review process with documented outcomes. The operational challenge is usually not turning logs on; it’s proving completeness (coverage), integrity (tamper resistance), and governance (who reviews what and what happens when something looks wrong).

This page gives requirement-level implementation guidance you can hand to security engineering, cloud platform, and operations teams, while still being able to evidence the control to auditors.

Regulatory text

ISO/IEC 27017:2015 Clause 12.4.1 states: “Event logs recording user activities, exceptions, faults and information security events shall be produced, kept and regularly reviewed for cloud services.” ¹

What an operator must do:
You must (1) generate event logs for cloud services, (2) retain those logs as records, and (3) perform regular reviews of those logs. Your logging must include, at minimum, user activity, exceptions, faults, and information security events. ¹

Plain-English interpretation (what the requirement really demands)

This requirement is asking for two things:

1. Detectability: enough logging to reconstruct actions and system behavior in your cloud environment (who did what, what broke, and what security-relevant events occurred).
2. Governance: a documented practice of reviewing logs at a defined cadence, with follow-through when reviews reveal risk.

Auditors will typically treat “regularly reviewed” as a control activity you must evidence. If your only evidence is that logs exist in a bucket, you will struggle to demonstrate compliance.

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers (CSPs): you operate a cloud service for customers and must log events across the service’s control plane and operational components.
• Cloud Service Customers: you consume cloud services and must log events within your cloud environment and cloud-hosted workloads, to the extent you control configuration and monitoring. ¹

Operational contexts where this becomes concrete:

• Control plane activity (identity, access, admin actions)
• Workload events (OS, containers, serverless functions, applications)
• Security tooling events (EDR, WAF, IDS, CSPM)
• Platform reliability events (service faults, exceptions, job failures)

If you rely on third parties (managed service providers, SaaS platforms, logging providers), you still own the requirement outcome. Contractual terms and shared responsibility boundaries decide who provides which logs, but you must be able to show the control works.

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

1) Define logging scope and objectives

Create a short Event Logging Standard that answers:

• Which cloud environments are in scope (accounts, subscriptions, tenants, regions)
• Which services and tiers are in scope (control plane, network, workload, application, data)
• Which event types must be captured: user activities, exceptions, faults, security events (use these words verbatim to map to the clause)
• What the logs are used for (incident investigation, access accountability, operational troubleshooting)

Deliverable: an approved standard plus a coverage matrix (even a spreadsheet is fine if it is maintained).

2) Establish log sources and minimum events

Build a “minimum required log sources” list. Keep it practical:

• Identity and access logs: sign-ins, MFA events, privilege changes, API calls, admin actions
• Administrative actions: creation/modification/deletion of cloud resources, policy changes, key management actions
• Network and perimeter logs: firewall/WAF events, load balancer access logs, DNS query logs where available
• Workload and app logs: system auth logs, application audit logs, error/exception logs, job scheduler failures
• Security events: detections from security tools, alert triage outcomes, rule changes in security platforms
• Faults and exceptions: service health events, failed deployments, crash loops, timeout spikes

Map each source to: owner, collection method, storage destination, and expected fields (timestamp, actor, action, target, result).

3) Turn on logging and centralize collection

Operationalize “produced” by enabling logging at the source and forwarding to a centralized logging platform (SIEM or log lake). Focus on:

• Standardized time synchronization and timestamps
• Consistent parsing and normalization for search and correlation
• Segregation of duties: admins of production should not be able to silently delete or alter security logs

If you need a system of record for evidence, Daydream can help you track log-source coverage, assign owners, and collect recurring review attestations in one place, so audits do not devolve into screenshots and tribal knowledge.

4) Protect log integrity and access (treat logs as evidence)

“Kept” is not only retention; it implies controlled records:

• Restrict access to logs (least privilege, break-glass access, monitored admin actions)
• Use immutable storage or write-once controls where feasible
• Alert on logging being disabled, log forwarding failures, or sudden drops in volume
• Back up or replicate logs if your threat model includes attacker log destruction

Auditors often focus on whether an attacker (or a careless admin) could erase traces. Build your control narrative around prevention and detection of log tampering.

5) Define retention and retrieval requirements

Set a retention rule by log class (security vs. application vs. operational). Even if ISO/IEC 27017 does not specify a duration, you still need a written policy decision and a rationale, plus proof that retention is enforced in configuration.

Also define retrieval expectations:

• Who can retrieve logs for investigations
• How quickly logs can be searched
• How you preserve logs for incidents (export, legal hold, case management linkage)

6) Implement “regular review” as a real process, not a hope

Create a Log Review Procedure with:

• Review cadences by log type (higher-risk sources reviewed more frequently)
• Review methods (alerts, dashboards, sampling, correlation rules)
• Required outputs (ticket, case, or annotated report)
• Escalation triggers (privileged access anomalies, repeated faults, authentication spikes, policy changes)

Make the review outcome auditable: each review should leave a trail that shows date, reviewer, scope, findings, and actions taken.

7) Test, measure, and continuously improve

Add two lightweight tests:

• Coverage test: verify required sources are still sending logs (detect silent failure)
• Control effectiveness test: run a simulated event (for example, a known test account action) and confirm it appears end-to-end in the central log store and in review workflows

Document test results and fixes. This becomes strong evidence that the control is alive.

Required evidence and artifacts to retain

Keep evidence that ties directly to “produced, kept, reviewed”:

• Event Logging Standard (scope, minimum events, roles)
• Log source inventory and coverage matrix (in-scope services, owners, status)
• Configuration evidence showing logging enabled (exported settings, IaC, or configuration baselines)
• Central logging architecture diagram and data flow notes
• Access control records for log platforms (role definitions, access reviews)
• Retention configurations (policy settings, storage lifecycle rules)
• Log review procedure and calendar
• Review records: tickets, SIEM case notes, sign-offs, findings and remediation actions
• Evidence of monitoring for logging failures or tampering (alerts, runbooks, incident records)

Common exam/audit questions and hangups

Expect questions like:

• “Show me which user activities are logged for cloud admin actions.”
• “How do you know exceptions and faults are captured across all production workloads?”
• “Who reviews logs, how often, and where is that documented?”
• “Can a production administrator delete or alter security logs?”
• “Show evidence from a recent log review and the follow-up action.”
• “How do you detect logging gaps (agent down, forwarding misconfigured, quotas hit)?”

Hangups usually occur when teams cannot prove review frequency, cannot explain shared responsibility boundaries, or cannot show consistent coverage across accounts/tenants.

Frequent implementation mistakes (and how to avoid them)

1. Relying on default logging settings. Defaults rarely cover all required event types; confirm coverage against your matrix.
2. Logging without ownership. Every log source needs an owner accountable for health and content.
3. No evidence of “regular review.” Fix by forcing reviews through a ticketing or case workflow with required fields.
4. Unprotected logs. If too many admins can modify logging configuration or delete logs, auditors will question integrity. Separate duties and alert on configuration changes.
5. Ignoring exceptions and faults. Security teams often focus on detections only; reliability and exception logs are part of the requirement text. ¹

Enforcement context and risk implications

No public enforcement cases were provided for this requirement. Practically, weak logging increases incident impact because you cannot confirm scope, root cause, or data access patterns. It also increases regulatory and contractual risk: you may be unable to support customer notifications, audit inquiries, or post-incident reports with reliable evidence.

Practical execution plan (30/60/90-day)

First 30 days (stand up governance and baseline coverage)

• Approve Event Logging Standard and Log Review Procedure
• Build the log source inventory and coverage matrix for all in-scope cloud environments
• Enable control plane logging and centralize it
• Define retention rules and implement them for the central log store
• Start a log review record (ticket/case template) and run the first review cycle

Next 60 days (expand workload coverage and integrity controls)

• Add workload/app logging for critical systems and high-risk data paths
• Implement alerts for logging disablement, forwarding failure, and suspicious log access
• Tighten access controls to logging platforms and document segregation of duties
• Run a coverage test and remediate gaps

By 90 days (make it repeatable and auditable)

• Normalize parsing and correlation for priority log sources
• Operationalize routine reporting (review completion, findings, remediation status)
• Perform an internal audit-style walkthrough: pick a recent security event, show end-to-end evidence from event to review to action
• If you are coordinating across many teams, use Daydream to maintain the log coverage register, collect review attestations, and keep artifacts audit-ready without chasing screenshots

Frequently Asked Questions

What counts as “regularly reviewed” for ISO/IEC 27017 event logging?

ISO/IEC 27017 requires regular review but does not define a cadence. Set a documented cadence by log type and risk, then retain proof each review occurred and produced a result. ¹

Do I need to log both cloud control plane events and application events?

Yes if they are part of your cloud service delivery and security monitoring. The requirement explicitly includes user activities, exceptions, faults, and security events, which usually spans both platform and application layers. ¹

We use multiple third parties (SaaS, MSP, logging provider). Who owns the logging requirement?

You still own demonstrating the outcome. Allocate responsibilities contractually and operationally, then keep evidence that required logs are produced, retained, and reviewed across the shared responsibility boundary. ¹

How do we prove log integrity to auditors?

Show restricted access, separation of duties, retention enforcement, and detection of logging being disabled or altered. Auditors respond well to evidence of tamper-resistant storage plus alerts on configuration changes.

What evidence is most persuasive for “review”?

Dated review records tied to a procedure: a SIEM case, ticket, or signed checklist that lists scope, findings, and actions taken. Pair it with a sample of follow-up remediation tickets to show the review drives outcomes.

If we can’t centralize every log source yet, can we still meet the requirement?

Potentially, but you need a controlled approach: documented scope limitations, compensating reviews at the source, and a plan to bring remaining sources into the central system. Centralization simplifies proving “kept” and “reviewed” across cloud services. ¹

Footnotes

1. ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services