Who Patches the Server? The Managed Hosting Responsibility Boundary

No standards body defines what managed hosting includes. Two providers can use the identical phrase and ship completely different scopes, and neither one is lying. What is defined, publicly and in writing, is the split between cloud provider and customer. That published split is the floor, and everything above it is where the arguments happen. So evaluate a managed hosting arrangement from the platform’s own model outward, then ask which customer-side rows your provider has agreed to take.

Microsoft’s definition of IaaS, in its shared responsibility article on Microsoft Learn, is that “you manage virtual machines, operating systems, and applications” — which is precisely what a hosted server is. The responsibility matrix in that same article puts the operating system, applications, network controls, identities, configurations and data in the customer’s column for IaaS, and Microsoft’s column does not begin until the physical host.

Read that matrix across its four deployment columns — on-premises, IaaS, PaaS and SaaS — and the line is easy to find. The operating system only crosses into Microsoft’s column at PaaS; network controls only become fully Microsoft’s at SaaS. Microsoft’s list of what it owns runs from the physical datacenter through the hypervisor to platform services, and it qualifies that last entry: operating systems, runtimes and middleware are its job “in PaaS and SaaS,” not in IaaS. The prose is blunter still — “In IaaS, you’re fully responsible for deployed applications.”

Three rows read “Customer” straight across every deployment column: customer data, configurations and settings, identities and users. The article carries a section headed “Responsibilities you always retain,” and puts it without hedging — “For all cloud deployment types, you own your data and identities.”

One caveat for the contract conversation: Microsoft calls that matrix “illustrative guidance” that is “not intended to convey legal conclusions or to modify or contradict the terms of any agreement.” It says who should do the work; your contract says who is liable when nobody did.

Azure does ship guest patching tooling, and that is often what a provider means by “we handle updates.” Microsoft’s automatic VM guest patching documentation on Microsoft Learn says the feature has to be enabled on the VM, that patches “classified as Critical or Security are automatically downloaded and applied,” that they go on within 30 days of the monthly releases, and that custom images “aren’t currently supported.” So: some updates, some images, if somebody switched it on. Confirming it ran and covering what it skips is still a person’s job.

This is where hosted servers hurt people. Microsoft’s Shared Responsibility for Reliability article on Microsoft Learn leaves no room to argue: “You’re responsible for verifying whether backups are enabled and for configuring them appropriately.” Backup sits under what it calls “reliability-enhancing capabilities” — where Microsoft provides the capability but “you’re entirely responsible for selecting and using the appropriate ones for your needs.”

The same article splits by model: with PaaS “you might have automated capabilities for backup available to you,” but “if you use IaaS services, you typically need to plan and implement many reliability capabilities yourself.” A hosted server is IaaS.

And a backup nobody has restored is a hypothesis. The disaster recovery guidance in Microsoft’s Azure Well-Architected Framework tells architects to “recognize that no single tool covers everything” and to “regularly test restores to validate backups.” Microsoft’s shared responsibility article lists “insufficient backup and disaster recovery” among the unmet responsibilities it calls common in traditional on-premises environments, where backups are “infrequent, untested, or stored on-site.” That describes plenty of cloud tenancies too.

Microsoft’s Azure Virtual Machines reliability guide is blunt: “You’re responsible for detecting and responding to zone failures that affect your VMs,” and “Microsoft doesn’t automatically notify you when a zone is down.” Even the SLA is not self-executing — the Shared Responsibility for Reliability article warns that “you’re responsible for understanding and meeting these conditions; Microsoft doesn’t monitor or enforce your eligibility.”

The cloud provider column follows Microsoft’s published IaaS position in that shared responsibility article. The middle column comes from no vendor document — it is whatever your contract says, which is why you read it twice.

In practice it is the same pair every time: guest OS patching and restore testing. Both are invisible while they work. Both sit in the gap between a platform that says the customer owns them and an agreement that never mentions them. If your provider patches the OS, write it down alongside server management duties — patch windows, reboot approval, rollback. If somebody tests restores, name the cadence and who reports the result, then tie it to your backup and recovery plan and disaster recovery runbook. Unassigned means unowned.

These questions collapse the ambiguity. Who applies guest OS patches, on what schedule? Who verifies backups are enabled, and who proves a restore worked? Who holds privileged accounts? Who picks up the phone after hours, and what triggers that call? A provider who answers each one plainly is describing real managed IT services. One who answers “that’s all included” is describing a brochure.

What does managed hosting actually include?

Only what the contract names, plus the platform floor. The responsibility matrix in Microsoft’s shared responsibility article on Microsoft Learn assigns the operating system, applications, network controls, identities, configurations and data to the customer in IaaS, so anything on that list your provider handles is an added service, not an automatic one.

Does the cloud provider patch the operating system on my hosted server?

Not by default. Microsoft’s shared responsibility article on Microsoft Learn defines IaaS as “you manage virtual machines, operating systems, and applications,” and its matrix marks the operating system as the customer’s responsibility in IaaS. Azure’s automatic guest patching has to be switched on, and Microsoft’s documentation says only Critical and Security classifications get applied automatically.

If my hosting provider takes backups, am I covered?

Not until a restore has been tested. Microsoft’s Shared Responsibility for Reliability article states that “you’re responsible for verifying whether backups are enabled and for configuring them appropriately,” and the Azure Well-Architected Framework’s disaster recovery guidance tells architects to “regularly test restores to validate backups.”

Who responds when a hosted server goes down at night?

Whoever you have contracted for it. Microsoft’s Azure Virtual Machines reliability guide states plainly that “Microsoft doesn’t automatically notify you when a zone is down” and that detection and response sit with the customer. Automated monitoring can watch continuously; a person picking up the phone in the middle of the night is a separate commitment.

LayerLogix assigns the responsibility matrix before the migration, not after the outage — every row named, in writing, with 20+ Years Experience and 100% Texas-Based Support behind it. Start with our managed cloud hosting page, or talk through Azure managed services, cloud migration and business continuity planning with our team.