Operator's Guide

Hosting with imunify360 — One compromised client site, and eleven conversations you did not plan

Written for whoever will be explaining a malware incident to a client — where the useful question is not which plugin was at fault but how far the problem travelled.

See Secure Hosting plans More in Buying Guides

Straight answer first

Put client sites on a platform where Imunify360 is licensed and running underneath the account rather than relying on whatever plugin each client happens to have — on our shelf that is the Elite tier, with Imunify360 on guard and backups taken every six hours.

The reason to care as an operator is blast radius. A plugin sitting inside WordPress can only see requests that have already arrived; server-level defence turns traffic away before the application is involved, and the difference determines whether an incident is one account's problem or your whole client list's afternoon.

Written by the Hosting Seller staff · Checked 24 August 2026

NVMe

Disk under every account

Free

Domain for the first year

99.9%

Uptime target we hold

Flat

Cost across the renewal

Security on a client fleet is not really about prevention rates. It is about containment, evidence and the conversation afterwards — three things that are decided by architecture long before any particular attack arrives.

The commercial shape of an incident is also predictable. Somebody has to do the clean-up, somebody has to pay for the hour, and somebody has to tell the client. If none of that is agreed in advance, all three land on you at the least convenient moment.

Blast radius on a shared arrangement

The first question after any compromise is what else the attacker could reach. On a shared plan with several clients sitting as addon domains under one account, the honest answer is everything on that account — one filesystem, one set of database credentials, one backup.

On a reseller arrangement each client has an account of their own, so containment is structural rather than hopeful. Imunify360 runs on every client site, and account isolation means an incident on one is genuinely one incident rather than a fleet event you then have to describe.

That structural difference is what makes the conversation afterwards survivable. Telling one client their site was compromised is a bad afternoon; telling eleven that they shared an account is a business problem.

What server-level defence sees that a plugin cannot

Imunify360 is a suite that lives below the site: a web application firewall, a malware scanner that cleans as well as reports, intrusion prevention, and proactive defence that recognises exploit patterns. It runs whether or not the client remembered to keep a plugin licensed.

That last point is the operational one. Plugin-based protection depends on somebody renewing, updating and configuring it per site — which is exactly the kind of recurring per-site task that does not survive a fleet of twenty. Platform-level protection has no per-site upkeep to forget.

Keep a plugin as well if you like it, for the application-level conveniences: login hardening, an activity log, two-factor on wp-admin. It becomes seasoning rather than the meal, and nothing important depends on its renewal date.

Who cleans it, and who pays for the hour

Decide this before it happens and write it into the care plan. The realistic options are that clean-up is included up to a stated allowance, that it is billable at your hourly rate, or that it is included only where the client has kept to the update schedule. Any of the three works; none of them works if it is being invented during an incident.

The technical route out is usually a restore rather than a clean. Backups run every six hours on the Elite tier and daily elsewhere, and restores run from the panel, so the fastest resolution is often a known-good copy plus the update that was missed.

Keep the evidence regardless. What was found, when, what was restored from, and what changed afterwards. That record is what turns a repeat incident into a chargeable conversation about the client's own decisions rather than an argument about your competence.

What the other clients are told

Usually nothing, and that should be true rather than convenient. If the accounts are genuinely isolated then other clients were not affected, and saying so is a statement of fact you can stand behind.

Where you do have to notify — because a shared account meant shared exposure — do it quickly and in writing. Delay is the thing that converts a technical incident into a trust incident, and trust incidents do not stay confined to one client.

This is the real argument for isolation. Not that it prevents attacks, which nothing does, but that it keeps the number of difficult conversations at one.

A shield icon standing in for site security and DDoS filtering

Where we stand in this

We license the protection this page describes and sell the tiers that carry it, so treat it as a supplier's case. The checkable part is whether the software is genuinely licensed and running rather than a phrase on a feature list — ask, and ask any other supplier the same thing.

Isolation and platform-level defence are cheaper for us too. An incident contained to one account is a support ticket; one that is not is a much longer week for everybody.

Imunify360 licensed and running on every client site
Account isolation, so an incident stays one incident
Backups every six hours on the Elite tier
Restores run from the panel without a ticket

Why Hosting Seller

On every plan, as standard

Defence below the application

A firewall, malware scanner, intrusion prevention and proactive defence running underneath the site rather than inside it.

Nothing per-site to renew

Platform protection has no licence for a client to let lapse, which is the failure that actually happens across a fleet of twenty.

Containment by structure

An account per client means a compromise is one client's incident rather than a conversation you have eleven times.

Six-hourly backups on Elite

A recent known-good copy is usually the fastest route out of a compromise, and restores run from the panel.

Clean-up as well as detection

The scanner cleans rather than only reporting, which is the difference between a finding and a resolution.

Evidence for the conversation after

What was found, what was restored and what changed is the record that keeps a repeat incident chargeable rather than contentious.

First Steps

From choosing to live

1
Check the isolation before you check the software
Work out what a compromise on one client account could reach. If several clients share one account, no security product changes the answer — the structure does.
2
Write the clean-up clause into the care plan
Included up to an allowance, billable hourly, or conditional on the update schedule. Choose one now, because inventing it during an incident always resolves against you.
3
Rehearse the restore, not the scan
The way out of most compromises is a known-good copy plus the missed update. Time that restore on a quiet afternoon so the number is known before it matters.

In the Box

Packed with every plan

Imunify360 genuinely licensed and running, not a feature-list phrase
Firewall, malware scanning, intrusion prevention and proactive defence together
Malware clean-up included rather than detection only
Account isolation between clients on a reseller arrangement
Backups every six hours on the Elite tier, daily elsewhere
Restores run from the panel without raising a ticket
Free SSL issued and reissued on every client domain
DDoS filtering at the network edge in front of it all
A 99.9% uptime target with a pro-rated credit when missed
Support reachable at any hour during an incident

Across the Counter

Things people ask us all the time

How far does a compromise on one client site actually reach?

As far as the account boundary. Several clients sharing one account means one filesystem, one set of database credentials and one backup, so the honest answer is everything on it. On a reseller arrangement each client has their own account, which is what makes containment structural rather than hopeful.

Is a security plugin enough if every client has one?

No, and the reason is administrative rather than technical. Plugin protection depends on somebody renewing, updating and configuring it per site, which is precisely the recurring task that does not survive a fleet of twenty. Platform-level defence has nothing per site to forget. Keep the plugin for login hardening if you like it.

Who should pay for cleaning up a compromised client site?

Whoever your care plan says, which means deciding before it happens. Included up to a stated allowance, billable at your rate, or included only where the client kept to the update schedule — all three are defensible. Inventing the answer during an incident is not, and always resolves against you.

Do I have to tell my other clients when one is compromised?

Only if they were exposed, which on properly isolated accounts they were not — and saying so should be a statement of fact rather than a convenience. Where a shared account did mean shared exposure, notify quickly and in writing. Delay is what turns a technical incident into a trust problem.

Moving your site to another host? Start with this checklist.

A step-by-step order of work for a move your visitors never spot: which files to copy first, how to carry email across without losing one message, the right moment to repoint DNS, and the two mistakes behind nearly every hour of downtime people ring us about.

Contain the incident before it happens.

Imunify360 on every client site, an account each for isolation, six-hourly backups on Elite, and restores you run yourself.

See Secure Hosting plans