The Shared Responsibility Model

Every major cloud provider publishes a shared responsibility model. AWS has one. Microsoft Azure has one. Google Cloud has one. They are prominently featured in security documentation, referenced in compliance frameworks, and cited in vendor contracts. Most organizations have seen the diagram , the one that shows the provider owning the physical infrastructure while the customer owns everything on top. The problem is not that people have not seen the diagram. The problem is that almost nobody has thought carefully about what it actually means when a vendor is operating inside your cloud environment. At that point, you are not looking at two parties splitting responsibility. You are looking at three , and the model was never designed to explain that.

What is the Shared Responsibility Model, Really?

The shared responsibility model is a framework that cloud providers use to delineate which security obligations belong to the provider and which belong to the customer. At its most basic: the provider secures the physical infrastructure , data centers, hardware, networking, hypervisors, and the managed services running on them. The customer secures everything built on top of that infrastructure , operating systems, applications, data, identity configurations, network controls, and access management. The line between those two domains varies depending on the service model being used, and that variation is where most confusion originates.

In an Infrastructure as a Service (IaaS) model , where a customer provisions raw compute, storage, and networking , the customer owns almost everything above the hypervisor. They patch the operating system, configure the firewall, manage encryption, and control who has access to what. In a Platform as a Service (PaaS) model, the provider manages more of the stack , the runtime, the middleware, the operating system , but the customer still owns their application code, their data, and their identity and access configuration. In a Software as a Service (SaaS) model, the provider manages nearly the entire stack, but the customer still owns their data, their user access governance, and their integration configurations. The responsibility never disappears entirely. It just shifts in proportion.

Where this framework breaks down in practice is at the boundary of vendor relationships. When a third-party vendor operates inside your cloud environment , accessing your tenant through a service principal, running workloads in your account, or managing infrastructure on your behalf , the shared responsibility model has no formal answer for what they own. The provider's model addresses provider versus customer. It does not address customer versus the customer's vendors. That gap is entirely the customer's problem to solve, and most organizations have not solved it.

The practical ownership breakdown in a cloud environment with vendor access looks like this:

• Cloud provider owns: Physical security, hardware, hypervisors, managed service availability, and the underlying network fabric
• Your organization owns: Identity and access configuration, data classification and protection, network security controls, logging and monitoring, and the governance of who , including vendors , can do what inside your tenant
• Your vendor owns: Their own internal security practices, their management of the credentials you issue them, their compliance with the access controls you set, and any infrastructure they deploy within your environment on your behalf
• Nobody automatically owns: The governance of how vendor access was scoped, whether it is still appropriate, whether it is being monitored, and whether it will be revoked when no longer needed , unless your organization explicitly claims that ownership

Why this matters

The shared responsibility model matters enormously for TPRM because it defines the ceiling of what a vendor's own security posture protects you from , and that ceiling is lower than most practitioners assume. A vendor with excellent internal security practices, a SOC 2 Type II report, and a mature vulnerability management program has secured their own environment. They have not secured how they operate inside yours. Their SOC 2 does not cover the IAM role they use in your AWS account. Their vulnerability management program does not scan your cloud tenant for misconfigurations they may have introduced. Their encryption standards apply to data in their systems, not necessarily to data they access in your storage buckets.

This creates a specific and often invisible risk: organizations assess vendors as discrete entities and receive assurance about the vendor's own environment, while the actual attack surface , the vendor's footprint inside the customer's cloud tenant , goes entirely unexamined. The shared responsibility model, properly understood, makes clear that this footprint is the customer's responsibility to govern. That governance cannot be outsourced to the vendor's compliance program. It requires the customer to actively manage what they have permitted the vendor to do inside their own environment.

From a TPRM program design perspective, this means vendor cloud access needs its own assessment dimension , separate from the standard questionnaire, focused specifically on what the vendor can do inside your tenant, how that access is monitored, and how it will be controlled over time. Most programs do not have this dimension. They assess the vendor. They do not assess the vendor's position inside their own cloud environment. Those are different things.

Where most teams get this wrong

The most widespread failure is the assumption that the cloud provider's security posture extends to everything running inside the cloud. This is the 'we're on AWS so we're secure' misconception that the reviewer embodies perfectly , and it is genuinely common, not just among IT managers but among security teams who should know better. The provider's security certifications , FedRAMP, ISO 27001, SOC 2 , certify the provider's infrastructure. They do not certify the customer's configuration or the vendor access the customer has permitted.

The second failure is treating the shared responsibility model as a static assignment rather than a dynamic governance obligation. Even organizations that understand the model intellectually often apply it as a one-time checklist at the point of cloud adoption, rather than as an ongoing framework for evaluating every new vendor integration, every permission change, and every expansion of cloud usage. The model does not just define who is responsible for what , it defines who is responsible for governing change over time.

• Assuming a vendor's SOC 2 certification covers their activity inside your cloud tenant , it does not
• Failing to include cloud-specific access governance in vendor assessments because it feels like an IT concern rather than a risk concern
• Treating cloud provider compliance certifications as a substitute for customer-side configuration governance
• No process for reviewing how vendor cloud access has changed since initial provisioning
• Interpreting 'the cloud is secure' as meaning your specific configuration is secure , these are entirely different claims

What good looks like

Organizations that have internalized the shared responsibility model treat it not as a diagram to reference but as a governance accountability framework to operationalize. For every vendor with cloud access, there is a clear answer to three questions: what can this vendor do inside our cloud environment, how do we know what they are actually doing, and what is our process for changing or revoking that access when circumstances change.

• Vendor cloud access documented and reviewed against the shared responsibility boundary , what is the vendor responsible for, and what has the customer explicitly retained control over
• Cloud-specific sections in vendor assessments that address configuration governance, not just the vendor's internal security controls
• Active monitoring of the customer-owned layer , logging, alerting, and periodic review of vendor activity within the tenant
• Vendor onboarding processes that include a cloud access justification , documenting what access is needed, why, and under what conditions it will be reviewed or revoked
• Regular reassessment of the responsibility boundary as vendor integrations evolve , what was appropriate at onboarding may not reflect the current state of the relationship

Tooling

The shared responsibility model is ultimately a governance framework, but specific tools help operationalize the customer-side obligations it creates.

Cloud Security Posture Management , Wiz, Prisma Cloud, Orca Security

CSPM tools continuously audit the customer-owned layer of the cloud environment , the configurations, access controls, and resource settings that the shared responsibility model assigns to the customer. They surface misconfigurations, overprivileged roles, and exposed resources that represent failures of customer-side responsibility. For TPRM practitioners, a vendor managing cloud infrastructure on your behalf should be able to demonstrate CSPM coverage of the environments they operate in your name.

Cloud-Native Policy Enforcement , AWS Config, Azure Policy, GCP Organization Policy

These native services enforce configuration guardrails across your cloud environment , ensuring that resources cannot be created or modified in ways that violate your security baseline. They are the automated enforcement layer for the customer-side responsibilities the shared responsibility model assigns. When vendors operate in your environment, these policies constrain what they can do regardless of their own practices.

Identity Governance , AWS IAM Access Analyzer, Azure AD Access Reviews, Okta

Identity and access management sits squarely in the customer-owned layer of the shared responsibility model. These tools provide visibility into what vendor identities can access, flag overpermissioned roles, and enable periodic access reviews. They operationalize the customer's obligation to govern who has access to what , including third parties.

Cloud Audit Logging , AWS CloudTrail, Azure Monitor, GCP Audit Logs

Logging is a customer responsibility in every cloud service model. These tools capture the activity record that makes the customer-owned layer auditable. For vendor access specifically, they answer the question: what did the vendor actually do inside our environment, and does that match what we authorized them to do?

Governance challenges

The governance challenge with the shared responsibility model is that it creates obligations without automatically creating the organizational structures to fulfill them. Knowing that identity and access management is the customer's responsibility does not tell an organization who within the customer is responsible, at what frequency access should be reviewed, or what the escalation path is when a vendor's cloud footprint grows beyond what was originally approved. The model defines the domain of responsibility. It does not provide the operating model for fulfilling it.

In practice, the customer-side responsibilities tend to fall into the gaps between teams , too technical for risk, too governance-oriented for engineering, and too vendor-specific for the cloud operations team that manages the environment at scale. Closing that gap requires explicit ownership assignment, not just policy documentation.

• Assign explicit ownership of vendor cloud access governance , a named individual responsible for each vendor's footprint in your environment
• Create a vendor cloud access register that maps each vendor to the specific resources, roles, and permissions they hold in your tenant
• Include the shared responsibility boundary in vendor contract language , specify what the customer retains control over and what obligations the vendor accepts within that framework
• Review vendor cloud access at the same cadence as vendor risk reassessments , not as a separate exercise, but integrated into the existing TPRM review cycle
• Educate business stakeholders on what the model means in practice , the 'cloud provider handles security' misconception is most dangerous when held by decision-makers who approve vendor relationships

If you are a small team

Start by mapping your vendor cloud access against the shared responsibility boundary for your cloud service model. For each vendor with access to your cloud environment, answer three questions: what layer of the model does their access touch, what have you done to govern that layer specifically, and when was that governance last reviewed. The answers will tell you where your gaps are more precisely than any questionnaire.

• Enable cloud-native policy enforcement tools , AWS Config, Azure Policy , they are largely free and immediately surface customer-layer misconfigurations
• For each vendor with cloud access, confirm that audit logging is active and that you have a process for reviewing it
• Add a cloud access section to your standard vendor assessment that specifically asks about the vendor's practices within your tenant , not their internal environment
• Brief your business stakeholders on the shared responsibility model using plain language , understanding that the provider does not cover their configuration decisions is a prerequisite for meaningful governance

What to require

Ask directly:

"How do you interpret your security obligations when operating inside our cloud environment , specifically, what do you consider your responsibility versus ours under the shared responsibility model?"

"What controls do you have in place to ensure your activity within our cloud tenant stays within the scope we have authorized, and how would you detect and notify us if you operated outside that scope?"

"If a misconfiguration were introduced in our cloud environment as a result of your activity, what is your process for identifying, disclosing, and remediating it?"

Expect as evidence

• A clear articulation of what the vendor considers their security obligations within your environment versus what they expect the customer to govern
• Evidence of change management controls that prevent unauthorized modifications to customer cloud environments
• Defined notification and remediation process for configuration issues introduced through vendor activity
• Logging or monitoring capability that gives the vendor visibility into their own activity within your tenant

A vendor who responds to these questions by pointing to their SOC 2 report has not understood the question. The SOC 2 covers their environment. You are asking about yours.

How to evidence it

Regulators and auditors increasingly understand cloud environments well enough to ask about customer-side responsibility. Demonstrating due diligence in this area requires evidence that your organization has not only understood the shared responsibility model but has operationalized it for third-party access specifically.

• Documented vendor cloud access register with responsibility boundaries defined for each relationship
• Evidence of cloud-native policy enforcement covering vendor-accessible resources
• Audit log retention and review records for vendor activity within your cloud tenant
• Vendor assessment records that include cloud-specific governance questions , not just generic security questionnaire responses
• Access review evidence demonstrating that vendor cloud permissions are periodically validated against actual need

Key Takeaway

The shared responsibility model is not a division of labor that protects you from your own configuration decisions , it is a framework that makes clear those decisions are entirely yours to own. When vendors operate inside your cloud environment, that ownership does not transfer to them or to the cloud provider. It stays with you. The vendor's SOC 2 covers their house. You are responsible for what happens in yours. And if you have not defined, monitored, and governed what your vendors can do inside your cloud tenant, you have not fulfilled your half of the model , regardless of how carefully you assessed the vendor themselves.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations