DigiTrustAsia
CCSP

CCSP and the Shared Responsibility Model in Cloud Security

The single most tested idea in cloud security: who secures what. Get the shared responsibility line wrong and you inherit risk you did not plan for.

If the CCSP exam has a center of gravity, it is the shared responsibility model. It appears directly as definitional questions, and indirectly inside almost every scenario: incident response, contracts, auditing, data protection, IAM. Practitioners get it wrong in production for the same reason candidates get it wrong on the exam — they memorise a diagram instead of internalising the principle that generates it.

The principle that generates every diagram

The cloud provider is responsible for security of the cloud. The customer is responsible for security in the cloud. Everything else is derivation: the more of the stack the provider manages, the more of the security responsibility the provider absorbs — and the responsibility line moves accordingly across service models.

LayerIaaSPaaSSaaS
Data & data classificationCustomerCustomerCustomer
Identity & accessCustomerCustomerCustomer (config)
ApplicationCustomerCustomerProvider
Runtime & middlewareCustomerProviderProvider
Operating systemCustomerProviderProvider
VirtualisationProviderProviderProvider
Physical & network infrastructureProviderProviderProvider

Two rows never change hands, and the exam loves both of them:

The customer always owns the data, and the customer always owns who can access it. There is no service model — none — where data classification, data governance or access decisions transfer to the provider.

Where candidates lose the marks

Confusing "managed" with "secured." In PaaS the provider patches the OS — but your application code, your secrets handling and your dependency hygiene remain entirely yours. A question describing a vulnerable library in a PaaS-hosted app is testing whether you'll wrongly reach for "provider responsibility."

Forgetting configuration is a customer duty. In SaaS, almost everything is the provider's — except how you configure it. Sharing settings, retention rules, MFA enforcement, admin role assignment: the majority of real-world SaaS breaches are customer-side misconfiguration, and ISC2 writes questions accordingly.

Treating the model as fixed rather than contractual. The matrix above is the default. The actual line in any engagement is set by the contract and SLA — which is why CCSP folds this topic into its legal and contracts domain. On the exam, when a scenario mentions a contract or SLA, the answer routes through it.

Accountability versus responsibility. Tasks shift; accountability does not. You can outsource patching; you cannot outsource being answerable to your regulator for a breach. Under privacy regimes from GDPR to India's DPDPA, the customer-as-controller remains accountable for personal data even when the CSP processes it. This single distinction resolves a surprising number of BEST-answer questions.

The model in real operations

Incident response. Your IR plan must pre-define the split: the provider detects and handles hypervisor- or facility-level events; you detect and handle everything in your tenancy. Scenario questions about "who investigates" are testing whether you know you'll never get hypervisor forensics — you get logs, attestations and the provider's process.

Audit and assurance. You cannot walk into a hyperscaler's data centre. Assurance over the provider's half arrives as SOC 2 reports, ISO 27001 certificates and CSA STAR entries. Reviewing those artefacts is the audit of the lower stack; your auditors test the upper stack directly.

Third-party risk. In risk-register terms, the provider's half of the model is a transferred-but-monitored risk: you respond to it with contracts, SLAs and assurance reviews, and you keep residual ownership. That framing is pure CRISC — and the exams increasingly cross-pollinate.

How to answer shared-responsibility questions

  1. Identify the service model in the stem (it's almost always stated or strongly implied).
  2. Place the affected layer against the matrix.
  3. Check for a contract/SLA mention — if present, it governs.
  4. Remember the two invariants: data and access are always yours.
  5. If the question asks about accountability to a regulator or data subject, the answer is the customer, regardless of who performed the task.

Master the generating principle and you stop needing the diagram — on the exam, and in the architecture review where it actually counts.

Put it into practice.

700+ exam-weighted questions, every one with a rationale. Your first practice exam is free.

Start free