A small business can reduce WordPress risk a long way without enterprise tooling. Patch supported software, protect the accounts that control the site and prove you can recover. Then match any extra controls to the data and services at risk. No plugin or maintenance plan is a security guarantee.
If you think the site is already compromised, skip prevention for now. Go to the section on suspected compromise further down. Contact your host or technical provider using details you already know. Keep evidence while they limit the harm.
Where WordPress security risk comes from
WordPress needs active care. So does everything around it, from plugins and themes to the host.
Security reduces risk without removing it. WordPress's hardening guide says security "is risk reduction, not risk elimination".
The controls in this guide sit in four layers:
Layer | What it covers |
|---|---|
Software | Core, themes, plugins, PHP and integrations |
Identity and permissions | Accounts, MFA, roles and integration credentials |
Hosting and public interfaces | The server, forms, uploads and login routes |
Detection and recovery | Alerts, logs, backups and tested restores |
Company size alone doesn't decide what's enough. A site that takes bookings or payments needs more care than a simple brochure site. So does one that collects health details.
ASD's small business cyber security guide sets a sensible baseline:
turn on MFA, starting with the most important accounts
turn on automatic updates
back up your information and your website regularly
give each person only the access they need
keep an emergency plan
Installing a security plugin doesn't tick off that list. It isn't a certification either.
Flaws in WordPress itself happen as well. WordPress 7.1.3 shipped on 6 October 2026 with 7 security fixes. Always check the current release.
These are possible routes in, with the question each one raises. They're examples, not a ranked list of causes.
Possible route | Question to ask |
|---|---|
Vulnerable core, theme or plugin | Is it supported, patched or safely replaced? |
Stolen or reused passwords | Are accounts unique and protected, with safe recovery? |
Too much or forgotten access | Who can change code, data, payments or permissions? |
Untrusted software source | Is the source legitimate, maintained and updatable? |
Hosting, device or email compromise | Could access to another system reset or replace the website? |
Unsafe inputs or exposed data | Are uploads, forms and stored records handled properly? |
A failed login isn't evidence that anyone got in. A blocked request might be harmless probing or a genuine attempt. It might also be a false alarm. Each signal needs sorting before anyone draws a conclusion.
Moving to another platform changes who does the work without removing it. For that wider decision, see WordPress benefits and responsibilities.
Nine practical security controls
Start with the first four. Every other control depends on your software and accounts staying in your hands.
Control 1: keep supported software patched
Start with an inventory of everything that can need a security fix:
WordPress core
themes, including any parent theme a child theme relies on
plugins, including must use plugins that load automatically
PHP, the programming language WordPress runs on
integrations and the code that connects them
Give one person the job of reading security notices and chasing failed updates.
Urgent fixes can't wait for a monthly maintenance slot. When a fix targets a flaw that's being exploited, act on it promptly. WordPress recommended installing the 7.1.3 release immediately because it was a security release.
If no patch exists yet, the technical owner may need to disable, isolate or replace the affected feature. Plan how the business keeps running while that happens.
A common mistake is treating a scheduled update as a finished one. Automatic updates for plugins and themes are opt in, not on by default. WordPress emails the admin about successful and failed updates by default.
The feature relies on WordPress Cron, the built in task scheduler. The documentation warns it "may not work correctly". It says to keep a way to roll back. Someone still has to read those emails. Check key tasks afterwards as well.
A staging copy, a private test version of the site, helps on complex sites. Manual updates aren't automatically safer, though, if they leave a known hole open for weeks.
PHP needs the same attention. A version can still run your site after its security fixes stop. PHP's supported versions page showed this in October 2026:
PHP version | Active support until | Security fixes until |
|---|---|---|
8.1 and earlier | Ended | Ended |
8.2 | Ended | 31 December 2026 |
8.3 | Ended | 31 December 2027 |
8.4 | 31 December 2026 | 31 December 2028 |
8.5 | 31 December 2027 | 31 December 2029 |
Ask your host which version the site runs and when it will move.
Control 2: use unique passwords and protect the recovery chain
Use a password manager and a strong, unique password for every person and service. Cover every account that can change or reset the website:
WordPress administrator accounts
hosting control panels and file access
the company that registers your domain
the DNS settings that route your domain to the website and email
business email, especially the recovery mailbox
backup storage and the logins that manage it
database and deployment access
Email is an easy link to miss. Whoever controls the recovery mailbox can often reset the website login as well.
In the map, you means the business. Shared means the business and its provider. It's a suggested split. Providers and permissions often overlap.
Staff devices and phishing matter for the same reason. A compromised laptop or mailbox can undo strong website passwords.
Treat any email asking to change bank details or payment instructions with suspicion. ASD's guide recommends calling the sender to confirm, using contact details you already hold.
Control 3: configure and verify multi factor authentication
Multi factor authentication (MFA) asks for a second proof after the password, such as an app code. For a self hosted site, WordPress's two step guidance points to plugins. Two Factor and Wordfence are among its starting points.
MFA on your WordPress.org or WordPress.com account is separate. It doesn't protect the login on your own installation. A hosting dashboard MFA switch protects the hosting account, not necessarily WordPress admin.
The guidance warns that "SMS is not a secure communication channel". ASD recommends "turning on phishing-resistant MFA, such as passkeys". Where passkeys aren't supported, it suggests another method, such as an authenticator app.
Check which of these is true:
State | What it means |
|---|---|
Installed | The MFA plugin or integration is active |
Enrolled | A user has set up a second factor |
Enforced | The site requires it for the roles you chose |
The Two Factor plugin is one focused option, with authenticator app, email and backup codes. Its FAQ says "there are no built-in enforcement settings" for roles or users.
Test enrolment and enforcement on every login route before you rely on MFA. Then test recovery without locking out the only administrator. Store recovery codes where the business controls access, never in shared project documents or ordinary email.
Check the login still works for staff who use assistive technology. Our guide to accessible authentication and forms covers what to test.
Control 4: limit human and integration access
Give every person a named account and only the access their work needs. WordPress roles differ a lot. An Administrator on a single site controls everything, from plugins and themes to users and core updates. An Editor manages all posts. An Author manages only their own.
Plugins can change these permissions. Confirm what each account can actually do. Remove access promptly when a person or supplier leaves.
Integrations need their own inventory. Typical examples:
WordPress Application Passwords
API keys that let other software connect to the site
deployment keys used to push code changes
access tokens for third party services such as forms or payments
WordPress's REST API documentation treats these routes separately. The REST API is how other software reads and changes site content. The normal browser login covers people working inside WordPress. Application Passwords, available since version 5.6, let outside applications connect.
Those connections don't go through the login screen. A login MFA prompt may not cover them. Record each one:
Service: [integration and business purpose]
Owner: [the person responsible for this credential]
Access: [permissions granted and which environment]
Storage: [where it's kept, such as a password manager]
Review: [last use, support and renewal checks]
Revoke: [safe procedure and dependency test]
Never paste real passwords, keys or recovery codes into this record or a shared checklist.
Changing a person's password doesn't prove every integration credential or session is revoked. Revoke old credentials deliberately. Then check what depended on them. A common mistake is leaving a former supplier's Application Password active after the work ends.
Control 5: understand the host's actual security scope
Your host secures only what its contract covers. Ask your host about:
supported server software and how quickly it's patched
how your site is kept separate from other customers
secure file transfer and who holds access
monitoring, backups and restore support
the incident contact and response hours
Managed hosting and a firewall are product features. They don't mean the host manages every plugin or cleans up malware. The hardening guide also notes that "The web server running WordPress, and the software on it, can have vulnerabilities".
Old staging copies count too, along with other sites on the same hosting account. A neglected copy can keep old customer data or an outdated plugin. Agree who secures, retires or isolates it.
A different web address on the same account isn't necessarily separate for security purposes. For questions to ask before you buy, see assessing Australian website hosting.
Control 6: use HTTPS and understand its limit
Check the live site's HTTPS setup, certificate renewal and redirects. Cover the admin login and every customer journey, such as forms and checkout.
HTTPS means this website is safe
HTTPS protects the connection. It doesn't prove the site is trustworthy or free of malware.
Chrome changed the familiar padlock in 2023. The Chromium team announced that Chrome 117 would replace it with a variant of the tune icon. The team said the lock icon doesn't indicate a trustworthy website.
Chrome's help page now calls that control "View site information". A secure connection means information is "private between you and the site". Google still says to "always be careful when you share sensitive or personal information".
Some sites use separate WordPress and site addresses. Don't change both URL settings blindly. Ask your technical owner to check how the site is actually set up. Certificate detail lives in our guide to HTTPS and certificate responsibilities.
Control 7: select a coordinated security setup
Start from what your host and existing tools already provide. Then fill the gaps. Security tools do different jobs:
a firewall filters traffic before it reaches the site's code
malware scanning looks for known signs of infection
login protection limits password guessing
vulnerability alerts flag known flaws in installed software
activity records log who changed what and when
Run overlapping security plugins only with a reason and a compatibility plan. Equally, don't expect one plugin to cover every layer. The next section compares what four named options document.
Control 8: remove unnecessary or unsupported components
Keep a component inventory with these fields:
Field | Why it matters |
|---|---|
Purpose | Shows whether the site still needs it |
Source and supplier | Shows where updates come from |
Owner | Names who decides on changes |
Support status | Flags abandoned or end of life software |
Licence | Confirms updates will keep arriving |
Dependencies | Shows what breaks if it's removed |
Check dependencies before deleting anything. An active child theme, a customised layer built on a parent theme, needs that parent. Must use plugins and platform integrations need a deliberate review too.
Deactivating a plugin isn't the same as deleting it. Its files stay on the server. WordPress's hardening guide, linked above, says to delete any plugin you aren't using. Do that once the dependencies are clear.
Get software from legitimate, maintained sources. The hardening guide says "Do not get plugins/themes from untrusted sources". Plugins from the official directory still need security updates. Paid plugins need updates too. Plugin count alone tells you little about security.
Control 9: protect public entry points and stored information
Review every place the public can send something to the site:
contact and quote forms
comments and account registration
password recovery and site search
file uploads
integrations that accept incoming data
Add proportionate controls such as validation and limits on repeated submissions. Spam filters and bot checks can help too. Test them with real users and real error messages. Then confirm emails still arrive.
A CAPTCHA, the puzzle that checks you're human, isn't malware protection. Check any bot test for accessibility. For layout and error messages, see usable forms and error handling.
File uploads need more than a check of the file extension. OWASP's file upload guidance says to allow only safe, business critical file types. It warns "don't trust the Content-Type header as it can be spoofed". It also recommends:
letting the application generate file names
setting a size limit for uploads
storing files outside the public web folder
letting only authorised users upload
The aim is that an uploaded file can never run as code on your server. Your developer should adapt and test these for your site. Don't make every upload publicly reachable by default.
Stored information needs the same care. Review what the site keeps, such as form entries and exports. Database dumps, logs and staging copies count too. Collect only what you need. Decide who can see it and how long it's kept.
An unlinked file or a private page doesn't protect the underlying file. Neither does a noindex tag, an instruction for search engines to leave a page out. Anyone with the file's address may still open it. For the legal side, see privacy coverage and website information handling.
XML-RPC is a remote interface that lets outside software manage posts, media and comments. Keep it on only where something needs it. Turn it off as a tested change, after checking what relies on it.
Don't disable the REST API across the board, though. The block editor and integrations may depend on it. Protect the real login and permission paths instead.
Choosing a security plugin
A security plugin is one layer. Choose it for the gaps your host and other tools leave.
Option | Main documented jobs | Limit to know |
|---|---|---|
Wordfence Security | Firewall inside WordPress, malware scan, login security | Free rules arrive 30 days late |
Kadence Security | Login security and site scans | Scans for known flaws, not every file |
Sucuri Security | Activity logs and a remote scan | Scan sees what visitors see |
Two Factor | App, email and backup codes | No built in role enforcement |
A few details sit behind those cells, as listed in October 2026:
Wordfence also offers two factor login and passkeys. Its free version delays new firewall rules and malware signatures, the patterns its scanner looks for. The delay doesn't apply to every update.
Kadence Security was formerly Solid Security, and before that iThemes Security. It adds two factor login, password rules and limits on password guessing. Its scan checks known vulnerabilities and Google's list of unsafe sites. Patching and user logs need the paid version.
Sucuri Security also detects changed files and warns if major services list the site as unsafe. Its remote scan reaches the site the way a regular visitor would. The firewall is a paid service.
These are examples, not endorsements or a tested ranking. You don't need all of them. Before installing one, check its current version and licence terms. Then check its privacy terms and compatibility with your host.
A product can cover several jobs, each imperfectly. No product label proves complete coverage.
A web application firewall (WAF) inspects incoming web traffic and can block requests that match its rules. Where it sits and which rules it runs decide what it catches. It doesn't replace patching or access control.
A malware scan looks for signs within its scope. A clean result means that check found nothing at that time. It doesn't prove the site is uncompromised. Ask what's scanned, how fresh the signatures are and who investigates alerts. Ask how it handles false alarms too.
Coverage: [controls and systems included]
Limits: [free, paid, remote and local scope]
Updates: [rules, signatures and software updates]
Owner: [who reviews and acts on alerts]
Test: [compatibility, customer tasks and recovery]
Exit: [removal steps and what would replace it]
Use the record to compare a proposal with what your host already does. Test key customer tasks after setting up any tool. Don't publish dashboard screenshots that show user names or IP addresses.
Backups that support recovery
Backups make recovery possible. Keep copies somewhere that won't fail or be compromised along with the live site. A folder in the same hosting account doesn't count.
WordPress's backup documentation says a backup has two parts, the database and the files. You need both to restore the site fully. WordPress suggests treating them as one backup set, taken around the same time. Our guide to backups and restore testing covers what to include and how often.
Set backup frequency against those answers, not against the type of site you run.
Test a restore somewhere safe. Record what came back and how long it took. Note which customer tasks you checked afterwards.
Pick the restore point carefully, because a compromise can start well before anyone notices. Keep the orders and enquiries made since that point. Account changes need reconciling too.
Backups help you recover but don't prevent data theft or undo exposure that's already happened. A restored site can still need an incident and privacy assessment.
Monitoring that leads to action
Monitoring only helps when someone acts on what it finds. Match each signal to an action:
Signal | What to do |
|---|---|
Unknown admin or access change | Verify it via a trusted route, then escalate |
Security notice or failed update | Find the component, urgency, exposure and owner |
Suspicious files, redirects or content | Investigate the scope before deleting anything |
Uptime or journey failure | Test the real task. A normal response isn't proof |
Backup failure | Fix the process and confirm usable restore points |
Search Console security warning | Investigate, and request review only after cleanup |
Changed payment or contact details | Confirm approval, then check where enquiries and money go |
Every important alert needs:
a primary recipient and a backup recipient
a severity rule and an expected response time
an investigation record
evidence before anyone closes it
Keep those contact details somewhere you can reach if the website or main email is down. A common mistake is sending every alert to one person's inbox with no backup.
Analytics can show odd traffic patterns. It isn't a security audit or a substitute for logs.
Observed: [signal, time and source]
Scope: [affected service and known facts]
Priority: [likely impact and what's still uncertain]
Owner: [primary and backup contact]
Action: [containment, investigation or repair]
Closure: [retest evidence and remaining limits]
Keep real personal information, IP addresses and secrets out of any shared copy of this record.
Search Console's Security issues report flags hacked content and malware that Google has found. It also covers social engineering, such as deceptive pages. Because its sample URLs may not be complete, fix every affected page before requesting a review. No warning isn't proof of a clean site.
Read security evidence honestly
Each kind of evidence shows something different:
Evidence | What it shows | What it doesn't show |
|---|---|---|
Failed login | Someone tried a password | That they got in |
Blocked request | A rule stopped a request | That the rule alone prevented harm |
Scanner finding | A known sign in the scan's scope | The full extent of a problem |
Confirmed compromise | Proof of unauthorised access | The data involved, until assessed |
Requests aren't the same as attackers, because one source can send many. Report blocked requests separately from confirmed incidents.
When a provider quotes attack numbers, ask how they were counted:
the period and time zone covered
how many sites were included
the exact definition of an event
the data source and tool settings
how duplicates and false alarms were handled
Never upload full customer or security logs to a public checking tool.
A practical maintenance schedule
A routine keeps controls working. Urgent events always come first.
When | What to do |
|---|---|
Critical fix or active exploitation | Assess it promptly. Don't wait for the monthly slot |
Unexpected admin access or suspected compromise | Follow the incident plan straight away |
Ongoing automated checks | Watch uptime, backups, updates and alerts, with a named owner |
Regular review | Confirm backups and updates worked, then test an enquiry or sale |
Monthly maintenance | Review the inventory, open alerts and stale integrations |
Quarterly, or after staff changes | Test a restore and account recovery, and review access |
Renewals and major changes | Confirm domain, hosting and licences. Recheck after a rebuild |
This is a suggested routine, not a legal timetable or a service level agreement. Adjust it for your exposure, your staff and how many transactions you handle.
Each quarter, also rehearse who calls whom if something goes wrong. Don't wait for the quarter to remove a departing person's access.
For new releases, use our manual website launch checklist. It's a manual tool. It isn't a penetration test, where specialists try to break in with permission. It isn't a security certification either.
Big changes need their own plan. Our redesign guide covers security checks during a redesign, from release responsibilities to launch day.
Our free audit checks your updates, plugins, logins and backups, then tells you what to fix first.
What to do if you suspect a compromise
Stay calm and work through a sequence. These signs are worth investigating:
Sign | What to check first |
|---|---|
Unknown administrator accounts | Who created them, when and with what access |
Changed payment or contact details | Where enquiries and money now go |
Unexpected redirects or spam pages | Which pages and templates are affected |
Browser or search warnings | The issue Google or the browser reports |
Unfamiliar files or a hosting suspension | What the host found and when |
Odd messages from customers | What they received and who it came from |
Treat these as reasons to investigate, not proof of the cause.
The steps can overlap. Containment shouldn't wait for perfect evidence. Legal assessment shouldn't wait until the homepage looks normal. Get competent help when the scope or data exposure is unclear.
Contain harm and keep evidence
Contact your host or incident specialist using details you already know. Record what you noticed and when. If an account may be compromised, use a clean device and a safe channel. If you switch off a form or checkout, give customers another way to reach you.
WordPress's hacked site FAQ says to document what you see and scan your own computer. It warns "The hack may have affected more than just your site, especially if you are using shared hosting".
Keep logs, snapshots and messages somewhere secure, with their timestamps. Don't delete files at random or overwrite the only evidence in a rush to restore. A common mistake is deleting suspicious files before anyone has copied the logs.
Find the full scope
Work out how they got in and whether they left persistence, a hidden way back in. Look beyond the website itself:
other sites on the same hosting account
old staging copies
staff devices and email accounts
integrations and their credentials
A clean looking homepage doesn't show whether the attacker still has another route in. Start any privacy assessment alongside the technical work.
Rotate credentials in order
Change credentials in a planned sequence. Changing database, API or mail credentials can break legitimate services. Update whatever depends on them. Then check it all works.
Revoke active sessions and old tokens deliberately. A WordPress password reset doesn't fix a compromised mailbox or hosting account. WordPress's hacked site guidance also says to change passwords again once the site is clean.
Restore without bringing the problem back
Don't restore a vulnerable or already compromised backup and call the job done. Close the entry route first and check for persistence. Ask the specialist whether a clean rebuild beats piecemeal cleanup.
Preserve the orders, enquiries and account changes made after the restore point. Before reopening, test customer tasks and integrations. Check payment details and permissions too.
Communicate what you know
Separate known facts from open questions in customer updates. Don't claim no data was accessed just because the database works or a scan came back clean. Notification decisions sit with the business and its adviser.
Learn from it
Watch closely for the problem coming back. Record the cause and every action taken. Then fix the controls that failed or were missing.
Australian reporting and data breach duties
Reporting a cybercrime and notifying a data breach are separate jobs. Doing one doesn't complete the other.
ASD's ransomware reporting guidance says to report cybercrimes, security incidents and abuse through ReportCyber. Its Australian Cyber Security Hotline is 1300 CYBER1 (1300 292 371).
Privacy notification is a different question. First check whether the Privacy Act covers your business. The OAIC says the Act generally doesn't cover a small business with turnover of $3 million or less. Some are covered regardless, such as health service providers and businesses that trade in personal information. Our guide to Australian privacy law changes for websites explains which businesses are covered.
Don't assume your position from size alone. Contracts, sector rules or overseas laws may add duties of their own.
The OAIC's quick reference guide explains when a breach is eligible. The unauthorised access, disclosure or loss must be likely to cause serious harm to someone. Remedial action must also have failed to prevent that likely harm. Not every hack meets this test.
The OAIC's scheme guidance says the assessment of a suspected breach must be "reasonable and expeditious". Entities must take all reasonable steps to finish it within 30 calendar days. The OAIC expects 30 days to be treated as a maximum. It isn't a grace period before acting.
Once a breach is clearly eligible, notify the OAIC and affected people as soon as practicable. Some exceptions apply. Don't wait for day 30 if eligibility is clear earlier. A useful notice tells people what they can do to protect themselves.
This section is general information. Get qualified advice on a real incident and on the wording of any notice.
Responsibilities and care plan scope
Name one accountable person in the business, even when suppliers do the work. Then record who does each task. The example below shows the shape. Swap in your own names.
Updates
Backups and restore tests
Access and offboarding
Integration credentials
Monitoring and alerts
Domains and certificates
Incident escalation
Our web design page describes optional ongoing care after launch. It covers:
software, plugin and security updates, tested before they go live
regular backups you can restore from if anything goes wrong
page speed and Core Web Vitals checks
help and changes from the people who built the site
The plan is optional, with no lock in. You can also manage the site yourself after handover, with training and notes. Ongoing costs are separate from the build price.
That public summary isn't a full incident response schedule. Before relying on any plan, ours included, confirm the details in writing:
Area | What to confirm |
|---|---|
Updates | What's covered, urgency, testing and failed updates |
Backups | Scope, frequency, retention, separate storage and restores |
Monitoring | Tools, signals, alert owner, hours and escalation |
Incident response | Whether investigation, cleanup and restores cost extra |
Support | Hours, after hours cover and response versus fix times |
Accounts and suppliers | Ownership, recovery, dependencies and offboarding |
Use the public description as a starting point when confirming the website care plan scope. This draft email covers the main questions:
Subject: Website security responsibilities for [business name]
Please confirm which updates, backups and restore tests our plan includes.
Who monitors the site and receives urgent alerts, and what response hours apply?
Is investigation or malware cleanup included, or charged separately?
What stays our responsibility, and how do we recover access if you're unavailable?
Please list the exclusions and the evidence we'll receive after each task.
Be wary of any plan promising unlimited cleanup or guaranteed response times without a written schedule. Changing supplier? Follow our steps for website handover and access removal.
Prevention and incident cost example
Prevention and incident costs are different kinds of money. This example keeps them apart. The figures are assumptions in AUD, not market prices or an Elev8d care plan.
Example item | Calculation | Amount |
|---|---|---|
Annual preventive care allowance | $180 × 12 months | $2,160 a year |
Incident investigation | 5 hours × $180 | $900 |
Technical cleanup | 8 hours × $160 | $1,280 |
Recovery and verification | 4 hours × $150 | $600 |
Owner and staff response time | 10 hours × $75 | $750 |
Assumed lost contribution | 6 hours × $120 | $720 |
One incident's modelled impact | $900 + $1,280 + $600 + $750 + $720 | $4,250 |
The external technical fees total $2,780 excluding GST. The $750 of staff time and $720 of lost contribution are economic assumptions, not supplier invoices. Don't add GST to the whole $4,250.
Lost contribution is the margin you'd have earned on lost sales, not the full sale price. If delayed sales come back later, the real loss is smaller. The example isn't a forecast of your risk.
The $2,160 allowance is a separate yearly provision, not part of the $4,250. Because a year of care and one incident are different units, the comparison proves no saving or payback.
Prevention reduces risk but can't rule out an incident. A business can end up paying for both. The example leaves out:
legal advice and notification costs
specialist forensics beyond the assumed hours
payment fraud losses
data recovery complications
longer term disruption
Real quotes need a defined scope, support hours and exclusions. For budgeting, see ongoing WordPress maintenance scope and costs.
Final checklist and common mistakes
Use this as a working list. Give each line an owner and some evidence.
Area | Check |
|---|---|
Accounts | Unique passwords, enforced MFA and safe recovery everywhere |
Software | Supported versions, with an owner for urgent fixes |
Integrations | Application Passwords and API keys recorded and owned |
Hosting | Scope confirmed, with staging copies secured or retired |
Data | Uploads restricted, stored entries limited and protected |
Recovery | Separate backups, a tested restore and agreed data loss |
Monitoring | Every alert has two owners and closure evidence |
Don't turn the list into a score that certifies the site as secure. For a wider website health review, use our DIY audit checklist alongside it.
Waiting a month for an urgent patch
Apply critical fixes on their own timeline, not the maintenance calendar's.
Sharing one admin account
Give everyone a named account.
Installing software from untrusted sources
Use legitimate, maintained sources, and keep paid plugins updated too.
Giving people more access than they need
Match each role to the work, and review it when people change.
Keeping unsupported components
Replace or remove anything that no longer gets security fixes.
Treating HTTPS as proof of safety
HTTPS protects the connection. Check the site itself separately.
Keeping backups where the same failure can reach them
Store copies where a hosting or account compromise can't reach them.
Never testing recovery
Run a test restore and record what came back.
Ignoring email account security
Protect the recovery mailbox as carefully as WordPress admin.
Restoring without closing the entry route
Find and fix how the attacker got in before you restore.
What we recommend at Elev8d
Treat security as a routine with owners, not a product you buy once. Patch quickly when it matters. Protect the accounts behind the site, and test recovery before you need it. If something looks wrong, contain it and keep the evidence. Check your privacy duties at the same time.
Frequently asked questions
Does self hosted WordPress include enforced two factor authentication?
Don't assume it does. WordPress's own two step guidance points to plugins for it. Installing one doesn't enforce it. Check enforcement for every role you chose.
Is a free security plugin enough?
It can be part of a sound setup. Check what the free tier leaves out, such as Wordfence's 30 day delay on new firewall rules. Someone also needs to act on its alerts.
Should I turn on automatic updates?
Usually, yes. ASD's small business guide recommends them. Make sure someone reads the success and failure emails. Keep a way to roll back, and test key tasks afterwards.
Does a clean malware scan mean the site is safe?
No. It means that scan found nothing within its scope at that time. A remote scan only sees what a visitor sees.
Does a hack always need an OAIC notification?
No. Notification applies when a covered business has an eligible data breach likely to cause serious harm. Assess any suspected breach promptly and get advice.
Is malware cleanup included in a care plan?
Only if the written schedule says so. Our public care description covers tested updates and restorable backups. It doesn't list incident cleanup, so confirm that and any charges first.
Next steps
Pick the situation that fits. For the bigger picture, see running a small business website.
Nobody owns security yet
Name who receives urgent alerts and updates. Then check MFA and recovery on email, hosting and WordPress.
You want ongoing care
Agree a written maintenance scope, including incident handling and any charges.
You suspect a compromise now
Contact your host or specialist through a known channel. Contain harm, keep evidence and start the privacy assessment.
