A cloud provider may secure the underlying infrastructure, but your organization usually remains responsible for configuration, identities, data handling, and evidence. This cloud shared responsibility compliance checklist helps you map each obligation to an owner, document what your provider covers, and maintain proof that your controls work as services, regions, contracts, and processing activities change.
Overview
Shared responsibility is a useful operating model for cloud security compliance, not a substitute for reading service documentation or interpreting your specific regulatory obligations. Providers generally describe the security of the cloud infrastructure they operate, while customers are responsible for how they configure and use cloud services. The exact boundary depends on the provider, service model, product configuration, deployment architecture, and contract.
For example, a provider may maintain physical facilities, core networking, and the managed service platform. Your team may still need to manage administrator access, application permissions, encryption settings, secrets, logging, retention, backups, vulnerability remediation, and incident procedures. In a virtual machine environment, you may have more operating-system responsibilities than you would with a managed database or serverless service.
The compliance risk appears when a team assumes that a provider certificate, security report, or contract covers the entire environment. A provider’s attestations can support your program, but they do not normally prove that your tenant configuration, code, data flows, access decisions, or internal processes meet every applicable requirement.
Use a responsibility matrix to make the boundary visible. For every important control, record:
- Requirement: the security, privacy, contractual, or internal policy obligation.
- Cloud component: the account, region, service, application, database, network, or data flow involved.
- Provider responsibility: what the provider operates, maintains, or makes available.
- Customer responsibility: what your organization must configure, operate, review, or prove.
- Owner: the person or team accountable for the control.
- Evidence: the record that demonstrates design and operation.
- Status and review date: whether the control is complete, deficient, accepted, or awaiting review.
This structure turns a general cloud security statement into an auditable operating record. It also gives engineering, security, privacy, procurement, and audit teams a common view of unresolved gaps.
What to track
1. Services, accounts, and regions
Start with an accurate inventory. List production and non-production accounts, subscriptions, projects, tenants, cloud services, regions, environments, and important integrations. Record which services store, transmit, process, or provide access to personal, confidential, regulated, or customer data.
Include services that are easy to overlook: object storage, managed identity, monitoring, backups, message queues, analytics, support tools, deployment pipelines, and logging platforms. A responsibility matrix is only as reliable as the inventory behind it.
2. Identity and access management
Separate the provider’s responsibility for its identity platform from your responsibility for using it safely. Track administrator accounts, single sign-on, multifactor authentication, service accounts, privileged roles, access reviews, emergency access, key rotation, and termination procedures.
For each high-risk role, document who approves access, how access is provisioned, how often it is reviewed, and what evidence is retained. Avoid recording only that a control is “enabled.” Capture the configuration, review output, exceptions, and remediation history.
3. Configuration and network security
Track baseline settings for storage, databases, firewalls, security groups, public endpoints, network segmentation, encryption, key management, container registries, and administrator interfaces. Record whether the control is provider-managed, customer-configured, or shared.
For each exception, note the business reason, risk assessment, compensating control, approver, expiration date, and next review. Permanent exceptions should be treated as architecture decisions rather than left as undocumented findings.
4. Data protection and privacy operations
Map data flows from collection through deletion. Identify the controller and processor roles where relevant, the cloud services involved, the processing purpose, data categories, retention period, access groups, and locations or regions used. Keep this information aligned with your records of processing activities; the RoPA requirements checklist provides a practical structure for maintaining those records.
Track encryption in transit and at rest, customer-managed keys where used, backup copies, support access, subprocessors, deletion workflows, and data export or return procedures. A provider’s privacy documentation can inform your assessment, but your organization must still decide whether the service and configuration fit your processing purpose and risk profile.
5. Logging, monitoring, and detection
Define which events the provider generates and which events your team must enable, collect, protect, review, and respond to. Relevant records may include authentication events, privileged actions, configuration changes, network activity, data access, deployment events, and security alerts.
Document log sources, retention, time synchronization, access restrictions, alert ownership, review frequency, and failure handling. Logging that is available but not enabled, retained, or reviewed is unlikely to provide strong evidence of an operating control.
6. Vulnerability management, backups, and resilience
Clarify who patches the physical platform, managed service, operating system, libraries, containers, and application code. Track scanning coverage, remediation targets, risk acceptance, unsupported components, backup schedules, restoration tests, recovery objectives, and dependencies.
Backups need their own responsibility entry. Confirm who configures them, where copies are stored, who can delete them, how they are protected from unauthorized changes, and how restoration is tested. A backup job that runs successfully does not by itself demonstrate recoverability.
7. Incident response and provider notifications
Document how cloud-related incidents are detected, escalated, contained, investigated, and communicated. Identify the provider’s notification channels and your internal decision points. Your plan should address compromised credentials, exposed storage, malicious changes, data loss, service disruption, and suspected unauthorized access.
Keep contact details, escalation paths, evidence-preservation steps, customer communication responsibilities, and regulatory or contractual review steps current. For broader readiness, compare the matrix with your audit evidence checklist for SOC 2 and ISO 27001.
8. Provider assurance and contractual evidence
Track the provider’s applicable assurance reports, certifications, security documentation, data processing terms, service commitments, subprocessors, breach-notification terms, audit rights, and data return or deletion provisions. Record the document name, coverage period, services and regions covered, limitations, reviewer, and follow-up actions.
Do not treat an assurance report as a blanket approval. Map its scope to your actual services and note the controls that remain customer-owned. This mapping is particularly important when responding to customer security questionnaires or completing a vendor risk review.
| Control area | Provider may cover | Your organization must prove |
|---|---|---|
| Physical security | Facilities and underlying hardware | That your selected service and contract fit the required risk and data use |
| Identity | Identity features and availability | Roles, approvals, MFA, reviews, service accounts, and offboarding |
| Data protection | Platform encryption capabilities | Configuration, key ownership, retention, access, deletion, and data mapping |
| Logging | Available platform events | Activation, collection, retention, monitoring, and response |
| Resilience | Platform availability and infrastructure redundancy | Backups, recovery design, tests, dependencies, and business continuity |
| Incident response | Provider-side investigation and notification process | Your detection, escalation, customer communications, and regulatory assessment |
Cadence and checkpoints
Review the matrix on a recurring schedule rather than only before an audit. A practical cadence is:
- Monthly: review high-risk findings, privileged access, expiring exceptions, logging failures, backup errors, and changes to production services.
- Quarterly: reconcile the cloud inventory with the matrix, review access, validate evidence links, reassess critical providers, and test a sample of backup or incident procedures.
- Before a major release: assess new data flows, regions, integrations, permissions, retention settings, and monitoring requirements.
- At contract or renewal review: check assurance coverage, processing terms, subprocessors, service changes, notification language, and exit provisions.
- After an incident or material control failure: update ownership, assumptions, evidence requirements, and compensating controls.
Assign a named owner for each review and record the outcome. “Reviewed” should mean that someone compared the current environment with the documented responsibility, not merely opened a provider webpage. Link evidence to a controlled repository and use consistent naming so an auditor or internal reviewer can follow the trail.
Teams building a broader program can use the cloud compliance roadmap for startups to place these activities within a wider readiness plan. Keep policy review dates aligned with technical reviews; the policy review schedule can help coordinate that work.
How to interpret changes
Not every cloud change creates the same compliance impact. Classify changes by what they alter: data sensitivity, access scope, processing purpose, region, service model, internet exposure, retention, resilience, or provider dependency.
A change from a managed service to self-managed infrastructure usually increases customer-owned responsibilities. A new region may require a privacy and contractual review. A new integration may expand access and create a new processor or subprocessor question. A product feature that introduces profiling, sensitive data, or high-volume monitoring may warrant a documented privacy assessment; use the DPIA checklist for high-risk SaaS features as a related workflow.
When a provider changes its terms, service architecture, assurance scope, or notification process, compare the change with your matrix rather than assuming the existing assessment remains valid. Mark each affected row as unchanged, updated, requiring evidence, or requiring a risk decision.
Prioritize gaps using practical factors: the sensitivity and volume of data, privilege involved, external exposure, likelihood of misuse, detectability, recovery impact, contractual commitments, and the age of the evidence. A missing screenshot may be an evidence problem; an unreviewed administrator role is a control problem. Distinguishing the two helps teams choose the right response.
When to revisit
Revisit this cloud shared responsibility compliance checklist monthly for operational exceptions and at least quarterly for a full control review. Trigger an additional review whenever you add a cloud account, service, region, integration, data category, privileged role, or subprocessors; change a retention or encryption design; migrate between service models; renew a material contract; receive a provider assurance update; or experience a security or privacy incident.
End each review with three concrete outputs:
- Update the responsibility matrix and cloud inventory.
- Assign owners and due dates for every open gap or evidence request.
- Save the review record, supporting evidence, decisions, and exceptions in a controlled location.
Finally, compare the result with your vendor register and security questionnaire materials. The third-party risk register guide and security questionnaire response library can help keep external answers consistent with your internal evidence. A maintained matrix will not eliminate cloud risk, but it will make responsibility clearer, reviews repeatable, and audit readiness less dependent on last-minute reconstruction.
