Topics in this domain
- The Security Program: Charter, Scope and Objectives
- Security Team Structure, Roles and Staffing
- Working with Legal, HR, IT, Audit and the Business
- Program Implementation: From Plan to Operating Controls
- Information Asset Identification and Valuation
- Data Classification: Owners, Custodians and Users
- Data Lifecycle: Retention, Archiving and Secure Disposal
- Enterprise Architecture for Security Managers
- Information Security Architecture: Principles and SABSA
- Defence in Depth and Zero Trust
- Cloud Security and Shared Responsibility
- Control Frameworks: NIST SP 800-53, CIS Controls and ISO 27002
- Security Policy Development and Lifecycle
- Security Standards and Baseline Requirements
- Procedures, Guidelines and Acceptable Use
- Policy Enforcement, Exceptions and Review
- Designing Security Metrics: KPIs, KRIs and KCIs
- Collecting, Analysing and Reporting Metrics
- Security Maturity Models and Program Assessment
- Control Types and Categories
- Control Design and Selection Based on Risk and Cost
- Control Testing: Design vs Operating Effectiveness
- Identity and Access Management
- Network and Endpoint Security Controls
- Application Security and the Secure SDLC
- Configuration, Change and Patch Management
- Cryptography for Security Managers
- Security Testing: Scanning, Pen Testing and Tracking Remediation
- Security Awareness Program Design
- Role-Based Security Training
- Phishing Simulations and Social Engineering Defences
- Third-Party Risk Management and Due Diligence
- Vendor Contracts, SLAs and Right to Audit
- Fourth-Party and Supply Chain Risk
- Outsourcing and Managed Security Services
- Security Stakeholder Communication
- Executive Dashboards and Board Reporting
- Continuous Improvement of the Security Program
Cloud Security and Shared Responsibility
Renting, not owning
Cloud computing hands parts of the technology stack to a provider. That changes who runs what, but not who is accountable for the data. The security manager’s job is to know exactly where the line falls for each service, and to govern the organisation’s side of it.
Who looks after what
| Model | Provider runs | Customer runs |
|---|---|---|
| IaaS | Facilities, hardware, virtualisation | OS, runtime, applications, data, identity |
| PaaS | Also the OS, runtime and middleware | Applications, data, identity |
| SaaS | Also the application | Data, users and their access, configuration |
Whatever the model, data, users and access are always the customer’s job. Gaps appear where each side assumes the other covers something, so the split should be documented for every significant service.
The customer’s side
- Identity: single sign-on, MFA, least privilege, privileged access management for cloud admins.
- Configuration: infrastructure as code, guardrails, and cloud security posture management (CSPM) to detect drift and public exposure.
- Data: encryption, key management choices (provider-managed or customer-managed keys), data residency.
- Network: virtual networks, security groups, private endpoints.
- Logging: cloud API and console logs fed into the SIEM.
- SaaS: a cloud access security broker (CASB) for visibility of SaaS use and data controls.
Cloud governance
- Approved services: a process to assess and approve cloud services before use.
- Data location: where data is stored and processed, and the legal implications.
- Provider assurance: SOC 2 reports, ISO 27001 certificates, CSA STAR entries, checked to make sure they cover the services and regions actually used.
- Exit plan: how to get data back in a usable form, in time.
Misconfiguration is the big risk
Example. A team spins up a cloud database for analytics and leaves it reachable from the internet with a default password. CSPM flags it within an hour, the alert goes to the owning team, and a guardrail is added so public databases can’t be created at all.
Preventive guardrails (policies that block risky settings) plus continuous posture monitoring catch most misconfigurations before attackers do.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| What the customer is always responsible for | Its data, users and access |
| Most common cause of cloud breaches | Customer misconfiguration and weak identity controls |
| Tool that detects cloud misconfiguration | Cloud security posture management (CSPM) |
| Assurance over a large cloud provider | Independent reports, checked for scope |
| Does moving to the cloud transfer accountability? | No |
In short
- In IaaS, PaaS and SaaS the provider takes on different layers, but the customer always remains responsible for its data, users and their access.
- The shared responsibility split must be understood and documented; gaps appear where each side assumes the other covers something.
- Most cloud incidents come from the customer's misconfiguration and weak identity controls, not from the provider.
- Key cloud controls: strong identity and MFA, configuration monitoring (CSPM), encryption and key management, logging, and visibility of SaaS use (CASB).
- Governance covers approved services, data location, exit plans and assurance from providers (SOC 2, ISO 27001 for the services used).
- Accountability for data protection stays with the organisation, whatever the contract says.
Exam traps
- Moving to the cloud doesn't transfer accountability for protecting data.
- In SaaS, the customer still manages user access and data classification.
- A provider's certificate must cover the specific services and regions in use.
- Shadow cloud services bypass governance; discover and bring them in.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Who looks after what
The customer's side
1 / 9