Key takeaway
Do not concentrate controls only at the network edge. Design for resource ownership, identities that can reach each resource, event detection and recovery.
Assign responsibility by service model
IaaS, PaaS and SaaS do not share one responsibility boundary. For each workload, record provider-managed layers and customer-managed areas such as accounts, data, settings and application components. For example, the customer may patch a virtual machine’s operating system while the provider operates some lower layers of a managed application service. Build a responsibility matrix from the actual service configuration and documentation, not the service label alone. The examples below are starting points; the exact split depends on service documentation and configuration.
| Service example | Provider-managed area | Customer verification |
|---|---|---|
| IaaS VM | Physical and virtualization infrastructure | Guest OS, applications and permissions |
| Managed application platform | Platform and runtime layers defined by the service | Application code, data, identities and exposed configuration |
| SaaS | Application service operated by the supplier | Users, sharing, tenant configuration and data handling |
Build network and access controls around identity
Map network segments, entry points, APIs and service-to-service paths. Rather than relying on broad trust boundaries, authenticate users and workloads and allow each service only the connections it needs. Restrict management interfaces and review where and under what conditions they can be reached. Network filters are one layer; they do not replace account and application permissions.
Protect applications and data during design
Trace where application data is created, stored and transferred. Plan authentication, authorization, secret storage, encryption and audit logs that respect data sensitivity. In multitenant services, verify boundaries between customers and tenants at the application, storage and access layers. Assign owners for runtime environments, packages, service accounts and APIs in serverless and container deployments too. Moving an application to the cloud does not provide these controls by itself.
Design for detection, recovery and change
Decide in advance which records support investigations and who receives alerts. Track configuration changes, keep policies and templates under version control, and test the business impact of automated remediation. Evaluate backup and recovery separately from the cloud provider’s availability. An architecture review should consider threat scenarios, ownership, operating procedures and recovery steps together.
Test templates and supplier boundaries
Secure starter templates and CI/CD checks help teams reuse approved configuration. Document exceptions with a reason, owner and expiry date; before release, check privileged access, exposed services and secrets in code. For external SaaS, managed databases and integration providers, clarify security responsibilities, incident notification, log export and recovery dependencies in contracts and operating plans.