---
id: 13462
title: "WordPress Security Audit: What It Should Cover and How to Hire One"
slug: "wordpress-security-audit"
lang: "en"
url: "https://heshamsaad.com/en/wordpress-security-audit/"
markdown_url: "https://heshamsaad.com/en/wordpress-security-audit.md"
translations: {"ar":"https://heshamsaad.com/ar/wordpress-security-audit/"}
description: "WordPress security audit for business sites: what it should check, what the report must include, a 30-minute self-check and how to hire a provider."
author: "Khadija"
date_published: "2026-10-18T17:00:00Z"
date_modified: "2026-10-21T14:50:36Z"
categories: ["Security & Maintenance"]
tags: ["Website Security","WordPress Maintenance","WordPress Security","WordPress Security Audit"]
featured_image: "https://heshamsaad.com/wp-content/uploads/2026/10/wordpress-security-audit-og-en.jpg"
word_count: 2954
reading_time_min: 15
content_sha256: "a60f8b584e62baf16c67d6072591455ff2c3fb159651847e428e69acb44fc7cd"
---

# WordPress Security Audit: What It Should Cover and How to Hire One

A WordPress security audit is a structured check of everything that keeps your business site safe: the software versions, the plugins, who has access, how the server is set up, and whether you could recover if something went wrong. Most owners in Egypt, Saudi Arabia and the Gulf only think about security after a warning from Google or a strange admin account shows up. An audit done before that day is cheaper, calmer and tells you exactly what to fix first.

This guide explains what a proper audit should cover, what the final report should look like, what you can check yourself in half an hour, and how to judge a provider before you hand over access. If you would rather have someone run it for you, our [WordPress security and care service](https://heshamsaad.com/en/wordpress-development/) includes audits for business sites and WooCommerce stores. Either way, the checklist below is worth reading first so you know what you are paying for.

## What a WordPress security audit is, and what it is not

People use the word "audit" for very different jobs, and that is where many disappointing purchases start. Before you ask for a quote, it helps to separate four things:

- A security scan. An automated tool checks your site from outside, or from a plugin inside, and lists known problems. It is fast and useful, but it only finds what it was built to look for.
- A security audit. A person reviews the whole setup, uses scanners as one input, and checks the things tools cannot judge, such as who should still have admin access or whether your backups are stored somewhere safe. The output is a written report with priorities.
- A malware cleanup. This is emergency work after a site is already infected. If that is your situation, our guide on how to [fix a hacked WordPress site](https://heshamsaad.com/en/fix-hacked-wordpress-site/) is the right starting point, and an audit comes after the cleanup.
- A penetration test. A tester actively tries to break in, usually against custom code or a web application with its own features. For a typical company site or store built on well known plugins, a full penetration test is often more than you need. For custom portals and member areas, it may be worth it.

A good audit sits in the middle: deeper than a scan, calmer than an emergency cleanup, and focused on the risks a WordPress business site actually faces.

## When a business site should get an audit

You do not need an audit every month. Ongoing maintenance handles the routine work. An audit makes the most sense at specific moments: An urgent server-level flaw like [php2shell](https://heshamsaad.com/en/php2shell-php-vulnerability/) is also a good reason to check that the PHP version and patches are covered.

- You took over a site from a previous developer or agency and do not know what was installed or who still has access.
- You are about to add online payments, a booking system or a customer account area.
- A staff member, freelancer or agency that had admin access has left.
- The site was hacked and cleaned, and you want to confirm nothing was left behind and the original entry point is closed.
- You are preparing a big campaign, a launch season or a redesign and cannot afford downtime.
- Nobody has looked at the site properly for a year or more.

## WordPress security audit checklist: what a proper audit covers

The areas below come from the WordPress Advanced Administration handbook on hardening, the official requirements page, and the tools WordPress itself provides. A provider may group them differently, but each one should appear somewhere in the work.

### 1. Software versions and support status

The WordPress security page states that only the latest version of WordPress is officially supported. The security team does backport fixes to older versions as a courtesy, but you should not plan around that. The auditor should record your WordPress version, your PHP version and your database version, and compare them with what is supported today.

PHP matters more than many owners expect. According to php.net, each PHP branch gets two years of active support and then two more years of security fixes only, after which it reaches end of life. At the time of writing, PHP 8.2 receives security fixes until 31 December 2026, and 8.3 until 31 December 2027. WordPress recommends PHP 8.3 or newer, MariaDB 10.11 or newer or MySQL 8.0 or newer, and HTTPS support. If your host is still on an end-of-life PHP version, that finding belongs near the top of the report.

### 2. Plugins and themes

Plugins and themes make up most of the code on a typical business site, so this part of the audit usually produces the most findings. The auditor should check each installed plugin and theme, including inactive ones, for:

- Known vulnerabilities in the installed version, using a public vulnerability database such as WPScan or Patchstack.
- Status on WordPress.org. The plugin directory shows a notice when a plugin has been closed, and one of the listed reasons for closure is a security issue. It also warns when a plugin has not been tested with the last three major WordPress releases.
- Where it came from. The hardening handbook advises getting plugins and themes only from the WordPress.org repository or well known companies. Pirated "nulled" copies of premium plugins come from exactly the kind of untrusted source it warns about, and should be replaced with licensed copies.
- Whether it is still needed. Every inactive or duplicate plugin is code that can still be attacked. Removing it is often the easiest fix in the whole report.

### 3. File integrity

An auditor with server access can compare your files with the official versions. WP-CLI, the official command line tool, has `wp core verify-checksums` for WordPress core files and `wp plugin verify-checksums` for plugins from WordPress.org. Any modified or unexpected file is a lead to investigate. Premium plugins and custom code are not covered by these checksums, so they need a manual look.

### 4. Users, roles and access

This is the part that scanners handle worst and owners care about most. WordPress has built-in roles such as Administrator, Editor and Author, each with different capabilities. The audit should list every account with administrator access and ask a simple question for each one: does this person still need it?

- Old developer and agency accounts that were never removed.
- Shared logins used by several staff members, which make it impossible to know who changed what.
- Application passwords. The WordPress handbook recommends one per integration and revoking any that are no longer needed.
- Access outside WordPress: hosting panel, domain registrar, DNS provider such as Cloudflare, email, and payment gateway dashboards. Losing control of the domain is often worse than losing the site.

Login protection belongs here too: strong passwords, two-factor authentication for admins, and limits on repeated login attempts. We cover each method in our guide on how to [secure WordPress login](https://heshamsaad.com/en/secure-wordpress-login/).

### 5. Configuration and settings

A few settings in `wp-config.php` and on the server make a large difference:

- Debug output. The WordPress debugging handbook says debug tools are not recommended on live sites. The Site Health screen flags a site that displays errors to visitors, or logs them to a file that may be publicly reachable, because these can expose sensitive information.
- File editing from the dashboard. Setting `DISALLOW_FILE_EDIT` disables the plugin and theme file editor. The handbook describes it as an extra layer of security if an attacker gains access to a privileged account.
- File permissions. The hardening guide warns that letting the web server write to files is potentially dangerous, especially on shared hosting.
- Site Health. The built-in Tools, Site Health screen groups findings into critical issues, recommended improvements and passed tests. Its security items, such as outdated PHP or plugins waiting for updates, are a quick baseline for the audit.

### 6. Hosting, HTTPS and the server

The hardening handbook is direct about shared hosting: if another site on the same server is compromised, yours can be affected even if you follow every other step. The auditor should note what kind of hosting you use, whether the host isolates accounts, whether PHP and the web server are current, and whether a web application firewall sits in front of the site.

HTTPS should be on for every page, including the admin area. Response headers are worth checking as well. For example, the Strict-Transport-Security header tells browsers to use HTTPS only for your domain, and on later visits browsers will not let users click through certificate errors.

### 7. Backups and recovery

An audit is not finished until someone answers this question: if the site disappeared today, how long would it take to bring it back, and from what? The auditor should confirm that backups include both files and the database, run on a schedule, are stored away from the hosting account, and have been restored at least once as a test. Our step-by-step guide to [back up and restore WordPress](https://heshamsaad.com/en/wordpress-backup-restore/) explains what a tested backup looks like.

### 8. Google signals and monitoring

Google Search Console has a Security Issues report. Google's documentation calls it the source of truth for whether security issues exist on your site or have been fixed, because browser warnings may not appear for every visitor. The audit should confirm that Search Console is set up, someone receives its emails, and the report is clean. Uptime monitoring and alerts for new admin users or file changes complete the picture.

### 9. Payments and customer data

If you run a WooCommerce store, WooCommerce's own documentation says PCI DSS compliance is ultimately the store owner's responsibility. Using a gateway that handles card details off-site or through hosted fields reduces your scope, but because your site still serves the checkout page, PCI DSS still applies. The audit should check how card payments are collected and whether forms or plugins store customer data you do not need.

## What the audit report should include

The report is the product you are paying for. A long list of scanner warnings with no priorities does not help a business owner decide anything. Ask for these sections:

<figure class="wp-block-table">

| Section | What it should tell you |
|---|---|
| Summary for the owner | One page in plain language: the overall state, the three to five most urgent issues, and what happens if they are left. |
| Findings with severity | Each issue rated (for example critical, high, medium, low), with the evidence: version numbers, screenshots, file paths or settings. |
| Fix steps | What to change, who should do it (you, your host or a developer), and whether the fix needs testing on staging first. |
| Access review | A list of every account with admin, hosting, domain and DNS access, marked keep or remove. |
| Recovery status | Where backups live, how often they run, and when a restore was last tested. |
| Retest | A short follow-up check after fixes are done, so findings are closed with proof rather than promises. |

</figure>## Automated scan or manual audit?

Scanners are part of any good audit, but they are not the audit. The comparison below shows where each one fits.

<figure class="wp-block-table">

| Question | Automated scan | Manual audit |
|---|---|---|
| Finds known plugin and theme vulnerabilities | Yes, if the database is current | Yes, using the same databases |
| Judges whether an admin account should exist | No | Yes |
| Checks domain, DNS and hosting access | No | Yes |
| Confirms backups can be restored | No | Yes |
| Reviews custom code and premium plugins | Limited | Yes, within agreed scope |
| Gives business priorities | No | Yes |

</figure>## A 30-minute check you can do yourself

Before you pay anyone, spend half an hour on these steps. You will either feel confident the site is in decent shape, or you will have a clear list to show a provider.

1. Open Tools, Site Health and read every critical issue and every item marked Security.
2. Go to Users and filter by Administrator. Write down every name you do not recognize or who no longer works with you.
3. Open Plugins and note anything with an update waiting, anything inactive, and anything you cannot explain.
4. In your profile, check the Application Passwords section and revoke any you do not use.
5. Log in to Google Search Console and open the Security Issues report.
6. Ask your host where backups are stored and when one was last restored.
7. Check who controls the domain registrar and DNS accounts, and that two-factor authentication is on for both.

## How to hire a WordPress security audit service

Some providers sell this as a WordPress security service, a health check or a one-time security review. The name matters less than the scope, so compare offers by what they actually check and what you receive at the end.

### Questions to ask before you agree

- What exactly is in scope: WordPress only, or hosting, domain, DNS and email too?
- Will you work on a staging copy, or on the live site? What is your plan if something breaks?
- Which tools and vulnerability databases do you use, and what do you check by hand?
- Can I see a sample report with client details removed?
- Are fixes included, or quoted separately after the report?
- Is a retest included after the fixes?
- How will you receive access, and when will it be removed?

### How to give access safely

Create a separate, named account for the auditor instead of sharing your own login, and give it only the access the work needs. Agree in writing when the account will be deleted, then delete it. Never send passwords in plain chat messages or email. A password manager share or a temporary account is safer for both sides.

### Red flags

- Promises that your site will be "100% hack-proof". No honest provider can guarantee that.
- A report that is only a scanner export, with no priorities and no explanation.
- Installing several new security plugins on the live site without a backup or a plan.
- Asking for your main administrator password instead of a separate account.
- No clear answer about who fixes what, and at what cost.

## What affects the cost of an audit

Prices vary widely between providers and countries, so ask for a written quote based on your actual site. These are the factors that usually change the effort involved:

- The number of sites, and whether it is a bilingual setup with extra plugins.
- The number of plugins, and how many are premium or custom built.
- Whether the site is a WooCommerce store with payments and customer accounts.
- Whether server access is available, which allows file integrity checks.
- Whether fixes and a retest are part of the job or only the report.

## After the audit: keep it fixed

An audit is a snapshot. A week later a plugin may publish a new vulnerability, and a month later someone may add an admin account "just for today". The fixes need an owner. For most businesses that means a maintenance arrangement with updates, backups, monitoring and a short monthly report. Our guide to choosing a [WordPress care plan](https://heshamsaad.com/en/wordpress-care-plan/) explains what that should include and what to compare between providers.

## Frequently asked questions

### How often should a business site be audited?

A full audit once a year is a sensible baseline, plus an extra one after any of the events listed above, such as a developer leaving or a hack cleanup. Routine checks in between belong to regular maintenance.

### Is a security plugin enough?

A security plugin is one useful layer. It does not review who has access to your domain or hosting, whether your backups can be restored, or whether a plugin was closed on WordPress.org. Those need a person.

### Will the audit slow down or break my site?

A careful audit should not. Most checks are read-only. Anything that changes the site, such as updates or removing plugins, should happen after a backup and, ideally, on staging first.

### Do I need a penetration test instead?

For a typical company website or store built on established plugins, an audit usually covers the real risks. If you run custom code, a member portal or handle sensitive data, ask whether a penetration test of those parts makes sense as well. The OWASP Web Security Testing Guide is the common reference for that kind of testing.

## Your next step

If you want a WordPress security audit with a clear report and fixes you can trust, tell us what the site runs on, roughly how many plugins it has, and whether it takes payments. You can start from our [WordPress maintenance and security](https://heshamsaad.com/en/wordpress-development/) page or book a [free consultation](https://heshamsaad.com/en/free-consultation/), and we will tell you honestly whether you need a full audit or just a few quick fixes.

## References

- [Hardening WordPress, Advanced Administration Handbook](https://developer.wordpress.org/advanced-administration/security/hardening/)
- [WordPress security](https://wordpress.org/about/security/)
- [WordPress requirements](https://wordpress.org/about/requirements/)
- [PHP supported versions](https://www.php.net/supported-versions.php)
- [Plugin directory alerts and warnings](https://developer.wordpress.org/plugins/wordpress-org/alerts-and-warnings/)
- [wp core verify-checksums](https://developer.wordpress.org/cli/commands/core/verify-checksums/)
- [wp plugin verify-checksums](https://developer.wordpress.org/cli/commands/plugin/verify-checksums/)
- [Roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/)
- [Application passwords](https://developer.wordpress.org/advanced-administration/security/application-passwords/)
- [Debugging in WordPress](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/)
- [Editing wp-config.php](https://developer.wordpress.org/advanced-administration/wordpress/wp-config/)
- [Site Health screen](https://wordpress.org/documentation/article/site-health-screen/)
- [Strict-Transport-Security header, MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security)
- [WordPress backups](https://developer.wordpress.org/advanced-administration/security/backup/)
- [Security Issues report, Search Console Help](https://support.google.com/webmasters/answer/9044101)
- [PCI-DSS compliance and WooCommerce](https://woocommerce.com/document/pci-dss-compliance-and-woocommerce/)
- [WPScan](https://wpscan.com/)
- [Patchstack vulnerability database](https://patchstack.com/database/)
- [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)