CCSP Cloud Reference Architecture: Roles, Service Categories, Deployment Models and Shared Considerations

Cloud computing activities are the jobs each party performs in a cloud relationship, and ISO/IEC 17789 (the cloud computing reference architecture, now continued as ISO/IEC 22123-3 with the same roles and sub-roles) groups them into sub-roles under the three main roles of cloud service customer, cloud service provider and cloud service partner. A party is placed by the activity it performs and on whose behalf, not by who employs it: a staffing-agency temp who manages a customer's user accounts and security settings is performing the customer's cloud service administrator sub-role, because the work is done for the customer.

Near-twins to keep apart

• Business manager on each side. Both the customer and the provider have one. The customer's buys and oversees services for its organisation; the provider's runs the business of selling them.
• Developer versus provider. Building and maintaining a service's implementation is the cloud service developer sub-role (a partner); offering and operating the service to customers is the provider role. An independent studio that maintains the code of a hosted learning platform owned and run by another company is the developer; the company running it is the provider.
• Inter-cloud provider versus broker. A provider that peers or federates with other providers to serve its own customers is performing the inter-cloud provider sub-role; it remains the provider its customers contract with. A broker is a separate party standing between customers and providers.
• Integrator versus developer. The integrator connects an existing service to the customer's systems; the developer builds the service.

Broker services, briefly

NIST SP 500-292 gives brokers three services (taught in full in the cloud computing concepts lesson): intermediation enhances one service (identity, reporting, security); aggregation combines several services into one offering from a fixed set of providers; arbitrage is like aggregation except that the services are not fixed, so the broker has the flexibility to choose among providers, for example picking the best-scoring credit-check service each time. The deciding question is whether the broker may change the underlying providers. Provider-to-provider peering is not a broker service; it is the inter-cloud provider activity above. NIST SP 500-292 also uses service orchestration for how a provider arranges, coordinates and manages its own system components (physical resources, resource abstraction and the service layer) to deliver its services; that is a provider function, not a broker service either.

A cloud capabilities type is ISO/IEC 17788's classification of what a cloud service lets the customer do, based on the resources it uses. There are three types:

The quick test is whose code runs and what the customer provisions. Customer code on a provider runtime is the platform type even if the customer never sees a server; customer-provisioned compute, storage and networking is the infrastructure type; using the provider's finished application is the application type. Peering with other providers is not a capabilities type at all; it is a provider activity.

Capabilities types and service categories are deliberately separate. ISO/IEC 17788 states that a service category can include capabilities from more than one capabilities type. It is a common mistake to assume SaaS is always and only the application type, PaaS the platform type and IaaS the infrastructure type. A provider-run message queue service, for instance, is described by what it lets the customer do (create queues and send and receive messages through provider-run software), not by the fact that messages are persisted to disk. Where the customer's data is stored does not set the type; what the customer controls does.

A cloud service category is a group of cloud services that share a common set of qualities, and the three core categories are told apart by what the customer controls versus what the provider runs. NIST SP 800-145 calls them service models and defines them by the consumer's control:

Read a scenario from the customer's requirements upward: find the lowest layer the customer must control, and that sets the category. Control of the operating system itself (its hardening, kernel settings or installed agents) is available only in IaaS, because PaaS and SaaS keep the operating system on the provider's side. Control of application code but not of servers is PaaS. Managing only who uses a finished application and how it is configured for them, as with a hosted payroll tool, is SaaS.

ISO/IEC 17788 lists further categories, including Communications as a Service, Compute as a Service, Data Storage as a Service and Network as a Service, and mentions emerging ones such as Desktop as a Service (whole hosted desktops, not a single application), e-mail as a Service, Identity as a Service and Security as a Service. Each is still analysed the same way: which capabilities it gives the customer and which layers the provider keeps. How security responsibilities split across the categories is covered in the secure design principles lesson.

A cloud deployment model describes who the cloud infrastructure is provisioned for, and NIST SP 800-145 makes exclusive use, not ownership or location, the deciding test.

Two consequences follow. A regional bus operator's cloud that a hosting company owns, runs and houses is still a private cloud if no one but the bus operator uses it (a "hosted private cloud"). A consortium of universities sharing research-computing infrastructure provisioned only for its members, who share research-ethics and data-protection requirements, has a community cloud, whoever runs it. Being outside the customer's building does not make a cloud public, and having two organisations involved (customer and operator) does not make it hybrid or community.

Hybrid cloud and multi-cloud describe different properties, so one environment can be both, either or neither.

Hybrid is decided by the binding, not by how many models are in use: two deployment models used side by side without technology that lets data or applications move between them are simply two clouds. The labels can also apply together: an organisation whose private cloud is bound to one public provider, and which also uses a SaaS application from a second public provider, is hybrid and multi-cloud, because any public service from another provider counts towards multi-cloud, however minor its use.

Multi-cloud governance. The characteristic risk of multi-cloud is that each environment ends up with its own access policies, logging settings and encryption defaults, so gaps hide in the differences. Because ISO/IEC 22123-1 makes integrating and managing the providers the customer's job, the root-cause fix is the customer's own: one governance baseline, translated into each provider's controls, with monitoring and evidence brought together in one place so differences show up.

Interoperability, portability and reversibility are three ISO/IEC 17788 cross-cutting aspects that all concern the customer's freedom to work across, and eventually leave, a provider, but each answers a different question.

Interoperability is an ongoing property: systems keep exchanging and using information while the service runs. Where the set of connected services is expected to change, interoperability rests on open, vendor-neutral standards, because they keep working whichever vendor sits at the other end; for example, a learning platform that must pass grades to whichever student-records system each school uses depends on a standard interchange format. Portability is about the move itself: whether databases, documents, configurations and workloads can be taken to another provider in forms the new environment can use.

Reversibility has two halves. ISO/IEC 17788 describes it as the customer retrieving its customer data and application artefacts, and the provider deleting all customer data and contractually specified cloud service derived data (data the provider generates from the customer's use, such as logs and usage analytics) after an agreed period. A complete exit clause therefore covers both halves:

• Retrieval of customer data and application artefacts in an agreed, usable format.
• An agreed post-termination retrieval period, so the customer can retrieve and verify its migration before the deletion clock starts.
• Deletion that reaches every copy the provider holds: primary storage, replicas, backups and the contractually specified derived data, not only the live system.

Reversibility is negotiated before signing, not at exit, because after termination the customer has nothing left to bargain with. How portability and lock-in shape design decisions is covered in the secure design principles lesson.

Availability, resiliency and performance are distinct shared considerations, and each needs its own measurable commitment because meeting one says nothing about the others.

A file-sharing service can be reachable all month while uploads slow to a crawl during month-end close (a performance failure), and a long uptime record may only mean nothing has yet gone wrong (no proof of resiliency). Resiliency is demonstrated by evidence that the recovery mechanism has worked when exercised, such as the results of tested failover between independent facilities; a target or a plan states intent, not capability.

What makes an SLA enforceable

A service-level agreement is only as good as its metric definitions. The ISO/IEC 19086 series sets out SLA framework concepts, and the practical rules are:

• Define each metric precisely: what counts as available, over which window (for example business hours) and with which exclusions.
• Make it verifiable: a measurement method the customer can check, not only the provider's internal monitoring.
• Check the unit and scope of measurement. A metric measured over a large unit (all customers, a whole region, a full month) can report the service as available while the smaller part a customer depends on is down. The measured scope has to match how the customer's application is actually deployed.

Service credits are a fee rebate, not loss compensation. They are typically a capped percentage of the monthly charge and often the customer's sole remedy for an SLA miss. They do not transfer continuity duties to the provider or replace a business impact analysis; business losses are handled through continuity planning and, where appropriate, insurance.

Outsourcing to a cloud provider transfers the work but not the accountability: the customer, as data owner (the controller, in privacy law), still answers to regulators for its data. Contracts, data processing agreements and the shared responsibility model allocate duties and remedies between the parties; none of them moves accountability off the data owner. Under GDPR Article 28, for example, a controller may use only processors that give sufficient guarantees, bound by a contract covering documented instructions, confidentiality, security, approval of sub-processors, assistance, deletion or return of data at the end, and cooperation with audits; the signed agreement gives the provider its own processor obligations but does not make it the accountable controller. That is why governance of providers, security and privacy are listed as shared considerations at all.

Auditability

Auditability, in ISO/IEC 17788's terms, is the capability of collecting and making available the evidential information needed for an audit of a cloud service. In practice much of that evidence sits with the provider. When a large provider refuses individual customer audits, the customer relies on independent attestations:

Some evidence only the provider can produce. The customer's own logs show what its users did; what the provider's staff did in the customer's tenant appears only in the provider's records, so where that evidence is needed the contract must oblige the provider to produce its administrative access logs for the tenant.

Subcontracting and the carve-out method

A SOC report handles a provider's subservice organisations (for example a firm that supplies its data-centre facilities or its network transport) in one of two ways: the inclusive method covers the subservice organisation's controls in the report; the carve-out method excludes them. A customer that needs oversight of the whole supply chain therefore obtains separate assurance over any carved-out subservice organisation (such as that organisation's own report) and contracts for notice of subcontractor changes. A report derived from the same examination carries the same carve-out.

Regulatory and jurisdiction

Data residency is not the whole regulatory picture. Under EDPB Guidelines 05/2021, making personal data available to a separate entity in a third country, including by remote access, is an international transfer that needs a legal basis and safeguards (access by the exporter's own employees travelling abroad is treated differently). Data stored inside the EU can therefore still be transferred if any separate entity elsewhere can reach it, so the provider's access model, not only its storage location, is assessed before signing; the answer can require specific safeguards or rule the provider out.

Maintenance and versioning is the shared consideration covering changes the provider makes to the service on its own schedule: upgrades, new releases, and the deprecation and retirement of features and API versions. In multi-tenant SaaS especially, the provider typically runs one release line for all tenants, so the customer cannot simply refuse an update. Versioning in the ISO/IEC 17788 (now ISO/IEC 22123-1) sense is also a labelling practice: the service carries a version label so the customer can tell which version is in use, which is what lets it track changes, pin integrations and match evidence to the release it covers.

The protective contract terms buy time and a place to adapt:

• Advance notice of changes, with release notes.
• A support period for superseded versions, so integrations built on an API version keep working while they migrate.
• A preview or sandbox tenant that receives releases before production, so the customer can test or formally validate each change first.

Regulated customers carry an extra duty. Where rules require a customer to validate the computerised systems that hold its regulated records for their intended use, as in clinical-laboratory and medical-device quality systems, supplier testing can be leveraged but does not discharge the customer's own validation duty, so each provider change has to be assessed against that duty before it reaches production.

The outline asks how emerging technologies change cloud risk. For each, know what it is and the security or privacy consequence it introduces.

Confidential computing

Confidential computing protects data in use by processing it inside a hardware-based trusted execution environment (TEE) whose memory is encrypted and isolated from the host operating system, the hypervisor and the provider's administrators. It closes the gap that encryption at rest and in transit leave open: data must be decrypted in memory to be processed.

Remote attestation is the proof that makes it trustworthy: hardware-signed evidence of the TEE's identity and the measurements of the code loaded into it. A key service that verifies the attestation before releasing a decryption key ensures secrets reach only genuine, unmodified workloads.

Quantum computing

The risk that applies today is harvest now, decrypt later: traffic protected by RSA or elliptic-curve key exchange can be recorded now and decrypted once a capable quantum computer exists, so data that must stay confidential for decades is already exposed. Forged signatures, by contrast, only become possible once such a computer exists. Post-quantum algorithms run on ordinary networks; quantum key distribution is not required. Migration starts with a cryptographic inventory: find where public-key algorithms are used and what they protect, then prioritise exchanges that protect long-lived data.

Edge computing and the Internet of Things

Moving processing from a central region to many small nodes (edge computing) and connecting large fleets of devices (IoT) both trade one well-protected environment for a larger, physically dispersed attack surface of devices that are exposed to physical access and hard to harden, monitor and patch. Edge processing reduces raw data sent to the centre; the cost is many more places to secure. Where devices cannot be patched or hardened themselves, compensating controls go around them: a segmented network behind a gateway that brokers, filters and monitors their traffic to the cloud, so a compromised device is contained.

Containers

Containers isolate processes using features of a shared host kernel; virtual machines each run their own kernel above a hypervisor. Containers therefore give weaker isolation than virtual machines: a kernel flaw or container escape can affect every container on the same host, which matters when workloads of different trust levels share hosts. Container security controls are covered in the cloud security concepts lesson.

Blockchain

A blockchain is a distributed ledger replicated across nodes whose entries, once written, are effectively immutable. That gives tamper-evident, independently verifiable records, and it conflicts with privacy rights to erasure and rectification. Whatever is written to the chain stays on every node. The EDPB's Guidelines 02/2025 on processing personal data through blockchain technologies (version 2.0 adopted in July 2026) accordingly advise against storing personal data on-chain. The reconciling design keeps personal data off-chain in a store that supports deletion and puts only a salted hash and pointer on the ledger, so members can verify records and erasing the off-chain data and salt breaks the link to the person.

Data science, machine learning and AI

These concentrate large data sets in the cloud for training and analysis, which raises data governance, privacy and model-integrity questions. They are covered in their own sub-domain, in the AI/ML in the cloud lesson.