Shared Responsibility Resolver: Know Exactly What the Cloud Covers

Preview / draft. This article describes Advisedly's inherited-controls baselines for AWS, Azure, and GCP, plus the direction of the Shared Responsibility Resolver. Capabilities described as forthcoming -- per-service deployment-model tagging, automated SSP/FedRAMP Appendix A population, and multi-cloud reconciliation -- are on the roadmap, not yet generally available. Contact us for the current state before relying on any capability here for an assessment.

Every major cloud provider publishes a shared responsibility model. AWS has a diagram. Azure has a matrix. GCP has a table. Each one communicates the same basic idea: the provider handles some things, you handle others, and there is a gray area in the middle where both parties have obligations.

This is understood in theory and mishandled in practice.

The problem is not that organizations fail to read the shared responsibility documentation. The problem is that the documentation is written at a level of abstraction that does not map cleanly to specific security controls, specific cloud services, or specific compliance frameworks. When an auditor asks "who is responsible for control AC-2 (Account Management) on this system?" the answer depends on whether the workload runs on EC2 instances, ECS Fargate containers, or a fully managed SaaS product. The shared responsibility diagram does not give you that answer. You are expected to figure it out yourself, document it correctly, and defend it during assessment.

Most organizations get this wrong. Not because they are negligent, but because the mapping is genuinely complex -- and it changes every time you add a service, change a deployment model, or onboard a second cloud provider.

The Three Categories of Control Responsibility

Before we can resolve who owns what, we need a precise vocabulary. Every control in a compliance framework falls into one of three categories relative to your cloud deployment.

Inherited Controls

These are controls that the cloud provider satisfies entirely. You benefit from the protection, but you do not implement, configure, or operate anything to achieve it. Physical security of data centers is the canonical example. When your workload runs in AWS us-east-1, AWS controls facility access, surveillance, environmental protections, and physical media destruction. You inherit that protection by virtue of using the service.

Inherited controls sound simple, but they carry a documentation obligation that many organizations miss. You cannot simply write "AWS handles physical security" in your System Security Plan and move on. You must identify which specific controls are inherited, cite the provider's responsibility (typically referencing the provider's own FedRAMP authorization package or SOC 2 report), and confirm that the inheritance is valid for the specific services you consume.

Shared Controls

These are controls where both you and the provider have responsibilities, but the boundaries differ based on the service model. Encryption is a clear example. Your cloud provider offers encryption capabilities -- server-side encryption for storage, TLS termination at the load balancer, key management services. But the provider does not decide which data gets encrypted, which key rotation policy you adopt, or whether you enable encryption at all.

Shared controls are where the most audit findings occur. The provider has done their part by making the capability available. Whether you have done your part by enabling, configuring, and monitoring it -- that is the question the auditor is asking.

Customer Controls

These are controls that remain entirely your responsibility regardless of what the cloud provider offers. Access management policy, data classification, application-level authentication, security awareness training, incident response procedures -- the cloud provider does not touch these. Moving to the cloud does not transfer ownership of a single customer control. It never has.

The Contrarian Take: Shared Responsibility Models Protect the Provider, Not You

Here is something the cloud marketing teams will never say: the shared responsibility model exists primarily as a liability boundary for the provider, not as operational guidance for the customer. AWS, Azure, and GCP publish these models to establish legal clarity about what they are and are not responsible for when something goes wrong. The models are not designed to help you fill out your SSP or pass an audit.

This means that treating the provider's shared responsibility diagram as your compliance documentation is a category error. The diagram tells you where the legal boundary sits. It does not tell you which of your 300+ NIST 800-53 controls are satisfied by that boundary, which are partially satisfied, or which specific services create the inheritance. That mapping work is entirely on you -- and it is the work that auditors are testing.

Why the Service Model Changes Everything

The three-category split would be manageable if it were static. It is not. The responsibility boundary shifts based on the type of cloud service you consume.

IaaS (Infrastructure as a Service). You get virtual machines, networks, and storage. The provider handles the physical infrastructure and hypervisor. You handle the operating system, middleware, runtime, application, and data. The vast majority of controls are either shared or customer-owned.

PaaS (Platform as a Service). The provider now manages the operating system, runtime, and often the database engine. Your responsibility shrinks to the application layer and data. Controls related to OS patching, runtime configuration, and platform hardening shift from customer to inherited or shared.

SaaS (Software as a Service). The provider manages nearly everything. Your responsibility narrows to identity and access management, data classification, and how you configure the application. Most infrastructure and platform controls become inherited.

FaaS (Functions as a Service). Serverless compute pushes the boundary even further. You provide the function code and the provider manages everything else -- compute provisioning, scaling, patching, and runtime. But you still own the security of your code, the permissions your function assumes, and the data it processes.

This means that a single organization using EC2 instances, RDS databases, Lambda functions, and a SaaS-based identity provider has four different responsibility models operating simultaneously. Each control in their framework must be evaluated against the correct service model for the component it applies to.

This is where spreadsheets break down.

The Auditor Problem

Auditors do not accept "the cloud provider handles that" as a control implementation statement. What they require is specificity:

Which controls are inherited from the provider?
Which specific services create the inheritance? (A control inherited from an IaaS compute service is not automatically inherited from a PaaS database service.)
What evidence confirms the provider is actually meeting their responsibility? (A reference to the provider's FedRAMP authorization package, SOC 2 Type II report, or ISO 27001 certificate.)
What is the customer's residual obligation for shared controls?

For FedRAMP specifically, Appendix A of the System Security Plan requires a control-by-control disposition that categorizes each control as "Provided by CSP," "Inherited from underlying CSP/IaaS," "Shared," or "Customer Responsibility." This is not optional. It is a required component of the authorization package. Getting it wrong does not result in a finding -- it results in a rejection.

CMMC assessors evaluating cloud-hosted Controlled Unclassified Information (CUI) environments face the same challenge. NIST 800-171 does not natively define a shared responsibility model, but the assessment methodology requires that organizations demonstrate they have not assumed a control is covered when it is not.

The Multi-Cloud Reality

The complexity compounds for organizations operating across multiple cloud providers. This is not an edge case -- it is increasingly the norm, especially in federal and defense environments where different workloads may reside in AWS GovCloud, Azure Government, and an on-premises enclave simultaneously.

Each provider defines shared responsibility differently:

AWS publishes a Security of the Cloud vs. Security in the Cloud model, with specific service-level matrices that vary between standard and GovCloud regions.
Azure provides a shared responsibility table that breaks out responsibilities by SaaS, PaaS, IaaS, and on-premises across ten security domains.
GCP documents a shared fate model (their term), which extends shared responsibility to include prescriptive guidance and tooling, not just boundary definition.

An organization running workloads across two of these providers must reconcile two different models, using two different vocabularies, against one set of compliance controls. The person doing this reconciliation is typically an ISSO or compliance analyst who is already overloaded.

How Advisedly Approaches This

Advisedly ships inherited-controls baselines for the three major cloud providers and is building toward a full Shared Responsibility Resolver. This section separates what is available today from what is on the roadmap.

Inherited-Controls Baselines (available today)

Advisedly ships curated baselines for AWS, Azure, and GCP that classify controls as inherited, shared, or customer-responsible for each provider. These baselines give your team a documented starting point -- rather than a blank spreadsheet -- for the control responsibility mapping that assessors require. Each classification carries a per-control disposition you can review, adjust, and cite as you build your control responsibility narrative.

The baselines encode the well-understood cases: physical and environmental controls inherited from the provider, encryption and configuration controls that are shared, and policy and access-management controls that remain customer-owned regardless of provider.

Per-Service Resolution (on the roadmap)

A future release will let you inventory the specific cloud services each component consumes, tag each with its deployment model (IaaS, PaaS, SaaS, FaaS), and resolve responsibility per-service rather than per-provider. This is where a single control can carry different classifications across different parts of your system -- for example, SC-28 (Protection of Information at Rest) being shared for IaaS compute but inherited for a SaaS product that encrypts by default. Per-service resolution is not yet generally available.

Provider Attribution (on the roadmap)

Planned work will generate provider attribution statements that reference the specific service and the provider's own compliance documentation (FedRAMP authorization package ID, SOC 2 report reference, or ISO certificate number). Today, the baselines capture provider evidence as reviewable notes rather than structured attestation references.

SSP and FedRAMP Appendix A Integration (on the roadmap)

The intended destination for the resolver is direct population of your System Security Plan -- including the FedRAMP Appendix A control disposition matrix -- from the maintained responsibility classifications. This automated SSP population is planned, not shipped. Use the baselines today to inform the disposition you author in your SSP tooling.

Multi-Cloud Reconciliation (on the roadmap)

Unified reconciliation across multiple providers, so a single view shows where each control stands regardless of how many clouds are involved, is part of the resolver's design. Today, each provider baseline is maintained independently.

What Changes When Responsibility Is Explicit

Organizations that move from ambiguous to explicit shared responsibility classification tend to see three improvements.

Audit preparation time drops. The number-one time sink in assessment preparation is reconstructing the inherited controls mapping from scratch because the last person who built it has left the organization or the cloud environment has changed since the last assessment cycle. Starting from a maintained baseline instead of a blank spreadsheet removes much of that work.

Findings decrease. A significant percentage of cloud-related audit findings trace back to controls that were assumed to be inherited but were actually shared -- or shared controls where the customer's half was never implemented. Making the classification explicit narrows the gap between assumption and reality.

Multi-cloud governance becomes more manageable. Working from documented per-provider baselines makes tracking shared responsibility across two or three cloud providers a more structured effort than ad-hoc spreadsheets.

The Bigger Picture

Shared responsibility is not a one-time exercise. Cloud providers update their service offerings, retire legacy services, change security defaults, and modify their own compliance posture. A service that was PaaS last year might offer a new serverless tier this year, shifting the responsibility boundary for any workload that adopts it.

The resolver is designed to accommodate this. As the provider baselines are maintained, your starting point for inherited-controls documentation stays current with how the major clouds actually divide responsibility. The roadmap work above -- per-service resolution, automated SSP population, and multi-cloud reconciliation -- extends this into continuous, environment-aware classification.

Key Takeaways

Shared responsibility models are liability boundaries for providers, not compliance documentation for customers.

The same control can be inherited, shared, or customer-owned depending on the service model (IaaS/PaaS/SaaS/FaaS).

FedRAMP Appendix A requires per-control disposition -- "the provider handles it" is not an acceptable statement.

Multi-cloud environments require reconciling different responsibility vocabularies against a single control framework.

Start from maintained baselines, not blank spreadsheets. Adjust per-service as your environment evolves.

Frequently Asked Questions

How do I document inherited controls in my SSP?

For each inherited control, your SSP must identify: the specific control number, the cloud service that creates the inheritance, the provider's evidence (reference their FedRAMP authorization package ID, SOC 2 Type II report period, or ISO 27001 certificate), and a statement confirming the inheritance applies to your specific deployment. A bare "AWS handles this" fails every auditor review. The provider's own compliance documentation is the evidence -- your job is citing it correctly.

Does using a FedRAMP-authorized CSP mean my controls are automatically inherited?

No. Using a FedRAMP-authorized cloud service provider means the provider has demonstrated their own controls meet FedRAMP requirements. Which of those controls you can inherit depends on which services you consume and your deployment model. A workload running on bare EC2 instances inherits far fewer controls than one running on a fully managed SaaS product from the same provider. The authorization covers the provider's environment -- the mapping to your controls is your responsibility.

What happens when a provider changes a service and the responsibility boundary shifts?

This is why shared responsibility classification must be treated as a living document, not a point-in-time exercise. When a provider introduces a new tier (e.g., a managed version of a previously self-hosted service), adds a new default security feature, or deprecates a service, the control responsibility boundary may shift. Your continuous monitoring program should include periodic review of the provider's shared responsibility documentation against your current service inventory.

How do I handle shared controls where both parties have obligations?

For shared controls, your SSP must document both halves: what the provider does (e.g., "provider offers server-side encryption at rest for S3 buckets") and what you do (e.g., "organization enables default encryption on all buckets via AWS Config rule, with key rotation enforced via KMS policy"). The auditor tests your half. If you have not documented and implemented your portion of a shared control, the control is not met -- regardless of what the provider offers.

Is the shared responsibility model the same in GovCloud regions?

Generally yes for the boundary definitions, but GovCloud regions often have additional restrictions and certifications. AWS GovCloud operates under a separate FedRAMP High authorization with US-person access requirements. Azure Government has its own authorization boundary. The shared responsibility categories (inherited/shared/customer) remain the same conceptually, but the specific services available -- and therefore the specific controls inheritable -- may differ between commercial and government regions.

How Advisedly Helps

Advisedly ships inherited-controls baselines for AWS, Azure, and GCP that give your team a documented, per-control starting point for the responsibility classification that assessors require. Rather than building from a blank spreadsheet every assessment cycle, you start from curated baselines that encode the well-understood inheritance patterns and adjust for your specific service inventory. The baselines integrate with Advisedly's multi-framework compliance engine, so a single responsibility classification maps across every attached framework -- FedRAMP, NIST 800-53, CMMC -- simultaneously. Reach out to begin@advisedly.ai to see the current baselines and where the resolver is headed for your deployment model.