Moving a workload to the cloud does not transfer every security responsibility to the provider.
The cloud provider secures the infrastructure and managed service components it operates. The customer remains responsible for the identities, configurations, applications, and data that remain under customer control.
Exactly where the boundary falls depends on the service model.
The current 350-701 SCOR v2.0 blueprint explicitly includes cloud shared responsibility across common models, NIST SaaS/PaaS/IaaS service models, and Cloud Access Security Broker capabilities.
Shared responsibility changes with the service model
The principle is stable: provider and customer responsibilities meet at a boundary.
The boundary moves depending on how much of the stack the provider manages.
In IaaS, the provider operates physical infrastructure, core cloud platform, and virtualization layers. The customer usually has significant responsibility for guest operating systems, application configuration, identities, network controls, and data.
In PaaS, the provider manages more of the runtime and platform stack. The customer still owns application logic, identity configuration, data handling, and security settings exposed by the platform.
In SaaS, the provider runs the application itself. The customer still has critical responsibility for users, access, tenant configuration, data governance, sharing, and how the SaaS service is used.
This is why “the provider handles security” is an unsafe summary.
The service model changes how far the provider’s responsibility extends up the stack. In IaaS, the provider operates the physical facilities, hardware, core network, and virtualization layer, while the customer still owns guest operating systems, workload configuration, identities, applications, and data. PaaS removes more operating-system and runtime administration from the customer, but application identities, secrets, data classification, and secure use of the service remain customer responsibilities. SaaS moves most of the application stack to the provider, yet the tenant still controls users, access policy, data handling, sharing, and many security settings.
This is why “the cloud provider handles security” is never a complete answer. The provider can deliver a secure capability while the customer configures that capability insecurely. Public storage exposure, excessive SaaS sharing, weak administrator roles, unmanaged OAuth consent, or an unprotected API key are customer-side failures even when the underlying service is functioning exactly as designed.
The provider secures the cloud; the customer secures its use
Cisco summarizes the shared-responsibility idea as the provider securing the cloud while the customer secures what runs in it.
That wording is useful, but it should not be read as one universal checklist.
Different services expose different configuration controls.
For example, an IaaS customer may configure network segmentation, guest patching, endpoint protection, and operating-system hardening.
A SaaS customer cannot patch the SaaS provider’s servers but still has to manage identities, tenant settings, data sharing, and access policy.
Cloud architecture is therefore a governance problem as much as a technology problem.
Public, private, hybrid, and community cloud deployment models describe where and how cloud resources are deployed; the shared-responsibility model answers the separate question of which party manages each part of the technology and security stack.
Identity remains a customer responsibility in every model
Cloud providers supply identity features, but customers decide how to configure and use them.
That includes:
- who receives accounts
- how strong authentication is enforced
- which roles are assigned
- how privileged access is managed
- when access is reviewed or revoked
- whether service identities are over-permissioned
A SaaS application can be fully patched by the provider and still be exposed by a stolen administrator account or unsafe tenant configuration.
This is why identity is a shared-responsibility topic even when the provider owns most of the technical stack.
Shared responsibility should also be mapped to individual controls rather than only to broad service labels. For each workload, identify who patches the operating system, who manages the runtime, who owns identity configuration, who encrypts and classifies data, who defines network exposure, who collects logs, and who is responsible for backup or recovery.
The answer can vary inside one application. A managed database may reduce patching responsibilities while the application team still controls database identities and data retention. A SaaS application may handle service availability while the customer remains responsible for deciding which users can export sensitive records. Control-by-control ownership prevents gaps that disappear inside a simplistic SaaS/PaaS/IaaS diagram.
Data responsibility never disappears
The provider can offer encryption, backup, retention, classification, and DLP capabilities.
The customer still has to decide:
- which data may enter the service
- who is allowed to access it
- whether sharing is appropriate
- how long it should be retained
- whether regulations restrict location or processing
- what happens when an employee or application no longer needs access
Cloud adoption changes control mechanisms. It does not remove data ownership.
That becomes especially important in SaaS, where users can adopt applications much faster than traditional infrastructure teams can provision servers.
Identity and data are the two responsibilities that most consistently remain with the customer. Federation, multifactor authentication, conditional access, privileged-role governance, and lifecycle management determine who can enter a cloud tenant. Classification, sharing rules, encryption choices, retention, and DLP determine what authenticated users can do with information after they enter.
Logs bridge those controls to incident response. If the customer cannot identify who signed in, which application was used, what data was shared, and whether a risky session was blocked, the organization cannot validate its side of the shared-responsibility boundary. Logging and evidence retention should therefore be designed before an incident rather than added after one.
CASB addresses the SaaS visibility gap
A Cloud Access Security Broker provides visibility and policy enforcement between users and cloud services.
Cisco describes CASB as addressing problems such as cloud-app sprawl, shadow IT, inconsistent policy, and limited visibility into SaaS data flows.
A CASB can help security teams answer:
- Which cloud applications are employees using?
- Which are sanctioned?
- Which are risky or unsanctioned?
- Are users sending sensitive data to them?
- Are risky OAuth applications connected to corporate SaaS tenants?
- Is unusual user behavior occurring?
CASB therefore sits directly at the point where customer responsibility for cloud use becomes difficult to enforce.
CASB is not the same thing as cloud-provider security
A cloud provider can secure its infrastructure perfectly while an organization still allows employees to upload regulated data to an unsanctioned SaaS application.
That is not primarily a provider-infrastructure failure.
It is a customer governance and access-control problem.
CASB helps address that layer.
It can provide SaaS discovery, app risk information, policy enforcement, tenant restrictions, DLP integration, malware protection, and user/entity behavior monitoring depending on platform.
Cisco Secure Access, for example, includes CASB as one component of a wider SSE architecture.
CASB capabilities are often summarized around visibility, data security, threat protection, and compliance. Visibility helps discover sanctioned and unsanctioned cloud use. Data controls can identify sensitive content and restrict risky transfers. Threat analytics can surface compromised accounts or anomalous behavior. Compliance functions help apply policy consistently across cloud services.
Those functions are valuable because a SaaS provider normally sees its own tenant, while the enterprise needs a policy view across many services. CASB does not replace each provider’s native controls; it creates a cross-service layer for the customer’s governance and security requirements.
Inline and API-based control see different things
CASB capabilities can operate inline and out of band.
Inline inspection sees user traffic as it moves to or from cloud services.
API-based integration can inspect data or activity directly inside supported SaaS tenants, including content that already exists at rest.
The two methods therefore solve different visibility problems.
Inline enforcement can stop a user action during access.
API integration can inspect stored data or cloud-tenant activity that might not traverse the same inline path.
A mature cloud-security design may use both.
Inline and API-based approaches answer different timing questions. Inline inspection can make a decision while a user session is active, which is useful for blocking an upload or enforcing tenant restrictions in real time. API-based integration can examine data and configuration inside supported SaaS platforms after the data is already present, including information created outside the inline path.
A mature design may therefore use both. Inline controls protect transactions that traverse the enforcement point, while API controls extend visibility into stored content and cloud-native activity. The choice should follow the required control and the traffic path, not the assumption that one CASB connection mode sees everything.
CASB complements DLP rather than replacing it
CASB and DLP overlap in data-protection use cases, but they are not identical.
DLP focuses on identifying and controlling sensitive information.
CASB provides broader visibility and control over SaaS applications, tenant use, app risk, OAuth integrations, and cloud activity.
Cisco’s current Secure Access platform combines CASB and DLP because the controls reinforce each other.
The CASB tells you which cloud service and activity is involved.
DLP tells you whether the content contains sensitive information that should not be shared.
Map responsibility control by control
For any cloud service, ask:
- Which layers does the provider operate?
- Which configuration remains under customer control?
- Who controls identities and privileged roles?
- Who is responsible for application code?
- Who protects and classifies the data?
- Who configures network exposure?
- Who monitors tenant activity?
- Who handles backup and recovery for this service?
- What evidence is available for audit and incident response?
- Which SaaS/CASB controls are needed for user behavior outside centrally managed infrastructure?
The answer should be specific to the service, not just to the words “SaaS,” “PaaS,” or “IaaS.”
Shared responsibility is a control-ownership map, not a slogan. For every cloud service, the organization should be able to name which responsibilities moved to the provider and which stayed with the tenant. CASB becomes valuable where that tenant responsibility spans SaaS usage, identities, data movement, and cloud-application behavior that would otherwise be difficult to see or govern consistently.