WEBSITE OPERATIONS / PROCUREMENT
Choose the host.
Own the consequences.
A practical buying guide to hosting models, recovery, security, and the responsibilities hidden in the small print.
The website may be beautifully designed and still depend on a hosting arrangement that cannot meet the business’s needs when something fails. A low monthly invoice tells you little about the recovery assistance, investigation evidence, or urgent maintenance included behind it.
Hosting is a supplier and operating-risk decision. Once customer information, transactions, or essential business activity depend on that environment, its weaknesses can become your downtime, lost income, or damaged reputation. The useful question is what the whole arrangement will deliver—not whether the product page calls it “secure”.
THE EXECUTIVE BRIEF
Buy for the website you actually operate.
- Choose a hosting model that matches the site’s purpose, sensitivity, and the expertise available to maintain it.
- Require clear ownership of patching, administrative access, backups, incident response, and recovery.
- Compare demonstrated outcomes and total operating cost, not an uptime headline or a security label.
01
Decide what the website must withstand.
A brochure site, a booking service, and a customer portal can have very different consequences when they fail. Start with the information held, the transactions supported, the interruption you can tolerate, and the people who must respond. That gives the supplier something concrete to explain.
Continuity
Can the business restore a useful service?
Include customer access, transactions, and confidence in the restored data.
Information
Who can reach the data, and from where?
Look beyond the primary server to backups, support access, and subcontractors.
Customer trust
Can you explain what happened?
Require usable logs, an escalation route, and evidence your own team can obtain.
Operating capacity
Who will maintain the service?
Price the work left with your staff, developer, or another supplier.
An uptime promise is not a recovery commitment. Read the measurement period, exclusions, and remedy, then ask separately what happens after a compromise or data loss. A service credit may compensate for part of a bill without restoring your website or lost business.
02
Five hosting models, five responsibility questions.
There is no universal security ranking in which shared hosting is always unsafe and a dedicated server is automatically secure. Isolation, configuration, maintenance, access, and support change the outcome. Use the model to understand what you are buying and what remains yours to run.
| Hosting model | Fit and responsibility to examine |
|---|---|
| Shared hosting | Several customers use a shared platform. It can suit a straightforward site where isolation, maintenance, support, and recovery are well managed. Ask how a compromised customer is isolated and how your site can be restored. |
| Virtual private server (VPS) | More control over a logically separated server environment, with more configuration and maintenance to own unless these are managed. Confirm who patches the operating system and investigates a compromise. |
| Dedicated server | A server allocated to your use can support demanding workloads or particular isolation needs. It still requires secure configuration, monitoring, maintenance, and recovery; confirm the exact management service. |
| Cloud infrastructure | Flexible infrastructure can support complex applications and availability designs. It also requires decisions about identity, configuration, resilience, cost, and the layers your team operates. Scalability alone is not a recovery plan. |
| Managed platform / PaaS | The provider operates defined platform layers, reducing some maintenance work. Check the scope: custom code, extensions, identities, data, and application-level recovery may still require your attention. |
A well-run managed service may be the practical choice for an SME with limited engineering capacity. A business needing unusual control may accept more responsibility. In either case, the decision should include the skills, support, and maintenance you must fund after the initial migration.
03
Four capabilities worth examining before you sign.
01
Backups you can actually recover.
Ask about retention, separation from the live account, protected or immutable copies where appropriate, and restore testing.
Immutability protects a retained copy from certain changes; it does not prove that the copy is clean, complete, or usable. Test recovery to an accepted website outcome.
02
Protection at the edge and in the application.
Examine the web application firewall, traffic protection, and how incidents reach the people operating the site.
A CDN or WAF can help reduce particular threats, but it cannot replace secure code, controlled access, patching, or response. Ask how abusive automation is handled without excluding legitimate customers; an “AI defence” label is not an explanation of the protection supplied.
03
Patching with a named owner.
Separate the operating system, server software, website platform, extensions, and custom code.
“Managed” can mean different things at each layer. Agree how urgent vulnerabilities are prioritised, who tests the change, and what happens if an update fails.
04
Clear data and jurisdiction arrangements.
Identify where the live data and backups are stored, who can access them, and which subcontractors are involved.
A UK or European address does not establish compliance on its own. Where personal information is transferred internationally, the applicable legal requirements also need to be addressed.
For the specific international-transfer point, see the ICO’s brief explanation. The practical buying questions here are CyberSolace’s editorial guidance; your requirements depend on the service and information involved.
04
Put the responsibility boundary in writing.
The provider’s infrastructure, your application, and your administrative accounts do not necessarily have the same owner. A cloud or managed-service contract can remove some work without removing all of it. Document who acts and who verifies the result.
THE ONE-PAGE RESPONSIBILITY SCHEDULE
An owner for every important layer.
Hosting environment
Infrastructure, server configuration, platform availability, and the limits of provider support.
Website and code
Platform updates, extensions, custom development, testing, and rollback.
Identities and evidence
Administrative MFA, privileged access, logging, investigation access, and retention.
Recovery and exit
Backup access, restore assistance, service acceptance, domain control, and export or migration.
For each line: named owner · included service · evidence · escalation contact.
Keep emergency contacts and essential recovery access available outside the failed website or hosting account. If the person who can approve a restore cannot be reached, or if recovery instructions are stored only on the affected system, a technically available backup may still leave the business waiting.
Provider documentation illustrates why the boundary varies by service. AWS, for example, distinguishes its infrastructure responsibilities from the customer’s responsibilities for relevant systems, applications, and configuration. The useful result is your own agreed schedule, not a generic diagram copied from a supplier.
05
Ask three questions—and ask to see the answer.
01
How quickly can we recover?
Agree the recovery-time objective: the target time to restore the service. Also agree the recovery-point objective: the amount of recent data loss the business can tolerate. Ask for evidence of a representative restore, including any additional cost and assistance required.
02
How is administrative access protected?
Require strong authentication, including MFA for important administrative access. Examine who holds privileged accounts, how developer and supplier access is removed, and how a lost or compromised account is recovered.
03
What evidence will we receive after an incident?
Agree which logs and audit records exist, who can obtain them, and how quickly support will respond. A promise of security is less useful than evidence that lets your organisation establish what happened and make recovery decisions.
Then compare the total arrangement: subscription, management work, monitoring, recovery, support, migration, and exit. The cheapest invoice can become an expensive operating model if every urgent task is excluded or falls to a team without the time to do it.
BEFORE THE NEXT RENEWAL
Customers experience the service, not the supplier boundary.
Choose one plausible outage or compromise and walk through it with the host and the website owner. Establish who declares the incident, who can reach the backup, who restores which layers, and who decides the site is ready for customers.
If those answers are unclear, resolve them before a migration or renewal. CyberSolace can help review the security and recovery assumptions behind your hosting choice.
SOURCES & EDITORIAL REVIEW
Original publication date retained; research and presentation reviewed 20 October 2026. The hosting comparison and buying questions are CyberSolace editorial guidance. Suitability depends on the service, configuration, responsibilities, and information involved.