Managed or Unmanaged Hosting: Who Is Responsible When Your Website Is Compromised?
Your website has been compromised. Malicious files appear inside the application, customers are being redirected and an administrator account you do not recognise has been created.
The hosting provider says its infrastructure is operating normally. The plugin vendor says its product needs to be updated. The developer needs server and log access. The internal team asks whether the site can simply be restored. Nobody is certain who may take the site offline or communicate with customers.
This is not only a technical problem. It is a responsibility problem.
“Managed hosting” is often interpreted as “the provider handles security”. In reality, managed is a commercial label with no universal scope. One service may patch the server but not WordPress. Another may update WordPress core but exclude plugins and custom code. A provider may scan for known malware but not investigate how access was gained. Backups may exist without a guaranteed recovery point or tested restoration process.
Unmanaged hosting makes more duties visibly yours. Managed hosting can transfer some of them to a provider. Neither arrangement removes the need to allocate every layer.
The contract, service description, system design and response plan determine who does what when the website is compromised.
Security is shared across layers
Cloud providers commonly describe security as a shared responsibility. AWS, for example, distinguishes security of the cloud from security in the cloud. AWS secures underlying cloud infrastructure, while customer responsibilities vary with the selected service and can include the guest operating system, applications, data and firewall configuration. AWS: Shared Responsibility Model
The same principle applies more broadly to websites. Responsibility may be distributed across:
- physical and cloud infrastructure
- network and edge controls
- operating system and runtime
- control panel and database
- CMS and ecommerce platform
- themes, plugins and custom code
- user accounts, credentials and integrations
- content and personal data
- monitoring and alerting
- investigation, containment and recovery
- business, legal and customer response
A provider can manage several layers without owning all eleven.
“Managed” needs a schedule of duties
Ask the provider to define managed in verbs, not adjectives.
Useful duties include:
- provision
- configure
- patch
- update
- back up
- test
- scan
- monitor
- alert
- investigate
- contain
- restore
- report
- support
For each duty, identify the covered assets, frequency, exclusions, response time and evidence.
“Daily backups” does not answer:
- database, files or both?
- where are copies stored?
- how long are they retained?
- are they immutable or isolated?
- can the customer access them?
- are restores tested?
- how long does restoration take?
- can a clean point be identified after compromise?
“Security monitoring” does not answer:
- which events are monitored?
- is coverage continuous?
- who sees the alert?
- who validates it?
- who may isolate the site?
- what investigation is included?
The clearer the service description, the less likely the organisation is to discover gaps during an incident.
Compare common hosting models
The following models are simplified. Actual contracts govern.
Unmanaged virtual server or infrastructure
The provider normally operates physical facilities and base cloud services. The customer or its technical partner may own:
- operating system build and patches
- firewall and network configuration
- runtime and database
- web server
- backups
- monitoring
- WordPress and extensions
- performance
- incident investigation and restoration
This model offers control and demands operating capability.
Managed infrastructure
The provider may manage the operating system, runtime, database service, patching, backup and infrastructure monitoring. Application-level responsibility can remain with the client and website team.
Confirm whether “managed” includes:
- WordPress core
- plugins and themes
- custom code
- application malware scanning
- WAF configuration
- account investigation
- forensic support
Managed WordPress hosting
The provider may operate infrastructure optimised for WordPress, apply platform controls, maintain backups and provide WordPress-aware tooling or support.
Do not assume it owns:
- every plugin update
- compatibility testing
- abandoned extensions
- insecure custom code
- compromised administrator credentials
- third-party integrations
- content governance
- customer-notification decisions
Software-as-a-service platform
The platform provider operates more of the application stack, but the merchant or site owner still controls configuration, users, content, integrations, access and data practices. Custom frontends and connected systems can create separate hosting and security domains.
The more a provider manages, the more operational burden can shift. Accountability for business data, access decisions and incident governance does not disappear.
Allocate the website stack explicitly
Create a responsibility matrix for the actual environment.
Infrastructure and availability
Questions:
- Who operates compute, storage and networking?
- Who manages capacity and denial-of-service controls?
- Who monitors infrastructure availability?
- Who owns DNS and domain access?
- Who may change firewall or edge rules?
Operating system and runtime
Questions:
- Who patches the OS, PHP, database and web server?
- How quickly are critical updates assessed?
- Is end-of-support software identified?
- Who controls privileged server access?
WordPress, plugins and themes
Questions:
- Who inventories components?
- Who monitors security advisories?
- Who tests and deploys updates?
- Who removes unused or abandoned software?
- Who reviews custom code?
WordPress’s official security guidance says the most important action is to keep WordPress, plugins and themes current and to choose components that continue to receive updates. It also describes security as continuous work requiring planning, monitoring, maintenance and recovery. WordPress Advanced Administration Handbook: security
Accounts and credentials
Questions:
- Who approves administrators?
- Is multi-factor authentication required?
- Are shared accounts prohibited?
- Who removes access when people leave?
- How are API keys and application credentials issued and revoked?
- Who owns the hosting account and provider relationship?
Application and business data
Questions:
- What personal, payment or commercially sensitive data is stored?
- Who defines retention?
- Who can export or delete it?
- Which third parties receive it?
- Who assesses notification obligations after an incident?
Monitoring and incident response
Questions:
- What logs exist across edge, server, CMS, application and identity layers?
- How long are they retained?
- Who receives alerts?
- Who investigates?
- Who can contain the incident?
- Who authorises restoration?
These decisions should connect hosting, website support, internal IT, legal, privacy and business leadership.
A compromise crosses provider boundaries
Consider a vulnerable plugin exploited to upload malicious code.
The hosting provider may:
- identify unusual process or file activity
- suspend the site to protect the platform
- provide snapshots or logs
- block hostile traffic
- restore infrastructure
The website support team may:
- inspect WordPress and plugin state
- identify altered files and accounts
- preserve evidence
- update or replace the vulnerable component
- rebuild or restore the application
- validate functionality
The client may need to:
- approve containment and downtime
- rotate internal and third-party credentials
- involve legal, privacy, insurance or executive stakeholders
- determine whether personal information was accessed
- communicate with customers or authorities where required
- approve return to service
The plugin vendor may publish a patch but will not normally operate the website incident.
If nobody owns the handoffs, every party can perform its stated role while the incident remains unresolved.
Define the first-response authority
Before an incident, agree who can:
- take the site offline
- place it in maintenance mode
- block traffic or regions
- revoke accounts and API keys
- preserve logs and snapshots
- contact the host
- initiate restoration
- communicate externally
- approve return to service
For a serious compromise, preservation and containment may conflict with the desire to restore immediately. Overwriting the environment before evidence is retained can make scope and cause harder to determine.
The response plan should define priorities based on the business and data risk, not improvisation.
Backups are a recovery capability, not a checkbox
WordPress documentation notes that a proper backup of both database and files can support restoration. WordPress Advanced Administration Handbook: backups
For compromise recovery, ask:
- Is the backup older than the initial intrusion?
- Does it include malicious persistence?
- Are database and files from a consistent point?
- Are uploads, configuration and environment secrets included or separately managed?
- Can the backup be restored into an isolated environment for inspection?
- How are new orders, leads or content since the recovery point handled?
Restoring a compromised backup can return the vulnerability and malicious code. A clean recovery also requires closing the entry path, rotating credentials and validating the rebuilt environment.
Test restoration. Recovery time cannot be inferred from the existence of a backup file.
WAF, malware scanning and patching do different jobs
A web application firewall can block or challenge certain traffic. Malware scanning can identify known patterns or suspicious changes. Patching removes known vulnerable code. Access controls reduce credential risk. Backups support recovery.
None is a complete security system.
Clarify who configures each control, reviews findings and responds. A malware alert sent to an unattended mailbox is not a managed response service.
WordPress hardening guidance covers controls including file permissions, database security, administration access and server configuration. These measures reduce risk but do not make compromise impossible. WordPress Advanced Administration Handbook: hardening WordPress
Contract for evidence and handover
A useful service agreement should identify:
- in-scope environment and domains
- normal support hours and emergency contact
- monitoring and alert coverage
- patch and update scope
- backup schedule, retention and restore process
- exclusions
- access requirements
- incident severity levels
- response and communication pathway
- log and evidence availability
- customer responsibilities
- third-party costs
- termination and data handover
Do not confuse a service-level target with guaranteed prevention. An SLA may define response or availability while excluding application compromise.
Questions to ask a managed hosting provider
- Which exact layers do you manage?
- Which operating system, runtime and database updates do you apply?
- Do you update WordPress core, plugins and themes?
- Do you test compatibility before application updates?
- Which security events are monitored, and at what times?
- Does an alert trigger investigation or only notification?
- What logs can be supplied during an incident?
- What backups exist, where are they stored and how are restores tested?
- What malware remediation is included?
- Who has authority to isolate the site?
- What happens if custom code or a third-party plugin is the source?
- What assistance is available for evidence, insurance or legal review?
- Which responsibilities remain with the client?
Ask the website agency or internal team the complementary questions. Security gaps often sit between contracts rather than inside one.
Build a practical RACI
For each activity, assign:
- Responsible: performs the work
- Accountable: owns the outcome and decision
- Consulted: provides relevant expertise
- Informed: receives status
Include:
- infrastructure patching
- application updates
- vulnerability review
- account administration
- backups and restore tests
- alert triage
- incident containment
- forensic investigation
- data-breach assessment
- customer communication
- return-to-service approval
One activity may involve several parties, but only one should be accountable for the decision.
Emote’s hosting, warranty and support boundaries
Emote does not sell, resell or directly provide website hosting infrastructure. It can help define hosting requirements, recommend and coordinate with an appropriate hosting partner, or work with a client’s existing suitable provider. The client normally contracts and pays the hosting provider directly.
Emote’s standard 30-day functional warranty covers agreed website implementation functionality from production go-live. It is not a substitute for infrastructure service, security monitoring, software maintenance, incident response or ongoing website support.
Ongoing activities can be delivered through an agreed support arrangement or block of hours where appropriate. The exact service, response expectations and exclusions should be confirmed in current approved collateral and the relevant agreement. A serious compromise may also require specialist cybersecurity, legal, privacy, insurance or forensic support outside normal website support.
Frequently asked questions
Is managed hosting more secure than unmanaged hosting?
It can transfer important operational duties to specialists, but security depends on the actual service, configuration and remaining customer responsibilities. The word managed is not enough to establish protection.
Does managed WordPress hosting update every plugin?
Not necessarily. Some providers update selected components; others offer tools but leave deployment and compatibility with the client. Confirm the contract and service description.
If the server is secure, can WordPress still be hacked?
Yes. Compromise can involve application vulnerabilities, credentials, integrations, misconfiguration or social engineering even when underlying infrastructure is functioning as designed.
Who restores the website after a compromise?
It depends on the agreement. The host may restore a snapshot, while the website team validates and repairs the application and the client makes business decisions. Assign the full recovery workflow in advance.
Is a daily backup enough?
Not by itself. Retention, isolation, completeness, recovery point, integrity and tested restoration all matter. A recent backup may already contain the compromise.
Does a web application firewall prevent all attacks?
No. It is one control. It does not replace patching, secure code, credential controls, monitoring and recovery.
Is incident response covered by a website warranty?
No. The standard 30-day functional warranty covers agreed implementation functionality, not ongoing security operations or third-party compromise response unless a project-specific agreement expressly says otherwise.
Can Emote host the website directly?
No. Emote does not sell or resell hosting. It can define requirements and coordinate with a suitable hosting provider contracted directly by the client.
How Emote can help
Managed hosting can reduce operational burden and improve access to specialist capability. It cannot protect an organisation from duties that were never assigned, evidence that was never retained or a response decision nobody had authority to make.
Emote’s website support and maintenance services can help make application duties, hand-offs and escalation paths explicit alongside the hosting agreement, with a practical operating model for routine work and incidents.
If responsibilities are unclear across the host, website team and organisation, book a meeting with Emote to map the questions that need answers.