Moving to cloud hosting gives you better infrastructure than most small businesses could ever build themselves — but it does not make security automatic. Every week, sites on powerful cloud servers get compromised through the same handful of preventable gaps: an unpatched application, a weak password, no encryption, or access left wide open. The attackers are not targeting you; automated bots probe every server on the internet, all day, looking for exactly these gaps.
This is the non-negotiable checklist: the security basics every site on cloud infrastructure needs, whether you run a blog, a store, or a client project. Each item includes what it is, why it matters, and what “done” looks like. None of it requires a security team — just deliberate setup and a little ongoing attention.
The Checklist at a Glance
- Encrypt everything with HTTPS (SSL/TLS)
- Keep everything patched — OS, app, plugins, themes
- Lock down access: strong auth, least privilege, no defaults
- Configure the firewall: close what you do not use
- Add a Web Application Firewall (WAF)
- Back up automatically and test restores
- Monitor and log: know when something is wrong
- Secure your DNS and domain
1. Encrypt Everything with HTTPS (SSL/TLS)
What it is: A TLS certificate enables HTTPS, encrypting traffic between your visitors and your server so it cannot be read or modified in transit.
Why it matters: Without HTTPS, logins, form submissions, and payment details travel in readable form across networks you do not control. Beyond security, browsers now flag non-HTTPS sites as “Not Secure,” and search engines treat HTTPS as a ranking signal. There is no legitimate reason to skip it.
What “done” looks like: A valid certificate installed, automatic renewal configured (free certificates from automated authorities make this trivial), all HTTP traffic redirecting to HTTPS, and no mixed-content warnings. Test with an SSL checker and confirm the redirect works from a fresh browser session.
2. Keep Everything Patched
What it is: Promptly applying security updates to the operating system, the web application (WordPress, etc.), plugins, themes, and any server software.
Why it matters: The overwhelming majority of site compromises exploit known vulnerabilities with available patches — not zero-days. Bots scan for outdated software versions within hours of a vulnerability disclosure. An unpatched plugin is an unlocked door with a sign on it.
What “done” looks like: Automatic security updates enabled wherever the platform supports them; a weekly manual check for everything else; unused plugins and themes deleted (not just deactivated); and a staging process for testing major updates before they touch production. On managed hosting, confirm exactly which layers the host patches for you — this boundary is precisely what the shared responsibility model describes.
3. Lock Down Access: Strong Auth, Least Privilege, No Defaults
What it is: Controlling who can log in to what, with credentials that resist guessing and permissions limited to what each person actually needs.
Why it matters: Brute-force login attacks are constant background noise on the internet. Default usernames (“admin”), weak passwords, and over-privileged accounts turn that noise into breaches.
What “done” looks like:
- No default credentials anywhere — change every factory password on day one.
- Long, unique passwords for every account, stored in a password manager. No reuse.
- Two-factor authentication (2FA) on hosting panels, CMS admin accounts, domain registrar, and DNS — everywhere it is offered.
- Least privilege: each user and each application gets the minimum permissions it needs. The blog editor does not need server root; the backup script does not need database write access.
- SSH key authentication instead of passwords for server access, with password login disabled.
- Old accounts removed promptly when people leave a project.
4. Configure the Firewall: Close What You Do Not Use
What it is: Network rules controlling which traffic can reach your server on which ports.
Why it matters: Every open port is a surface attackers can probe. Most web servers need only web traffic (ports 80/443) and admin access (SSH) open — everything else should be closed by default.
What “done” looks like: A default-deny firewall with explicit allow rules; SSH restricted to your IP addresses where possible (or moved off the default port in addition to key-only auth, never instead of it); database ports not exposed to the public internet at all; and cloud security groups reviewed as carefully as the server firewall itself, since on cloud hosting there are two layers to configure.
5. Add a Web Application Firewall (WAF)
What it is: A filter sitting in front of your site that inspects incoming requests and blocks known attack patterns — SQL injection probes, cross-site scripting attempts, and bot abuse — before they reach your application.
Why it matters: Patching protects you from known vulnerabilities; a WAF protects you during the window between a vulnerability’s disclosure and your patch, and against entire classes of attacks regardless of patch state. It is defense in depth, not a replacement for updates.
What “done” looks like: A reputable WAF enabled (many CDNs and security services bundle one), set to block rather than merely log the obvious attack signatures, with its own logs reviewed occasionally. If your site faces meaningful adversarial traffic, our DDoS protection guide covers the heavier artillery.
6. Back Up Automatically — and Test Restores
What it is: Regular, automated copies of your site’s files and database, stored somewhere other than the server itself.
Why it matters: Backups are your last line of defense against everything: hacks, bad updates, accidental deletions, provider failures. But an untested backup is a hope, not a plan — restores fail for boring reasons (corrupt archives, missing database credentials) that you only discover when it is too late.
What “done” looks like: Automated daily backups at minimum; copies stored off-server (and ideally with a second copy in a different region or provider); retention covering at least a few weeks; and a restore actually performed — to a staging location — at least quarterly. Document the restore steps so you are not figuring them out during an incident.
7. Monitor and Log: Know When Something Is Wrong
What it is: External uptime monitoring plus server and application logs that record what happened, so you can detect intrusions and diagnose problems.
Why it matters: Most compromised sites sit compromised for weeks because nobody was watching. Monitoring turns “we found out from a customer” into “we got an alert at 3 AM.” Logs turn “something is wrong” into “here is exactly what happened.”
What “done” looks like: An independent uptime monitor checking your site every few minutes with alerts to your phone or email; failed-login alerting or rate limiting on admin areas; logs retained long enough to investigate (weeks, not days); and a habit of actually glancing at the monitor dashboard weekly.
8. Secure Your DNS and Domain
What it is: Protecting the domain name itself: registrar account security, DNS configuration, and safeguards against hijacking.
Why it matters: If an attacker controls your DNS, they control where your visitors go — no server security in the world helps. Domain hijacking is rare but devastating, and registrar accounts are phished constantly.
What “done” looks like: 2FA on the registrar account; a registrar lock enabled on the domain; DNSSEC enabled if your provider supports it; DNS hosted with a reputable provider (separate from your hosting if you want resilience); and contact details current so renewal notices reach you — an expired domain is a self-inflicted outage.
When Prevention Fails: Basic Incident Response
Even with every item above done, incidents happen. What separates a bad day from a disaster is having a plan before you need it:
- Detect fast. This is what monitoring is for. The goal is to know within minutes, from your own systems — not from a customer email hours later.
- Contain first, diagnose second. If you suspect compromise, isolate the affected system: take it offline or firewall it off before you start investigating. A compromised server left running can attack others or leak more data while you poke at logs.
- Preserve evidence. Snapshot the system before you wipe and rebuild. You may need logs for forensics, for understanding the entry point, or for regulatory notifications.
- Rebuild cleanly. Do not try to “clean” a compromised server and put it back into service — rebuild from known-good sources (your code repository, your tested backups) and rotate every credential and key that touched the old system.
- Find the entry point. Rebuilding without understanding how they got in just schedules the next incident. Check for the usual suspects: unpatched software, brute-forced credentials, leaked API keys.
- Notify if required. If personal data was exposed, data-protection laws in many jurisdictions require notifying regulators and affected individuals within strict deadlines. Know your obligations before the incident, not during it.
Write these steps down — a one-page runbook stored somewhere you can reach even when your own infrastructure is down. Incident response performed from memory, under stress, at 3 AM, is how small mistakes compound.
The Mindset Behind the Checklist
Two principles tie these eight items together. First, defense in depth: no single measure is perfect, so you layer them — if the WAF misses something, patching catches it; if patching lags, the firewall limits the blast radius; if everything fails, backups bring you back. Second, assume breach: configure logging and monitoring as if an incident is a matter of when, not if, so that when it happens you detect it fast and recover cleanly.
Finally, remember that security is a practice, not a project. Run through this checklist when you launch, then revisit it quarterly: update the patches, review the user accounts, test a restore, glance at the logs. Thirty minutes every few months is the entire maintenance cost of staying off the “compromised site” lists — a bargain by any measure.
