Assign responsibility across service models

Once an offer's cloud characteristics are understood, the operational question remains: who manages which layer? IaaS, PaaS and SaaS are not fixed security grades or price bands. They describe the capability delivered and the consumer's control boundary. With Infrastructure as a Service, a team obtains compute, storage and network resources and generally remains responsible for its chosen operating system, application, data and configuration. With Platform as a Service, the team deploys an application onto a provider-operated platform, but it has not delegated its code quality, data policy or user access decisions. With Software as a Service, the team uses a ready-made application and configures users, content and permitted settings. These are model descriptions; the actual contract and operational documentation define the boundary for a particular offer.

Draw the stack from bottom to top: physical facility, physical network, host, operating system, runtime, application, identity, data and backup. Do not assume that every layer has exactly one party for every task. A provider may operate a managed database while the customer chooses retention, users and keys. Microsoft's shared-responsibility guidance illustrates that customers retain duties for their data, identities and settings across service types, while some infrastructure duties shift to the provider according to the model. This is guidance for that provider, not a universal legal clause for all services. Record an operating owner, a verifier and an escalation contact rather than filling a cell with an unexplained word 'shared'.

Consider a course-booking service needing a web application and booking data. With a virtual machine, the team can install its application and manage the operating system, patches and data backups according to the service agreement. It gains environmental control but needs operational capacity and monitoring. With a managed application platform, the provider may carry operating-system maintenance; the team still needs an owner for code tests, application secrets, access rules, data backups and booking outcomes. With a ready-made booking application, the offer is closer to SaaS but may not support the required business rules or data export. Do not choose a model until data, integration and recovery requirements are known.

Deployment model is a different question. NIST distinguishes public, private, community and hybrid cloud by how infrastructure is provisioned and used. Do not equate 'private' with IaaS or 'public' with SaaS. The former describes the infrastructure arrangement; the latter describes what capability a consumer uses. A private application platform or a public infrastructure service is possible. 'Hybrid' does not merely mean using two suppliers: it describes distinct infrastructures bound by technology that enables data and application portability. A deployment decision requires evidence about operations, connectivity and governance rather than an inference from a company name or address.

Make the decision through a task matrix. Include operating-system updates, application defect repairs, user access, booking-data protection, backup and restoration, performance monitoring, and removing a leaver's account. Columns should name who executes, who authorizes, where evidence resides, and which offer term still needs confirmation. An empty cell is a task likely to be missed. Do not fill it with 'provider' without a source. If marketing says 'backup included', ask what is backed up. Does it cover configuration or only data? Who requests a restore, and how long did a tested restore take? Do not turn a backup promise into an RPO or RTO claim without measuring a recovery point and recovery time against the business requirement.

More provider management is not always better. PaaS can reduce operating-system work but constrain runtime versions or network choices. IaaS can accommodate a legacy application requiring a special environment, but increases patching and monitoring work. SaaS may make a standard function available quickly but constrain customization and export. Put the non-negotiable requirement first, then ask whether a constraint rules out the model or calls for a design change. If exit documentation or API limits are missing, mark the decision conditional instead of guessing. After choosing, test one real task: create a limited test user, change the permission, revoke it and inspect the log. This reveals more about identity responsibility than the model's name alone.