Separate the infrastructure type from the management service
Shared hosting, a virtual server and a managed application service can give customers different control and different obligations. The hosting category does not answer who updates the application, checks a failed backup or handles a compromised administrator account. Read the actual plan and service scope. Avoid assuming that root access creates security or that lacking root access means the provider operates every necessary control.
Start with the business workload: website, database, email, integrations and recovery needs. Identify which services are bundled and which are separate suppliers. A migration can move responsibility even when the visible website looks unchanged. Before comparing plans, list the tasks the business needs performed and the owner capable of doing them under each proposed arrangement.
Fill a responsibility matrix before accepting a plan
Use a task-owner matrix to turn marketing descriptions into operational questions. For every important task, record the provider, business or technical supplier responsible, the evidence they supply and the escalation route. If the answer is shared, identify the actual handoff rather than leave both parties assuming the other will act. A task with no agreed owner remains a gap regardless of the plan's name.
This original worksheet does not prescribe a hosting product or declare one architecture best for every business. It helps compare whether the offered service fits the team's capabilities. Include absence and supplier-change scenarios: the owner must be able to reach support, retrieve required records and authorize recovery when the person who bought the plan is unavailable.
| Task | Question for the actual plan | Evidence or handoff to request |
|---|---|---|
| Operating system | Who maintains the guest or platform layer? | Included components, exclusions and update handling. |
| Website/application | Who updates code, plugins and dependencies? | Approved source, release and functional acceptance record. |
| Administrative access | Who owns accounts, recovery and supplier changes? | Named owner, revocation process and escalation route. |
| Backup and restore | What is retained and who performs restoration? | Scope, access, consistency, limits and a usable test result. |
| Security incident | Who contains each layer and what support is available? | Actual scope, evidence access and specialist dependencies. |
| Exit or migration | Who controls exports, domain and billing access? | Usable handoff and known data/recovery limitations. |
Use shared-responsibility examples within their real scope
AWS's shared-responsibility model explains that duties vary with the chosen service. Its EC2 example places guest operating-system, installed-application and security-group configuration tasks with the customer. More abstracted services divide responsibilities differently. This is a useful provider-specific illustration of why renting infrastructure does not necessarily include managing the customer's entire application environment.
Do not copy that allocation onto every shared-hosting company or managed plan. Ask the actual provider which tasks it performs, what access it needs and what the customer must maintain. A supplier's infrastructure controls may be valuable without covering plugin configuration or business-account recovery. The agreement and operational handoff need to describe the service actually purchased rather than a generic diagram.
Check the application and recovery workflow, not only the host
Review how the website is deployed, who controls its code and which integrations remain outside the host's service. A healthy virtual machine does not establish that a form delivers, a checkout records the right order state or an application account is secure. Define the expected business functions and who tests them after hosting or application changes, using controlled data and supported test modes.
Backups need specific questions: which data and configuration are included, whether the selected recovery point is usable, how access is protected and who can perform the restore. A provider snapshot can have a different scope from application-consistent recovery. Record restoration limits and any data reconciliation required. Do not treat a line saying daily backup as proof of the recovery the business expects.
Make incident support and evidence access concrete
Ask what happens when the host restricts the site or a user reports unwanted behavior. Who can change the relevant account, retrieve logs and approve a restore? Which activities need another supplier or specialist? Record the real support channel and service terms without turning an advertised response target into a promise about the time needed to resolve every incident.
Evidence availability can matter as much as the support label. Clarify which records are retained, who can request them and what limitations apply to shared resources. A provider may be able to contain part of the environment while the application still needs its own review. Keep those handoffs explicit so a business is not left with separate suppliers each declaring their own layer operational while the incident remains unresolved.
Choose a service the business can actually operate
Compare the completed matrix with the people and maintenance capability available. More control may be appropriate when someone owns the work; a narrower managed service can also fit when its constraints match the workload. Include the cost and practicality of the missing tasks in the decision without inventing price comparisons or assuming that a more expensive infrastructure tier guarantees stronger security.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with practical Israeli website, Linux and digital-infrastructure knowledge. We can discuss the scoped technical responsibilities described on this site and their provider dependencies. No hosting partnership, provider certification or continuously staffed managed service is claimed. Bring the actual plan and workload description so included tasks, exclusions and acceptance can be agreed before changes begin.
