Cloud Shared Responsibility Mapper
Identity and security ยท service category

Security monitoring: who owns each control

Collects security events, detects threats and alerts the people who respond. Delivered as software as a service unless your line says otherwise.

Places a line such as Security monitoring and threat detection. Map this line.

The split, area by area

Control areaOwnerWhy, and the clause
GOV Governance and policysharedEach party governs its own side: the provider the service it delivers, you which data and services you allow and who may procure them. The allocation between you has to be written down. ISO/IEC 27017 6.1.1
IAM Identity and accesssharedThe provider runs the sign-in service and its administrative plane; who holds an account, which role it carries and whether a second factor is enforced are yours. ISO/IEC 27017 9.2.3
DAT Data classification and handlingyoursWhat the data is, how it is labelled and where it may go is yours on every model; the provider only tells you what labelling and location options the service offers. ISO/IEC 27017 8.2.2
KEY Encryption and keysthe provider'sThe provider encrypts the application's data with keys it manages; a key you hold exists only where the service offers one and you turn it on. ISO/IEC 27017 10.1.2
NET Network securitythe provider'sThe provider runs the application's network end to end; you control only which addresses and devices may sign in, where the service offers it. ISO/IEC 27017 CLD.9.5.1
LOG Logging and monitoringyoursThe monitoring service is the tool; which sources you send it, which alerts you turn on and who answers them are yours. ISO/IEC 27017 CLD.12.4.5
VUL Vulnerability and patch managementthe provider'sThe provider patches the application and everything under it; you keep only the devices and integrations that reach it. ISO/IEC 27017 12.6.1
CFG Configuration and hardeningsharedThe provider hardens the platform it runs; every setting you choose in your tenancy, and a public or open default you leave on, is yours. ISO/IEC 27017 CLD.12.1.5
APP Application securitythe provider'sThe application is the provider's to build and test; your side is the integrations and extensions you add to it. ISO/IEC 27017 14.2.1
INC Incident responsesharedBoth sides respond: the provider must report incidents affecting your data within the agreed time, and you must detect and handle incidents in what you run and report to the provider what affects its service. ISO/IEC 27017 16.1.2
BCP Business continuity and backupsharedThe provider keeps the service available and may keep its own backups; whether you rely on those, keep your own copy and test the restore is yours to decide and prove. ISO/IEC 27017 12.3.1
PHY Physical and environmentalthe provider'sThe data centres, power, cooling, access to the floor and the disposal of retired media are the provider's; your evidence is its assurance report, not your own inspection. ISO/IEC 27017 11.2.7
SUP Supplier and subservicesharedThe provider must publish its side of the model and the suppliers behind the service; you must hold the matrix for your estate, read the provider's side and keep the agreement that binds both. ISO/IEC 27017 CLD.6.3.1
AIR AI use and data retentionsharedRetention and purpose settings in the service are yours to choose; how the provider itself retains and uses what you send is set by its terms, which you must read. ISO/IEC 27018 A.3.1

This category moves the line on logging and monitoring whatever the model: The monitoring service is the tool; which sources you send it, which alerts you turn on and who answers them are yours.

The clauses behind the split, quoted

The split is ours, drawn from the model and these clauses; it does not reproduce any provider's own matrix. Check it against your provider's shared responsibility documentation (named, not quoted) before you hand it to an assessor.

ISO/IEC 27017 6.1.1 Information security roles and responsibilities

Roles and responsibilities for the security of each cloud service should be allocated between the cloud service customer and the cloud service provider and inside each organisation. The customer should assign who owns the relationship, who manages customer-side controls and who evaluates the provider's information; the provider should state which responsibilities it accepts and which remain with the customer for each service it offers, so that no control falls between the two.

What an assessor asks to see:
  • Responsibility matrix per cloud service naming customer and provider owners
  • Provider service description or terms stating accepted responsibilities
  • Internal role assignments for cloud relationship and control ownership
Where it usually falls short:
  • A control both parties assume the other performs, typically backup, logging or key management
  • Responsibility matrix drafted at onboarding and never updated for new service features
Source: ISO/IEC 27017:2015
ISO/IEC 27017 9.2.3 Management of privileged access rights

Privileged access in a cloud service sits on both sides. The customer should control the privileged rights it holds over its tenancy, using strong authentication and keeping the number of privileged users small, and the provider should control privileged access of its own staff to the cloud service and to customer environments, with the assurance the customer asks for. The provider should offer sufficient authentication techniques for the customer's privileged accounts.

What an assessor asks to see:
  • List of privileged cloud accounts on the customer side with approvals
  • Provider description of privileged access controls for its staff
  • Evidence of multi-factor authentication on privileged cloud accounts
Where it usually falls short:
  • Provider root or console credentials shared between customer staff
  • No statement from the provider on how its administrators reach customer environments
Source: ISO/IEC 27017:2015
ISO/IEC 27017 8.2.2 Labelling of information

The customer should label information according to its classification before and while it is in a cloud service, using labelling the service can carry, and the provider should describe what labelling capability the service offers and whether labels survive processing. Both should agree how labels are handled where the provider's staff can see customer information.

What an assessor asks to see:
  • Labelling scheme applied to cloud-hosted information
  • Provider documentation of labelling features
  • Test that labels persist through the service
Where it usually falls short:
  • Labels stripped when information is uploaded to a service that cannot carry them
  • No labelling rule for information created inside the cloud service
Source: ISO/IEC 27017:2015
ISO/IEC 27017 10.1.2 Key management

Cryptographic keys used by the service should be explained to the customer: the provider should give information about the keys the service uses and the key management options available, including whether the customer may manage its own keys and how keys are protected and destroyed. The customer should decide who manages the keys for its cloud-hosted information and should keep management of keys it controls under its own key management policy.

What an assessor asks to see:
  • Key management arrangement per cloud service stating who holds keys
  • Provider documentation of key protection, rotation and destruction
  • Customer key management records for customer-managed keys
Where it usually falls short:
  • Keys held by the provider with no statement of who can access them
  • Customer-managed keys lost, making cloud-hosted data unrecoverable
Source: ISO/IEC 27017:2015
ISO/IEC 27017 CLD.9.5.1 Segregation in virtual computing environments

A customer's virtual environment running on a cloud service is to be protected from other customers of the service and from unauthorised persons. The provider should enforce logical segregation between tenants across compute, storage and network, should segregate its own management environment from customer environments, and should describe the segregation to customers; the customer relies on that segregation and should verify the description before placing sensitive information in the service.

What an assessor asks to see:
  • Provider description of tenant segregation across compute, storage and network
  • Independent assurance covering tenant isolation
  • Customer review of the segregation before onboarding
Where it usually falls short:
  • Isolation claimed at the hypervisor with shared storage that is not segregated
  • Provider management plane reachable from a customer network
Source: ISO/IEC 27017:2015
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
ISO/IEC 27017 12.6.1 Management of technical vulnerabilities

Technical vulnerabilities in a cloud service are divided between what the provider patches and what the customer patches, and the provider should give the customer information about how it manages vulnerabilities affecting the cloud service, including the parts the provider patches and the parts the customer must patch itself, and the notification it gives. The customer should manage vulnerabilities in the components it controls (its virtual machines, applications and configuration) and should track the provider's handling of the rest.

What an assessor asks to see:
  • Provider vulnerability management statement and notification channel
  • Customer vulnerability process covering cloud-hosted components it controls
  • Patch records for customer-managed cloud assets
Where it usually falls short:
  • Customer assumes the provider patches guest operating systems it actually leaves to the customer
  • No provider channel for vulnerability notification the customer monitors
Source: ISO/IEC 27017:2015
ISO/IEC 27017 CLD.12.1.5 Administrator's operational security

Procedures for administrative operations of a cloud computing environment are to be defined, documented and monitored. The provider should document how its administrators operate the service and monitor their activity; the customer should document the administrative procedures for its own use of the service, covering critical operations such as configuration changes, backup and restore, and access management, and should monitor that they are followed, because a mistaken administrative action in a cloud console can affect the whole tenancy.

What an assessor asks to see:
  • Documented administrative procedures for the cloud environment on each side
  • Monitoring records of administrative activity
  • Provider description of its administrative practice
Where it usually falls short:
  • Cloud console administration done ad hoc with no procedure for high-impact actions
  • Administrative activity logged but never monitored
Source: ISO/IEC 27017:2015
ISO/IEC 27017 14.2.1 Secure development policy

Where the customer develops applications on a cloud service, its secure development policy should address the cloud environment, including the provider's development tools and interfaces and the security of code and data in shared development resources. The provider should give customers information about the secure development practices and the interfaces it makes available.

What an assessor asks to see:
  • Customer secure development policy with a cloud section
  • Provider documentation of development interfaces and practices
  • Review of cloud-hosted development environments against the policy
Where it usually falls short:
  • Production credentials used in a cloud development environment
  • Customer developers using provider tooling with no security guidance
Source: ISO/IEC 27017:2015
ISO/IEC 27017 16.1.2 Reporting information security events

The provider should give the customer a mechanism to report information security events it observes in the cloud service, and should report to the customer events and incidents affecting the customer's information within the agreed time. The customer should report to the provider events it detects that may affect the service, and should tell its own users how to report events involving cloud services.

What an assessor asks to see:
  • Provider reporting channel and notification commitment
  • Customer procedure for reporting events to the provider
  • Records of events reported in each direction
Where it usually falls short:
  • Incident notification obligation in the contract with no working contact behind it
  • Customer users unaware that cloud service events should be reported
Source: ISO/IEC 27017:2015
ISO/IEC 27017 12.3.1 Information backup

The provider should specify the backup capabilities it offers, including scope, frequency, retention, protection of the backups and how the customer may restore, and should state what it does not back up. The customer should decide which of its cloud-hosted information needs backup, whether to rely on the provider's backups or keep its own, and should test that restoration works.

What an assessor asks to see:
  • Provider backup specification for the service
  • Customer backup decision and arrangements per cloud service
  • Restore test records
Where it usually falls short:
  • Customer assumes the provider backs up its data when the service only replicates it
  • Backups held only inside the same cloud account they protect
Source: ISO/IEC 27017:2015
ISO/IEC 27017 11.2.7 Secure disposal or re-use of equipment

The provider should arrange for secure disposal or re-use of equipment that has held customer information, so that customer data cannot be recovered from storage that is retired or reassigned to another tenant, and should tell customers about the arrangement. The customer should confirm that the provider's disposal practice meets its requirements for the information it places in the service.

What an assessor asks to see:
  • Provider media sanitisation and disposal procedure
  • Disposal or destruction records
  • Customer review of the provider's disposal statement
Where it usually falls short:
  • Storage reassigned between tenants without sanitisation
  • Customer requirement for certified destruction not passed to the provider
Source: ISO/IEC 27017:2015
ISO/IEC 27017 CLD.6.3.1 Shared roles and responsibilities within a cloud computing environment

Responsibilities for information security in the use of a cloud service are shared, and the standard requires that they be allocated to identified parties, documented, communicated and implemented by both the cloud service customer and the cloud service provider. The provider should document and publish the responsibilities it takes on and those it leaves with the customer; the customer should record the allocation, assign owners inside its organisation, and act on its share.

What an assessor asks to see:
  • Shared responsibility document for each cloud service, agreed by both parties
  • Communication of the allocation to the customer's users and the provider's staff
  • Evidence the customer performs its allocated responsibilities
Where it usually falls short:
  • A published provider responsibility model that the customer never mapped to its own roles
  • Allocation that names organisations but no individuals
Source: ISO/IEC 27017:2015
ISO/IEC 27018 A.3.1 Public cloud PII processor's purpose

PII to be processed under a contract should not be processed for any purpose independent of the instructions of the cloud service customer; the processor acts only on the customer's documented instructions and does not determine purposes of its own for customer PII.

What an assessor asks to see:
  • Contract clause restricting processing to customer instructions
  • Internal rule and controls preventing secondary use
  • Evidence of instruction-based processing
Where it usually falls short:
  • Analytics or product improvement run on customer PII without instruction
  • Instructions accepted informally with no record
Source: ISO/IEC 27018:2019

Other services in identity and security