Managed hosting security is useful when it makes the responsibilities around a website clear and operational. A provider may maintain the hosting platform, monitor particular events and offer recovery support. That does not necessarily mean it updates every plugin, manages every administrator account or investigates every application problem.
The word “managed” describes an arrangement that needs to be examined. Two packages can use the same label while covering different layers, response times and activities. A business should understand those differences before relying on the service.
A strong comparison asks what is maintained, what is monitored, what happens after an alert and what the customer must still do. It also challenges broad promises that imply a website can never be compromised. Security is an ongoing operating responsibility, supported by specific controls and a workable response process.
Identify the layers in your website's operation
Map the platform, application and connected services. A typical website may involve the hosting account, server software, a CMS, extensions, administrator accounts, DNS, email and external integrations. Some layers may be operated by different organisations.
List the business owner and technical contact for each layer. If a provider handles the hosting platform and a developer handles application updates, both need to know where their responsibilities meet. An unexplained gap can leave a task that everyone assumes someone else performs.
Hosting responsibility changes with the service model. Separate infrastructure maintenance from customer-controlled data, accounts and configuration, then inspect the actual agreement and implementation. A managed label does not resolve every responsibility. Our managed hosting and VPS responsibilities guide provides the related checks.
Ask the supplier to describe coverage in the language of your installation. “Platform patching included” is helpful when you know which software it covers. It is ambiguous when the business assumes it includes the website application and the provider means only its underlying environment.
Make patching responsibilities specific
Confirm which updates the provider applies, how it identifies relevant updates and what triggers action. Ask about the hosting environment, runtime and application separately. A package may include one set of updates while leaving another to the website owner or developer.
Discuss how updates are checked for compatibility and how an unsuccessful change is handled. A business website needs important functions to remain usable after maintenance. Testing should reflect the installation and its key journeys rather than assuming a successful update command proves the site works.
Clarify the treatment of unsupported components. If an old extension cannot be updated safely, the business needs a decision about replacement, removal or another justified arrangement. Managed hosting cannot make an abandoned application component fully supported by changing the server package.
Record the response process for urgent updates as well as routine maintenance. Identify who can authorise a change, who receives notice and what happens outside normal support hours. The organisation should understand its practical options when timing matters.
Understand what monitoring observes
Separate availability monitoring from security monitoring. A check that confirms the homepage responds can identify downtime, but a compromised website may still load normally. Ask what signals the provider observes and what types of problem those signals can reasonably detect.
Find out which alerts receive human review. A monitoring system may generate a notification without anyone investigating it under the package. Confirm the destination of alerts, expected review process and the customer's role in supplying context.
Ask for an example of an alert-to-action journey. The provider might detect suspicious activity, assess the evidence, contact the owner and propose containment. Each step needs ownership and realistic timing. A dashboard full of events is not the same as an incident response service.
Understand the limits of visibility. If the provider does not manage the application or a connected third-party service, it may not see relevant events there. A broader response may require coordination with a developer, an email supplier or another specialist.
Keep access management in the arrangement
Identify who can enter the hosting account and who can administer the website. These are separate access boundaries. Review whether accounts identify individuals, whether appropriate multifactor authentication is available and how the business removes access when a role ends.
Clarify how suppliers obtain and use access. Temporary maintenance work may require a different arrangement from continuing administration. Give access according to the actual task and preserve enough accountability to understand who made important changes.
Ask who owns account recovery and how the business proves its authority if the usual administrator is unavailable. Recovery should be planned before an incident or staff departure. A hosting service becomes difficult to use when the only person with recognised access cannot be reached.
Check connected credentials and integrations as well. A website may depend on mail delivery, payments or a customer system. Changing hosting access alone does not review those relationships, so assign responsibility for the credentials and settings each integration uses.
Examine recovery as a practical capability
Ask what is backed up, how often, how long copies are kept and where the restore boundary sits. Files, databases and platform settings may have different arrangements. A backup of one component may be insufficient to reconstruct a working customer journey.
Request a description of the restore process and any associated costs. Establish who requests it, who performs it and what is checked afterwards. Recovery expectations should include the application's useful outcome, not only the return of files to a directory.
Discuss how a suitable recovery point is chosen after a suspected compromise. Restoring the latest copy without understanding the incident may restore the same problem. The investigation and the recovery decision need to work together.
Plan a proportionate restore test in an appropriate environment. Confirm important pages, accounts, forms and dependencies behave correctly after restoration. Document the result and any missing configuration, so the next recovery attempt starts with better information.
Agree what happens during an incident
Prepare a contact route the business can use when the website is unavailable or accounts are affected. Include an alternative to the system that may be disrupted. Identify who coordinates decisions and who can authorise service changes.
Clarify the provider's incident scope. Does the service include investigation, containment, application clean-up or only platform support? Which activities are chargeable or supplied by another team? Knowing this in advance helps the organisation respond without debating basic responsibilities under pressure.
Discuss how evidence and communication are handled. The technical teams may need logs and a timeline, while the business needs an understandable account of impact and next steps. Preserve relevant information through the agreed process rather than making changes that erase useful evidence unnecessarily.
Include the route back to normal operation. Confirm how fixes are verified, how access is reviewed and how the business knows important enquiries are reaching the team again. A page loading successfully is one checkpoint, not the whole recovery decision.
Challenge promises through evidence and boundaries
Ask suppliers to explain broad claims such as “fully secure” or “complete protection” in operational terms. A credible answer names controls, coverage, ownership and limits. The business should be able to understand what the service makes more reliable and what remains its responsibility.
Compare relevant evidence: defined maintenance coverage, tested recovery, a clear alert process and an incident contact route. Attractive badges can be useful when their meaning is explained, but they should not replace the details needed to run the website.
Giraffe Digital's digital strategy service considers hosting and other tools within the customer journey. A managed security arrangement supports that journey when the work is specific, responsibilities are understood and recovery can be demonstrated.
Frequently asked questions
How should we identify the layers in our website's operation?
Map the platform, application and connected services. A typical website may involve the hosting account, server software, a CMS, extensions, administrator accounts, DNS, email and external integrations. Some layers may be operated by different organisations. List the business owner and technical contact for each layer. If a provider handles the hosting platform and a developer handles application updates, both need to know where their responsibilities meet. An unexplained gap can leave a task that everyone assumes someone else performs. Hosting responsibility changes with the service model. Separate infrastructure maintenance from customer-controlled data, accounts and configuration, then inspect the actual agreement and implementation. A managed label does not resolve every responsibility. Our managed hosting and VPS responsibilities guide provides the related checks.
How should we understand what monitoring observes?
Separate availability monitoring from security monitoring. A check that confirms the homepage responds can identify downtime, but a compromised website may still load normally. Ask what signals the provider observes and what types of problem those signals can reasonably detect. Find out which alerts receive human review. A monitoring system may generate a notification without anyone investigating it under the package. Confirm the destination of alerts, expected review process and the customer's role in supplying context. Ask for an example of an alert-to-action journey. The provider might detect suspicious activity, assess the evidence, contact the owner and propose containment. Each step needs ownership and realistic timing. A dashboard full of events is not the same as an incident response service.
How should we keep access management in the arrangement?
Identify who can enter the hosting account and who can administer the website. These are separate access boundaries. Review whether accounts identify individuals, whether appropriate multifactor authentication is available and how the business removes access when a role ends. Clarify how suppliers obtain and use access. Temporary maintenance work may require a different arrangement from continuing administration. Give access according to the actual task and preserve enough accountability to understand who made important changes. Ask who owns account recovery and how the business proves its authority if the usual administrator is unavailable. Recovery should be planned before an incident or staff departure. A hosting service becomes difficult to use when the only person with recognised access cannot be reached.
How should we examine recovery as a practical capability?
Ask what is backed up, how often, how long copies are kept and where the restore boundary sits. Files, databases and platform settings may have different arrangements. A backup of one component may be insufficient to reconstruct a working customer journey. Request a description of the restore process and any associated costs. Establish who requests it, who performs it and what is checked afterwards. Recovery expectations should include the application's useful outcome, not only the return of files to a directory. Discuss how a suitable recovery point is chosen after a suspected compromise. Restoring the latest copy without understanding the incident may restore the same problem. The investigation and the recovery decision need to work together.
How should we challenge promises through evidence and boundaries?
Ask suppliers to explain broad claims such as "fully secure" or "complete protection" in operational terms. A credible answer names controls, coverage, ownership and limits. The business should be able to understand what the service makes more reliable and what remains its responsibility. Compare relevant evidence: defined maintenance coverage, tested recovery, a clear alert process and an incident contact route. Attractive badges can be useful when their meaning is explained, but they should not replace the details needed to run the website. Giraffe Digital's digital strategy service considers hosting and other tools within the customer journey. A managed security arrangement supports that journey when the work is specific, responsibilities are understood and recovery can be demonstrated.
