Advanced Data Protection in Web Hosting: What It Means and How to Verify It

What Data Protection Actually Means for WordPress

Most people think data protection means installing Wordfence. It does not. Wordfence is security monitoring. Data protection is a broader discipline that includes what happens after an attack succeeds. The three terms below are not synonyms, and treating them as synonyms leaves gaps that attackers and hardware failures exploit.

Backup

A point-in-time copy of your data stored independently from the live site. The defining property is independence: if the live site is destroyed, the backup survives. A backup stored on the same server as the live site does not meet this definition in any meaningful sense.

Security

The set of controls that reduce the probability of a bad event occurring: firewalls, login protection, plugin updates, and WAF rules. Security reduces likelihood. It does not eliminate it, and it does not help you recover after a failure.

Data Protection

The complete discipline covering prevention (security), continuity (backups), and response (incident procedures). Data protection answers the question: if security fails, can we recover, and how quickly?

Business Continuity

The broader practice of keeping the business operational during and after a disruption. For a WordPress site, this includes having a restore process that meets your RTO (how long you can be offline) and RPO (how much data you can afford to lose).

The CIA Triad for WordPress

The CIA triad (Confidentiality, Integrity, Availability) is the standard framework for thinking about what data protection is supposed to protect. Applied concretely to WordPress:

• Confidentiality: customer email addresses, WooCommerce order data, user passwords, API keys stored in wp-config.php, and any personal data collected by your forms. A breach of confidentiality means this data is exposed to unauthorized parties.
• Integrity: the accuracy and consistency of your database records, your theme and plugin files, and your core WordPress files. A breach of integrity means data has been modified without authorization, including malware injected into PHP files or orders altered in the database.
• Availability: the site being accessible when users need it. A breach of availability is a ransomware encryption event, a server failure, or a botched update that takes the site offline.

The Complete WordPress Asset Inventory

Data protection only covers what you have identified. Most WordPress owners think of their database and uploads folder. The full asset list is longer, and each item has a different failure mode:

Threat Modeling: What You're Actually Defending Against

Most WordPress security articles skip this step entirely. Knowing what you are defending against changes which defenses actually matter. A WooCommerce store processing customer payment data faces different priority threats than a personal blog. Spending an hour on threat modeling is more useful than installing three more security plugins.

External Threats

Brute force and credential stuffing. Automated tools try thousands of password combinations against wp-login.php and the XML-RPC endpoint. Credential stuffing uses email and password combinations leaked from other services: if a customer used the same password on your WooCommerce store that they used on a breached service, that credential is in attacker lists. Real-world consequence: admin account takeover, which leads to malware installation, backdoor shells, or silent data exfiltration within minutes of access.

Malware injection and backdoor shells. After gaining access, attackers typically install a web shell inside wp-content/uploads where file execution may not be restricted. The shell persists even after you change passwords. Real-world consequence: the site becomes part of a botnet, sends spam, mines cryptocurrency on your server, or silently exfiltrates customer data for weeks before detection.

Ransomware. A growing attack category on WordPress, covered in depth in the ransomware defense section below. For the full taxonomy of WordPress attack types including SQL injection, XSS, and DDoS, see the security threats guide. Real-world consequence: all site files and the database are encrypted, the site is taken offline, and the attacker demands payment for the decryption key.

Supply-Chain Attacks

Over 56% of WordPress breaches in 2025 involved unpatched or compromised plugins. Supply-chain attacks work because you trust plugins and themes by default: you install them, they run PHP on your server, they have database access. The three attack vectors in this category:

• Abandoned plugins with unpatched vulnerabilities still installed on millions of sites. The attacker does not need to target your specific site. They find a plugin with a known vulnerability and scan for every site running it.
• Nulled themes and plugins downloaded from unofficial sources. These frequently contain pre-installed backdoors. The apparent cost savings do not survive first contact with the consequences.
• Compromised plugin update packages. Rare, but documented: a plugin repository account is taken over and a malicious update is pushed to all installed sites without any action required from the site owner.

Internal Threats and Human Error

This is statistically the most common cause of data loss. Most sites have no offboarding checklist for former developers or contractors. The practical scenarios:

• Accidental deletion: an admin deletes the wrong post, runs an UPDATE without a WHERE clause, or empties a trash folder containing important content.
• Ex-developer access: a contractor who built the site two years ago still has an admin account and SSH key that were never revoked.
• Shared credentials: the admin account is used by three people. One of them gets phished. You cannot tell which login was the attacker, and you cannot audit which actions were legitimate.

How Ransomware Attacks WordPress Specifically

The attack chain has consistent steps that explain why certain defenses work and others do not:

1. Initial access: exploit a vulnerable plugin, brute-force a weak password, or use a stolen credential from another compromised service.
2. Webshell installation: a PHP file is uploaded to wp-content/uploads (or another writable directory) giving the attacker persistent server access independent of WordPress credentials.
3. Privilege escalation: the webshell is used to read wp-config.php for database credentials, escalate to server-level access where configuration allows, and map the full file structure.
4. Backup discovery: the attacker scans for backup archives inside public_html and any mounted storage accessible via the compromised account.
5. Backup deletion: discoverable backup archives are deleted before encryption begins. If backup credentials are stored in the WordPress database (as most plugin-based systems store them), those destinations are also cleared.
6. Encryption: all PHP, database, and media files are encrypted with a key held by the attacker.
7. Extortion: a ransom note is placed in the web root.

WordPress Backup Architecture: Real Strategy, Not Just "Install UpdraftPlus"

A backup plugin is a tool. A backup strategy is a set of decisions about frequency, storage location, redundancy, retention, and testing. Most WordPress sites have the tool without the strategy. Installing UpdraftPlus and pointing it at Dropbox is better than nothing, but it is not a strategy. The strategy is what happens when the tool fails, when the host suspends the account, or when ransomware runs before the next scheduled backup.

Backup Types Explained Simply

Full backup. A complete copy of the database and all site files every time it runs. Simplest to restore from (one file, one restore step), but uses the most storage. Practical for small sites on weekly schedules.

Incremental backup. Only the data that has changed since the last backup run. Much smaller per run, faster to take, but requires the complete chain of incrementals to restore. Best for large or frequently-changing sites. The full comparison of backup types is in the backup and restore guide.

Snapshot. A storage-layer image of the server at a point in time. Nearly instant, but tied to the same storage system as the live data. Useful for fast server-level rollback. Not a substitute for an independent offsite backup.

The 3-2-1 Rule Applied to WordPress

Three copies of your data, on two different storage providers, with one copy offsite. Applied concretely:

• Copy 1: the live site (counts as a copy)
• Copy 2: a backup on the same hosting account (the host's daily snapshot, or a plugin-generated archive stored on the server)
• Copy 3: an offsite copy on a completely separate provider (Backblaze B2, Wasabi, or Amazon S3)

For a personal blog, this is adequate. For a WooCommerce store, this is the minimum. For an agency managing client sites, a fourth copy on a second separate provider is worth the small additional cost.

The 3-2-1-1 Extension for 2026

Ransomware has added a fourth requirement: one copy must be immutable or air-gapped. An immutable copy using S3 Object Lock, Backblaze B2 Object Lock, or Wasabi Object Lock cannot be deleted or overwritten during the lock period, even by an authenticated API request from a compromised server. This is the specific defense that makes ransomware backup-deletion attacks fail.

Enabling Object Lock on Backblaze B2 is a bucket-level setting during bucket creation. It costs nothing extra and takes five minutes to configure. For any site with real revenue, this is worth doing today.

RPO and RTO

Before choosing a backup frequency, define two numbers:

RPO

How much data you are willing to lose, measured in time. A WooCommerce store with daily backups has a 24-hour RPO. That means a Tuesday afternoon failure means recovering to Monday's 3 AM state, losing all of Tuesday's orders. If that is an unacceptable loss, the backup frequency must be shorter.

RTO

How long your site can be offline before it causes serious harm. A personal blog can tolerate a day offline. A store doing real revenue probably cannot tolerate more than an hour. Your restore process must fit inside this window, which means you need to have tested the restore process before the incident.

Hosting-Level Data Protection: What Your Host Should Actually Be Doing

The hosting layer is the only protection that works even when WordPress itself is compromised. Plugins run inside WordPress. If WordPress is taken over, plugin-level defenses are available to the attacker. Server-level defenses, configured outside WordPress, are not.

WAF: Server-Level vs Plugin-Level

A WAF (Web Application Firewall) inspects HTTP requests before they reach your application. There are two fundamentally different positions for it, and the difference matters for data protection:

DNS-level WAF (Cloudflare, Sucuri): traffic routes through the WAF service before reaching your server. Malicious requests are blocked at the WAF's network edge. Your server never sees them. A compromised server cannot disable this firewall because the firewall does not run on your server.

Plugin-level WAF (Wordfence): a PHP plugin running on your server that inspects requests after they arrive. The malicious request already reached your server. The plugin attempts to block it before WordPress processes it further. If the plugin is bypassed, disabled, or if WordPress is already compromised, the firewall is gone.

A DNS-level WAF is categorically stronger for data protection. A plugin-level firewall is still worth running, but it should not be your only defensive layer at the network edge.

Isolated Environments and Cross-Site Contamination

On shared hosting, multiple customers share a server. Without isolation, a compromised site on the same server can access files belonging to other accounts. CloudLinux CageFS creates a virtual filesystem for each account, preventing cross-account file access entirely. If you run on shared hosting, ask your host whether CageFS is enabled. "We use CloudLinux" without CageFS is not isolation. The two are different features.

RAID Is NOT a Backup

RAID protects against hardware failure. It does not protect against accidental deletion, ransomware, database corruption, or account suspension. RAID keeps your server running if a physical drive dies. It does nothing to protect you from a developer who accidentally drops a database table, a plugin that corrupts wp_postmeta, or an attacker who encrypts your files. RAID and backups serve completely different purposes, and one does not substitute for the other. The full technical breakdown is in the RAID levels guide.

Immutable and Air-Gapped Backups

Immutable backup storage uses WORM (Write Once Read Many) semantics: once data is written, it cannot be overwritten or deleted for a set retention period. On Backblaze B2 and Wasabi, this is called Object Lock. On Amazon S3, it is S3 Object Lock. For most WordPress sites, immutable cloud storage is the practical implementation. Full air-gap (physically disconnected storage) is rare outside enterprise environments but provides the strongest possible protection.

Hosting-Side Backup Tools

JetBackup is the most common backup system on cPanel hosts. It produces incremental daily backups on a separate backup server within the same datacenter. The interface allows per-database or per-file restores without restoring the full account. Retention is host-defined, typically 14 to 30 days.

R1Soft is a continuous data protection agent used by many managed hosts. It takes incremental block-level snapshots rather than file-level backups, enabling faster restores and more granular recovery points.

BorgBackup and ZFS snapshots are common on VPS and dedicated server environments. ZFS snapshots are nearly instantaneous and space-efficient, but are tied to the same storage system as the live data, meaning a storage failure affects both.

The two hosts I rely on, ScalaHosting and Cloudways, both include independent backup infrastructure. ScalaHosting stores daily offsite backups separately from the live server. Cloudways manages backups on its own infrastructure with configurable frequencies. Details are on the main hosting pages.

Ransomware Defense for WordPress: Specific and Actionable

Ransomware attacks targeting WordPress sites more than doubled from 2024 to 2025. Most security articles still treat this as a single bullet point under "keep backups." This section goes deeper because the defenses that work against ransomware are not the same as general security hardening. Several standard recommendations fail entirely in a ransomware scenario.

How a WordPress Ransomware Attack Actually Progresses

1. Initial access: a vulnerable plugin (frequently one that has not been updated in 90 days), a brute-forced weak admin password, or a credential stolen from another service where the password was reused.
2. Webshell installation: a PHP file is uploaded to wp-content/uploads or another writable directory, giving the attacker persistent server access independent of WordPress credentials.
3. Privilege escalation: the webshell is used to read wp-config.php for database credentials, escalate to server-level access where server configuration allows, and map the full account file structure.
4. Backup discovery: the attacker scans for backup archives inside public_html, wp-content subdirectories, and any mounted storage accessible from the compromised account.
5. Backup deletion: discoverable backup archives are deleted before encryption begins. If backup destination credentials are stored in the WordPress database (as most plugin-based backup systems store them), those remote destinations are also wiped.
6. Encryption: all PHP files, database files, and media are encrypted with a key held by the attacker.
7. Extortion: a ransom note is placed in the web root with payment instructions.

Why Backups Inside public_html Are Not Protection

Backups stored in the same web root as your live site are the first thing ransomware encrypts. They are not a separate layer. They are part of the attack surface. The default UpdraftPlus storage path is wp-content/updraft. That folder is inside public_html. It is accessible from the same process that will encrypt everything else. A backup stored here provides zero protection against a server-level compromise, which is exactly the scenario where you most need a backup.

Immutable Backup Storage

WORM storage prevents deletion or modification of data for a set period, even by authenticated API requests. Object Lock on Backblaze B2 and Wasabi works at the bucket level: you define a retention period such as 30 days, and no API call can delete those objects during that window, regardless of the credentials used.

Enabling Object Lock on Backblaze B2:

1. Create a new B2 bucket and enable Object Lock during bucket creation. This cannot be added to an existing bucket retroactively.
2. Set the default retention mode to Compliance and the period to 30 days.
3. Create an application key scoped to this specific bucket with write permissions only. No delete permission.
4. Use this write-only key in your backup plugin's B2 configuration. The plugin can write new backups but cannot delete existing ones, even if the server is fully compromised.

Separate Backup Credentials

Most backup plugins store the destination credentials (S3 access key, B2 application key, Dropbox token) inside the WordPress database or wp-config.php. A compromised server with access to those files also has access to those credentials. The defense is a write-only token: a credential that can upload new backup files but cannot list, read, or delete existing ones.

Both Backblaze B2 and Wasabi support capability-scoped keys. Create a key with the writeFile capability only. Even if an attacker reads this key from your WordPress database, they cannot use it to delete your backup history.

Access Segmentation

The backup system should be isolated from the live site's credential chain. The stronger design: backup credentials are stored outside WordPress entirely (in hosting control panel environment variables or a secrets manager), the backup destination uses a separate account from your main cloud storage, and the backup key is scoped to write access only on that specific destination bucket.

Access Control, Credentials, and Identity Security

Principle of Least Privilege in WordPress

An editor does not need plugin install rights. A developer does not need to share the admin account. A support agent answering comments does not need Author access. These are not inconveniences. They are the controls that contain the blast radius when a credential is compromised. A compromised Editor account cannot install a backdoor plugin. A compromised Author account cannot delete all users. Scope the role to the job, and limit what any single credential failure can accomplish.

The practical test: for each user account on your site, ask "what is the minimum role that lets this person do their job?" If the answer is unclear, the account probably has more access than it needs.

MFA, Passkeys, and Hardware Keys in 2026

Password-only authentication is not acceptable for any WordPress admin account in 2026. The options, from weakest to strongest additional factor:

TOTP codes (Google Authenticator, Authy): a 6-digit code valid for 30 seconds. Significantly better than a password alone, but interceptable by a real-time phishing proxy. The attacker presents a fake login page, captures the code as you enter it, and uses it on the real site within the validity window.

Passkeys (WebAuthn): the private key never leaves your device. Authentication is cryptographically bound to the specific domain, so a phishing site at a lookalike domain cannot capture and replay a passkey. Browser and password manager support has matured significantly in 2025 to 2026.

Hardware security keys (YubiKey, Google Titan): similar phishing resistance to passkeys, with the private key stored in a dedicated hardware device. The gold standard for high-value admin accounts managing sensitive sites.

SSH Key Authentication

For any WordPress site where you use SSH access, disable password-based authentication and use key-based authentication only. Ed25519 keys are preferred: smaller and faster than 4096-bit RSA with equivalent or better security. Add the public key to authorized_keys on the server. Protect the private key with a passphrase.

ssh-keygen -t ed25519 -C "youremail@example.com"

IP Allowlisting for wp-admin

If you manage the site from a fixed IP address or a small set of known addresses, restrict wp-admin to those addresses at the server level. A brute-force attack cannot succeed against a login page that returns 403 to 99% of the internet. This is one of the highest-return hardening steps available on any VPS or managed host with server configuration access.

Offboarding Checklist for Developers and Contractors

The most common access control failure I have seen is not weak passwords. It is former contractors with active accounts and SSH keys that were never revoked. When a developer, designer, or agency relationship ends, this sequence must run:

WordPress Hardening Directly Tied to Data Protection

Generic hardening lists have 50 items. This section covers only the steps that directly prevent data loss or data exposure. The rest are noise that distracts from the few that actually matter. If you do only five things from this section, the table at the end identifies which five have the highest return.

Harden wp-config.php

wp-config.php holds your database credentials and security keys. Every protection measure applied here has direct data protection value:

• Move it above the web root. WordPress natively supports wp-config.php placed one directory above public_html. It finds it automatically. Move it there and the file is no longer reachable via a web request even if directory traversal is attempted.
• Set permissions to 400. Read-only by the owner. The web server does not need to write this file. No other process should be able to modify it.
• Add define('DISALLOW_FILE_EDIT', true); This disables the theme and plugin code editors inside the WordPress admin dashboard. An attacker with admin access can no longer execute arbitrary PHP code through the editor without direct server access.
• Rotate secret keys after any incident. The WordPress secret key service at api.wordpress.org generates fresh keys. Replacing the keys in wp-config.php invalidates all active sessions instantly, logging out anyone with a current session including an attacker who obtained a session token.

Disable PHP Execution in /wp-content/uploads/

The uploads directory is world-writable to allow media uploads. It should never execute PHP. A webshell uploaded as a .php file here is one of the most common persistence mechanisms after a WordPress compromise. Block it at the server level:

location ~* /wp-content/uploads/.*\.php$ {
    deny all;
    return 403;
}

<Files *.php>
    deny from all
</Files>

Disable XML-RPC

XML-RPC is a legacy remote publishing interface that WordPress has included since version 2.6. In 2026 it is rarely used for its intended purpose, but it is still actively exploited for brute-force attacks (bypassing lockout plugins that only watch wp-login.php) and pingback-based DDoS amplification. If you do not use the Jetpack mobile app, remote publishing, or any integration that specifically requires XML-RPC, block it at the server level:

<Files xmlrpc.php>
    order deny,allow
    deny from all
</Files>

File Integrity Monitoring

File integrity monitoring detects when PHP files are modified outside of normal update processes. Malware injected into core WordPress files fails a checksum comparison. Two practical tools:

WP-CLI checksum verification compares your core files against the official checksums published by WordPress.org. Run it monthly from SSH:

wp core verify-checksums

Wordfence file scanner runs inside WordPress and monitors both core files and plugin files for unexpected changes. The free version runs scheduled scans. The premium version adds real-time alerts.

Backup Verification and Restore Testing: The Step Most People Skip

An untested backup is a hopeful file, not a safety net. I have seen this go wrong directly: a WordPress agency whose most recent offsite backup turned out to be a corrupt mysqldump that had been failing silently for six weeks before anyone discovered it during an actual recovery attempt. The backup job ran on schedule. The backup file existed at a plausible size. The contents were a partial dump that would not import cleanly. The only way they would have known was to test it.

Why Backups Fail Silently

Three mechanisms cause most silent backup failures:

• Disk space exhaustion: the backup process starts writing, fills the available disk quota, and terminates early. The process exits, the truncated file sits on disk, and no alert is raised unless the tool specifically monitors expected output size.
• PHP timeouts: plugin-based backups run as PHP processes subject to max_execution_time limits. Large database tables (wp_postmeta on a WooCommerce store with years of orders, for example) can push the process past the time limit. The backup file is truncated at the last completed operation.
• mysqldump memory or row limits: mysqldump on some shared hosting environments is configured with row count or memory limits. A database that exceeds the limit produces a partial dump that imports without errors but contains only a portion of the table data.

Three Lightweight Checks Without a Full Restore

These take under two minutes and catch the most common corruption cases before you need the backup in an actual emergency:

1. File size sanity check. Know roughly how large your site is. A WooCommerce store with 3 GB of data should produce a backup in that range. A 50 MB backup from a 3 GB site signals early termination, a missed directory, or a tool that only captured the database and skipped wp-content.

2. SQL dump completion check. The last line of a valid mysqldump is always the completion comment. Run this and check the output:

tail -1 backup.sql
# Expected: -- Dump completed on 2026-05-06 03:00:01

3. Archive listing check. A corrupt tar archive fails to list contents. A valid one shows the expected directory structure:

tar -tzf wp-content.tar.gz | head -20

Monthly Restore Drill

Quarterly is the minimum cadence for a full restore test. Monthly is appropriate for WooCommerce stores and any site where data loss has direct financial consequences. The process:

1. Take the most recent offsite backup.
2. Restore it to a staging environment completely isolated from the live site: a local container, a sandbox subdomain, or a temporary VPS instance.
3. Verify the home page loads without PHP errors or broken layout.
4. Log in as admin with the expected credentials.
5. Check five randomly selected posts from different publish dates render correctly.
6. For WooCommerce: find a recent order in the staging admin and confirm all line items, customer data, and order status came through accurately.
7. Confirm the entire restore completed within your defined RTO window.

Common WordPress Data Protection Myths

These six beliefs cause more data loss than any individual security vulnerability. Each one creates a false sense of security that stops the person from taking the actions that would actually help.

Myth 1: RAID is a backup.
False. RAID is availability, not recoverability. RAID keeps your server running if a physical drive fails. It has no protection against accidental deletion, database corruption, ransomware, or account suspension. Two drives in a RAID 1 array can fail simultaneously on aging hardware with drives from the same manufacturing batch. Backups and RAID serve entirely different purposes and neither substitutes for the other.

Myth 2: Daily backups are enough for my WooCommerce store.
Not if your acceptable RPO is 24 hours. A failure at 2 PM on a Tuesday means recovering to 3 AM on Monday, losing every order placed between those two points. For a store processing orders throughout the day, daily backups mean the recovery point is yesterday's state. Hourly incremental backups are the practical minimum for any store with meaningful transaction volume.

Myth 3: My host handles backups so I'm covered.
Hosting backups exist primarily for the host's operational needs: recovering from infrastructure failures on their end. They are typically stored on the same datacenter infrastructure as your live site, have a short rolling retention window, and become inaccessible if your account is suspended for any reason. They are one layer, not a complete strategy. You do not fully control them.

Myth 4: Cloud storage means it's safe.
A cloud bucket is storage with the same properties as any other storage. Buckets can be deleted, accidentally made public, or completely wiped if connected credentials are compromised. Ransomware with access to your backup destination credentials can delete your entire backup history from a cloud bucket in seconds. Immutable Object Lock is the protection. "Cloud" by itself provides none.

Myth 5: If the backup file exists, recovery will work.
Often false. I have encountered mysqldumps that produced files at a plausible size but contained only 40% of the database. The file existed. The import process appeared to complete. Half the site was missing until someone tried to load a post that predated the truncation point. Untested backups are hopeful files. The safety net only exists after a successful restore test confirms it.

Myth 6: Backups inside public_html are protected copies.
These are the first things ransomware encrypts. The UpdraftPlus default directory, the uploads folder, and any other backup location inside your web root is part of your attack surface. A backup is defined by its independence from the live site. A backup that shares the same directory structure as the live site does not meet that definition.

The Gold Standard WordPress Data Protection Stack

After working across dozens of WordPress sites from personal blogs to high-volume WooCommerce stores, this is what a properly protected site actually looks like. Not the version on the sales page. The version that holds up when something actually goes wrong.

Recommended Stack by Site Type

Tier 1: Personal blog or brochure site

• Managed host with daily snapshots stored separately from the live server
• UpdraftPlus free with Backblaze B2 as the remote destination
• Daily full backup, 30-day retention window
• MFA enabled on the WordPress admin account and the hosting control panel
• Quarterly restore test to a staging or local environment

Tier 2: WooCommerce store or small business site

• All of Tier 1
• BlogVault or UpdraftPlus Premium for hourly incremental backups
• Backblaze B2 or Wasabi as destination with Object Lock enabled on the bucket
• Write-only application key configured for the backup destination
• MFA on all admin accounts, passkeys preferred over TOTP
• DNS-level WAF (Cloudflare or Sucuri) in front of the server
• Monthly restore test that verifies a recent WooCommerce order end-to-end

Tier 3: Agency, multisite, or high-traffic site

• All of Tier 2
• Dedicated backup server or separate cloud account completely independent from the production host
• Bastion host or VPN required for all SSH access to production
• IP allowlist enforced for wp-admin at the server level
• Automated file integrity alerts (Wordfence real-time monitoring or equivalent)
• Centralized backup dashboard covering all managed sites
• Developer offboarding checklist enforced on every contractor departure

Monitoring and Alerting

A protection stack without monitoring is a stack you cannot observe until something is already wrong. Three alerting layers worth implementing:

• Uptime monitoring: Better Stack or UptimeRobot checks your site every 30 to 60 seconds and sends an alert if it goes down. Both have free tiers that cover most sites without cost.
• File change alerts: Wordfence real-time monitoring alerts when core file checksums change. Combined with monthly WP-CLI verification, this catches malware injections before they propagate.
• Failed login alerts: Limit Login Attempts Reloaded or Wordfence can send an alert when there is an unusual spike in failed logins from a specific IP, indicating an active brute-force attempt.

What to Do in the First 30 Minutes After a Compromise

Having this written down before you need it saves critical minutes during a live incident. The sequence:

1. Put the site in maintenance mode or take it offline entirely. Stop active damage before investigating.
2. Preserve server access logs before log rotation overwrites them. These are your evidence for determining the initial access vector.
3. Rotate every credential: hosting account password, all WordPress admin passwords, database password, FTP password, and all SSH keys. Every access point, without exception.
4. Restore from the last known clean backup to a staging environment first. Never restore directly to the live site until the staging copy has been verified clean.
5. Scan the restored staging copy for persistence mechanisms: unauthorized admin accounts, unknown cron jobs, webshell PHP files in wp-content/uploads, and any recently modified core files.
6. Verify DNS records have not been modified to redirect traffic to an attacker-controlled server.
7. Audit all WordPress user accounts for additions made since the last audit. Remove any accounts that should not exist.
8. If personal data was exposed, notify affected customers as required by applicable privacy law. GDPR requires notification within 72 hours of becoming aware of the breach.

Your 10-Point Self-Assessment

Run through this list once. The items you cannot answer confidently are your priorities:

1. Do you have an offsite backup stored on a different provider from your host?
2. Have you tested a restore in the last 90 days?
3. Does every admin account use MFA?
4. Are your backup destination credentials separate from your hosting credentials?
5. Do you have immutable or versioned storage for at least one backup copy?
6. Is file editing disabled in wp-config.php via DISALLOW_FILE_EDIT?
7. Is PHP execution blocked in /wp-content/uploads/?
8. Do you have a written offboarding procedure for developers and contractors?
9. Does your monitoring alert you to file changes, not just downtime?
10. Do you know your RTO and RPO targets?

If your current hosting does not include independent backup infrastructure, real server-level hardening, and developer-grade SSH access control, these are the two I rely on: ScalaHosting for managed VPS with daily offsite backups and SPanel included, and Cloudways for managed cloud hosting with configurable backup frequency and a performance stack built for WordPress.