Study guide
16.2 Cloud Security: Deployment, Service Models, and Shared Responsibility
ISC2 Systems Security Certified Practitioner SSCP
Track your progress as you read
Finished sections get a check mark.
1 Introduction and Exam Overview
1.1 Current Exam Facts 1.2 Computerized Adaptive Testing, Scoring, and Retakes 1.3 Eligibility, Associate Pathway, Endorsement, and Maintenance
2 Ethics and Security Concepts
2.1 Comply with Codes of Ethics 2.2 Understand Security Concepts 2.3 Identify and Implement Security Controls
3 Functional Controls, Assets, and Change Management
3.1 Document and Maintain Functional Security Controls 3.2 Support and Implement the Asset Management Lifecycle 3.3 Support and Implement the Change Management Lifecycle
4 Security Awareness and Physical Security Operations
4.1 Support and Implement Security Awareness and Training 4.2 Collaborate with Physical Security Operations
5 Authentication Methods and Trust Architectures
5.1 Implement and Maintain Authentication Methods 5.2 Federated Access with OAuth2, SAML, and OpenID Connect 5.3 Understand and Support Internetwork Trust Architectures
6 Identity Lifecycle and Access Control Models
6.1 Support and Implement the Identity Management Lifecycle 6.2 Mandatory, Discretionary, and Role-Based Access Control 6.3 Rule-Based, Attribute-Based, and Privileged Access Management
7 Risk Management, Visibility, and Legal Concerns
7.1 Risk Management Concepts and Treatment 7.2 Risk Visibility, Reporting, and Threat Intelligence 7.3 Legal and Regulatory Concerns
8 Assessments, Monitoring, and Analysis
8.1 Security Assessments and Vulnerability Management 8.2 Operate and Monitor Security Platforms 8.3 Analyze Monitoring Results
9 Incident Response and Forensic Investigations
9.1 Incident Response: Preparation, Detection, Analysis, and Escalation 9.2 Containment, Eradication, Recovery, and Lessons Learned 9.3 Understand and Support Forensic Investigations
10 Business Continuity and Disaster Recovery
10.1 Business Continuity and Emergency Response 10.2 Disaster Recovery and Restoration Metrics 10.3 Backup, Redundancy, Testing, and Drills
11 Cryptography Foundations
11.1 Reasons and Requirements for Cryptography 11.2 Hashing, Salting, Symmetric, Asymmetric, and ECC 11.3 Digital Signatures, HMAC, Algorithm Strength, and Cryptanalysis
12 Secure Protocols and Public Key Infrastructure
12.1 Understand and Implement Secure Protocols 12.2 Understand Public Key Infrastructure
13 Networking Fundamentals, Attacks, and Access Controls
13.1 Understand and Apply Fundamental Concepts of Networking 13.2 Understand Network Attacks and Countermeasures 13.3 Manage Network Access Controls
14 Network Security Operations, Wireless, and IoT
14.1 Manage Network Security 14.2 Operate and Configure Network-Based Security Appliances and Services 14.3 Secure Wireless Communications 14.4 Secure and Monitor Internet of Things
15 Malware, Malicious Activity, and Endpoint Security
15.1 Identify and Analyze Malicious Code 15.2 Malicious Activity, Social Engineering, and Behavior Analytics 15.3 Implement and Operate Endpoint Device Security
16 Mobile, Cloud, and Virtual Environments
16.1 Administer and Manage Mobile Devices 16.2 Cloud Security: Deployment, Service Models, and Shared Responsibility 16.3 Cloud Legal, Regulatory, and Third-Party Requirements 16.4 Operate and Maintain Secure Virtual Environments
16.2 Cloud Security: Deployment, Service Models, and Shared Responsibility
Key Takeaways Explain This Topic AI
SSCP knowledge area 7.4 (outline effective 1 October 2025) deployment models are public, private, hybrid, and community. Community is a shared pool for organizations with a common mission or compliance need, not a synonym for hybrid.
Service models are Infrastructure as a Service, Platform as a Service, and Software as a Service. Who patches the guest operating system is the fastest way to tell them apart on CAT items.
In Infrastructure as a Service you patch the guest operating system, applications, and virtual-network configuration; the provider patches the hypervisor, hardware, and facility. In Software as a Service the provider patches the application stack; you still own identity, access, data classification, and acceptable use.
A virtual private cloud is an isolated virtual network you configure inside a public cloud. It is not a private-cloud building and it does not move legal jurisdiction by itself.
The shared responsibility model never lets the customer hand data classification or identity governance to the provider, regardless of service model.
Last updated: August 2026
Why cloud configuration is a Domain 7 operations skill
Knowledge area 7.4 is Understand and configure cloud security . Domain 7 as a whole remains 15% of the SSCP under the outline effective 1 October 2025. This section teaches the first cluster of 7.4 bullets: deployment models (public, private, hybrid, community), service models ( Infrastructure as a Service (IaaS) , Platform as a Service (PaaS) , Software as a Service (SaaS) ), virtualization (hypervisor, virtual private cloud (VPC) ), and the shared responsibility model . Legal and regulatory concerns, data storage and transmission, and third-party or outsourcing requirements are the next section. Secure virtual environments (Type 1 versus Type 2, containers, virtual machine escape) are knowledge area 7.5.
The SSCP is a practitioner credential. You are not being asked to recite a provider's marketing names. You are being asked who patches the guest operating system this week, whether a VPC is the same thing as a private cloud, and what you still own when the clinic's charting system is SaaS.
Deployment models
A deployment model is who shares the pool and where it lives , not which service tier you bought.
Model Who shares the infrastructure Typical SSCP tell Trap
Public Provider's multi-tenant infrastructure, consumed over the internet by many customers Clinic virtual machines in a commercial region; you pay for capacity Public does not mean the data is public; it means the platform is multi-tenant
Private Dedicated to one organization, on-premises or hosted for that tenant only Hospital-owned rack running a hypervisor cluster only for that hospital Hosted-private is still private if the pool is not shared with other customers
Hybrid Combination of private and public, usually with connectivity and consistent identity Burst rendering to public cloud while protected health information (PHI) stays in the on-premises cluster Hybrid is not two SaaS products; it is two deployment models working together
Community Shared by organizations with a common mission, industry, or compliance community Several clinics on a regional health-information network with a shared control baseline Community is not a synonym for hybrid or for public
If the stem says several hospitals jointly consume a cloud that is built to a health-sector baseline and is not open to arbitrary tenants, that is community . If the stem says production stays in the data hall and disaster-recovery copies run in a commercial region, that is hybrid . Do not answer public merely because a browser is involved.
Service models: who patches what
A service model is how much of the stack the provider operates . The outline's examples are IaaS, PaaS, and SaaS. Shared responsibility is easier if you memorize the patch line.
- Layer IaaS PaaS SaaS
- Data classification, identity, access, acceptable use Customer Customer Customer
Application code and tenant configuration Customer Customer (your code and config) Provider operates the app; customer still configures tenants, roles, and data
- Guest operating system patches Customer Provider Provider
- Runtime / middleware Customer unless you buy it as a service Provider Provider
- Hypervisor, host, physical facility Provider Provider Provider
Virtual network / VPC configuration Customer designs subnets, routes, and security groups; provider runs the fabric Mixed — you still own how your app is exposed Provider; you still own who may sign in
IaaS sells compute, storage, and network. You deploy a guest operating system and you patch it. Leaving an IaaS virtual machine unpatched because it lives at a famous provider is how ransomware walks a subnet.
PaaS sells a runtime (application platform, managed database, functions). You do not patch the operating system. You still own the code you push, secrets, and who can invoke the function.
SaaS sells the finished application. You do not patch the application binary. You still own accounts, multi-factor authentication (MFA) , data you put in, and whether marketing may export member lists.
Scenario (who patches IaaS versus SaaS). The clinic runs two workloads. Claims imaging is a fleet of IaaS virtual machines you built from a gold image. Charting is a SaaS EHR in another company's region.
Tuesday's guest operating-system cumulative update on the imaging servers is your change window. The IaaS provider will not log in and patch Windows for you. They will patch the hypervisor and the hardware under the virtual machines.
Tuesday's EHR application patch is the vendor's . You still verify that MFA is enforced, that former contractors are deprovisioned, and that export roles match job functions. You do not get to skip identity hygiene because the vendor patched the app.
If an imaging virtual machine is compromised, you isolate it, rebuild from a known-clean image, and review security groups. If the SaaS EHR is compromised at the provider, you still rotate tenant credentials, review audit logs you can export, and execute the contract — you do not patch their kernel.
Exam trap: answering that SaaS means the customer has no security work, or that IaaS means the provider patches the guest operating system because they own the building.
Loading diagram... Shared responsibility: who patches which layer
Virtualization in the cloud: hypervisor and VPC
The outline's virtualization examples under 7.4 are hypervisor and virtual private cloud (VPC) . Type 1 versus Type 2 detail is knowledge area 7.5; here you need the cloud meaning.
A hypervisor is the software (or firmware plus software) that multiplexes physical hosts into virtual machines. In public IaaS you do not walk up to that hypervisor. You consume virtual machines , virtual disks , and a software-defined network the provider operates. You still choose sizes, images, and whether management ports are exposed to the internet — that last choice is how brute-force against Remote Desktop becomes your incident, not the provider's.
A VPC is an isolated virtual network you define inside a public (or hosted) cloud: subnets, route tables, gateways, security groups or network access control lists (ACLs) , and peering. It is how you keep the imaging subnet from being a default-open campus. A VPC is not :
A private-cloud building. You can have a VPC in a public region.
Automatic encryption or automatic legal jurisdiction. Data residency is a contract and region choice, taught in the next section.
A substitute for guest hardening. A perfect subnet with an unpatched guest is still IaaS customer failure.
Peering, transit gateways, and hybrid VPN or dedicated interconnects turn a VPC into the cloud side of a hybrid deployment. Mis-peering a development VPC to production is a segmentation failure, the same class of mistake as a flat virtual local area network on-premises.
Shared responsibility — the exam's operational test
The shared responsibility model is the split of who implements which control , not a way to dump accountability. Across every service model the customer retains:
Data — classification, what you upload, encryption in the application, retention.
Identity and access — accounts, federation, MFA, joiner-mover-leaver.
Acceptable use and configuration of the tenant — which features are on, which regions, which sharing links.
The provider retains the physical facility, hardware, and (except when you run your own private-cloud hypervisor) the hypervisor. Everything between those poles moves with IaaS, PaaS, and SaaS as in the table above.
Exam traps. Calling a VPC a private cloud. Calling community cloud hybrid. Claiming the IaaS provider patches Windows because the virtual machine is in their region. Claiming SaaS means you no longer own personally identifiable information (PII) you typed in. Treating shared responsibility as shared blame after an incident instead of a pre-agreed patch line.
When a CAT item asks who patches what, name the service model first, then the layer. Guest operating system on IaaS is you. Application binary on SaaS is the vendor. Identity is you either way.