Category: Cloud Security

Shared Responsibility Model

Also known as: SRM, Shared Responsibility Framework, Cloud Shared Responsibility Model

Simply put

The Shared Responsibility Model is an agreement that divides security duties between a cloud service provider and its customer, making clear which protections each party is responsible for. In general, the provider secures the underlying cloud infrastructure, while the customer secures what they put in the cloud, such as their data, access controls, and applications. It helps organizations avoid dangerous assumptions that the provider handles everything automatically.

Formal definition

The Shared Responsibility Model is a security and compliance framework that delineates which cybersecurity processes and controls belong to the cloud service provider (CSP) versus the customer for a given cloud deployment. Providers such as AWS and Azure typically describe it as securing the infrastructure of the cloud itself, while customers remain responsible for security in the cloud, with the exact boundary varying by service model (IaaS, PaaS, or SaaS). From a governance standpoint, a virtual CISO should note that this model reallocates operational security tasks but does not transfer organizational or regulatory accountability away from the customer; even where the CSP contractually assumes control of certain layers, legal accountability for the customer's data, configurations, and compliance posture generally remains with the client organization and its officers. Common expert corrections include not treating the CSP as responsible for customer misconfigurations, identity and access management, or data classification simply because those functions run within the provider's platform.

Why it matters

The Shared Responsibility Model matters because one of the most common and costly sources of cloud security failures is the mistaken assumption that moving to a cloud provider transfers all security duties to that provider. In practice, providers such as AWS and Azure describe themselves as responsible for the security of the cloud infrastructure itself, while the customer remains responsible for security in the cloud, including data, access controls, and application configuration. When organizations do not understand where that boundary sits, gaps emerge in exactly the areas the provider never agreed to cover, such as identity and access management, data classification, and workload configuration.

For security leaders and the executives they advise, the model is as much a governance concern as a technical one. As AWS describes it, the shared model can help relieve the customer's operational burden, but a virtual CISO should be clear that reallocating operational tasks is not the same as transferring accountability. Even where a cloud service provider contractually assumes control of certain layers, legal and regulatory accountability for the customer's data, configurations, and overall compliance posture generally remains with the client organization and its officers. Treating the provider as accountable for a customer's own misconfiguration is a mistake an experienced practitioner would insist on correcting.

The boundary is also not fixed. It shifts depending on whether a workload is delivered as IaaS, PaaS, or SaaS, meaning the customer's obligations expand or contract with each service model. Because the exact division varies by provider and by service, the value of understanding the model depends heavily on organizations reading provider documentation carefully and mapping their own controls against it rather than assuming a single universal split applies everywhere.

Who it's relevant to

CISOs and Security Leaders

Security leaders use the Shared Responsibility Model to determine which controls their organization must own and operate versus which the provider covers. Because the boundary varies by provider and by IaaS, PaaS, or SaaS deployment, leaders are responsible for mapping customer-side duties such as identity and access management, data classification, and configuration to internal owners rather than assuming the provider handles them.

Executives and Boards

Executives and officers should understand that while a cloud provider may relieve operational burden by securing infrastructure, legal and regulatory accountability for the organization's data and compliance posture generally remains with the client organization and its officers. The model reallocates tasks; it does not transfer that accountability.

Virtual and Fractional CISOs

In advisory engagements, a vCISO helps clients read the specific provider's documented responsibilities, avoid the common error of treating the provider as responsible for customer misconfigurations, and establish governance so that customer-side controls are assigned and monitored. The value of this guidance depends on client cooperation and access to accurate deployment information.

Cloud and Platform Teams

Teams operating workloads need the model to know precisely where their responsibility begins, particularly for configuration and access controls that run inside the provider's platform but remain the customer's duty. Since the split shifts across service models, these teams must confirm the boundary for each deployment rather than applying a single assumption.

Inside SRM

Division of Security Duties

The core premise of the shared responsibility model is that security obligations are split between a service provider and the customer. In cloud contexts, the provider typically secures the underlying infrastructure while the customer secures their data, identity configurations, and application-level controls. The exact division varies by service type and by provider, and it should be documented rather than assumed.

Provider-Managed Layers

The portions of the environment the provider is typically accountable for, which may include physical facilities, host infrastructure, and foundational platform components. What falls under provider control differs across infrastructure, platform, and software service models, so practitioners should confirm boundaries in the specific contract or service documentation.

Customer-Managed Layers

The portions the customer generally retains responsibility for, often including data classification and protection, access management, identity and configuration settings, and appropriate use of provided security features. These responsibilities frequently increase as the service model shifts toward less-managed offerings.

Accountability Versus Responsibility

A shared responsibility model may delegate operational responsibility for certain tasks to a provider, but legal and organizational accountability for protecting data and meeting regulatory obligations typically remains with the customer organization and its officers. Delegating a task is not the same as transferring accountability, unless a contract explicitly states otherwise.

Role of the Virtual CISO

In a vCISO engagement, the virtual CISO typically advises on how responsibilities should be mapped, helps document the boundary between provider and customer duties, and directs governance around it. The vCISO generally does not perform hands-on operational security tasks such as configuring cloud controls unless that work is explicitly contracted.

Framework and Regulatory Context

The model is often referenced when aligning to frameworks and regulations such as NIST CSF, ISO 27001, SOC 2, HIPAA, PCI DSS, or GDPR. Using a provider that holds a certification does not automatically make the customer compliant; the customer typically remains responsible for their portion of controls. A vCISO engagement can support readiness and clarify responsibility boundaries but does not by itself guarantee compliance or certification.

Common questions

Answers to the questions practitioners most commonly ask about SRM.

Does the shared responsibility model mean my cloud provider handles security so I don't need a virtual CISO?

No. The shared responsibility model divides duties between the cloud provider and the customer, but it does not transfer accountability for your data, identity and access management, application-layer configuration, or governance to the provider. Providers typically secure the underlying infrastructure (physical facilities, host operating systems, and the network fabric), while the customer generally remains responsible for how they configure and use those services. A virtual CISO advises on the customer side of that boundary, defining policy, assessing risk, and guiding secure configuration, rather than being replaced by the provider's controls. Accountability for security decisions usually remains with the client organization and its officers regardless of the model.

Is the division of responsibility the same across every cloud provider and every service?

No, and treating it as fixed is a common mistake. The boundary shifts depending on the service model. For infrastructure-as-a-service, the customer typically carries more responsibility for operating systems, runtime, and applications; for platform-as-a-service and software-as-a-service, the provider generally assumes progressively more of the stack. The specifics also vary by provider and by individual service, so the model should be read against each provider's documented terms rather than assumed. A virtual CISO can help map these boundaries for your particular mix of services, but the details may vary by provider and contract.

How can a virtual CISO help us apply the shared responsibility model in practice?

In many engagements, a virtual CISO helps by clarifying where the provider's responsibilities end and the customer's begin, then translating the customer-side duties into policies, standards, and program requirements. This often includes reviewing service-specific documentation, identifying configuration and monitoring gaps on the customer side, and prioritizing remediation by risk. Note that a virtual CISO typically provides strategy and governance rather than performing hands-on configuration or tool administration; execution generally falls to internal teams or contracted operational providers unless the engagement scope states otherwise.

How does the shared responsibility model relate to frameworks like NIST CSF, ISO 27001, or SOC 2?

These frameworks and reports address the customer's side of the responsibility boundary. Even when a provider maintains its own certifications or attestations for the infrastructure it controls, the customer remains responsible for demonstrating that its configurations, access controls, and processes meet the relevant requirements. A virtual CISO often supports readiness by mapping customer-side controls to the applicable framework, but supporting readiness is distinct from asserting that the organization is certified or fully compliant. Provider attestations do not automatically satisfy the customer's own obligations.

What organizational factors affect how well the shared responsibility model can be implemented?

The value of applying the model depends heavily on organizational maturity, stakeholder cooperation, and clearly defined scope. Effective implementation typically requires accurate inventory of cloud services in use, access to the teams that configure and operate them, and clarity on internal ownership for each customer-side duty. Where these are missing, responsibility gaps often go unaddressed. A virtual CISO can identify and help close such gaps, but the outcome depends on the client providing access to relevant systems and stakeholders.

Who is accountable if a misconfiguration on the customer side of the model leads to an incident?

Accountability for customer-side configuration and its consequences generally remains with the client organization and its officers, not with the cloud provider or the virtual CISO. A virtual CISO advises and directs on how to reduce that risk, but advising is distinct from assuming legal or regulatory accountability, which does not transfer unless a contract explicitly specifies otherwise. It is also worth noting that no engagement or control set guarantees breach prevention; the model reduces and clarifies responsibility rather than eliminating risk.

Common misconceptions

Using a cloud or managed provider transfers all security accountability to that provider.

The provider typically assumes responsibility for defined layers, but legal and organizational accountability for data protection and regulatory obligations usually remains with the customer organization unless a contract specifies otherwise. Responsibility for a task can be delegated; accountability generally is not.

A virtual CISO or a shared responsibility model means someone else operationally manages your security controls.

A vCISO advises on and directs how responsibilities are divided and governed, but generally does not perform hands-on tasks such as configuring cloud settings, monitoring a SOC, or administering tools unless those are explicitly in scope. The customer-managed layers still require someone to operate them.

If the provider is certified against a framework, the customer is automatically compliant.

Provider certifications typically cover only the provider's portion of the environment. The customer generally remains responsible for their own controls, and compliance depends on how well the customer manages their assigned responsibilities. A vCISO can support readiness but cannot guarantee certification.

Best practices

Document the specific boundary between provider-managed and customer-managed responsibilities for each service, rather than assuming a default division, since it varies by provider and service model.

Explicitly define what falls within the scope of any vCISO or provider engagement, and note that operational tasks such as tool administration, monitoring, and incident response execution are typically out of scope unless contracted.

Keep a clear record distinguishing delegated responsibility from retained accountability, confirming that legal and regulatory accountability remains with the client organization unless a contract states otherwise.

When mapping responsibilities to frameworks or regulations such as NIST CSF, ISO 27001, SOC 2, HIPAA, PCI DSS, or GDPR, verify that provider certifications cover only their layers and that customer-managed controls are addressed separately.

Engage stakeholders and confirm ownership of each customer-managed layer, since the value and effectiveness of the model depend on organizational maturity, defined scope, and stakeholder cooperation.

Revisit the responsibility mapping when service models change or new services are adopted, as the customer's share of responsibility often shifts toward less-managed offerings.