Which Parts of Security Are Yours, and Which Are Your Host's?
Where the security line sits on shared, VPS, dedicated, public cloud and managed private cloud hosting, plus five questions to ask your host.
Published October 6, 2026 by Danish Rumane
3 Minutes to Read

Every hosting plan splits security between you and your provider. Very few people read where the line is until something goes wrong, and by then the question isn't academic. It's "whose job was it to patch that?" asked at 2 a.m.
The split isn't hidden. It's in the plan description and the terms of service. It's just rarely stated in plain words, and it changes a lot depending on what kind of hosting you're on.
The line moves with the type of hosting
Think of a server as layers. At the bottom is the physical data center and hardware. Above that is the network, then the virtualization layer, then the operating system, then the web server and database, then your application, and finally the people who log in and the data they handle.
The more managed the service, the higher up the stack your provider's responsibility goes. Here's where the line typically sits. Your own plan's terms are what count, so treat this as a starting map, not a contract.

Two rows stay with you on every plan: your application and the people who can log in to it. No host patches your plugins for you without your say-so, and no host can stop a teammate from reusing a password. If you're on a public cloud platform, we covered how wide that gap gets in The Shared Responsibility Model Nobody Reads.
Three places the line gets blurry
Backups. "Backups included" tells you a job runs. It doesn't tell you where the copy lives, how long it's kept or whether anyone has tested a restore. A backup stored on the same server it protects disappears with that server. We went deeper on this in Your Continuity Plan Is Only as Good as Your Last Restore.
Patching above the operating system. Many "managed" plans patch the OS but not the web server, database or language runtime. If PHP needs a major-version upgrade, check whether that counts as maintenance or as a project you're expected to run.
Incident response. When something gets in, someone has to contain it, work out how it happened and close the gap. On an unmanaged plan, that's you. On a managed plan, ask whether investigation and cleanup are included or billed separately.
Five questions to ask your host

Clarify who handles each security task before an incident exposes a gap.
Vague answers are an answer too. They usually mean the job is yours.
How the split works on InMotion Cloud
InMotion Cloud is a managed private cloud, so our side of the line sits high in the stack. Every plan includes OS patching and hardening, care for the software inside your servers (web servers, databases and application services), monitoring, file and VM backups, WAF and DDoS filtering, SSL certificate management and managed incident response. Senior engineers handle all of it, and they're the first people you talk to.
Your side covers your application code, your plugins and dependencies, the people who have access and the decisions about your data, including what's sensitive and how long it should be kept.

InMotion Cloud manages the infrastructure and software stack. Your team owns application choices, user access and data policies.
One limit, stated plainly. Our plans differ by monthly managed engineer hours, not by which services are included. Routine patching and monitoring fit comfortably in any plan. A large project, like moving a legacy application to a new runtime, may need more hours than your plan includes. We'd rather tell you that while scoping the work than surprise you with it later.
If you'd like to see exactly where the line would sit for your workload, talk to an InMotion Cloud engineer.
Related resources
Explore more stories and guides that pair well with this article.

Cloud hosting improves security automatically — DDoS mitigation, malware scanning, and server hardening — so your team can focus on building, not firefighting.


Your cloud workloads share physical hardware with other tenants. Most teams never think about what that means for security until something goes wrong.