Shared Responsibility Model

Overview

The Shared Responsibility Model is the cornerstone principle of cloud security and ISO 27017 implementation. It defines the division of security responsibilities between Cloud Service Providers (CSPs) and Cloud Service Customers (CSCs), ensuring that both parties understand their obligations and can work together to maintain a secure cloud environment.

Learning Objectives

By the end of this lesson, you will be able to:

• Understand the fundamental concept of shared responsibility in cloud security
• Identify specific responsibilities for CSPs and CSCs across different service models
• Recognize common responsibility gaps and how to address them
• Document shared responsibilities in contracts and agreements
• Implement governance structures to manage shared responsibilities
• Apply ISO 27017 guidance to clarify responsibility boundaries

Understanding Shared Responsibility

Core Concept

In traditional IT environments, organizations have complete responsibility for all aspects of security—from physical data center security to application security. In cloud computing, this responsibility is shared between the provider and the customer, creating a partnership model.

The Golden Rule:

CSPs are responsible for security OF the cloud
CSCs are responsible for security IN the cloud

Why Shared Responsibility Matters

For Cloud Service Providers:

• Defines scope of security obligations
• Limits liability exposure
• Enables transparent security posture
• Facilitates compliance demonstrations
• Clarifies support boundaries

For Cloud Service Customers:

• Prevents security gaps
• Ensures compliance requirements are met
• Guides security investment decisions
• Enables proper risk assessment
• Facilitates security audits

For Regulators and Auditors:

• Clear accountability framework
• Compliance verification guidance
• Risk assessment foundation
• Audit scope definition

Responsibility Matrix by Service Model

Comprehensive Responsibility Breakdown

Responsibility Legend

• Customer: Full responsibility for implementation and management
• Provider: Full responsibility for implementation and management
• Shared: Both parties have specific responsibilities that must be coordinated

IaaS Shared Responsibility Model

Provider Responsibilities in IaaS

Infrastructure Layer:

• Physical security of data centers

  • Perimeter security, access controls
  • Video surveillance, security guards
  • Environmental controls (fire, flood, temperature)

• Network infrastructure

  • Core network equipment and security
  • DDoS protection at network edge
  • Physical network segmentation

• Compute infrastructure

  • Server hardware maintenance
  • Hypervisor security and patching
  • Multi-tenant isolation mechanisms

• Storage infrastructure

  • Physical storage security
  • Storage network security
  • Media sanitization upon decommissioning

Service Availability:

• Infrastructure uptime as per SLA
• Hardware failure recovery
• Infrastructure capacity management
• Geographic redundancy (if contracted)

Compliance:

• Infrastructure-level compliance certifications (SOC 2, ISO 27001)
• Physical security audit rights
• Infrastructure security documentation

Customer Responsibilities in IaaS

Operating System Layer:

• OS selection and licensing
• OS hardening and configuration
• Security patch management
• Anti-malware deployment
• Audit logging configuration

Application Layer:

• Application installation and configuration
• Application security testing
• Code security reviews
• Dependency management
• Application monitoring

Data Security:

• Data encryption (at rest and in transit)
• Encryption key management
• Data backup and retention
• Data classification and handling
• Data loss prevention

Network Security:

• Virtual network configuration
• Firewall rules (security groups)
• Network access control lists
• VPN configuration
• Network segmentation

Identity and Access Management:

• User account management
• Authentication mechanisms
• Authorization policies
• Privileged access management
• Multi-factor authentication

Compliance:

• Application and data compliance
• Security control implementation
• Audit evidence collection
• Regulatory reporting

IaaS Responsibility Example

Scenario: Virtual Machine Security

PaaS Shared Responsibility Model

Provider Responsibilities in PaaS

Infrastructure and Platform Layer:

• All IaaS-level responsibilities

• Operating system management

  • OS patching and updates
  • OS security configuration
  • OS vulnerability management

• Runtime environment

  • Language runtime security
  • Framework security
  • Library patching

• Middleware security

  • Database engine security
  • Web server security
  • Message queue security

Platform Services:

• API security
• Platform authentication services
• Platform-level encryption
• Platform monitoring and logging
• Service availability and performance

Development Tools:

• Secure development environment
• CI/CD pipeline security
• Code repository security

Customer Responsibilities in PaaS

Application Layer:

• Application code security
• Secure coding practices
• Application logic security
• Input validation
• Output encoding

Application Configuration:

• Security settings configuration
• Feature flag management
• Connection string security
• Environment variable management

Data Management:

• Data schema design
• Data access controls
• Data encryption configuration
• Backup strategy implementation
• Data retention policies

Access Control:

• Application-level authorization
• Role-based access control (RBAC)
• API key management
• Service account management

Monitoring:

• Application performance monitoring
• Application security monitoring
• Custom logging implementation
• Alert configuration

PaaS Responsibility Example

Scenario: Managed Database Service

SaaS Shared Responsibility Model

Provider Responsibilities in SaaS

Complete Stack Management:

• All IaaS and PaaS responsibilities
• Application development and maintenance
• Application security
• Multi-tenant isolation
• Application availability

Security Features:

• Authentication mechanisms
• Built-in authorization models
• Data encryption at rest and in transit
• Audit logging capabilities
• Security monitoring

Compliance:

• Application-level compliance certifications
• Data processing agreements
• Subprocessor management
• Security documentation
• Incident notification

Data Management:

• Database management
• Backup and recovery infrastructure
• Data center redundancy
• Business continuity capabilities

Customer Responsibilities in SaaS

Access Management:

• User provisioning and deprovisioning
• Role assignment
• Permission management
• Access reviews
• Guest user management

Configuration:

• Security settings configuration
• Privacy settings
• Data retention settings
• Integration configurations
• Feature enablement

Data Governance:

• Data classification
• Appropriate use of service
• Data input quality
• Data export and portability planning
• Third-party integration approval

User Management:

• User training and awareness
• Acceptable use policy enforcement
• User activity monitoring
• Insider threat detection

Compliance:

• Compliance with usage terms
• Regulatory requirements for data handling
• Documentation of controls
• User access audits

SaaS Responsibility Example

Scenario: Enterprise Email Service (Microsoft 365)

Shared Responsibilities: The Grey Area

Access Control - A Shared Responsibility

Access control typically involves shared responsibilities that require coordination:

Provider Responsibilities:

• Provide authentication mechanisms (passwords, MFA, SSO)
• Offer authorization frameworks (RBAC, ABAC)
• Implement session management
• Provide audit logging capabilities
• Ensure platform-level access controls

Customer Responsibilities:

• Configure authentication requirements
• Define and implement authorization policies
• Manage user lifecycle
• Review and monitor access logs
• Implement least privilege principle
• Conduct regular access reviews

Coordination Required:

• Integration with customer identity providers
• Federation configuration
• API access management
• Service account permissions

Data Encryption - Another Shared Area

Provider Responsibilities:

• Provide encryption capabilities
• Manage encryption infrastructure
• Ensure secure key storage mechanisms
• Implement secure key generation
• Offer various encryption options

Customer Responsibilities:

• Enable encryption features
• Choose encryption methods
• Manage customer-managed keys (if applicable)
• Define what data to encrypt
• Implement key rotation policies
• Control key access permissions

Example Encryption Model:

┌─────────────────────────────────────────────┐
│         Data Encryption Layers              │
├─────────────────────────────────────────────┤
│ Application-Level Encryption                │ ◄── Customer
│ (Customer manages keys and encryption)      │
├─────────────────────────────────────────────┤
│ Platform Encryption (Customer-Managed Keys) │ ◄── Shared
│ (Provider encrypts, customer manages keys)  │
├─────────────────────────────────────────────┤
│ Platform Encryption (Provider-Managed Keys) │ ◄── Shared
│ (Provider encrypts and manages keys)        │
├─────────────────────────────────────────────┤
│ Infrastructure Encryption                   │ ◄── Provider
│ (Transparent to customer)                   │
└─────────────────────────────────────────────┘

Common Responsibility Gaps

Gap 1: Assumption of Provider Protection

Misconception: "The cloud provider will protect my data"

Reality: Providers protect the infrastructure, but customers must:

• Implement proper access controls
• Encrypt sensitive data
• Configure security features
• Monitor for unauthorized access
• Backup critical data

ISO 27017 Guidance: Clause 5.1.1 emphasizes customer responsibility for data protection

Gap 2: Lack of Visibility

Misconception: "I can see everything in the cloud"

Reality: Visibility varies by service model

• IaaS: High visibility into VMs, networks, but not underlying infrastructure
• PaaS: Limited to application and service logs
• SaaS: Only user activity and configuration

Solution:

• Understand logging capabilities
• Implement cloud access security broker (CASB)
• Use provider monitoring tools
• Establish clear monitoring requirements in contracts

Gap 3: Incident Response Confusion

Misconception: "The provider handles all security incidents"

Reality: Incident response is shared

• Provider responds to infrastructure incidents
• Customer responds to application/data incidents
• Coordination required for cross-layer incidents

Best Practice:

• Define incident notification procedures
• Establish escalation paths
• Conduct joint incident response exercises
• Document roles in incident response plan

Gap 4: Compliance Misconceptions

Misconception: "Provider compliance means I'm compliant"

Reality: Provider certifications don't transfer automatically

• Provider certifications cover their responsibilities
• Customers must implement their controls
• Customers responsible for their compliance evidence
• Shared controls require customer configuration

Approach:

• Map compliance requirements to service model
• Understand inherited vs. customer controls
• Maintain evidence of customer controls
• Conduct regular compliance assessments

Gap 5: Data Residency and Sovereignty

Misconception: "Data stays where I choose"

Reality: Data may move for various reasons

• Backup and disaster recovery
• Load balancing across regions
• Service provider operations
• Subprocessor involvement

Requirements:

• Specify data residency in contracts
• Understand data flow architecture
• Review subprocessor locations
• Implement technical controls (encryption, tokenization)

Documenting Shared Responsibilities

Contractual Documentation

Service Level Agreement (SLA) Components:

1. Availability and Performance

   • Uptime commitments
   • Performance guarantees
   • Maintenance windows
   • Incident response times

2. Security Responsibilities Matrix

   • Detailed responsibility breakdown
   • Control implementation ownership
   • Monitoring and reporting requirements
   • Incident handling procedures

3. Data Protection Clauses

   • Data location and residency
   • Data encryption requirements
   • Data retention and deletion
   • Data portability provisions

4. Compliance and Audit

   • Provider certifications
   • Audit rights
   • Evidence provision
   • Change notification requirements

5. Incident Management

   • Notification timelines
   • Communication channels
   • Escalation procedures
   • Post-incident reporting

Responsibility Assignment Matrix (RACI)

Example: Data Breach Incident Response

Legend: R=Responsible, A=Accountable, C=Consulted, I=Informed

ISO 27017 Guidance on Shared Responsibility

Key Controls for Responsibility Management

Control 5.1.1 - Policies for information security

• Establish clear policies defining CSP and CSC responsibilities
• Document responsibility boundaries
• Review and update policies regularly

Control 15.1.1 - Information security policy for supplier relationships

• Define security requirements in supplier agreements
• Specify CSP security responsibilities
• Establish monitoring and review processes

Control 15.1.2 - Addressing security within supplier agreements

• Include security requirements in contracts
• Define incident notification procedures
• Specify audit rights and compliance reporting

Control 15.1.3 - Information and communication technology supply chain

• Understand CSP's supply chain
• Assess subprocessor security
• Maintain visibility into dependencies

ISO 27017 Responsibility Principles

1. Clarity: Responsibilities must be clearly defined and documented
2. Completeness: All security aspects must be assigned
3. Consistency: Assignments must be consistent across services
4. Communication: Responsibilities must be communicated to all parties
5. Review: Regular review and updates as services evolve

Best Practices for Managing Shared Responsibilities

1. Conduct Responsibility Mapping Workshops

Purpose: Align understanding between CSP and CSC

Process:

1. Identify all security domains
2. Map each control to responsible party
3. Identify shared controls
4. Define coordination mechanisms
5. Document agreements
6. Review with stakeholders

Participants:

• Cloud architects
• Security teams (both parties)
• Compliance officers
• Legal representatives
• Operations teams

2. Implement Shared Responsibility Governance

Governance Structure:

┌────────────────────────────────────────┐
│   Cloud Security Steering Committee    │
│   (Executive oversight)                 │
└────────────┬───────────────────────────┘
             │
    ┌────────┴────────┐
    │                 │
┌───▼────────────┐  ┌─▼─────────────────┐
│  CSP Liaison   │  │  CSC Cloud Team   │
│  (Provider     │  │  (Customer cloud  │
│   interface)   │  │   security)       │
└───┬────────────┘  └─┬─────────────────┘
    │                 │
    └────────┬────────┘
             │
    ┌────────▼───────────────────────┐
    │  Shared Security Operations    │
    │  - Joint reviews                │
    │  - Incident coordination        │
    │  - Compliance reporting         │
    └────────────────────────────────┘

3. Establish Clear Communication Channels

Communication Framework:

4. Implement Continuous Monitoring

Monitoring Approach:

Provider Monitoring (CSP):

• Infrastructure health and performance
• Security event detection
• Compliance status
• Service availability

Customer Monitoring (CSC):

• Application performance and security
• User activity and access patterns
• Data access and modifications
• Configuration changes

Shared Monitoring:

• Joint security dashboards
• Integrated SIEM solutions
• Coordinated incident response
• Compliance reporting integration

5. Conduct Regular Reviews

Review Schedule:

Quarterly Reviews:

• Responsibility matrix validation
• Control effectiveness assessment
• Incident review and lessons learned
• Compliance status update

Annual Reviews:

• Comprehensive security assessment
• SLA and contract review
• Risk assessment update
• Strategic alignment check

Ad-hoc Reviews:

• After significant incidents
• Following major service changes
• When new regulations apply
• After audit findings

Case Studies: Shared Responsibility in Practice

Case Study 1: Healthcare Provider (HIPAA Compliance)

Scenario: Hospital using AWS for patient data storage and processing

Service Model: Primarily IaaS with some PaaS

Responsibility Implementation:

CSP (AWS) Responsibilities:

• HIPAA-eligible infrastructure
• Physical security of data centers
• Network infrastructure security
• Business Associate Agreement (BAA)
• Infrastructure compliance certifications

CSC (Hospital) Responsibilities:

• Sign BAA with AWS
• Implement encryption for PHI
• Configure access controls
• Conduct security risk analysis
• Implement audit logging
• Train workforce on HIPAA
• Maintain compliance documentation

Shared Activities:

• Incident response coordination
• Audit support
• Security assessment reviews

Outcome:

• Successful HIPAA compliance audit
• Clear delineation prevented gaps
• Coordinated incident response prevented breach escalation

Case Study 2: Financial Services (PCI DSS)

Scenario: Payment processor using PaaS for transaction processing

Service Model: PaaS (managed Kubernetes, managed databases)

Responsibility Implementation:

CSP Responsibilities:

• PCI DSS-compliant infrastructure
• Network segmentation capabilities
• Encryption at rest infrastructure
• Security patching of platform
• Infrastructure logging

CSC Responsibilities:

• Application security (PCI DSS SAQ D)
• Cardholder data encryption
• Application-level access controls
• Security testing (ASV, penetration testing)
• Compensating controls documentation
• Quarterly compliance reporting

Challenges Addressed:

• Responsibility boundary confusion resolved through detailed mapping
• Compliance evidence split clearly defined
• QSA audit scope properly scoped

Result:

• PCI DSS Level 1 certification achieved
• Reduced compliance costs through provider infrastructure certification
• Clear audit trail for assessors

Case Study 3: Multi-National Corporation (GDPR)

Scenario: Global company using SaaS for HR management

Service Model: SaaS (Workday HCM)

Responsibility Implementation:

CSP (Workday) Responsibilities:

• Act as data processor
• Implement technical safeguards
• Data processing agreement
• Sub-processor management
• Data center security
• Security certifications (ISO 27001, SOC 2)

CSC Responsibilities:

• Act as data controller
• Lawful basis for processing
• Data subject rights implementation
• Privacy impact assessments
• Employee privacy notices
• Configure data retention policies
• Manage user access rights
• International data transfers (SCCs)

Coordination Points:

• Data subject access requests
• Data breach notification
• Data deletion requests
• Audit rights exercise

Outcome:

• GDPR compliance maintained across 15 countries
• Efficient data subject request handling
• No regulatory penalties
• Enhanced employee trust

Responsibility Checklist for Cloud Adoption

Pre-Adoption Assessment

• Identify all regulatory and compliance requirements
• Determine data classification levels
• Assess current security controls
• Evaluate internal capabilities and resources
• Define security and compliance objectives

Provider Evaluation

• Review provider's responsibility documentation
• Verify provider certifications and compliance
• Assess provider's incident response capabilities
• Evaluate provider's financial stability
• Check provider's subprocessor list
• Review provider's track record and reputation

Contract Negotiation

• Include detailed responsibility matrix
• Define SLA metrics and penalties
• Specify data handling requirements
• Establish audit rights
• Define incident notification timelines
• Include data portability provisions
• Specify termination and data return procedures

Implementation

• Document responsibility assignments
• Implement customer security controls
• Configure provider security features
• Establish monitoring and logging
• Train personnel on responsibilities
• Test incident response procedures
• Validate compliance controls

Ongoing Management

• Conduct regular access reviews
• Monitor security metrics
• Review incident reports
• Update risk assessments
• Maintain compliance evidence
• Review and update contracts
• Assess new services and features

Key Takeaways

1. Shared responsibility is fundamental to cloud security and ISO 27017 implementation

2. Responsibilities vary by service model - IaaS has most customer responsibility, SaaS has least

3. Customers are always responsible for data - regardless of service model

4. Documentation is critical - contracts, SLAs, and policies must clearly define responsibilities

5. Shared areas require coordination - access control, encryption, and incident response need joint effort

6. Gaps are common - proactive gap analysis and mitigation is essential

7. Continuous communication is necessary between CSP and CSC

8. Regular reviews ensure alignment - responsibilities must be reassessed as services evolve

9. ISO 27017 provides guidance - use the standard to structure responsibility assignments

10. Compliance is not inherited - provider certifications don't automatically make customers compliant

Preparation for Next Lesson

In the next lesson, we'll explore Cloud Security Challenges including:

• Unique security threats in cloud environments
• Multi-tenancy risks and mitigation
• Data breaches and prevention
• Compliance complexity
• Vendor lock-in and exit strategies
• Emerging cloud security threats

Self-Assessment Questions

1. What is the fundamental principle of the shared responsibility model?
2. In IaaS, who is responsible for operating system security?
3. Name three areas where responsibility is typically shared between CSP and CSC.
4. What is a common misconception about provider compliance certifications?
5. Why is documentation of shared responsibilities important?
6. How does the shared responsibility model differ between IaaS and SaaS?
7. What is a RACI matrix and how is it used in cloud security?
8. Who is always responsible for data classification and governance?
9. Name three elements that should be included in cloud service contracts regarding security.
10. What are the key coordination points in incident response between CSP and CSC?

Practical Exercise

Exercise: Create a Shared Responsibility Matrix

Scenario: Your organization is planning to migrate a customer-facing web application to the cloud. The application consists of:

• Web application (custom developed)
• Customer database (PostgreSQL)
• File storage for customer documents
• Email notifications

You are evaluating two options:

• Option A: IaaS (VMs, block storage, virtual networks)
• Option B: PaaS (managed app service, managed database, object storage)

Tasks:

1. Create a responsibility matrix for both options covering:

   • Infrastructure security
   • OS/platform security
   • Application security
   • Data security
   • Access control
   • Monitoring and logging
   • Compliance

2. Identify the shared responsibility areas for each option

3. Document key contract clauses you would negotiate with the provider

4. Create an incident response RACI chart for a data breach scenario

Understanding the shared responsibility model is critical for successful ISO 27017 implementation. The next lesson will build on this foundation by exploring the unique security challenges that arise in cloud environments.