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.

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

Area	Practical question	Evidence to request
Identity	Who can access the service?	Users, roles, MFA, keys, reviews
Configuration	What can be exposed?	Baseline, drift scans, policy code
Logging	Who detects change?	Sources, retention, alerts, response
Resilience	Can the service recover?	Objectives, backups, restoration tests

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.