Start with shared responsibility
Microsoft's cloud shared-responsibility guidance says customers always retain responsibility for data, identities, accounts, and access management, while responsibility for applications, networks, operating systems, and physical infrastructure changes across SaaS, PaaS, and IaaS. AWS similarly distinguishes its security “of” the cloud from customer security “in” the cloud in its shared-responsibility model.
Customer-cloud internal-app products add another vendor boundary inside that cloud model. Ask which component the platform vendor operates, which the cloud provider operates, and which the buyer operates.
Potential benefit: account and network control
When the runtime is genuinely in a buyer-controlled account, the buyer may be able to apply its own organization policies, private network routes, egress rules, key systems, and cloud audit logs. That can make the deployment fit existing controls and let the buyer collect evidence directly.
But account location alone does not establish the boundary. A vendor control plane, browser route, authentication service, telemetry endpoint, update agent, or support tunnel may remain outside. Document every inbound and outbound path, then test the important ones.
Potential benefit: direct evidence and response
Customer ownership can give internal responders direct access to configuration, flow logs, runtime events, and resource history. It may reduce dependence on a vendor ticket during an investigation.
The corresponding risk is an empty console with no useful retention, alerting, or practiced query. Evidence ownership matters only if someone configures, monitors, protects, and can interpret the evidence.
Transferred risk: configuration and patching
In a managed service, the vendor normally operates more of the platform. In a customer-cloud model, the buyer may inherit operating-system or container updates, database maintenance, certificates, network policy, capacity, and version compatibility—or may contract the vendor to perform some of them.
Require a responsibility schedule that names the actor, cadence, supported versions, evidence, and missed-update escalation for every layer. “Runs in your VPC” is not an operating schedule.
Transferred risk: backup and recovery
Data being in the buyer's account does not prove it is backed up, restorable, or compatible with the application version. Microsoft’s reliability guidance notes that customers remain responsible for application resilience and must understand service-specific conditions.
Ask who configures backup, who can restore platform metadata and business data, which dependencies must be rebuilt, and when a representative restore was last run. A buyer-controlled snapshot without a tested application recovery path is only a stored artifact.
Compare the same controls
For each deployment candidate, fill the same matrix:
| Control or threat | Who configures? | Who operates? | Where is evidence? | Acceptance test |
|---|---|---|---|---|
| Identity and privileged access | ||||
| Network ingress and egress | ||||
| Secrets and encryption keys | ||||
| Platform and application patching | ||||
| Logging and incident response | ||||
| Backup and recovery | ||||
| Vendor support access | ||||
| Release and rollback |
Label vendor documentation, buyer-reproduced behavior, and unresolved questions separately. Absence from a reviewed page is not proof that a control is absent.
Decision rule
Choose customer-cloud for security only when the desired controls are actually within the buyer's boundary, a named operator can perform the transferred work, and representative tests produce evidence the buyer can retain. Choose a managed model when its vendor-operated controls and evidence meet the risk need more reliably than the buyer can.
The security question is not “Whose cloud?” It is “Who must make each control work, and what proves they did?”