Category: Cloud Security & Providers

Shared Responsibility Model

Also known as: SRM, Shared Responsibility in the Cloud, Cloud Shared Responsibility Model

Simply put

The Shared Responsibility Model is an arrangement that divides cybersecurity and compliance duties between a cloud service provider (CSP) and the customer that uses its services. In general terms, the provider secures certain parts of the cloud environment while the customer remains responsible for other parts, such as how they configure and use the service. This division is meant to make clear who is accountable for which security tasks and can help reduce the customer's operational burden.

Formal definition

The Shared Responsibility Model is a security and compliance framework, typically formalized as an agreement between a cloud service provider and its customer, that delineates which cybersecurity processes, controls, and responsibilities belong to the CSP and which belong to the customer for a given public cloud deployment. The precise allocation generally varies by service model (for example, infrastructure, platform, or software offerings) and is defined by each provider, so practitioners should confirm the specific boundaries against the applicable CSP's documentation. Note that this model, as described in the provided evidence, is a commercial cloud construct and is not itself a federal control set or authorization; a clear assignment of responsibility does not by itself establish compliance with any particular framework, and readers should verify how a given deployment maps to their governing requirements (such as FedRAMP or DoD authorization obligations) against current authoritative sources.

Why it matters

The Shared Responsibility Model matters because ambiguity over who secures what is a recurring source of cloud risk. When a cloud service provider secures certain layers of the environment and the customer retains responsibility for others, such as how they configure and use the service, gaps can emerge if either party assumes the other has a task covered. A clear division of duties is meant to establish accountability and, as providers such as AWS describe it, can help relieve the customer's operational burden. That said, reducing operational burden is not the same as transferring accountability; the customer generally remains answerable for the portions allocated to them.

For defense and public sector readers, a critical caution applies: the Shared Responsibility Model as described here is a commercial cloud construct, not a federal control set or an authorization. A well-documented split of responsibilities does not by itself establish compliance with any particular framework. Practitioners should not assume that a provider's security of its portion satisfies obligations such as FedRAMP authorization or DoD authorization requirements, and should verify how a given deployment maps to their governing requirements against current authoritative sources.

Because the precise allocation of responsibilities generally varies by service model and is defined by each provider, treating the model as a fixed or universal division is a common mistake. What one provider handles under an infrastructure offering may fall to the customer under a different service model, and the boundaries should be confirmed against the applicable provider's documentation rather than assumed.

Who it's relevant to

Compliance Officers and ISSMs

Those responsible for compliance and information system security need to understand how responsibilities are divided between the CSP and the customer for each deployment, and should confirm that the customer-retained portions are being met. They should treat the model as a starting point for accountability rather than as evidence of compliance, and verify how the arrangement maps to applicable governing requirements against current authoritative sources.

Government Contractors Using Cloud Services

Contractors deploying workloads on public cloud should confirm the specific boundaries of the Shared Responsibility Model against the applicable provider's documentation, because the allocation generally varies by service model. They should not assume that a provider's handling of its portion satisfies their own contractual or framework obligations, and should verify their responsibilities against current authoritative sources.

Authorizing Officials and Auditors

Those making or reviewing authorization decisions should recognize that the Shared Responsibility Model is a commercial cloud construct and not itself a federal control set or authorization. A documented division of duties does not by itself establish compliance; officials and auditors should confirm how a given deployment maps to the governing framework and obligations against current authoritative sources.

Inside SRM

Provider-Managed Responsibilities

The security and compliance obligations that the cloud service provider (CSP) retains, which generally vary by service model. In infrastructure-as-a-service arrangements the provider typically manages the physical facilities, host infrastructure, and virtualization layer, while assuming progressively more of the stack under platform-as-a-service and software-as-a-service. The precise allocation should be confirmed against the provider's authorization documentation.

Customer-Managed Responsibilities

The controls the consuming organization remains accountable for, which commonly include data classification and handling, identity and access management configuration, application-level security, and appropriate use of the service. Under a FedRAMP or DoD authorization, the customer generally retains responsibility for controls the provider does not fully implement.

Shared or Hybrid Controls

Controls where responsibility is divided between the provider and the customer, such that each party implements a portion. In most authorization packages these are documented so both parties understand their respective obligations; the split can differ by service model and by specific control.

Customer Responsibility Matrix (CRM)

A document commonly associated with FedRAMP and similar authorization packages that maps individual controls to the party responsible for their implementation. It is used to identify which controls the customer must inherit, configure, or implement independently. Readers should verify the current format and expectations against applicable authoritative sources.

Inherited Controls

Controls that a customer may rely on the provider to satisfy, often within a FedRAMP or RMF context. Inheritance does not transfer accountability for verifying that the inherited implementation meets the customer's specific requirements and impact level.

Service Model Dependency

The principle that the boundary of responsibility shifts with the deployment and service model. As of the applicable guidance, the allocation of duties under IaaS, PaaS, and SaaS differs and should not be assumed uniform across offerings.

Common questions

Answers to the questions practitioners most commonly ask about SRM.

Does using a FedRAMP-authorized cloud service mean the customer agency no longer has security responsibilities?

No. Under the shared responsibility model, a cloud service provider's authorization generally covers only the portions of the environment the provider operates, such as the underlying infrastructure or platform depending on the service model. The customer organization typically remains responsible for configuring the service securely, managing user access and identities, protecting its own data, and implementing customer-responsible controls. Treating a provider's authorization as covering the customer's full obligations is a common and consequential mistake. Review the provider's customer responsibility matrix and confirm scope against current authorization documentation.

If a cloud provider holds a FedRAMP authorization, does that automatically satisfy DoD requirements for the customer's system?

Not necessarily. FedRAMP authorization and DoD authorization processes are distinct, and FedRAMP authorization does not automatically satisfy DoD-specific requirements, which may involve additional impact-level considerations and DoD-managed authorization steps. The shared responsibility model does not shift a customer's separate compliance obligations to the provider. Organizations handling defense information should verify what the provider's authorization covers and confirm any additional DoD requirements against current authoritative guidance.

How do responsibilities typically differ across IaaS, PaaS, and SaaS service models?

The division of responsibility generally shifts with the service model. In infrastructure-as-a-service arrangements, the provider commonly handles the physical and virtualization layers while the customer manages more of the operating system, applications, and data. In platform-as-a-service, the provider generally assumes additional responsibility for the platform layer. In software-as-a-service, the provider typically operates most of the stack, though the customer usually retains responsibility for data, user access, and certain configuration settings. Exact allocations vary by offering, so confirm the specific split in the provider's documentation.

Where can an organization find the authoritative breakdown of which party is responsible for each control?

Providers commonly document the allocation of control responsibility in a customer responsibility matrix or equivalent artifact accompanying their authorization package. This may designate controls as provider-responsible, customer-responsible, or shared or hybrid. Because these designations vary across offerings and can change across revisions, organizations should obtain the current matrix directly and reconcile it against their own system's authorization boundary and applicable baseline.

How should shared or hybrid controls be handled during a security assessment?

Controls designated as shared or hybrid generally require coordination, because responsibility is split between the provider and the customer. In most implementations, the assessment should verify that the provider-implemented portion is addressed by the provider's authorization and that the customer-implemented portion is separately documented and assessed for the customer's system. Assessment and authorization are distinct activities, so confirming that a control is assessed does not by itself establish that the customer's system is authorized to operate.

How does the shared responsibility model interact with continuous monitoring obligations?

The model generally allocates continuous monitoring responsibilities across both parties rather than placing them entirely on one. A provider commonly monitors the layers it operates and may supply monitoring artifacts, while the customer typically monitors its own configurations, access, and data-layer controls. Because an authorization is time-bound and subject to ongoing monitoring rather than permanent, organizations should confirm which monitoring activities each party performs and how results are shared, based on the provider's current documentation and applicable authorization terms.

Common misconceptions

A FedRAMP or provider authorization means the customer has no remaining security obligations.

Authorization of a service generally covers only the provider-managed portion of the stack. The customer typically remains responsible for data, access configuration, and application-level controls, and must confirm which controls it inherits versus implements. Additionally, a FedRAMP authorization does not automatically satisfy DoD requirements, which may impose separate conditions.

Using an authorized cloud service makes the customer's system compliant and secure by default.

Compliance is not the same as security, and using an authorized service does not by itself produce an authorized or secure customer system. The customer must still assess and authorize its own use of the service, implement customer-side controls, and maintain continuous monitoring rather than treating the provider's status as sufficient.

The division of responsibility is fixed and identical across all cloud offerings.

The allocation of responsibilities generally shifts with the service model and specific offering. Practitioners should consult the provider's Customer Responsibility Matrix or equivalent documentation rather than assuming a uniform split, and verify details against current authoritative sources.

Best practices

Obtain and review the Customer Responsibility Matrix or equivalent documentation for each service to confirm which controls are provider-managed, customer-managed, shared, or inherited before relying on the service.

Verify that customer-retained responsibilities such as data classification, identity and access management configuration, and application-level security are explicitly assigned to accountable owners within your organization.

Confirm that a provider's FedRAMP authorization aligns with your applicable framework and impact level, and validate separately against DoD or agency-specific requirements where they apply rather than assuming automatic acceptance.

Treat inherited controls as requiring verification, ensuring the provider's implementation actually meets your system's requirements rather than accepting inheritance at face value.

Incorporate the shared responsibility boundary into your own authorization and continuous monitoring processes, recognizing that provider authorization does not replace authorizing and monitoring your own use of the service.

Re-review the responsibility allocation when the service model changes or the provider updates its offering, since the division of duties can shift across revisions and configurations.