Before you buy managed hosting: twelve questions that reveal who owns the work

“Managed hosting” can describe anything from operating-system patching to complete application administration. The label does not tell you who restores a database, tests a plugin update, responds outside office hours or helps you leave.

A good comparison therefore starts with work, not features. Ask each provider the same questions and require answers that apply to the exact plan, contract and workload you are considering.

1. Which components are you responsible for?

Ask for a named list: physical host, virtualisation, guest operating system, firewall, web server, runtime, database engine, certificates, application, plugins and content.

Do not accept “everything server-side” without a definition. A database engine may be inside the provider's server scope while database queries, schema and application data remain with you. If an application component is shared, identify who does what.

2. Which maintenance tasks are included?

For every managed component, ask whether the provider:

• monitors its supported lifecycle;
• plans and applies security updates;
• handles major-version changes;
• tests or only installs updates;
• manages configuration changes;
• documents what changed;
• maintains a rollback route.

“Updates included” is incomplete unless you know the components, timing, approval model and post-change checks.

3. What remains our responsibility?

Request the exclusions in the same level of detail as the inclusions. Common retained work can include application code, WordPress plugins and themes, content, licences, third-party integrations, user access, data classification and functional testing.

The NCSC recommends understanding exactly which security responsibilities remain with the customer. Microsoft's cloud model similarly keeps data, identities and configurations on the customer side across service models, while application and operating-system duties change with the service.

Your contract may divide the work differently. The purpose of these models is to expose gaps, not to replace the applicable agreement.

4. What do you monitor, and what happens after an alert?

Monitoring has at least three parts:

1. the signal being observed;
2. the threshold or condition that creates an alert;
3. the human or automated action that follows.

Ask whether monitoring covers host availability, guest health, disk usage, services, certificates, backups or application endpoints. Then ask who receives the alert, what they are expected to do and when the issue becomes your responsibility.

A dashboard without a response owner is visibility, not incident handling.

5. When is support available, and what is actually guaranteed?

Separate:

• the hours in which you can submit a request;
• staffed investigation hours;
• emergency escalation;
• target response or acknowledgement;
• restoration or resolution commitments;
• exclusions and service credits.

The NCSC's Principle 2.5 guidance warns that support without a contractual commitment should be treated as having no guaranteed support. A public “24/7” badge is not enough: determine whether it refers to ticket intake, monitoring, human response or resolution.

6. How are incidents divided between platform and application teams?

Ask the provider to walk through a realistic symptom, such as a checkout failure, slow response or unavailable database. Who investigates first? What evidence does each side supply? Who can make changes? Who communicates with the end client?

Require a route for ambiguous faults. “Not our layer” is not a useful handover unless the provider supplies the evidence needed by the next owner.

7. What is backed up?

Ask for the exact objects and boundaries:

• complete virtual machine, files, database or selected directories;
• configuration outside the guest;
• secrets and encryption keys;
• external storage and third-party services;
• logs and mail, if relevant;
• excluded data.

Then ask where copies are held, how they are protected, how long they are retained and which party owns backup failures. Do not infer that “daily backup” covers every component needed to make the application usable.

8. Who performs a restore, and how is it tested?

A backup feature and a recovery service are different things. Ask:

• who may request a restore;
• what identity and approval checks apply;
• whether restore work is included or separately charged;
• the available restore target and granularity;
• how application consistency is checked;
• who performs functional acceptance;
• what evidence exists from a representative test.

The NCSC recommends confidence that backups can return data to a known good state. That confidence should come from applicable evidence and tests, not merely from the existence of backup files.

9. Who can access the environment and customer data?

Identify the provider, subcontractors, administrators and customer users that may have technical access. Ask about:

• privileged access roles and approval;
• multifactor authentication;
• logging and review;
• emergency access;
• support access to readable data;
• staff and supplier locations;
• local copies and diagnostic exports;
• access removal when someone leaves.

Using a managed service provider can add another privileged participant to the shared-responsibility model. That can be reasonable, but it should be visible and controlled.

10. How are changes requested, approved and reversed?

Clarify routine and emergency changes. Who can authorise a runtime upgrade, firewall rule, restart or resource resize? What maintenance notice is provided? What happens if a change causes an application failure?

For agencies, also agree who gets client approval and who performs the final functional check. A technically successful server change can still produce a broken customer journey.

11. What limits and variable charges matter?

Compare more than disk space and headline CPU. Depending on the platform, material limits can include:

• shared or dedicated CPU access;
• memory;
• storage type and I/O;
• processes or PHP workers;
• database connections and size;
• outbound traffic;
• backup volume and retention;
• licences;
• support and restore charges.

Provider documentation shows why this matters: a shared-hosting plan can advertise an unlimited attribute while still applying CPU, memory, inode, database, I/O and mail limits. A VPS vCPU count can also hide whether CPU access is shared or dedicated.

Ask what happens at a limit: throttling, error, overage charge, forced upgrade or human review.

12. How do we leave?

Before signing, establish:

• which files, databases, configurations and logs you can export;
• the export format and compatibility requirements;
• who controls the domain and DNS;
• how certificates, licences and secrets move or rotate;
• migration assistance and charges;
• minimum notice and contract end date;
• data return, retention and deletion;
• access revocation;
• the support available during transition.

The NCSC's supplier-assurance questions explicitly include contract-exit provisions for secure deletion or return of data and assets, and transfer to another supplier. An exit clause is more useful when paired with a tested export and a named owner.

Turn the answers into a responsibility matrix

Create one row for every important task. Identify who performs it and name an accountable owner or buyer-side resolution owner, including when the task is shared or excluded. Use four values:

• Provider — the provider performs and owns the task.
• Customer — your team performs and owns it.
• Joint — name each party's steps, one lead for coordination and final acceptance, the decision authority and the handover condition.
• Not included — name the buyer-side owner who will obtain another supplier or make a conscious exclusion decision before commitment.

Add a source column pointing to the applicable service schedule, terms or runbook. If the salesperson's answer is not present there, treat it as unresolved until it is recorded by an authorised owner.

The final test

You should be able to answer three questions without interpretation:

1. What work are we paying the provider to remove from our team?
2. What work must our team still be ready to perform?
3. What happens at the boundary when the cause is not yet known?

If those answers are unclear, the offer is not ready to compare on price.

Sources

• NCSC: cloud security shared responsibility model — official guidance on service-dependent responsibility and the MSP role.
• NCSC: cloud security principles and Principle 2.5: physical resilience and availability — official provider-assessment, evidence, support and recovery guidance.
• NCSC: supplier assurance questions — official question set including contract exit and data/asset return.
• Microsoft: shared responsibility in the cloud — provider model used to illustrate changing responsibilities, not as a universal contract.
• Hostinger: hosting plan parameters and limits — dated provider example showing multiple resource limits.
• DigitalOcean: choosing a CPU Droplet plan — dated provider documentation illustrating shared and dedicated CPU distinctions.

Next: See the current Novasean responsibility page.