Cloud Security Is a Shared Operating Responsibility

Cloud security is a shared operating responsibility. The provider secures underlying infrastructure, while the customer remains accountable for identities, data, configurations, monitoring, and recovery choices. The boundary changes by service model, but ownership never disappears when a workload moves to the cloud.

A secure cloud account is created by assigning owners, writing controls into daily operations, and checking that those controls work.

On this page

• What shared responsibility means
• How the boundary changes by service model
• Why identity is the first control
• Who owns logging and detection?
• Why configuration is a security task
• How resilience fits security
• Turn the model into ownership
• Mistakes to avoid
• What leaders should ask before onboarding

What shared responsibility means

The provider protects facilities, hardware, core networking, and managed services within its scope. The customer protects what it puts into those services and how it uses them.

The exact split depends on the provider, product, contract, and service model. A customer using a virtual machine usually manages more than one using a managed database.

• Record provider responsibility.
• Record customer responsibility.
• Assign an operating owner.

How the boundary changes by service model

IaaS, PaaS, and SaaS move different tasks to the provider. More managed services mean less infrastructure to operate, not less security to govern.

Customers still own users, permissions, data, integrations, and settings exposed by the service. Confirm the boundary in current product documentation.

• Map the service model.
• List configurable controls.
• Record evidence and review frequency.

Why identity is the first control

Identity is the control plane for cloud operations. Stolen credentials, excessive roles, weak service accounts, and unreviewed integrations can create paths to sensitive resources.

Use central identity where practical, require strong multifactor authentication for privileged access, separate administrative accounts, and make short-lived credentials the default for automation.

• Least privilege.
• Separate production access.
• Review machine identities.

Who owns logging and detection?

Providers can generate logs without giving a customer a detection programme. Customers must select relevant sources, protect records, retain them, route signals, and respond.

Capture sign-ins, privilege changes, key use, network policy changes, data access where available, and security-service changes. A dashboard nobody reviews is not detection.

• Monitor collection gaps.
• Protect log integrity.
• Define escalation paths.

Why configuration is a security task

Public exposure, broad network paths, open storage permissions, weak encryption settings, and unused privileges can arise from ordinary changes.

Use approved templates and policy as code. Scan for drift and verify closure rather than merely changing a ticket status.

• Cover infrastructure code.
• Cover secrets and CI/CD.
• Review managed-service settings.

How resilience fits security

Confidentiality and integrity are not enough if a service cannot recover. Define recovery objectives, protect backups from production paths, control recovery credentials, and test restoration.

A backup report proves that a job ran. A recovery test provides evidence that systems and data can be restored within the chosen objectives.

• Map dependencies.
• Test restoration.
• Review recovery access.

Turn the model into ownership

For every service, list provider duties, customer duties, named owner, control, evidence, and review frequency. This makes responsibility useful during normal operations and incidents.

Inventory services and data, map the boundary, set the baseline, automate checks, exercise response, and review suppliers.

• Use a control register.
• Automate repeatable checks.
• Exercise compromise and recovery.

Mistakes to avoid

The most common mistake is treating provider security as customer security. A resilient data centre does not correct a public storage resource, broad administrator role, exposed secret, or absent recovery test.

Do not measure maturity by tools purchased. Measure controls working, monitored, tested, and owned.

• Do not outsource ownership.
• Do not ignore integrations.
• Do not confuse a dashboard with response.

What leaders should ask before onboarding

Ask who controls identity, data, configuration, logs, keys, recovery, and incident communication. Put the answers into architecture and contract records.

The goal is not a perfect boundary. It is a visible boundary with an owner and evidence.

• Name the customer owner.
• Name the provider evidence.
• Define failure response.

Comparison table

FAQ

Does the provider secure everything?

No. Providers secure infrastructure and managed services within scope. Customers still own data, identities, access decisions, configurations, and many workload controls.

Does SaaS remove customer responsibility?

No. Customers still manage users, permissions, data sharing, integrations, administrative settings, and response processes.

Who is responsible for cloud logs?

The provider operates available log sources. The customer selects, collects, protects, retains, reviews, and responds to relevant records.

How often should permissions be reviewed?

Set a schedule based on risk, privilege, data sensitivity, and organisational change. Review after role changes and incidents.

Conclusion

The useful decision is the one that can be tested. Use the framework above to define the problem, identify the evidence, assign ownership, and review the result after launch. Clear scope beats a large claim, and a measured workflow beats a polished demo.

Turn a cloud security decision into a working plan

A useful plan starts with the question the team must answer, then names the evidence that can answer it. For a cloud security decision, that means keeping identity, configuration, logging, resilience, and provider boundaries visible from the first design discussion through deployment and review. The plan should show what is known, what is assumed, and what still needs a test.

Keep the decision narrow enough to operate. A team can review one workflow, site, campaign, or service properly. It cannot improve a vague programme by adding another presentation. Define the boundary, assign the owner, and state what would make the team stop, change, or continue.

• Write the decision in one sentence.
• List the evidence required before approval.
• Record the owner, deadline, and change trigger.

What a useful test looks like

A test should resemble the conditions in which the technology will be used. Include ordinary input, incomplete input, an unavailable dependency, a change in volume, and a user who follows the process differently from the designer. The point is not to create an artificial obstacle. It is to expose the assumption that would otherwise fail in production.

Define the pass condition before the test begins. If the result is measured after the fact, the team may quietly move the target to fit the demo. Keep the test record with the result, limitation, decision, and next action.

• Use representative cases and edge cases.
• Name the threshold and measurement period.
• Keep failed tests and corrective actions visible.

How operators should review evidence

Evidence needs context. A log, report, benchmark, or supplier statement should identify its scope, date, method, owner, and limitation. Ask whether it describes the actual service or only a product family, laboratory result, design target, or marketing claim.

Review evidence at the point where a decision is made. When an operator cannot tell whether a signal requires action, improve the record or the runbook. The best evidence reduces a handoff and makes the next step safer.

• Separate measured, estimated, and projected results.
• Record scope, date, method, and limitation.
• Link evidence to the action it supports.

Failure modes to plan for

Every technology plan should describe how the service behaves when a dependency is slow, a credential is lost, data is incomplete, a supplier changes a feature, or a user disputes the output. Failure behaviour is part of the product, not an appendix for later.

Choose a safe degradation path. The system may queue, restrict, pause, fall back, require human review, or return a clear error. Make that choice explicit so people do not improvise a more dangerous workaround during an incident.

• List the important dependency and failure.
• Define the safe fallback or stop condition.
• Assign response, communication, and recovery owners.

A small rollout plan

Start with a bounded rollout that can be observed from beginning to end. Capture the baseline, train the users, open a route for exceptions, and schedule a review before the team expands the scope. A small rollout creates evidence without pretending that a pilot is proof of universal success.

At review, compare the result with the baseline and ask what changed in the workflow. If the technology improved one measure while creating rework, delay, risk, or confusion elsewhere, record the net result honestly and change the design.

• Choose one workflow or service boundary.
• Measure before and after with the same definition.
• Expand only after the owner accepts the evidence.

FAQ: practical decisions

What should be decided before implementation?

Define the purpose, owner, scope, data or inputs, expected output, failure path, acceptance test, and review date. These fields keep implementation tied to an operating result.

What if the evidence is incomplete?

Label the gap, assess its consequence, assign an owner, and decide whether the work can proceed with a control or must pause. Do not turn an unknown into a confident claim.

Who should review the result?

Include the person who owns the business outcome, the operator who runs the workflow, and the technical or risk owner who can change the control. Their questions are different and all three matter.

When should a team stop a rollout?

Stop or narrow the rollout when the failure mode is unsafe, the evidence cannot support the claim, the owner is missing, the acceptance condition is not met, or the dependency has changed materially.

Sources

• CISA Cloud Security Technical Reference Architecture
• NSA and CISA Shared Responsibility Model