Shared Responsibility Changes With Every Cloud Service You Choose
The shared-responsibility model is often presented as a diagram that moves colored boxes from the customer to the cloud provider. That diagram is useful, but the operational question matters more: when something must be configured, patched, monitored, backed up, investigated, or governed, who is expected to do it for this specific service?
The current AZ-900 objectives explicitly include the shared-responsibility model. The concept explains why moving to Azure changes security and operations without eliminating either one. As services become more managed, Microsoft operates more of the stack, while the customer continues to own critical decisions about data, identities, configuration, and appropriate use.
The model is therefore a control map, not a promise that “the cloud handles security.” A team that understands the boundary can assign work deliberately. A team that does not understand it can leave important tasks unowned because each side assumes the other side is responsible.
Some responsibilities remain with the customer in every cloud model
Microsoft’s shared-responsibility guidance keeps several customer duties consistent across IaaS, PaaS, and SaaS. Customer data remains the customer’s responsibility. Accounts, identities, and access decisions remain customer concerns. Configuration choices that the service exposes to the customer also remain customer responsibilities.
This is important because many cloud incidents do not require failure of the provider’s physical infrastructure. An over-privileged account, public sharing setting, weak application secret, misconfigured network rule, or unprotected data set can create serious exposure even while the Azure platform is operating exactly as designed.
Identity deserves particular attention because it crosses service models. The principles discussed in Azure identity and access management continue to matter whether a workload uses virtual machines, managed databases, serverless functions, or SaaS applications.
IaaS transfers hardware responsibility but leaves a large operating surface
With infrastructure as a service, Microsoft operates the physical datacenter, physical network, and physical hosts. The customer receives virtualized infrastructure and retains responsibility for much of what runs above it. Virtual machine operating systems, patches, installed applications, host-level security configuration, and many network controls remain customer work.
This model is attractive when the workload needs operating-system control, specialized agents, custom network behavior, or compatibility with software designed for traditional servers. The same flexibility creates a larger operational burden. The customer needs patch processes, hardening standards, vulnerability management, backup design, monitoring, and recovery procedures.
IaaS therefore illustrates the shared-responsibility model clearly: the cloud removes the need to own a physical server but does not automatically modernize the workload or remove the operational practices that a server still requires.
Teams should make the boundary concrete for each virtual-machine workload. Guest operating-system updates, endpoint protection, local firewall configuration, installed agents, application runtime versions, and the credentials used by the workload all need named owners. The fact that Microsoft maintains the hypervisor does not answer any of those questions.
PaaS removes operating-system work but not application responsibility
Platform as a service shifts more infrastructure operations to Microsoft. A managed application platform or database can eliminate direct operating-system patching and hardware management. Developers and administrators can focus on code, data, service configuration, identity, and application behavior instead of maintaining the underlying server fleet.
The customer still needs to secure the application. Code vulnerabilities, weak authorization, unsafe secrets, excessive permissions, bad data handling, and incorrect service configuration remain real risks. PaaS reduces one layer of operational work; it does not guarantee that the workload built on top of the platform is secure or reliable.
The shift can also change the skills a team needs. Engineers spend less time maintaining operating systems and more time understanding service configuration, supported runtimes, deployment slots, identity integration, diagnostic settings, throttling, and platform-specific recovery behavior. Responsibility becomes narrower but often more specialized.
PaaS also creates service-specific responsibilities. Teams must understand scaling settings, backup capabilities, network integration, identity options, logging, quotas, maintenance behavior, and supported resilience patterns. “Managed” describes who operates the platform, not whether the customer can stop making architecture decisions.
SaaS still requires identity, data, and configuration governance
Software as a service moves even more of the stack to the provider. The customer consumes a finished application rather than managing servers or application runtime. This reduces infrastructure work dramatically, but users, permissions, sharing, retention, business configuration, and data governance remain meaningful customer responsibilities.
A SaaS incident can result from an account takeover, an overly broad sharing rule, an unmanaged integration, or an inappropriate retention setting. None of those failures require Microsoft to lose control of a datacenter. They are failures at the layers the customer still controls.
SaaS configuration also changes over time. New collaboration features, external-sharing options, integrations, and defaults can alter the risk profile without any server deployment by the customer. Tenant administration therefore needs change review and periodic configuration assessment, not just one-time setup.
This is why shared responsibility connects directly to governance. The broader Azure governance discussion is not separate from cloud service choice. The more managed the service becomes, the more customer effort often shifts toward policy, identity, data, and configuration management.
Responsibility should be mapped control by control, not service by service
A single workload can mix IaaS, PaaS, and SaaS. It might use virtual machines for one legacy component, a managed database for application data, a SaaS identity platform, and serverless functions for event processing. Assigning one responsibility label to the entire application would hide the actual ownership boundaries.
A practical control matrix can identify who owns patching, encryption decisions, key management, backup configuration, identity administration, logging, vulnerability management, network security, data classification, incident response, and disaster recovery for each component. The matrix should distinguish provider-managed controls from customer-configured controls and genuinely shared controls.
This control-level view also reduces organizational gaps. If the cloud team believes application owners manage backups while the application team believes the service does it automatically, the gap can persist until a recovery event. Explicit ownership is an engineering safeguard.
Backup and disaster recovery are especially easy to misunderstand
Cloud durability is not the same as backup, and high availability is not the same as disaster recovery. A managed service may replicate data automatically for platform resilience while still requiring the customer to configure retention, backup frequency, geographic redundancy, restore permissions, or recovery testing according to business requirements.
The customer also owns the recovery objective. Microsoft can provide service capabilities, but it does not decide how much downtime a business process can tolerate or how much recent data loss is acceptable. Those requirements must be translated into service configuration and tested recovery procedures.
This is a useful boundary to remember: the provider can supply mechanisms, but the customer owns the business decision about how those mechanisms should be used.
Security tools do not replace ownership of security outcomes
Azure provides security controls, monitoring, identity services, policy enforcement, and threat-protection capabilities. Choosing or enabling a tool does not transfer responsibility for defining the right policy, responding to alerts, maintaining least privilege, or deciding which data requires stronger protection.
As candidates move toward security-focused work such as AZ-500, the shared-responsibility idea becomes more concrete. Security architecture is largely about understanding which controls exist at each layer, which party can configure them, and where gaps may appear between platform protection and workload protection.
The strongest cloud security programs therefore maintain both technical controls and clear ownership. A control that exists but is not configured, monitored, or reviewed is not equivalent to a control that is operating effectively.
Incident response must cross provider and customer boundaries cleanly
When an incident occurs, teams need to know whether they are investigating customer configuration, application behavior, identity activity, or a provider service issue. The escalation path is different for each. Good incident response documentation identifies which logs are available, which teams own them, which provider support channels apply, and what evidence must be preserved.
Shared responsibility also affects communication. A platform outage may require provider status information and support engagement, while a compromised identity may be entirely customer-operated. A security event can involve both: for example, a customer misconfiguration can create exposure through a service that is otherwise healthy.
Clear boundaries allow responders to move faster because they do not spend the first hour debating who is supposed to act.
Provider support cases also depend on evidence the customer can collect: timestamps, resource identifiers, correlation IDs, logs, and a clear statement of observed impact. Shared responsibility includes being prepared to collaborate across the boundary when the source of a failure is not immediately obvious.
Choose a cloud service partly by the responsibilities you want to retain
Service selection should consider more than features and price. A team with strong infrastructure operations may accept IaaS responsibility for a specialized workload. A small development team may prefer PaaS because it removes operating-system work. A standard business capability may be better consumed as SaaS because rebuilding it would create unnecessary engineering and support obligations.
The Microsoft Azure Fundamentals path is useful because it frames these choices before candidates specialize. The shared-responsibility model helps explain why the same business requirement can produce different operating models depending on the service selected.
Across Microsoft certifications, the details become more specialized, but the governing question stays simple: what does Microsoft operate, what does the customer operate, and what decisions can only the customer make? Cloud responsibility becomes manageable when those questions are answered explicitly rather than assumed.