Direct answer: AWS, Azure, and Google Cloud secure the physical facilities and foundational infrastructure behind their services, but they do not take over your data governance, identities, access decisions, application behavior, or every configuration. The exact boundary moves with each service. Prevent gaps by mapping responsibility at the workload-and-service level, assigning an accountable owner for every customer or shared control, naming the evidence that proves it works, and reviewing the map whenever architecture, contracts, or provider features change.
What to do first
- Inventory the real workload, not just the cloud provider.
- Classify every service as IaaS, PaaS, SaaS, serverless, or a documented hybrid.
- Assign customer, provider, and shared controls to named owners.
- Define evidence and a review cadence before calling a control complete.
- Test identity, logging, recovery, and incident handoffs across provider boundaries.
This guide is for teams that use, procure, or govern services across Amazon Web Services, Microsoft Azure, and Google Cloud. It is a practical ownership model, not legal advice or a replacement for a provider contract. No AWS account, Azure subscription, Google Cloud project, support plan, or live control was configured or tested for this article. Product documentation and service boundaries can change, so validate every important assignment against the exact service documentation and agreement in force for your workload.
What shared responsibility actually means
Shared responsibility is not a promise that both parties will somehow notice and cover the same gap. It is a division of work. The provider operates the cloud foundation; the customer secures what it chooses, configures, deploys, connects, and stores. Some controls are inherited from the provider. Some remain entirely with the customer. Others are shared because the provider and customer implement different layers of the same control.
AWS describes the boundary as security of the cloud versus security in the cloud. AWS protects the infrastructure that runs its services. The customer’s work depends on the services selected and can include guest operating systems, patches, applications, security groups, data classification, encryption choices, and permissions.
Microsoft’s Azure responsibility matrix shows responsibility moving across on-premises, IaaS, PaaS, and SaaS. It keeps customer data, configurations and settings, and identities and users on the customer side across those cloud deployment types. Microsoft also cautions that the matrix is governance guidance, not a legal conclusion or a modification of an agreement.
Google Cloud explains shared responsibility and “shared fate”. Shared fate adds provider guidance, secure blueprints, and partnership intended to improve outcomes. It does not erase the customer’s duties. Google still says customers must identify the controls required by their workloads, protect access and data, and understand which controls are customer-owned, provider-owned, or inherited.
The common rule is simple: moving up the managed-service stack transfers operational tasks, not accountability for every outcome. A provider may patch the host or runtime while you still own who can access the service, what data belongs there, how the application is configured, how alerts are handled, and whether recovery meets the business requirement.
Why one provider-wide chart is not enough
AWS, Azure, and Google Cloud each publish useful high-level diagrams, but a provider name is too broad to serve as a control boundary. An EC2 virtual machine, Azure App Service, and Google Workspace do not place the same tasks on the customer. Even services grouped under the same label can expose different identity, network, logging, backup, encryption, and recovery options.
For example, AWS says an EC2 customer manages the guest operating system, security patches, installed applications, and security-group configuration. For more abstracted services such as Amazon S3 and DynamoDB, AWS operates the infrastructure, operating system, and platform. The customer still decides how data is classified, who can access it, and which encryption options and IAM permissions apply.
Azure makes the same shift visible by service model. In IaaS, the customer owns the operating system, applications, and network controls above Microsoft’s physical infrastructure. In PaaS, Microsoft operates more of the runtime and operating system, while application configuration, code, data, identity, and access remain material customer concerns. SaaS transfers still more platform work, but customer data, users, settings, access policies, endpoint exposure, and business processes do not disappear.
Google Cloud’s guidance likewise says the customer carries most security responsibility in IaaS, shares application-level controls and IAM in PaaS, and retains access-control and data responsibilities in SaaS. Its shared-fate approach can provide stronger starting points and guidance, but the customer must still select, implement, and verify the controls appropriate to the workload.
That is why your working document should be a service-level responsibility register, not a screenshot copied from a provider marketing page.
Build a responsibility register that can be operated
A useful register connects architecture, ownership, implementation, and evidence. Create one row for each meaningful control within a defined workload. At minimum, capture:
- Workload and business owner: the application, data set, environment, and accountable business decision-maker.
- Provider, account, and service: the exact AWS service, Azure resource type, Google Cloud service, or third-party SaaS component.
- Service model: IaaS, PaaS, SaaS, serverless, or a provider-specific hybrid.
- Control objective: what must be true, such as “privileged access requires phishing-resistant authentication.”
- Responsibility: provider-owned, customer-owned, shared-independent, or shared-dependent.
- Implementation owner: a named internal team, managed service provider, software team, or vendor contact.
- Provider dependency: the feature, attestation, support process, or contractual commitment on which the control relies.
- Configuration location: the policy, infrastructure-as-code module, console path, or application setting.
- Evidence: the saved state, export, test result, alert, ticket, log, restore record, or provider report that demonstrates operation.
- Cadence and trigger: when to review the control and which architecture, service, contract, personnel, or incident changes force a new review.
The Cloud Security Alliance’s Cloud Controls Matrix 4.1 guidance uses provider-owned, customer-owned, and shared designations across IaaS, PaaS, and SaaS. It also warns that ownership varies by service and implementation. You do not need to adopt the entire framework to use the discipline: record who does what, for which service, and how the result is verified.
Map the controls most likely to fall between teams
Identity and privileged access
The provider runs identity services and underlying infrastructure, but you decide which identities exist, how they are federated, who receives privileges, how emergency access works, and when access is removed. Record separate owners for workforce identity, workload identity, service accounts, root or break-glass credentials, entitlement reviews, and authentication policy. Test a joiner, role change, departure, lost authenticator, and emergency-access event. A policy document is not proof that access was revoked or recovery works.
Data, encryption, and keys
Providers can supply encrypted storage, key-management services, hardware security modules, and compliance documentation. You still decide what data may enter the service, its classification, region, retention, sharing, backup, deletion, and key-management model. Document whether keys are provider-managed, customer-managed, or externally managed; who can administer them; what depends on them; and how loss, rotation, or revocation is handled. Default encryption is useful, but it does not answer whether the wrong identity can read the data.
Network exposure and service configuration
The provider protects its global network and physical infrastructure. You frequently control public endpoints, firewall or security-group rules, private connectivity, resource policies, cross-account trust, and application-level access. For managed services, the provider may own the base operating system while you own an option that makes the service public. Evidence should show the saved configuration and an independent exposure check, not only a deployment-success message.
Patching, runtime, and application security
In IaaS, guest operating systems and applications usually remain yours to patch. In PaaS or serverless, the provider operates more of the runtime, but you still own application code, dependencies, secrets, deployment policy, and supported configurations. In SaaS, you still manage tenant settings, users, integrations, data use, and business workflows. For every layer, record who tracks advisories, who decides urgency, who deploys the change, and who verifies that the vulnerable condition is gone.
Logging, detection, and incident response
A cloud provider can generate platform and service logs, but it may not enable, export, retain, correlate, or investigate them for your workload. Define required event sources, enablement, destinations, retention, integrity, alert rules, escalation, and access. Then generate controlled events where safe and confirm that a human or automation receives and handles them. For incidents, predefine what evidence your team can collect, what requires provider support, who opens the case, and how time-sensitive preservation requests are made.
Backup, resilience, and recovery
Service durability, high availability, replication, backup, restore, disaster recovery, and business continuity are different claims. A provider may operate redundant infrastructure while you remain responsible for selecting regions, configuring versioning or backups, protecting recovery credentials, maintaining application dependencies, and testing restoration. Record the recovery point and recovery time required by the business, then test a representative restore and keep the result.
Compliance and third-party assurance
Provider certifications and reports can support inherited controls. They do not prove that your workload configuration, data use, access policy, or operational process meets a legal or contractual requirement. Map each obligation to provider evidence and customer evidence separately. Have qualified legal, privacy, audit, or compliance professionals interpret obligations when the stakes require it.
Use a seven-step implementation sequence
- Set the boundary. Name the workload, environments, data, users, accounts, regions, integrations, and providers in scope.
- Inventory services. Export resources and identify the exact service and feature set, not merely “AWS,” “Azure,” or “GCP.”
- Classify the service model. Confirm which layers the provider operates and which settings or components remain under customer control.
- Map control ownership. Use provider documentation, contracts, architecture decisions, and a framework appropriate to your organization. Mark shared controls precisely.
- Assign internal accountability. Give every customer and shared control one accountable owner, including controls operated by an MSP or another vendor.
- Define and collect evidence. Pair each control with a saved configuration, test, log, ticket, provider report, or recovery record and an evidence owner.
- Verify and review. Test high-risk controls, close gaps, record accepted risk, and re-run the review after material change.
Verify the model instead of trusting the diagram
Start with a small sample of controls that can expose the organization quickly: privileged access, public storage or endpoints, logging, backups, recovery, and provider-support escalation. For each sample, compare four things:
- Expected ownership: what the register and provider documentation say.
- Saved state: the actual configuration, policy, entitlement, or contract in force.
- Operating result: a safe test showing that the control detects, prevents, restores, or escalates as intended.
- Review evidence: a dated record with result, exceptions, owner, and next action.
For example, do not stop after confirming that a provider offers audit logs. Verify that the relevant log is enabled for the right accounts and services, arrives in the intended destination, is protected from inappropriate alteration, is retained for the required period, and produces an actionable alert. Likewise, do not stop after enabling backups. Restore a representative workload or data set, validate dependencies and permissions, and record whether the business recovery target was met.
Provider attestations should be reviewed for scope, date, services covered, regions, carve-outs, and complementary customer controls. When a provider report says the customer must configure access reviews or monitoring, copy that requirement into your register with an internal owner and evidence—not into a folder labeled “vendor responsibility.”
Multi-cloud makes the handoffs harder
The challenge is not merely learning three consoles. Different providers use different resource hierarchies, policy languages, identity models, log schemas, control names, defaults, and evidence mechanisms. A centralized security tool can help, but it can also flatten important differences or create blind spots when a new service is not connected.
NIST’s August 2026 initial public draft on multi-cloud architecture challenges identifies structural friction in identity and access management, telemetry and logging, configuration and change management, data protection, and compliance or authorization. Because that document was still a draft as of September 29, 2026, treat its findings as current input rather than a final standard.
Build a common control language at the governance layer, then preserve provider-specific implementation underneath it. “Privileged access is reviewed” may be one common objective, but its evidence will differ across AWS accounts, Azure subscriptions, Google Cloud organizations and projects, and connected SaaS tenants. Normalize the outcome, not the details out of existence.
Common failure modes
“The provider handles security”
This phrase hides the service boundary. Replace it with a control-level statement: who configures it, who operates it, who monitors it, and who provides evidence.
Copying the provider’s generic chart
A generic chart is an orientation tool. It is not a workload inventory, service matrix, contract review, or operating assignment.
Treating an MSP as the accountable owner
A managed provider may perform work, but the customer still needs an internal accountable owner who verifies the service, manages exceptions, and acts when the relationship ends.
Assuming inherited controls prove compliance
A provider audit can establish evidence for provider-operated controls. It cannot prove the correctness of customer data flows, settings, identities, integrations, or procedures.
Leaving shared controls unnamed
“Shared” is incomplete unless each party’s task is written separately. Split the row when necessary: provider patches the host; customer patches the guest operating system and application.
Letting the matrix go stale
New services, acquisitions, region changes, identity migrations, contracts, and support changes can move the boundary. Tie the register to architecture and change management, and review high-impact responsibilities at least quarterly.
Decision
Use the provider diagrams to learn the pattern, then build a workload-specific responsibility register that your teams can operate and test. The safest question is not “Which cloud owns this control?” It is “For this service, configuration, data set, and failure scenario, who must act, what must they do, and what evidence will prove it happened?”
Begin with one critical workload across its full path: identity, data, network exposure, runtime, application, logging, recovery, compliance, and incident escalation. Close every unowned control before scaling the method. If you need a governance structure for that work, use EncryptCentral’s NIST CSF 2.0 90-day roadmap. For tenant-level identity and configuration examples, review the Microsoft 365 and Google Workspace security baselines.
