Cloud Shared Responsibility Mapper
Control area

Logging and monitoring: who owns it on each service model

Which events are logged, where the logs go, who watches them and who is alerted. The provider logs its platform; turning on and reviewing the logs of your own use is yours.

The split by service model

Service modelOwnerWhy, and the clause
Infrastructure as a serviceyoursLogs from the operating system, your applications and your account activity are yours to switch on, keep and watch; the provider logs its own layers. ISO/IEC 27017 CLD.12.4.5
Platform as a servicesharedThe provider logs the platform and makes activity logs available; turning them on, sending them somewhere you keep and reviewing them is yours. ISO/IEC 27017 CLD.12.4.5
Software as a servicesharedThe provider logs the platform and makes activity logs available; turning them on, sending them somewhere you keep and reviewing them is yours. ISO/IEC 27017 CLD.12.4.5
Serverless functions and event servicessharedThe provider logs the platform and makes activity logs available; turning them on, sending them somewhere you keep and reviewing them is yours. ISO/IEC 27017 CLD.12.4.5
Hosted AI models and AI platformssharedThe provider logs the platform and makes activity logs available; turning them on, sending them somewhere you keep and reviewing them is yours. ISO/IEC 27017 CLD.12.4.5

Services that move the line

The clauses each framework attaches

6 quoted
FrameworkClause
Cloud Controls Matrix v4.0.1CCM-LOG-03 Security Monitoring and Alerting
ISO/IEC 27017:2015ISO/IEC 27017 CLD.12.4.5 Monitoring of cloud services
SOC 2 Trust Services CriteriaSOC 2 CC7.2 Monitors system components for anomalies indicating malicious acts
ISO/IEC 27001:2022 Annex AISO/IEC 27001 8.15 Logging
CMMC 2.0CMMC AU.L2-3.3.1 System Auditing
C5 cloud criteria catalogueC5-OPS-10 Logging and Monitoring - Concept
CCM-LOG-03 Security Monitoring and Alerting

Watch applications and their underlying infrastructure for security-relevant events, and alert responsible stakeholders when those events and their metrics cross defined thresholds.

What an assessor asks to see:
  • The list of security-relevant events monitored per application and platform
  • Alert rules and their thresholds
  • Routing showing which stakeholder receives which alert
  • Records of alerts raised and the response
Where it usually falls short:
  • Events collected but no alerting configured on them
  • Alerts routed to a queue nobody owns
  • Application layer events omitted while infrastructure is well covered
Source: Cloud Controls Matrix v4.0.1
ISO/IEC 27017 CLD.12.4.5 Monitoring of cloud services

The cloud service customer is to have the capability to monitor specified aspects of the operation of the cloud services it uses. The provider should give customers the means to monitor the aspects relevant to their security, such as service availability, security events and the use of their resources, and should describe those capabilities; the customer should decide which aspects it needs to monitor and should use the capabilities provided, supplementing them where the provider's monitoring is not enough.

What an assessor asks to see:
  • Provider description of monitoring capabilities offered to customers
  • Customer monitoring configuration for the cloud service
  • Evidence the monitoring output is reviewed and acted on
Where it usually falls short:
  • Monitoring capability offered but never enabled by the customer
  • Customer security monitoring that stops at its own network edge
Source: ISO/IEC 27017:2015
SOC 2 CC7.2 Monitors system components for anomalies indicating malicious acts

Monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine

What an assessor asks to see:
  • The monitoring design for system components and their operation, showing what constitutes anomalous behaviour
  • Detection rules or analytics deployed, and evidence of the tuning applied over time
  • Evidence of the sources monitored, covering infrastructure, applications, identity and, where applicable, physical and environmental conditions
  • Records of anomalies detected during the period and of the analysis performed to determine whether they represent a security event
  • Evidence of the coverage of the monitoring against the components in the system description
Where it usually falls short:
  • Logs collected without any detection logic applied, so anomalies are only visible in hindsight
  • Monitoring covers malicious acts and omits natural disaster and error, both of which the criterion names
  • Alert volume exceeding triage capacity, so alerts are closed without analysis
  • Components in the system description with no monitoring coverage at all
Source: SOC 2 Trust Services Criteria
ISO/IEC 27001 8.15 Logging

Produce, store, protect and analyse logs of activities, exceptions and faults.

What an assessor asks to see:
  • Log collection policy
  • Log storage and protection
  • Log review and analysis
  • Log retention and disposal
Where it usually falls short:
  • Inconsistent log collection across systems
  • Insufficient protection of log integrity
  • Irregular or undocumented log review
  • Retention periods not aligned with policy
Source: ISO/IEC 27001:2022 Annex A
CMMC AU.L2-3.3.1 System Auditing Level 2

Generate and retain system audit logs in sufficient scope and detail to support monitoring, analysis, investigation and reporting of unlawful or unauthorized system activity.

What an assessor asks to see:
  • Defined auditable event list and rationale for its scope
  • Logging configuration on in scope systems
  • Retention settings and evidence logs are retained for the defined period
  • Sample audit records showing captured content
Where it usually falls short:
  • Logging enabled with default event sets never assessed for sufficiency
  • Retention shorter than investigation needs
  • In scope systems missing from logging coverage
Source: CMMC 2.0
C5-OPS-10 Logging and Monitoring - Concept

Establish written logging and monitoring policies for systems in the provider's area of responsibility that define which events could breach protection goals, how logs are activated, paused and stopped, their purpose and retention, role responsibilities, time synchronisation and legal obligations.

What an assessor asks to see:
  • Logging policy listing the event types classified as security relevant
  • Documented retention period per log source with the legal basis cited
  • Responsibility matrix naming owners of log configuration and of log review
  • Time synchronisation standard specifying the authoritative time sources
Where it usually falls short:
  • Policy enumerates log sources yet never defines which events matter
  • No rule stating who may pause or switch off logging on a system
  • Retention periods in the policy inconsistent with the platform configuration
  • No authoritative time source defined, so records across components cannot be correlated
Source: C5 cloud criteria catalogue