1 Understanding the shared responsibility model — who secures what

The cloud shared responsibility model is simple in principle, frequently misunderstood in practice. Here is the truth: your cloud provider is responsible for securing the cloud infrastructure itself — the physical data centres, network infrastructure, and hypervisors that host your applications. You are responsible for everything else: the data you store, the applications you run, the configurations you set, and the access controls you implement.

This is not a partnership. It is a dividing line. On the provider’s side: physical security, network isolation, and foundational infrastructure. On your side: everything else. And the boundary shifts depending on the service model you choose.

IaaS, PaaS, and SaaS — Different Responsibility Splits

Cloud services come in three primary models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). Each shifts the responsibility boundary.

IaaS (think AWS EC2, Microsoft Azure Virtual Machines) gives you virtual servers and storage. The provider handles the physical infrastructure. You handle the operating system, middleware, runtime, applications, and data. This is maximum responsibility on your side — maximum flexibility, maximum risk if you misconfigure.

PaaS (think Heroku, Google App Engine) provides a platform where you write and deploy applications. The provider handles infrastructure, operating system, and middleware. You handle the application code and data. Less responsibility on your side than IaaS, but you must still secure your code and configurations.

SaaS (think Salesforce, Office 365, Slack) is fully managed software. The provider handles nearly everything: infrastructure, platform, application, and often data security policies. You handle access control, user authentication, and data governance. Least responsibility on your side, but you are not off the hook.

Most boards assume the responsibility boundary. That assumption kills them. Misconfigure access to an S3 bucket in IaaS? That is your breach. Misconfigure identity and access management in SaaS? Also your breach.

2 Cloud misconfiguration — the number one cause of breaches

Cloud misconfiguration is the single largest attack vector in modern cybersecurity. Not advanced hacking. Not zero-day exploits. Misconfiguration. A simple error in access controls, encryption settings, or logging configuration that exposes gigabytes of sensitive data to the internet.

How Misconfiguration Happens

Developers build fast. Security is often an afterthought. An engineer stands up an S3 bucket to test an application and sets permissions to “public read” for convenience. The test finishes. The bucket is never locked down. Six months later, a researcher or attacker finds it and downloads millions of customer records. You do not know until it is too late.

Alternatively: you deploy a cloud database with default credentials. Or you leave an API key in source code. Or you configure a firewall rule that is too permissive. Or you fail to enable encryption. Each of these is a misconfiguration error — not a flaw in the cloud platform, but a failure of your governance.

Real-World Examples (Anonymised)

A financial services firm deployed AWS resources for a data analytics workload. The storage buckets were configured with public read permissions by mistake. For eight months, the bucket contained unencrypted customer transaction records accessible to anyone on the internet. A security researcher found it, notified the firm, and the data was publicly disclosed. Regulatory fines: £2 million. Reputational damage: immeasurable. Root cause: a single misconfiguration.

A healthcare provider migrated patient records to Microsoft Azure. Azure Key Vault (the encryption key management service) was not properly integrated into the data pipeline. Patient data was encrypted, but the encryption keys were stored in unencrypted form in a separate storage account. When an insider accessed that storage account, they could decrypt years of patient data. Breach scope: 500,000 records. Root cause: misconfiguration of encryption key management.

An e-commerce business provisioned cloud databases for their payment processing system. The databases had no access controls configured — any application with the connection string could read, modify, or delete data. A junior developer accidentally committed the connection string to a public GitHub repository. Within hours, attackers exploited it. Compromise scope: credit card data for 250,000 customers. Root cause: misconfiguration of database access controls.

These are not sophisticated attacks. They are governance failures. And they are preventable. But only if boards understand that this responsibility falls on them, not the cloud provider.

3 Multi-cloud and hybrid complexity — the governance nightmare

Most enterprises do not live in a single cloud. They live in two, three, sometimes four cloud environments simultaneously. AWS for compute. Azure for data analytics. Google Cloud for machine learning. On-premises infrastructure for legacy systems. Each cloud has different security models, different naming conventions, different logging mechanisms, and different compliance frameworks.

This is where governance breaks down. Security teams struggle to maintain consistent policies across platforms. A configuration that is secure in AWS might be insecure in Azure because the naming is different. Logging is enabled in one cloud but not in another. Encryption is enforced in one but optional in another. And visibility? Nearly impossible.

The Multi-Cloud Problem

In a single-cloud environment, you can hire cloud security specialists and build a cohesive security programme. In a multi-cloud environment, you need specialists in each cloud platform, plus a governance layer above them all. This is expensive. Most organisations skip it. They appoint a “cloud security lead” who is overwhelmed, under-resourced, and ultimately ineffective.

The result: security gaps. An attacker identifies that your Azure environment is heavily monitored but your Google Cloud environment is not. They target Google Cloud. Or they identify that access controls are strict in AWS but relaxed in on-premises systems, and they pivot there. Multi-cloud environments create strategic weak points that attackers exploit.

Boards must demand unified governance: a single security policy applied across all cloud environments, centralised logging and threat detection, consistent identity and access management, and regular audits of each platform’s configuration. This requires investment in cloud security orchestration tools and skilled personnel.

4 Data sovereignty and residency — where your data lives matters legally

Cloud providers offer global infrastructure. You can deploy your application in any region of the world. But the location of your data is not just a technical choice — it is a legal one.

Regulatory Residency Requirements

Some jurisdictions require personal data to remain within their borders. Canada’s PIPEDA modernisation (discussed in Canadian Cyber Law) tightens this. The EU’s GDPR explicitly allows data transfers only to jurisdictions with adequate protection. If your organisation processes EU resident data but stores it in the US, you must have Standard Contractual Clauses and documented legal justification.

Australia requires government data to stay in Australia. Japan has similar rules for Japanese personal data. And the US CLOUD Act allows US law enforcement to compel data held by US companies — even if that company is a subsidiary of a non-US parent and the data belongs to non-US citizens.

These regulations exist for a reason: to protect privacy. But they create operational complexity. If you process data across multiple jurisdictions, you may need to deploy separate cloud infrastructure in each jurisdiction, each with its own security controls, compliance audits, and disaster recovery plans.

Cross-Border Implications

Boards must map where personal data is stored and why. If you process Canadian, EU, and Australian resident data, you likely need infrastructure in three jurisdictions. This is not cheap. It is also not optional. Regulators are enforcing this now.

5 Cloud security posture management — continuous visibility and governance

Cloud security posture management (CSPM) is the practice of continuously monitoring your cloud environments for misconfigurations, compliance violations, and security risks. It is not a one-time audit. It is ongoing visibility and remediation.

What CSPM Does

CSPM tools scan your cloud infrastructure and identify issues: storage buckets with public access, databases without encryption, overpermissioned identity roles, unencrypted data in transit, logging disabled, and a thousand other misconfigurations. They compare your configuration to security frameworks (CIS Benchmarks, PCI DSS, HIPAA) and show you where you fall short.

Good CSPM is not optional. It is the only way to maintain governance across multi-cloud environments. But CSPM is reactive — it finds misconfigurations after they exist. What you need is a combination of CSPM (to find what is wrong) and Infrastructure as Code (IaC) governance (to prevent misconfigurations from being deployed in the first place).

Board Action: Implement CSPM and IaC Governance

Your cloud infrastructure should be defined in code (Infrastructure as Code). Before that code is deployed, it should be scanned for security violations. Only code that passes security checks should be deployed. This prevents misconfigurations from ever reaching production. Then, CSPM continuously monitors what is running, finds any drift (unauthorised changes), and alerts your security team.

6 The cloud shared responsibility matrix — at a glance

Below is the authoritative shared responsibility model: who (Customer or Provider) is responsible for each security layer, across IaaS, PaaS, and SaaS.

7 What boards must do now — eight immediate action items

1. Map Your Cloud Infrastructure

First, know what you have. Conduct a comprehensive inventory: which cloud providers do you use, which services, what data is stored where, and who has access. Many organisations discover shadow cloud usage — teams provisioning resources outside of official channels. This is a major risk.

2. Clarify Responsibility for Each Service

For each cloud service you use, clearly establish responsibility: what does the provider secure, and what do you secure? Use the shared responsibility matrix above. Make this explicit. Publish it to the board.

3. Implement Cloud Security Posture Management (CSPM)

Deploy a CSPM tool that continuously scans your cloud environments for misconfigurations. Budget for this. It is not optional. Without CSPM, you have no visibility into your cloud risk.

4. Establish Infrastructure as Code (IaC) Governance

Require all cloud infrastructure to be defined in code. Scan all code before deployment for security violations. Only approved code deploys to production. This prevents misconfigurations before they happen.

5. Centralise Identity and Access Management (IAM)

Implement a single source of truth for user identity and access across all cloud environments. This is complex in multi-cloud settings, but it is essential. Without it, you cannot enforce consistent access controls.

6. Enable Comprehensive Logging and Monitoring

Every action in the cloud should be logged. Every access, every configuration change, every data movement. Logs must be immutable and retained for compliance periods. Monitor logs for suspicious activity in real time.

7. Classify and Encrypt Sensitive Data

Know where your sensitive data is. Classify it (financial data, customer PII, intellectual property, etc.). Encrypt it at rest and in transit. Enforce encryption by default across all cloud services.

8. Establish Board Reporting and Executive Accountability

The board must receive quarterly reports on cloud security posture: what misconfigurations were found, how many were remediated, what high-risk gaps remain. Assign accountability to a single executive. Tie their compensation to cloud security metrics.

8 Five critical questions every director should ask