Shared responsibility model

What is a shared responsibility model?

A shared responsibility model in a cloud environment is a formal framework that clearly defines and divides security and compliance duties among the different parties involved in a cloud service relationship. When a Software as a Service (SaaS) provider builds its application on a public cloud (such as AWS), the model becomes a three-party agreement that allocates responsibility based on who has operational control over each component of the service stack. This can be defined as follows:

The cloud service provider (AWS) assumes responsibility for the security of the cloud, maintaining the physical hardware, host operating system (OS), and global network resilience (disaster recovery for the core infrastructure).
The SaaS provider (CloudBees platform) is responsible for the security of the application and platform, which includes all application code, patch management, managing the AWS environment configurations (virtual private clouds (VPCs), and firewalls), service continuity planning, and incident response for software vulnerabilities.
You (the customer) retain accountability for security in the application, including all data ownership, user access management (multi-factor authentication (MFA) enforcement), configuring granular security settings, and implementing a third-party data recovery strategy for accidental or malicious deletion.

Table 1. Detailed responsibilities
Responsibility area	Cloud service provider (AWS)	SaaS provider (CloudBees platform)	Customer (you)
Physical security	Global infrastructure, data centers, hardware, networking, and physical facilities.	Not applicable. Inherited from AWS.	Not applicable.
Core infrastructure	Security of the cloud, including the virtualization layer, host operating system, and base network security.	Configuration of the AWS-provided infrastructure (for example, VPCs, security groups, IAM for the AWS account).	Not applicable.
Application & code	Not applicable.	The core SaaS application, its code, deployment, maintenance, updates, and web application firewalls (WAF). Guidance on secure usage of the product.	Configuration of the application.
Patch management	Patching the underlying hardware and host operating system.	Patching the guest operating systems (if using IaaS), middleware, runtime environments, and the SaaS application itself.	Not applicable.
Identity & access management (IAM)	Availability of AWS IAM and core service endpoints.	Application’s user access service, including user roles and permissions, and access to infrastructure by CloudBees employees.	Managing user accounts, secrets, passwords, enabling/enforcing MFA, single sign-on (SSO), integrations, and user behavior.
Data & encryption	Providing encryption tools (for example, KMS, EBS/S3 encryption features).	Implementing data classification policies, configuring encryption settings (at rest/in transit).	Data ownership, data quality, legal/regulatory compliance (for example, GDPR, HIPAA), and controlling data-sharing permissions within the application.
Monitoring & logging	Provides the raw infrastructure logging capabilities/tooling (for example, CloudTrail and CloudWatch logs).	Collecting, analyzing, and acting on logs, tool configuration, establishing threat detection, and providing security incident response for the SaaS application.	Monitoring your own user activity, usage, and reporting suspicious behavior to CloudBees platform.
Incident management	Detecting and resolving incidents affecting the underlying AWS infrastructure.	Detecting, containing, and remediating incidents within the application or its managed cloud environment. CloudBees must notify customers of security incidents impacting their data.	Incident response actions related to your employees, endpoints, or credentials (for example, disabling compromised user accounts and initiating local device forensic analysis).
Disaster recovery	Resilience and recoverability of the AWS Rrgion/service itself (for example, availability zones and region failover for core services).	Maintaining service level agreement (SLA) continuity through application-level disaster recovery (DR) planning, multi-region failover, and ensuring RTO/RPO for the application’s overall function.	Responsible for your own data backup and recovery plan for individual data loss events (for example, accidental or malicious deletion). You may need a third-party backup solution for granular recovery.

This shared responsibility model is provided for informational purposes only and is not intended to be exhaustive. This document provides an overview of general principles and does not supersede the specific terms, conditions, and security obligations outlined in the CloudBees Subscription and Services Agreement and CloudBees Terms of Service (TOS).