Cloud Shared Responsibility Mapper
Framework

Cloud Controls Matrix v4.0.1: the clauses behind the split

The Cloud Security Alliance's control framework for cloud computing. Its STA domain is the shared security responsibility model itself: STA-04 asks for the control-by-control ownership this tool draws. Always shown.

Shown on every map. The framework on the compliance library.

Control areas it anchors

14
AreaClause
Governance and policyCCM-GRC-06
Identity and accessCCM-IAM-14
Data classification and handlingCCM-DSP-04 · CCM-DSP-19
Encryption and keysCCM-CEK-03 · CCM-CEK-08
Network securityCCM-IVS-03
Logging and monitoringCCM-LOG-03
Vulnerability and patch managementCCM-TVM-07
Configuration and hardeningCCM-IVS-04
Application securityCCM-AIS-04
Incident responseCCM-SEF-07
Business continuity and backupCCM-BCR-08
Physical and environmentalCCM-DCS-09
Supplier and subserviceCCM-STA-04 · CCM-STA-06
AI use and data retentionCCM-DSP-12 · CCM-DSP-16

Every clause cited, quoted

21 of the 197 held

The requirement text is our statement of each clause, read against the copy we hold and cited to it; it is not the instrument verbatim.

CCM-AIS-04 Secure Application Design and Development

Build applications through a secure development lifecycle so the organisation's security requirements are applied at design, build, deployment and operation.

What an assessor asks to see:
  • The documented secure development lifecycle with security activities at each stage
  • Design review or threat model records for recent applications
  • Evidence of security requirements being carried into build and deployment
  • Records showing the lifecycle applied to a real project end to end
Where it usually falls short:
  • Security activity concentrated at the end of the lifecycle only
  • Threat modelling done for flagship projects and skipped elsewhere
  • Operational stage excluded, so security requirements stop at go-live
Source: Cloud Controls Matrix v4.0.1
CCM-BCR-08 Backup

Back up cloud-held data on a defined cycle, protect the confidentiality and integrity of the backups, and prove by restore testing that the data can actually be recovered.

What an assessor asks to see:
  • Backup schedules and job success records
  • Backup encryption and access control configuration
  • Restore test results with date, scope and outcome
  • Retention settings matched to the recovery point objective
Where it usually falls short:
  • Backups running successfully but never restore tested
  • Backups readable by the same credentials that could destroy production
  • Restore tested for one system and the result generalised to all
Source: Cloud Controls Matrix v4.0.1
CCM-CEK-03 Data Encryption

Apply cryptographic protection to stored data and to data moving across networks, using libraries that hold certification against an approved standard.

What an assessor asks to see:
  • Configuration evidence showing encryption enabled at rest and in transit per system
  • The certification of the cryptographic libraries or modules in use, such as a validation certificate
  • Inventory of data stores and transport paths with their encryption status
  • Exceptions where encryption is not applied and the risk acceptance behind them
Where it usually falls short:
  • Encryption at rest claimed from a provider default without verification per data store
  • Uncertified or self-built cryptographic implementations in use
  • Internal traffic left unencrypted because it is considered a trusted network
Source: Cloud Controls Matrix v4.0.1
CCM-CEK-08 CSC Key Management Capability

Give cloud customers the means to manage the encryption keys that protect their own data.

What an assessor asks to see:
  • Documentation of the customer key management capability offered
  • Technical evidence the capability works, such as a customer-managed key configuration
  • Guidance published to customers on how to use it
  • Records of customers who have taken it up
Where it usually falls short:
  • Capability described in marketing material but not available in the product
  • Customer keys held in a way the provider can still unilaterally use
  • No documentation, so customers cannot exercise the capability
Source: Cloud Controls Matrix v4.0.1
CCM-DCS-09 Secure Area Authorization

Admit only authorised people to secure areas, restrict and monitor every entry and exit point with physical access mechanisms, and retain the access records for the period the organisation has set.

What an assessor asks to see:
  • The authorised access list per secure area and its review records
  • Physical access control configuration covering ingress and egress
  • Access logs retained for the defined period
  • Records of access reviews and removals
Where it usually falls short:
  • Egress not controlled or monitored, only entry
  • Access list never reviewed, so leavers retain badge rights
  • Retention period undefined, so logs are purged inconsistently
Source: Cloud Controls Matrix v4.0.1
CCM-DSP-04 Data Classification

Assign each dataset a classification reflecting its type and sensitivity.

What an assessor asks to see:
  • The classification scheme with defined levels and criteria
  • Classification values recorded against datasets
  • Evidence classification drives handling, such as differing controls by level
  • Review records for reclassification
Where it usually falls short:
  • Scheme published but most data left unclassified
  • Classification assigned without any control difference between levels
  • Datasets classified at creation and never reassessed when their content changed
Source: Cloud Controls Matrix v4.0.1
CCM-DSP-12 Limitation of Purpose in Personal Data Processing

Confine personal data processing to the purposes declared to the data subject and permitted by applicable law, and be able to demonstrate that limit.

What an assessor asks to see:
  • The declared purposes per processing activity and the notice given to data subjects
  • Controls that prevent processing outside the declared purpose
  • Evaluation evidence such as a review of actual processing against declared purpose
  • Records of new purposes and how consent or legal basis was re-established
Where it usually falls short:
  • Data collected for one purpose reused for analytics without re-establishing a basis
  • Declared purposes written so broadly they permit anything
  • No review comparing actual processing to declared purpose
Source: Cloud Controls Matrix v4.0.1
CCM-DSP-16 Data Retention and Deletion

Manage data retention, archiving and deletion against business requirements and applicable law, so data is neither kept longer nor destroyed sooner than allowed.

What an assessor asks to see:
  • The retention schedule by data type with the requirement behind each period
  • Evidence retention periods are enforced technically
  • Deletion records at end of retention
  • Legal hold procedure and its interaction with deletion
Where it usually falls short:
  • Retention schedule published with no technical enforcement
  • Data retained indefinitely because deletion was never built
  • Legal hold not accounted for, so data under hold is deleted
Source: Cloud Controls Matrix v4.0.1
CCM-DSP-19 Data Location

Record the physical locations where data is held, processed and backed up, and be able to produce that record.

What an assessor asks to see:
  • The data location record covering processing, storage and backup sites
  • The method that keeps it current as infrastructure changes
  • Evidence it is available to customers or regulators who may ask
  • Coverage of sub-processor locations
Where it usually falls short:
  • Locations recorded for primary storage with backup and replica locations omitted
  • Record based on contracted regions rather than actual deployment
  • Sub-processor locations unknown
Source: Cloud Controls Matrix v4.0.1
CCM-GRC-06 Governance Responsibility Model

Document who plans, implements, operates, assesses and improves the governance programme, and what each of those roles is accountable for.

What an assessor asks to see:
  • A responsibility model covering plan, implement, operate, assess and improve
  • Named roles or individuals against each
  • Evidence the assessment role is independent of the operate role
  • Review of the model as the organisation changes
Where it usually falls short:
  • Assessment and operation held by the same role, removing independence
  • Model documented at a level too abstract to hold anyone accountable
  • Improvement stage unassigned, so findings never drive change
Source: Cloud Controls Matrix v4.0.1
CCM-IAM-14 Strong Authentication

Authenticate access to systems, applications and data, using multifactor authentication at minimum for privileged users and sensitive data, and digital certificates or equivalent strength for system identities.

What an assessor asks to see:
  • Authentication configuration per system showing the factors required
  • Evidence multifactor authentication covers all privileged users and sensitive data access
  • The mechanism used for system identity authentication
  • Exception records where multifactor authentication is not applied
Where it usually falls short:
  • Multifactor authentication enforced at the perimeter but bypassable by direct application access
  • Service and system identities authenticating with static shared secrets
  • Exceptions granted with no expiry or compensating control
Source: Cloud Controls Matrix v4.0.1
CCM-IVS-03 Network Security

Restrict traffic between environments to authenticated and authorised connections, encrypt and monitor it, and review the configuration at least annually with a written justification for every allowed service, protocol, port and compensating control.

What an assessor asks to see:
  • Firewall and network policy rule sets between environments
  • The written business justification for each allowed service, protocol and port
  • Annual review record of the rule set
  • Evidence of encryption and monitoring on inter-environment traffic
Where it usually falls short:
  • Rules accumulated over years with no justification recorded
  • Any to any rules left in place from a migration
  • Annual review performed on the perimeter only, not between internal environments
Source: Cloud Controls Matrix v4.0.1
CCM-IVS-04 OS Hardening and Base Controls

Harden host and guest operating systems, hypervisors and the infrastructure control plane to a documented security baseline enforced by technical controls.

What an assessor asks to see:
  • The hardening baselines per platform and the standard they derive from
  • Compliance scan results against the baselines
  • Technical enforcement such as configuration management or policy as code
  • Exception records for deviations
Where it usually falls short:
  • Baselines documented but compliance never measured
  • Control plane excluded, with only guest operating systems hardened
  • Deviations found repeatedly and never remediated or accepted
Source: Cloud Controls Matrix v4.0.1
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
CCM-SEF-07 Security Breach Notification

Notify affected parties of security breaches, including breaches reaching the organisation through its supply chain, within the timeframes set by service agreements, law and regulation.

What an assessor asks to see:
  • The breach notification procedure with the timeframes from each obligation
  • The obligations register showing notification requirements per jurisdiction and contract
  • Notification records for actual breaches with timestamps
  • Evidence supply chain breaches are captured and assessed for notification
Where it usually falls short:
  • Regulatory timeframes documented while contractual ones are not
  • Supplier breach not treated as a notifiable event for the organisation's own customers
  • Notification decision made without legal input and recorded only informally
Source: Cloud Controls Matrix v4.0.1
CCM-STA-02 SSRM Supply Chain

Apply and manage the shared security responsibility model along the whole supply chain behind the cloud service, and document how it is applied.

What an assessor asks to see:
  • Documentation of the model applied to each supply chain tier
  • Evidence of management activity, such as periodic confirmation with suppliers
  • Identification of where responsibility passes between parties
  • Gaps identified and how they are closed
Where it usually falls short:
  • Model applied to the direct relationship only, with fourth parties unexamined
  • Responsibility boundaries assumed rather than agreed
  • Documentation produced at onboarding and never revisited
Source: Cloud Controls Matrix v4.0.1
CCM-STA-03 SSRM Guidance

Give cloud customers written guidance explaining how the shared security responsibility model applies to them across the supply chain.

What an assessor asks to see:
  • The customer-facing shared responsibility guidance
  • Evidence it is published and reachable by customers
  • Coverage of supply chain elements, not only the direct service
  • Version and review history of the guidance
Where it usually falls short:
  • Guidance written for the flagship service only
  • Guidance stops at the direct relationship and ignores sub-providers
  • Guidance not updated when the service or its suppliers changed
Source: Cloud Controls Matrix v4.0.1
CCM-STA-04 SSRM Control Ownership

State, control by control, which responsibilities sit with the provider, which sit with the customer and which are shared for the service offered.

What an assessor asks to see:
  • The control by control responsibility matrix for the service
  • Evidence every control in the framework carries an ownership determination
  • The basis for each shared designation
  • Review of the matrix as the service changes
Where it usually falls short:
  • Matrix covering a subset of controls with the rest left undetermined
  • Controls marked shared with no explanation of the split
  • Matrix not updated after a service change altered the boundary
Source: Cloud Controls Matrix v4.0.1
CCM-STA-06 SSRM Control Implementation

Implement, operate and assess the parts of the shared responsibility model that fall to the organisation, rather than assuming a provider covers them.

What an assessor asks to see:
  • Evidence of implementation for each customer-side responsibility
  • Operating records showing the controls run
  • Assessment or audit results covering those controls
  • Ownership assigned per responsibility
Where it usually falls short:
  • Customer-side responsibilities documented but not implemented
  • Implementation assumed from a provider certification that does not cover it
  • No assessment, so effectiveness of the customer side is unknown
Source: Cloud Controls Matrix v4.0.1
CCM-STA-07 Supply Chain Inventory

Maintain an inventory of every supply chain relationship the organisation depends on.

What an assessor asks to see:
  • The supply chain inventory with the service each supplier provides
  • The process by which new relationships enter the inventory
  • Criticality or risk rating per relationship
  • Evidence of currency, such as reconciliation against procurement records
Where it usually falls short:
  • Inventory covers contracted suppliers and omits services procured on expense cards
  • Fourth party dependencies not captured
  • Inventory not reconciled, so exits and additions are missed
Source: Cloud Controls Matrix v4.0.1
CCM-TVM-07 Vulnerability Identification

Scan organisationally managed assets for vulnerabilities at least monthly through a defined and evaluated process.

What an assessor asks to see:
  • Scan schedules and completed scan records covering the last several months
  • Asset coverage evidence comparing scanned assets to the asset inventory
  • Authenticated scanning configuration where applicable
  • Evaluation that the scanning finds what it should
Where it usually falls short:
  • Coverage gaps between the asset inventory and what is actually scanned
  • Unauthenticated scanning only, understating the findings
  • Monthly cadence claimed with gaps in the scan history
Source: Cloud Controls Matrix v4.0.1