WordPress security is not one setting or one plugin. It is a set of ongoing decisions about who can access the site, how software is maintained, where backups live, what a form is allowed to send, and how the team notices trouble. For a business website, the practical objective is to reduce avoidable risk and be ready to respond when something goes wrong.
No checklist can make a website invulnerable. Threats, suppliers, code, and business workflows change. A useful baseline focuses on controls the organization can actually maintain: least-privilege access, deliberate updates, recoverable backups, protected forms, monitoring, hardening, and an incident plan. NIST’s small-business cybersecurity guidance similarly emphasizes knowing what to protect, monitoring logs and alerts, and preparing to respond and recover (NIST CSF 2.0 Small Business Quick-Start Guide).
Start with access: fewer keys, better records
Every administrator account is a high-impact credential. Give each person an individual account, use strong unique passwords managed in a reputable password manager, and remove accounts when responsibilities end. Avoid shared administrator logins because they make it difficult to understand who made a change or to remove access safely.
Assign the least powerful WordPress role that allows the person to do their work. Editors generally do not need plugin or user-management privileges; content contributors should not need hosting-panel access. Review the user list regularly, including former employees, contractors, agency accounts, and old service accounts. Record the owner and purpose of every privileged account.
Add multi-factor authentication where the available identity, hosting, or security tools support it. Multi-factor authentication does not cure every access problem, but it makes a stolen password less useful. Protect related systems too: hosting, domain registrar, email inboxes used for password resets, backups, and analytics. An attacker needs only one weak path into the broader website operation.
Keep the software surface manageable
Keep WordPress core, themes, and plugins current through a controlled update process. WordPress documentation notes that plugin updates can improve security and performance and recommends a current backup before the update (WordPress: Manage Plugins). Review changelogs, use staging for material changes, and test the conversion paths that matter to the business before production deployment.
Remove plugins and themes that are no longer needed, rather than merely deactivating and forgetting them. Retain one supported default theme for troubleshooting, but inventory everything else. Before adding a new extension, assess whether its function could be handled by an existing platform feature, whether it is actively maintained, how it handles data, and what happens if the vendor stops supporting it. More components mean more updates, interactions, and potential entry points.
Use only trusted sources for WordPress software. Avoid nulled or unauthorized premium themes and plugins; they can carry altered code and leave the organization without legitimate updates or support. Keep a short record of licenses, renewal dates, and the business owner for each paid component.
Treat backups as recovery capability
Make backups on a defined schedule and before material changes. Include the WordPress files and the database, and store copies away from the primary server where practical. Limit backup access, because a backup can contain user accounts, form submissions, configuration, and other sensitive information.
More important than the word “backup” is recoverability. Document where backups are, who can restore them, what is covered, and how long restoration usually takes. Test a restoration in a safe environment periodically. NIST describes backups as copies that support recovery and stresses the relationship between backup and restore activities (NIST: Protecting Data from Ransomware). A restoration test often uncovers missing permissions, misunderstood retention rules, or a backup that is too old to meet the business need.
Secure forms and data flows
Forms are a common boundary between the public internet and internal teams. Collect only information needed to respond to the inquiry. Use encrypted connections, validate inputs on the server, protect against spam and automated abuse, and route submissions only to the people and systems that need them. Do not assume client-side validation alone protects a form; it improves the visitor experience but can be bypassed.
Make the notice and consent pattern understandable. Explain what the organization will do with submitted information, link to the relevant privacy notice, and avoid preselected marketing consent where it would be inappropriate. Ensure test submissions do not accidentally create real customer records or send sensitive data into unapproved tools.
Review form notifications and integrations after plugin, email, or CRM changes. A form that accepts data but silently fails to route it is both an operational and customer-service issue. Restrict who can download submissions, and set a retention approach consistent with the organization’s requirements.
Monitor the website and reduce obvious exposure
Monitoring does not need to be elaborate to be useful. Keep an eye on uptime, error alerts, unusual administrator activity, failed login patterns, unexpected file or configuration changes, security plugin findings, and form-spam spikes. Make sure alert emails reach a monitored inbox rather than an abandoned personal account. NIST advises businesses to understand indicators of incidents and to consider how they monitor logs and alerts (NIST CSF 2.0 Small Business Quick-Start Guide).
Apply basic hardening appropriate to the hosting environment: use HTTPS, keep production credentials out of public files and repositories, restrict administrative access where feasible, protect the hosting account and database, and use a web application firewall or host-level security controls when suited to the risk. Confirm file permissions and configuration are aligned with the host’s guidance. Hardening should be reviewed after migrations, platform changes, and new integrations.
Be ready to respond before you need to
An incident plan can be a one-page document. It should name the decision-makers and include hosting, domain, backup, developer, and security contacts; access locations; the approved communication path; and first-response steps. Decide in advance who can take the site into maintenance mode, rotate credentials, restore a backup, contact vendors, or notify affected stakeholders.
If an incident is suspected, preserve useful evidence, limit further exposure, and avoid making random changes that obscure what happened. Stabilize first, then investigate and recover. Afterward, document the cause, actions, impact, and changes to prevent recurrence. Incident readiness is not pessimism; it is respect for the website’s role in the business.
Security baseline checklist
| Area | Baseline question | Owner / evidence |
|---|---|---|
| Accounts | Does every person have an individual account with the minimum necessary role? | |
| Privileged access | Are admin, hosting, registrar, email, and backup access lists current and protected by MFA where available? | |
| Updates | Are core, active themes, and plugins inventoried, reviewed, tested in staging when appropriate, and updated? | |
| Components | Have unused plugins/themes been removed and paid licenses assigned to an owner? | |
| Backups | Are files and database backed up, access-controlled, retained appropriately, and restoration-tested? | |
| Forms | Are collection, validation, spam controls, consent, routing, and retention documented? | |
| Hardening | Are HTTPS, credentials, host controls, and administrative exposure reviewed? | |
| Monitoring | Do named people receive and review uptime, error, login, and security alerts? | |
| Incident plan | Are contacts, containment authority, recovery steps, and communications path documented? |