Cloud Security Shared Responsibility Explained for Business Leaders

The model in one sentence

AWS summarizes it as security of the cloud versus security in the cloud. The provider protects the facilities, hardware, network and virtualization that run its services. The customer protects everything it puts in, configures or connects to those services. Microsoft and Google publish equivalent models; Google also describes a "shared fate" approach in which it provides secure defaults and guidance to help customers with their part.

How the split changes by service model

Exact boundaries vary by service, so check each provider's documentation for the services you use.

Customer responsibilities most often missed

• Identity: MFA not enforced, former employees still active, shared administrator accounts.
• Permissions: broad administrator rights granted for convenience and never removed.
• Public exposure: storage buckets, databases or remote management ports reachable from the internet.
• Logging: audit logs not enabled, not collected centrally or kept too briefly to investigate an incident.
• SaaS data recovery: the provider keeps the service running, but recovering from your own deletions or meeting long retention needs may be your responsibility. Review what the service actually offers.
• Patching: virtual machines in IaaS still need operating system and application updates.
• Keys and secrets: access keys embedded in code or shared in chat.
• Third-party apps: integrations granted wide access to email, files or CRM data.

Why this matters to leadership

Contracts can assign tasks to a provider, but they do not transfer accountability. The Data Privacy Act makes the personal information controller responsible for personal data under its control, including data transferred to a third party for processing. Customers, partners, auditors and cyber insurers increasingly ask specific questions about MFA, backups and privileged access, and expect evidence.

Governance that works

• Name an owner for every cloud and SaaS service.
• Adopt a security baseline for each platform, such as the CIS Benchmarks.
• Run regular posture reviews with native tools such as AWS Security Hub, Microsoft Defender for Cloud or Google Security Command Center.
• Review privileged access every quarter.
• Make sure the incident response plan covers cloud accounts and SaaS applications.
• Assess providers before signing: certifications, assurance reports and data processing terms.

Reading provider assurance reports

SOC 2 reports list complementary user entity controls: controls the customer must operate for the provider's controls to be effective. Read that section and assign each item an owner. For ISO/IEC 27001 certificates, check the scope; it may not include the specific service or location you use.

Questions to ask your IT team or provider

1. Which cloud services do we use, and who owns each one?
2. Is MFA enforced for all users and every administrator?
3. How many people have administrative access, and when was it last reviewed?
4. Which of our resources are reachable from the internet, and why?
5. Where are logs collected, and how long are they kept?
6. Can we restore data from our SaaS applications, and when did we last test it?
7. Which third-party applications can access our data?
8. What would we do in the first hour if an administrator account were compromised?