Shared Responsibility Across AWS, GCP, and Azure

A startup migrates to AWS. The CTO tells the board: "We're on AWS now, so our infrastructure is secure — AWS is SOC 2 certified." Six months later, an auditor finds 14 S3 buckets with public read access, an IAM user with full admin privileges and no MFA, and CloudTrail disabled in two regions.

AWS was never responsible for any of those things. The company was.

This is the shared responsibility model, and it is the single most important concept in cloud GRC. Every audit finding, every control narrative, every risk assessment you write in your career maps back to one question: whose job was this?

Security OF the cloud vs. Security IN the cloud

AWS coined the clearest articulation: they handle "security of the cloud" — the physical data centers, the hypervisor, the global network backbone, the hardware. You handle "security in the cloud" — how you configure IAM, what your S3 bucket policies allow, whether CloudTrail is enabled, whether your VPC security groups are locked down.

The provider builds a secure platform. You are responsible for using it securely.

This is not a suggestion or a best practice. It is a contractual and regulatory reality. When an auditor reviews your SOC 2 controls, they assume you understand this split. They will not ask AWS about your IAM policies. They will ask you.

Layer               IaaS              PaaS              SaaS
─────────────────   ────────────────  ────────────────  ────────────────
Data governance     Customer          Customer          Customer
Access management   Customer          Customer          Customer
Application code    Customer          Customer          Provider
Runtime / OS        Customer          Provider          Provider
Network config      Shared            Provider          Provider
Virtualization      Provider          Provider          Provider
Physical security   Provider          Provider          Provider
─────────────────   ────────────────  ────────────────  ────────────────

Key insight: Data governance and access management are ALWAYS yours.
The provider never manages who in your org can access what.

The responsibility split changes as you move from IaaS to PaaS to SaaS

Notice what stays constant across all three models: data governance and access management are always the customer's responsibility. It doesn't matter if you're running bare EC2 instances or using a fully managed SaaS product. You decide who has access, what data classification applies, and how long data is retained.

This is why identity and access management dominates compliance work. It's the one thing that never shifts to the provider.

AWS shared responsibility

AWS publishes the most explicit version of this model. Their documentation breaks it into two clean halves.

What AWS handles:

Physical security of data centers (biometric access, 24/7 surveillance, hardware destruction on decommission)
Hypervisor and host OS isolation between customer workloads
Network infrastructure (backbone, edge locations, DDoS protection at the infrastructure layer)
Managed service internals — when you use RDS, AWS patches the database engine; when you use Lambda, AWS manages the execution environment
Global infrastructure availability (regions, availability zones, redundancy)

What you handle:

IAM configuration — who has access, what permissions they hold, whether MFA is enforced, whether access keys are rotated. This is the number one audit focus area.
S3 bucket policies — encryption settings, public access blocks, versioning, lifecycle rules. A misconfigured bucket policy is a control failure, not an AWS failure.
VPC security groups and NACLs — which ports are open, which CIDR ranges can connect, whether your database is exposed to the internet.
Encryption key management — KMS key policies, key rotation schedules, who can decrypt what. AWS provides the tool (KMS); you decide how to use it.
OS patching on EC2 — if you chose IaaS, you own the operating system. Unpatched instances are your finding.
CloudTrail configuration — enabling logging, setting retention, ensuring logs are stored in an immutable bucket. AWS provides the service; enabling it is on you.
Application-level security — input validation, authentication flows, secrets management, dependency patching. None of this is AWS's problem.

The pattern: AWS gives you secure building blocks. Whether you assemble them securely is entirely up to you.

GCP shared responsibility

Google takes the same concept and brands it "shared fate." The framing is slightly different — Google positions themselves as more actively helping customers secure their workloads — but the contractual split is nearly identical.

What GCP handles:

Physical infrastructure and data center security
Hardware encryption at rest by default (Google encrypts all data at rest with no customer action required — this is a genuine differentiator)
The container-based architecture that isolates workloads
Managed service internals (Cloud SQL patching, GKE control plane management)
BeyondCorp-style zero trust for Google's own internal operations

What you handle:

Cloud IAM policies — roles, service accounts, organization policies. GCP's IAM model uses roles (predefined and custom) rather than AWS's policy documents, but the compliance obligation is the same.
Service account key management — service accounts with downloaded JSON keys are GCP's equivalent of AWS access keys. Unrotated, overprivileged service account keys are a consistent audit finding.
VPC firewall rules — GCP uses firewall rules attached to VPC networks rather than security groups. The risk is the same: 0.0.0.0/0 on port 22 is still a finding.
Cloud Storage bucket permissions — same as S3. Public buckets, missing encryption configuration (though GCP encrypts by default, customer-managed encryption keys are often a compliance requirement), access logging.
Cloud Audit Logs configuration — Admin Activity logs are always on (and cannot be disabled — another GCP differentiator), but Data Access logs must be explicitly enabled. Many companies miss this.
GKE node security — if you run GKE, node OS patching and pod security policies are your responsibility. The control plane is Google's.

The "shared fate" branding means Google invests more in opinionated defaults — encryption on by default, admin logs always on — but the fundamental split is the same. You still own IAM, access control, and application security.

Azure shared responsibility

Microsoft publishes a responsibility matrix that maps each layer to "Customer," "Shared," or "Microsoft" across IaaS, PaaS, and SaaS. It's the most granular of the three providers.

What Azure handles:

Physical data center security (Microsoft operates 60+ regions with independently audited facilities)
Host infrastructure and hypervisor security
Network controls at the infrastructure layer
Managed service internals (Azure SQL managed patching, Azure Functions execution environment)
Identity infrastructure for Entra ID (formerly Azure AD) — Microsoft secures the platform itself

What you handle:

Entra ID (Azure AD) configuration — conditional access policies, MFA enforcement, Privileged Identity Management (PIM), access reviews. Azure's identity surface is the most complex of the three providers because most companies use it for both cloud IAM and corporate identity (Active Directory).
Network Security Groups (NSGs) — Azure's equivalent of security groups. Same risks. Overly permissive NSGs are a top-five audit finding.
Azure Storage access policies — SAS tokens, access keys, role-based access to storage accounts. Azure adds complexity with Shared Access Signatures, which are time-scoped access tokens that are frequently misconfigured (too broad, too long-lived, or leaked in code).
Azure Activity Log and Diagnostic Settings — Azure Activity Log captures control plane operations by default, but diagnostic settings for resource-level logging must be configured per resource. Many companies enable Activity Log but miss diagnostic logging on their SQL databases and Key Vaults.
Key Vault access policies — who can read secrets, who can manage keys, whether soft-delete is enabled (it should be).
VM patching and Update Management — Azure provides Update Management as a service, but enabling and configuring it is the customer's responsibility.

Azure's distinguishing complexity for GRC is the deep integration between cloud infrastructure and corporate identity through Entra ID. If your company uses Azure AD for SSO into SaaS apps and also for Azure cloud IAM, the identity attack surface spans both worlds. Auditors know this and probe accordingly.

Where the responsibility shifts

Across all three providers, there are twelve security tasks that come up in every compliance audit. Who owns each one depends on the service model.

Security Task                    IaaS           PaaS           SaaS
───────────────────────────────  ─────────────  ─────────────  ─────────────
Physical security                Provider       Provider       Provider
Network infrastructure           Provider       Provider       Provider
Hypervisor / host OS             Provider       Provider       Provider
OS patching                      Customer       Provider       Provider
Runtime / middleware patching    Customer       Provider       Provider
Application code security        Customer       Customer       Provider
Data classification              Customer       Customer       Customer
Access management (IAM)          Customer       Customer       Customer
Encryption key management        Customer       Shared         Provider
Network firewall rules           Customer       Shared         Provider
Endpoint protection              Customer       N/A            N/A
Audit log configuration          Customer       Customer       Shared
───────────────────────────────  ─────────────  ─────────────  ─────────────

"Shared" = provider offers the mechanism; customer must enable/configure it
"N/A"    = not applicable to that service model

Twelve security tasks: who is responsible under each service model

Two rows never change: data classification and access management are always yours. This is why a GRC Engineer who only knows "the cloud" at a surface level will spend most of their time on IAM and data governance regardless of which services the company uses.

Where auditors focus

Here is the practical implication for your work. Auditors do not focus on the provider's side of the shared responsibility model. They assume the provider is handling their obligations — and they verify this by requesting the provider's own SOC 2 Type II report (AWS, GCP, and Azure all publish them).

Auditors focus on your side. Specifically, they focus on the areas where companies most commonly fail:

IAM and access controls — Are there overprivileged users? Are there service accounts with admin access? Is MFA enforced for all privileged users? When was the last access review? This is the single highest-yield area for audit findings.

Encryption configuration — Is encryption at rest enabled? Is it using customer-managed keys where required? Is encryption in transit enforced? Can you prove it across all resources, not just one?

Network exposure — Are any databases, admin consoles, or management ports exposed to the internet? Are security groups / firewall rules following least-privilege principles?

Logging and monitoring — Is audit logging enabled across all accounts and regions? Are logs retained for the required period? Is there alerting on high-risk events (root account usage, security group changes, IAM policy modifications)?

Patching and vulnerability management — For IaaS workloads, are operating systems patched? Is there a documented patching cadence? Can you show evidence of patch compliance?

The pattern: auditors focus on the layers closest to your data and your users. The closer a control is to "who can access what," the harder they probe.

The most expensive assumption in cloud

The most common audit finding for cloud-native companies: "The customer assumed the cloud provider handled X." The provider handles less than most people think. Physical security, hypervisor isolation, and managed service internals — that's the provider's scope. Everything above that line is yours. If you cannot point to a specific line in the provider's shared responsibility documentation that says they handle it, assume you handle it.

Quick check

Your company runs a Python application on AWS Lambda that processes customer PII. During a SOC 2 audit, the auditor asks who is responsible for patching the Lambda execution environment's operating system. What is the correct answer?

Your company — you chose to run on AWS, so all patching is your responsibility

AWS — Lambda is serverless, so AWS manages the execution environment including the OS

Shared responsibility — you patch the OS, AWS patches the runtime

Neither — serverless functions do not have an operating system

Quick check

A company uses Google Cloud SQL (managed PostgreSQL) and assumes they don't need to worry about database security because it's a managed service. Which of the following is still their responsibility?

PostgreSQL engine patching and version upgrades

Physical security of the server running the database

Database user access controls, network exposure settings, and whether SSL connections are enforced

Replication and backup infrastructure reliability

Bringing it together

The shared responsibility model is not a theoretical concept you learn once and forget. It is the operating framework for every piece of compliance work you will do as a GRC Engineer.

When you write a control narrative, you are describing your side of the shared responsibility split. When you build a Terraform module, you are implementing your side. When you collect audit evidence, you are proving your side. When you assess a vendor, you are evaluating whether they handle their side.

The next lessons in this module will start mapping specific compliance controls to specific cloud services — turning this conceptual framework into the practical skill of reading a control requirement and knowing exactly which cloud configuration to check.