October is Cybersecurity Awareness Month, and most of the advice you’ll read this month is written for companies with a dedicated security team. If you run your own VPS, dedicated server, or reseller account, you probably don’t have one. You have yourself, maybe a developer, and a long list of things that aren’t security.

The good news is that most server incidents come back to the same handful of gaps. This guide walks through five questions that cover them. Each one includes why it matters, a quick self-check, and one thing to do this month. You can work through all five in an afternoon.

Almost everyone has backups. Far fewer have ever restored one. That’s the gap that hurts: a backup job can report success for months while the copy is incomplete, stored on the same server it protects or rotated out before you notice a problem.

Most restores aren’t triggered by attacks. They’re triggered by a bad plugin update, a deleted folder or a migration that goes sideways on a Friday afternoon. Either way, the question is the same: how fast can you get back to where you were?

Quick self-check

• Do you know exactly where your backups are stored, and is it somewhere other than the server itself?
• Have you restored a backup in the last six months?
• Do you keep enough history to go back to a version from before a problem started?

One thing to do this month: Pick one non-critical site and restore it. Time how long it takes and check what came back.

Go deeper: Your Continuity Plan Is Only as Good as Your Last Restore

Every login is a door. Over time, servers collect doors nobody remembers opening: a former developer’s SSH key, a contractor’s control panel account, an admin login the whole team shares.

Attackers don’t always need to break in when a working login is already out there. Stolen and reused credentials show up in a large share of breaches, often long after the person they belonged to stopped needing access.

Quick self-check

• Could you list every person with access to your hosting account, SSH, control panel and CMS admin?
• Is multi-factor authentication turned on for your hosting account and domain registrar?
• Does everyone have their own login, or are some passwords shared?

One thing to do this month: List every login on your server and match each one to a current person. Remove anything you can’t explain.

Go deeper: Who Can Get Into Your Server? A 30-Minute Access Audit

The moment a server goes online, automated traffic starts testing it for weak logins, known vulnerabilities and anything else it can use. Most of that traffic should never reach your application in the first place.

The layer in front of your site does that filtering. Depending on your setup, it might be a web application firewall, a CDN with DDoS protection like Cloudflare, a malware scanner such as Imunify360, or some combination. The important part is knowing which tools you have and what each one actually does, because they don’t overlap as much as people assume.

Quick self-check

• Do you know what protects your site from malicious traffic before it reaches the server?
• Are you scanning for malware on a schedule, not just after something looks wrong?
• Do you know what would happen to your site under a traffic flood?

One thing to do this month: Write down every security tool on your server and what it’s for. Gaps and duplicates both become obvious fast.

Go deeper: Do I Still Need Cloudflare If I Have Cloud Hosting? and Do I Still Need Imunify360 If I Have Cloud Hosting?

There’s a difference between software that’s out of date and software that’s unsupported. Out of date means a fix exists and you haven’t applied it. Unsupported means no fix is coming.

This one has a deadline attached. PHP 8.2 stops receiving security updates on December 31, 2026, and PHP 8.1 and earlier already have. For WordPress sites, plugins are the bigger risk. The vast majority of new WordPress vulnerabilities are found in plugins, and some of those plugins are no longer maintained by anyone.

Quick self-check

• Do you know which PHP version each of your sites runs?
• Have any of your plugins gone a year or more without an update?
• Is your server’s operating system still supported by its vendor?

One thing to do this month: Check the PHP version on every site, and delete any plugin you aren’t actively using.

Go deeper: Is Anything on Your Server Running Software That Stopped Getting Updates?

Every hosting plan splits security between you and your provider. On a managed plan, your host may handle operating system updates and server configuration. Whereas on an unmanaged VPS or dedicated server, most of that is yours. On every plan, your website’s code, plugins, and user accounts stay with you.

The split isn’t a problem. Not knowing where it sits is. The worst time to find out who was supposed to apply an update is the day after it wasn’t applied.

Quick self-check

• Do you know whether your plan is managed or unmanaged, and what that covers?
• Do you know who applies operating system security updates on your server?
• If your site were compromised tonight, do you know who you’d call first?

One thing to do this month: Read your plan details and write down which jobs are yours. If anything is unclear, ask our support team.

Go deeper: Which Parts of Security Are Yours, and Which Are Your Host’s?

If working through this list showed you how much of your week goes into upkeep, you’re not alone. Backups, access, patching and filtering are all jobs that keep growing as you add sites and traffic.

InMotion Cloud is our managed private cloud for teams that would rather hand those jobs to engineers. OS patching, backups, WAF and DDoS filtering, monitoring and incident response are included on every plan, with senior engineers as your first point of contact.

See how InMotion Cloud works ?