What to do before your company website gets hacked: a security checklist for small businesses

Most small businesses think of website security as somebody else’s problem — "we have nothing worth stealing". In reality most break-ins are not aimed at you at all. Automated scanners sweep the entire internet around the clock looking for known-vulnerable versions, guessable passwords and admin panels nobody closed; whatever they find gets used to inject spam pages, send junk mail, mine cryptocurrency or relay traffic. What attracts them is not your trade secrets but your server capacity and your domain reputation. The good news is that defending against this does not need expensive equipment — it needs a handful of basics, done and kept up. Scale the effort to what the site is: for a brochure site the worst case is redeploying it; a site with member accounts or personal data needs another layer of access control and logging; a site that takes payments should be treated as a production system.

Inventory the entry points and the keys before buying tools

• Domain and DNS: who holds the registrar account, whether it has two-factor authentication, and whether renewal is automatic. If the domain is taken or the DNS records are repointed, a perfectly clean website behind them does not help you.
• Hosting and access: how many SSH or FTP accounts exist, whether password login is still allowed, and who can get into the hosting control panel.
• The application layer: CMS version, the list of plugins and themes — including the ones deactivated but never deleted — and every administrator account. Plugins are the most common way into a small-business site.
• Data and backups: where the database lives, where the backups are kept, and when one was last restored successfully.
• Third parties and contractors: accounts you handed out to designers, marketers or a previous maintenance firm, the API keys used for integrations, and any form or analytics services. Access nobody revoked when a project or a job ended is the easiest route to overlook.

The measures worth putting in place first

• Two-factor authentication and no shared logins: start with the registrar, the hosting control panel, the CMS and company email. One account per person, disabled when they leave — a shared admin login makes it impossible to tell afterwards who did what.
• A fixed patching rhythm: schedule CMS, plugin and server updates into the same slot each month, and run them on a staging copy first. Refusing to update because it might break something leaves publicly documented holes sitting at your front door.
• Least privilege: whoever publishes articles does not need permission to install plugins, and an outside marketer does not need SSH. When permissions are too broad, one stolen account is the whole server.
• Backups you can actually restore: kept off the machine, with at least one copy offline or write-protected, covering both files and the database. Rehearse a restore once a quarter — an unverified backup is reassurance, not protection.
• HTTPS with automatic certificate renewal: an expired certificate has the browser block visitors at the door, and that kind of outage is almost always a missed renewal rather than an attack. While you are there, force HTTPS on the admin area and turn on HSTS.
• Switch off what you do not need: delete deactivated plugins, keep test copies and old version folders off the production host, and never leave database dumps or .env files inside the web root — putting them there is a public download link.
• Keep logs and basic monitoring: retain access and error logs for a reasonable period, then add uptime and file-change alerts. Without logs, investigating an incident is guesswork.

Where your host’s responsibility ends and yours begins

When this line is not drawn clearly, both sides assume the other was handling it. Shared hosting usually patches the operating system and the web server for you, but the CMS, the plugins and your own code are yours alone — and because other sites share the machine, a compromised neighbour can spill over onto you. A VPS or cloud server gives you full control, at the cost of owning operating-system updates, the firewall and SSH configuration yourself; plenty of people assume moving to the cloud is inherently safer, when in fact it hands the whole responsibility back to them. Managed platforms, including PaaS and managed WordPress, cover the most ground, but ask three questions before signing: do the backups include the database, can you download them yourself, and can you obtain raw logs during an incident. Having those three answers in writing beats arguing about them later.

The mistakes that come up most often

• Treating a renamed admin URL as a security measure: changing the path cuts background noise, but it stops nothing that is genuinely probing for holes. It is decoration, not a lock.
• Reusing one password across every service: after any leak elsewhere, the same credentials get tried on your registrar and your host. A password manager costs far less than rebuilding a site.
• Keeping backups on the same server as the site: if the machine is wiped or encrypted, the backups go with it. Locating the backups is the first thing ransomware does.
• Running a dozen plugins that nobody reviews: overlapping features and long-abandoned projects are ready-made entry points. If a built-in feature can do the job, do not add a plugin for it.
• No rate limiting on logins or forms: automated password guessing and spam floods are not merely annoying — they eat server resources and can get your domain flagged by mail providers.
• Assuming a redesign makes the site secure: if the new site inherits the old accounts, DNS records and host permissions, the problems come along unchanged.

If it does happen, work in this order

• Preserve the scene first: copy the logs and the affected files before you clean anything. Deleting the modified files in a hurry destroys the only evidence of how they got in.
• Contain it: take the site down or switch to a maintenance page if necessary, so it stops serving malicious content — once browsers and search engines flag it, clearing that takes far longer.
• Rotate every credential: admin, database, SSH and FTP, API keys, registrar and mail passwords — then check for administrator accounts or scheduled jobs that were quietly added.
• Restore from a clean backup rather than cleaning file by file: confirm the backup predates the first sign of intrusion, fix the underlying hole, and only then go back online — otherwise the same route gets used again within days.
• Assess your notification duties: where customer personal data or payment details are involved, notification obligations may apply, and quietly fixing the site is not enough. Have legal or compliance confirm this part.

Security is never finished, but it does not have to be perfect on day one. Consolidate the accounts, enable two-factor authentication, set a patching rhythm and prove that a backup really restores — those four turn away the overwhelming majority of automated attacks, and the rest can be layered on according to what the site does. If you are unsure what state your site and server are actually in, or there are old accounts you can no longer account for, Floatstone Digital can run an inventory and risk review, set out what to fix first, and take on the routine work of updates and backups.