Catalog
concept#Cloud#Security#Architecture#Governance

Shared Responsibility Model

Framework that defines clear allocation of security, compliance and operational responsibilities between cloud providers and customers.

Defines allocation of responsibilities between cloud provider and customer for security, compliance and operations.
Established
Medium

Classification

  • Medium
  • Organizational
  • Organizational
  • Intermediate

Technical context

Identity and access management (IAM) systemsMonitoring and SIEM platformsContract management and compliance tools

Principles & goals

Written, explicit assignment of responsibilities per service.Continuous review and adjustment upon architecture changes.Contractual coverage for critical tasks and SLAs.
Run
Enterprise, Domain, Team

Use cases & scenarios

Compromises

  • Misunderstandings lead to blind spots in security.
  • Unclear responsibility delays incident response.
  • Relying on provider controls without evidence is risky.
  • Use a standard template for responsibility matrices.
  • Perform regular audits and evidence collection.
  • Integrate provider documentation into operational processes.

I/O & resources

  • Service inventory including provider details
  • Legal and regulatory requirements
  • Organizational structure and responsibility roles
  • Responsibility matrix per service
  • Change requests for runbooks
  • Contractual or SLA addenda

Description

Defines allocation of responsibilities between cloud provider and customer for security, compliance and operations. It clarifies which controls the provider manages (infrastructure, physical security, global services) and which remain with the customer (data, identity, configurations). Widely used for public cloud, SaaS and managed services to reduce gaps and define governance.

✔

  • Reduces uncertainty about responsibilities.
  • Improves compliance and auditability.
  • Enables targeted security investments.

✖

  • Boundaries are only effective as documentation and enforcement.
  • Different provider models complicate standardization.
  • Incorrect assumptions can create security gaps.

  • Number of clearly documented responsibilities

    Counts services with a written responsibility model.

  • Time to incident ownership assignment

    Time between incident detection and assignment of clear ownership.

  • Number of auditable evidences per control

    Measures available evidences for provider and customer controls.

AWS Shared Responsibility Model (example)

AWS defines the separation between infrastructure and customer responsibilities for cloud services.

SaaS deployment in marketing

Marketing uses a SaaS tool; backup and access management remain customer-managed.

Hybrid data platform

A cloud data lake combines provider and customer responsibilities for encryption and access control.

1

Inventory all used cloud and SaaS services and map providers.

2

Develop a responsibility matrix per service with provider and customer duties.

3

Adjust runbooks, operational and security processes according to the matrix.

4

Clarify open contractual points and schedule regular reviews.

⚠️ Technical debt & bottlenecks

  • Outdated runbooks that do not reflect provider/customer boundaries.
  • Manual evidences instead of automated compliance reports.
  • Lack of a central inventory of used services.
Unclear responsibilities in hybrid environmentsMissing evidence of provider controlsInconsistent service documentation
  • Assuming provider handles all backups without contractual confirmation.
  • Customers configure critical services even though the provider is responsible.
  • Missing documentation for hybrid access paths.
  • Confusing infrastructure and application responsibilities.
  • Adopting a model without checking provider-specific details.
  • Insufficient communication between security and operations teams.
Basic understanding of cloud architectureSecurity and compliance knowledgeKnowledge of contract and SLA formulation
Compliance requirements (e.g., data protection, industry regulations)Security and access requirementsOperational and availability objectives
  • • Contractual limits of provider responsibility
  • • Technical interfaces that do not allow full control
  • • Regulatory mandates that impose customer duties