Cloud security: who owns which problem?

A team moves a database to a managed service and removes “database security” from its task list. The provider may now handle parts of the infrastructure, but someone still chooses who can read the records.

Shared responsibility: A division of security responsibilities between a service provider and its customer that depends on the service used.

Start with the service, not the logo

A virtual machine usually leaves guest operating-system maintenance with the customer. A managed database can move more platform maintenance to the provider. SaaS moves still more application operation away from the customer. Exact boundaries vary by product, contract, and configuration.

The useful question is specific: who patches this component, who configures this policy, and who proves it works? A broad statement that a cloud is “secure” is not an assignment of work.

Identity and information still need decisions

The customer commonly decides which users and workloads get access, what information is stored, and how it is classified and shared. A provider’s compliance report does not prove that your tenant’s roles, public sharing, retention, or recovery are correct.

Managed encryption is helpful, but it does not prevent an authorized identity from reading data it should never have been granted. Availability also depends on choices such as redundancy and restore procedures; not every service automatically supplies the same resilience.

Make the handoff observable

Use a responsibility table with component, provider duty, customer duty, named owner, and evidence. Include logs, key management, backups, incident escalation, and account recovery. “Shared” should not mean two teams each assume the other is doing the work.

Revisit the table when the architecture changes. Replacing a virtual machine with a serverless function changes patching duties, but the function’s dependencies, identity, permissions, and data handling still require attention.

EXPLORE THE CONCEPT

Choose a service model

See which example responsibility remains with the customer.

A virtual machine

The provider operates underlying infrastructure; the customer generally manages the guest OS, application, identities, and configuration.

A managed database

Platform duties shift, but customers still decide data access and configure service options appropriate to their needs.

A SaaS workspace

The vendor operates the application. Customers still manage their users, sharing, configuration, and appropriate use.

A simplified learning model. It connects to no systems and uses no real data.

Work the boundary: a managed photo library

Consider a fictional charity that stores event photos in a managed service. Asha, its coordinator, decides which albums may be public. Luis, its administrator, configures access. The provider operates storage hardware and the managed platform. These are different duties: the ability to operate a setting does not automatically make Luis the right person to decide which children’s photos may be shared.

Record the approved intent before discussing settings: published event images may be viewed publicly; originals remain restricted to the media team. The product’s permission model must then express that distinction. If it cannot, the architecture or workflow needs adjustment. A provider-operated service does not make an unsupported business requirement disappear.

This table is an assignment for the fictional service, not a universal statement about every provider’s contract. Confirm which features are included, which require configuration, and which require a different service tier or integration.

PredictThe provider reports healthy storage, but the charity accidentally deleted an album. Does platform health prove the album can be restored?

No. Healthy infrastructure and recoverable customer changes are different properties. The answer depends on retention, deletion behavior, available copies, permissions, and a usable restore process. Confirm these dependencies with the chosen product and a relevant rehearsal.

Separate operation, assurance, and response

A provider assurance report may describe its control environment over a stated period. It does not show whether Asha approved yesterday’s sharing change or whether Luis configured the intended audience. Keep provider evidence and tenant-specific evidence linked to the claims they actually support. Neither has to prove everything to be useful.

Incident handling also crosses boundaries. If the platform fails, the customer still needs a contact path, service-impact assessment, and communication owner. If an overbroad role caused an exposure, contacting the provider does not substitute for the customer’s permission decision. A clear handoff identifies who can change settings and who decides whether the proposed restriction preserves the charity’s essential work.

More managed service can reduce maintenance work while increasing reliance on provider logs, recovery options, or response times. Consider these tradeoffs before choosing the design. Define an exit or continuity need where it matters: the charity may need an export it can actually read if the service becomes unavailable.

Review responsibilities after a migration, new integration, staff change, or important product change. An old table can be neatly completed and still describe the wrong system. Practice the access part in the permission-review case.

Turn the idea into a decision

Turn “the cloud handles it” into a precise sentence naming a service, responsibility, owner, and piece of evidence.