In early November 2025 one of our customer sites was compromised and started serving phishing content under the customer's own domain. The compromise wasn't subtle. Netcraft, an external security monitoring service, picked it up and filed a report. Sharing an IP with a host serving phishing is the kind of incident that puts the whole shared platform's reputation at risk for every other customer on the same edge. So our acceptable use policy is unambiguous: web access is suspended immediately, the customer is notified by ticket, and the site stays offline until the malware is removed.
We opened the ticket with the customer that morning. Nine days later the customer still hadn't replied. He hadn't logged in. The site stayed offline because we couldn't confirm he'd seen the report. The path most hosts take in that situation is to keep the package suspended indefinitely until the customer engages, or quote a malware-removal fee.
Pippa, on our support team, took a different call. She manually cleaned the malware off the site herself, brought it back online, and asked the customer to rotate his WordPress user passwords and his database password as the two post-clean-up actions. No fee. No "incident response" invoice. She also coordinated the relevant notification to the data centre so the platform-side record of the incident matched what we'd done.
The customer responded eventually. The site stayed clean. The pattern is the point: our security model isn't built around catching the customer paying for the rescue. It's built around protecting the shared-IP reputation that matters every day for every other customer on the platform. The fastest way to protect that reputation is to clean the site for the silent customer rather than leave it festering.
Most hosting plans claim to monitor for compromise. The proof is what you do on day nine, when the customer is silent and the package is still suspended.
