ISO/IEC 27017 FAQ Logging

Define the required event categories and fields before comparing services. Include security-relevant identity and access events, customer and provider administrative actions visible to the customer, configuration changes, application and workload events, and incident-relevant service events where they apply. The customer should verify that the named service and tier meet those requirements; the provider should supply logging capabilities. In IaaS, the provider's responsibility can stop at infrastructure components while the customer logs its own virtual machines and applications.

Apply a separate branch to delegated privileged operations. Clause 12.4.3 says the operation and its performance should be logged, and the customer should decide whether provider logging is appropriate or whether additional customer logging is needed. Ask which clock the provider uses and how customer systems can synchronize to it; without synchronization, events from both sides can be difficult to reconcile.

Treat service monitoring as a capability built on records and service signals, not as another name for a log. CLD.12.4.5 says the provider should document capabilities that let the customer monitor specified aspects relevant to its use, such as detecting use of the service to attack others or leakage of sensitive data. Access should expose only the customer's own service instances, the monitoring data should be consistent with event logs, and it should help assess service-level terms.

Set event retention, protection, export delay, alert thresholds, and response times from the customer's risks, incident needs, laws, contracts, records rules, and technical constraints. ISO/IEC 27017:2015 does not supply one retention number or require a particular monitoring product.

Keep the approved logging requirements, service-specific allocation, provider capability description, enabled-event configuration, access list, retention and protection settings, clock information, export or integration status, alert rules, service-level mapping, and investigation procedure. Preserve evidence of configuration and operation; a provider feature list proves availability, not enablement or successful receipt.

Run a known-event test through the complete path. Record the source event, actor and resource, provider and customer timestamps, receipt time, expected and actual fields, tenant boundary, alert result, analyst action, escalation, retained record, and dropped or delayed data. Repeat separately for infrastructure, workload, application, or privileged sources when different parties or pipelines handle them.

ISO/IEC 27017 allocates customer and provider duties but does not prescribe internal approval titles. As a practical model, the cloud service owner and security monitoring owner can approve the event set and responsibility split, platform or application owners can operate customer logging, and supplier management can maintain provider commitments.

Include privacy, records, legal, or regulatory owners when they set retention, access, or disclosure constraints. The authorized risk owner decides whether an unresolved visibility gap is acceptable.

ISO/IEC 27017:2015 sets no fixed logging-review period. Review after service, tier, architecture, event schema, retention, export, alerting, provider, or incident-process changes. Repeat the known-event test after integrations or clock settings change.

Also review after an incident reveals missing, inaccessible, late, or ambiguous records. Update the agreement, responsibility matrix, monitoring procedure, and risk treatment together.