Cloud security strategy, from shared responsibility to operating model

TL;DR: A cloud security strategy is a written decision about four things: which security tasks your provider carries and which your teams carry, which preventive guardrails block unsafe configurations, how you check posture continuously, and which named team owns each duty. Amazon Web Services (AWS), Microsoft Azure and Google Cloud publish similar splits. Microsoft says data and identities stay with you in every deployment type. This guide covers landing zones, detection, team structure and a 90-day sequence.

What is a cloud security strategy?

A cloud security strategy is a written decision about four things: which security tasks your provider carries and which your teams carry, which preventive guardrails stop unsafe configurations before they ship, how you check posture continuously once workloads run, and which named team owns each of those duties. If a document covers only one or two of these, in our reading it is a policy or a tool plan, not a strategy.

Start with the split

Every major provider publishes a shared responsibility model. Amazon Web Services (AWS) states that Security and Compliance is a shared responsibility between AWS and the customer. The split moves with the service you buy. AWS gives the example that its virtual server offering, Amazon EC2, counts as infrastructure as a service (IaaS) and so requires the customer to perform all of the necessary security configuration and management tasks.

Some duties never move. Microsoft's guidance says that for all cloud deployment types, you own your data and identities, and that holds across IaaS, platform as a service (PaaS) and software as a service (SaaS). Google adds a practical warning: the model requires an in-depth understanding of each service you utilize, including its configuration options.

Then add guardrails, checks and an owner

Knowing the split tells you what you must do. Guardrails and posture checks are how you do it at scale. A guardrail is a preventive control, such as an organization policy that blocks public storage buckets. A posture check is detective: it scans running accounts for drift from your baseline. The Cybersecurity and Infrastructure Security Agency (CISA) built its federal reference architecture around Cloud Security Posture Management (CSPM), describing approaches to illustrate recommended approaches to cloud migration and data protection for agency data collection and reporting. The current version dates from June 2022.

In our reading, ownership is the part most often left vague. Microsoft frames responsibility as a governance question of who is expected to configure, operate, and monitor each control. We think that sentence is the test to apply: each control in your strategy should map to a team name, not to "security" in general.

For a chief information security officer (CISO) new to the role, this four-part list doubles as an audit script. Ask for the document behind each row. Where none exists, that gap belongs in your first 90 days plan.

Who is responsible for what at AWS, Azure and Google Cloud?

Each provider publishes its own split. The wording differs more than the substance. A Pluralsight comparison puts it this way: "In general, all three cloud providers follow the same principles for shared responsibility; they just have slightly different approaches."

The table sets the published positions side by side for infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS).

Controls, not only layers

AWS also sorts controls into three groups: inherited, shared and customer specific. Patching is shared: AWS patches the infrastructure, and customers patch their guest operating systems and applications.

Microsoft labels its matrix as illustrative guidance that is not intended to convey legal conclusions or to change the terms of a customer agreement. A reader can check the contract itself for the binding terms.

What to do with the table

In our reading, the provider matters less than the service mix. One account can hold IaaS, PaaS and SaaS workloads at once, so each needs its own row in your ownership record.

• List every cloud service in use and tag it by service type.
• For each one, name an internal owner for data, configuration, network controls and the operating system where it is yours.
• Compare that list with the provider's current page, since these pages are revised over time.

Terms used here are defined in the glossary.

How Google's shared fate model differs from shared responsibility

Google's alternative is a second idea it calls shared fate. In our reading, it is an addition to the division of duties, not a replacement for it, and the customer's list of duties does not get shorter.

Google says shared fate includes building and operating a trusted cloud platform for customer workloads. Beyond that, the page describes four further commitments.

• Guidance and code. Google says it provides best practice guidance and "secured, attested infrastructure code" that customers can use to deploy workloads in a secure way.
• Packaged solutions. It releases solutions that combine various Google Cloud services aimed at complex security problems.
• Insurance. It offers insurance options to help customers measure and mitigate "the risks that you must accept".
• Closer contact. Google describes shared fate as more closely interacting with you as customers secure their resources.

In our reading, the insurance phrase is the most telling. It assumes some residual risk always stays with the customer. Shared fate offers help in carrying that risk. It does not transfer it to Google.

What stays with the customer

Google's own page puts the knowledge burden on the customer. It says the customer is the expert in knowing the security and regulatory requirements for the business. The page lists three factors for choosing controls:

1. Your regulatory compliance obligations
2. Your organization's security standards and risk management plan
3. Security requirements of your customers and your vendors

Tenable's summary of the Google model is blunter: "if you can configure or store it, you are responsible for securing it." In our reading, that rule holds under any cloud model. Shared fate changes the starting point, not the owner.

How to use it in practice

We think the practical value is speed: you start from Google's attested code instead of a blank template. The governance work is the same as under any provider.

• Treat Google's code as an input to your standards, not a substitute for them. Record every deviation.
• Map each insurance or risk offer to a named risk owner on your side.
• Keep your control decisions traceable to the three factors above. Auditors and boards will ask why a control exists, not who supplied it.

For how this accountability sits with the board and the executive team, see /guides/ciso-accountability and /glossary/board-cybersecurity-oversight.

What a landing zone is and which guardrails belong in it

A landing zone is the prepared environment a workload team receives before it builds anything, with logging, monitoring and security settings already in place. In Azure the unit is the subscription. Microsoft's guidance says DeployIfNotExists (DINE) and Modify policies help ensure your landing zones, which are also known as subscriptions, and the resources within them are compliant.

The reason to put guardrails in policy is drift. In our reading, an estate designed carefully at the start rarely stays that way once many teams start shipping. A policy that checks for a setting and applies it when it is missing keeps working after the platform team has moved on to other things.

What the guardrails do when a subscription arrives

Microsoft's example is a new subscription placed in the corp management group. The policies then enable Microsoft Defender for Cloud and configure its exports to the central Log Analytics workspace in the management subscription. They also:

• send Azure Activity logs to that central workspace
• configure diagnostic settings for all resources to go there
• deploy Azure Monitor agents for virtual machines, scale sets and Azure Arc connected servers

Microsoft says these policies remove the operational burden for platform and landing zone teams as the environment scales. The limit matters as much as the reach: no actual workload resources are deployed via DINE or Modify policies, only supporting resources and settings. In our reading, that is the right boundary. Guardrails set telemetry and baseline controls. Workload teams own what they build.

Rolling out enforcement in stages

Not every organization can let a policy change its environment on its own. Microsoft lists reasons, including regulatory restrictions and strict change control processes that require human approval for every action. Its answer is a phased approach built on enforcement mode, which the portal labels Disabled and Enabled, while Azure Resource Manager (ARM) templates use DoNotEnforce and Default.

Microsoft says some customers can never move past phase 1 because of regulatory restrictions, and staying there is supported. The choice is also reversible: a member of the platform team can reenable the policies at any time.

What to check in your own estate

• Whether every new subscription lands under a management group with policies already assigned.
• Which assignments sit in audit-only mode, and who approved that choice.
• Whether a noncritical subscription exists to test automatic remediation before wider rollout.

We think audit-only mode without a named owner is where drift returns quietly. The policy reports the gap, and nobody is tasked with closing it.

Identity, misconfiguration and visibility come first

Earlier sections set out who owns what. This one covers three failures that sit on the customer side of every model: who can get in, what is configured wrong, and what nobody knows is running.

CISA's Secure Cloud Business Applications (SCuBA) guidance states the customer duty plainly. It says "an agency is responsible for securely configuring their cloud business applications and collecting the associated logs and telemetry to meet their security needs" (CISA SCuBA TRA). The project exists to address "cybersecurity and visibility gaps" in federal civilian executive branch cloud applications (CISA SCuBA TRA).

Identity

Identity and access management (IAM) is where we would start. Give each person one federated identity, require multifactor authentication for every console and API login, and keep standing administrator rights close to zero. Check each provider's current IAM and privileged-access documentation before you treat a feature as present or absent. Feature sets change, and comparisons from older secondary posts go stale.

Turning the three risks into checks

Cloud Security Posture Management (CSPM) tooling is what runs these checks continuously instead of once a quarter. In our reading, its value depends on whether each finding reaches a named owner, not on how many findings it produces.

A worked example: the public bucket

The following is an illustration, not a reported case.

1. Found. A posture scan flags a storage bucket readable by anyone on the internet. It holds exported customer records.
2. Owned. The bucket's owner tag points to a data team. Where there is no tag, the account owner gets the ticket by default.
3. Fixed. The team removes public access, rotates any credentials stored in the files, and reviews access logs for the exposure window.
4. Prevented. The platform team adds a guardrail that denies public access at the organization level, using the audit-then-enforce rollout described in the landing zone section. Teams that need public content go through a documented exception.

The fourth step is the one that matters. Without it, the same finding comes back next quarter under a different bucket name.

Baselines for software as a service

The SCuBA reference architecture "is product and vendor agnostic" and provides "threat-based guidance to inform product-specific security baselines" (CISA SCuBA TRA). It also says it "does not supersede existing federal requirements" (CISA SCuBA TRA).

How detection, response and secure development fit the cloud model

Detection in the cloud starts with logs the provider writes and the customer has to keep.

In our reading, the practical link to zero trust is identity. When every request is authenticated, the control-plane audit log becomes the record of who did what. Revoking a credential becomes the first containment move, before anyone touches a network.

What shifts for each function

Default log retention differs by provider, service and log type. Check each default in the provider's own documentation and write it into the runbook. In our reading, the default is often shorter than an investigation needs.

On data, the customer's share includes encryption at rest and in transit, secure transfer protocols and "monitoring for unusual data access patterns and activities" (SentinelOne). In infrastructure as a service (IaaS), the customer also handles backups and disaster recovery for its operating systems and applications (SentinelOne).

A worked playbook: leaked access key on a compute instance

1. Revoke the credential. Disable the key, end active sessions, and rotate any secrets the key could read.
2. Snapshot the volume. Take a snapshot of the instance's disk before stopping it. Tag it with the case ID and copy it to a separate forensics account.
3. Preserve the logs. Export audit logs for the exposure window to write-once storage in that same forensics account, and extend retention on the source.
4. Scope the activity. Query the logs for every action taken by the identity, including resources it created.
5. Rebuild, do not clean. Redeploy the workload from the pipeline with fresh credentials.

Checks for this quarter

• Confirm audit logs from every account land somewhere workload teams cannot delete.
• Record the default retention for each log type and the retention you actually set.
• Run the playbook above as a tabletop with the platform team.
• Confirm a forensics account exists and responders can write to it.

How a cloud security team is usually structured

Most cloud security teams we see settle into three groups. A central platform security group owns the guardrails. Embedded engineers or business information security officers sit with business units. A named line runs to the cloud platform team that operates the landing zones. That shape is our reading, not a standard, but it maps onto the platform and landing zone team roles Microsoft describes.

• Central platform security group. Writes and tests policy, owns the control library and decides which guardrails are mandatory.
• Embedded engineers or BISOs. A business information security officer (BISO) translates those guardrails into terms a product line can plan around, and brings exceptions back.
• Cloud platform team. Runs the landing zones, which Microsoft notes are also known as subscriptions, and ships the change.

The split matters most where Microsoft lists reasons a team may hold back on automatic DeployIfNotExists (DINE) policies. Two of them are people problems: a lack of expertise in managing those policies, and a requirement that workload teams define all configuration in infrastructure as code (IaC). We think both call for clear ownership before they call for more tooling.

A sample responsibility assignment

The RACI below (responsible, accountable, consulted, informed) covers two common events: a new guardrail rollout and a workload team asking to be exempt from one.

For the guardrail change, a useful first step is audit mode. Setting enforcement to DoNotEnforce lets an assignment become an audit-only policy without editing the definition. Write the runbook with both names: the Azure portal says Disabled and Enabled, while Azure Resource Manager (ARM) templates say DoNotEnforce and Default. Resource Selectors allow a gradual roll out by location or resource type, which gives the platform team a staged release it can own.

An escalation path with time frames

The stages below are our suggestion. Adjust the clock to your change calendar.

1. The workload team files the exception with its BISO, who triages it the same business day.
2. If the BISO and the platform security lead disagree, the platform security lead and the cloud platform lead decide before the next change window.
3. If it is still open, the deputy CISO or CISO rules at the next risk review. Every approved exception gets an owner and an expiry date.

Where the CISO sits in the wider company changes who holds the last step. Our guide on CISO reporting structure covers that question.

What a security leader can do in the first 90 days

This is our own view of a workable sequence, not a standard. It builds on the earlier sections: where provider duty ends, what a landing zone holds and why identity comes first. By day 90 the goal is a short set of facts you can defend in front of the board.

In our reading, 90 days buys a first version. It does not buy a finished one.

Days 1 to 30: inventory

• List every account, subscription and project at each provider. Record a business owner and a billing owner for each.
• Check expense reports and corporate card statements for accounts that central IT never approved.
• Add Software as a Service (SaaS) tenants. CISA's business application work covers capabilities that currently include productivity, messaging, content management, collaboration, and voice. Those tenants belong on the same list.
• Note which logs each source produces and where they land.

Days 31 to 60: responsibility map and guardrails

• Build one responsibility map per provider. Use one row per control and three columns: provider, us, shared.
• Add a row for provider-side detection. CISA notes that cloud vendors "respond to threats that may be undetectable to their tenants". Ask each provider how it tells you about such events and who receives the notice.
• Apply baseline guardrails in the landing zone. If change control requires human approval, start policies in audit mode and log every exception.

Days 61 to 90: owners and a board summary

• Name an owner for every control. Name a person, not a team.
• Write a one-page board summary covering what you found, what is covered, what is not, who owns each gap and when you will report again. Our board oversight report shows how committees tend to receive this material.
• If you report to a public company, read our guide to the Securities and Exchange Commission disclosure rules. Check with counsel which of them apply to you.

Treat the map as a living document. CISA says of its own business application architecture that it will periodically update the SCuBA TRA to ensure it is relevant and current. We think your map deserves a fixed review date for the same reason. For the wider first-quarter plan beyond cloud, see our first 90 days guide.

What this guide does not cover

It also does not compare current identity features at each provider, since those change often and the provider's own documentation is the place to check. For the rules and the record behind it, see CISO First 90 Days: A Week-by-Week Plan for a New Security Leader.