WordPress Security Audit Checklist for Businesses

Your checkout stalls during the morning sales rush. An administrator login appears from a location nobody recognises, followed by a homepage change no one approved. You need to know who still has access, which file changed, whether the backup can restore the site, and who owns the response. A WordPress security audit checklist should make those answers clear.

Growing businesses rarely struggle because they lack another security plugin. The harder problem is knowing what happened, who is responsible, and which controls still work. Your site needs a clear record of user access, software changes, backups, hosting settings, and suspicious activity. Without that evidence and ownership, a security issue can turn into a long search for answers.

A useful audit connects accounts, code, updates, backups, hosting, logs, and incident readiness. That lets you prove what's protected and what needs action. ShieldThemes can help you build, secure, host, and maintain your WordPress site when internal ownership is unclear, although an agency cannot replace clear business accountability. The result should be a defensible working checklist, not another generic list.

How the WordPress security audit checklist is ordered

A scanner may flag a vulnerable plugin, but you still need to know who owns it, whether the finding is real, and whether the fix worked. Without that evidence, your audit produces alerts rather than decisions.

Start with ownership and inventory, then examine code, recovery, infrastructure, and response. Pantheon recommends combining manual checks with automated scans in a WordPress security audit rather than relying on either method alone.

The steps in a security audit checklist

The steps move from inventory and identity to code and updates, backup recovery, hosting and configuration, and finally logs and incident response. Each stage provides evidence for the next. You cannot assess an abandoned administrator account properly if you haven't identified every account first.

What the audit examines and records

A complete audit combines automated scanning, manual review, activity logs, configuration checks, change records, and restoration proof. Pantheon notes that vulnerability scanning can identify common problems such as SQL injection, cross-site scripting, and insecure file permissions.

• Ownership: Record each account, system, component, and responsible person.
• Technical state: Capture versions, active plugins, themes, hosting settings, and exposed services.
• Activity evidence: Preserve relevant login records, file changes, alerts, and configuration history.
• Recovery proof: Restore a backup in a safe environment and record the result.

Why the sequence starts with ownership and inventory

Inventory gives you scope, while identity gives each finding an accountable owner. A scanner alert is only a lead. A verified fix, assigned owner, and successful retest are audit evidence.

Weak finding: “Outdated plugin detected.”

Verified finding: “The site administrator assigned the WooCommerce payment extension to the technical owner, updated it in staging, tested checkout, and recorded the production retest.”

How each control earns a pass, fail, or follow-up

A control earns pass when you have current evidence and a repeatable result. It earns fail when a required safeguard is absent or ineffective. Use follow-up when you have a credible risk but still need an owner, fix, or retest.

Practical rule: Preserve the finding, owner, evidence, deadline, and retest result before moving to the next audit stage.

1. Inventory every WordPress account, component, and exposed service

Who can still reach your WordPress site, and which parts does nobody own? You need those answers before changing a plugin, removing an account, or tightening a hosting setting.

Every asset needs a named owner and a last-verified date.

Connect each asset to a named technical or business owner. This also exposes abandoned plugins, former employee accounts, staging sites, unknown services, and code installed outside your approved process. Without that connection, your findings remain a list rather than an accountable audit.

What to record before changing anything

Create one shared document or ticketing record for your site. A startup can begin with a spreadsheet. As your business grows, maintain an asset register that records the owner and last-verified date for every entry.

• WordPress stack: Record the core version, active and inactive themes, plugins, custom code, and each component's owner.
• Accounts: List WordPress users, hosting users, database access, SSH keys, agency accounts, and former employee accounts.
• Infrastructure: Record hosting providers, domains, DNS accounts, SSL certificates, administrative panels, and staging sites.
• Services and jobs: Identify scheduled jobs, payment services, email tools, analytics, remote integrations, and unknown services.
• Evidence sources: Note where access logs, server logs, security alerts, and backup records are stored.
• Backup locations: Record each backup destination, its owner, retention setting, and most recent successful backup.
• Unknown values: Mark missing owners, dates, or service details as findings instead of guessing.

Weak entry: “WooCommerce plugin, managed by the web team.” Strong entry: “WooCommerce 9.8.1, production checkout dependency, owned by Jordan Lee, verified March 8, 2026, hosted on WP Engine, logs in the shared security folder.” That detail gives you a person, location, and retest path.

Best use case

Use this register when several people, vendors, or environments touch your WordPress site. It gives you a reliable handoff before remediation starts and keeps each finding attached to someone who can fix or approve it.

Best for

• Startups: A lightweight spreadsheet that captures assets, owners, and verification dates.
• Growing businesses: A maintained asset register connected to tickets and change records.
• Agency-managed sites: A clear boundary between your business owner, technical owner, and service provider.

Trade-offs and the decision rule

Building the register takes time, especially when your hosting, DNS, backups, and development work sit with different providers. That effort is preferable to deleting a needed service or overlooking an account because nobody knows it exists. Use it if every asset and finding has a named technical or business owner before remediation begins.

2. Lock down WordPress accounts, roles, and permissions

You may know which users work on your site, yet still have no proof that every account remains necessary. A former contractor, shared login, or forgotten hosting credential can give someone more control than their current work requires.

Start with access evidence, not a generic password reminder. Pantheon recommends reviewing WordPress roles, requiring strong passwords, and enabling two-factor authentication as part of a security audit. That baseline still needs to connect each permission to a current business duty.

What to check in WordPress and hosting access

Open Users in WordPress and record every administrator, editor, developer, and service account. Then extend the same review to your hosting panel, domain registrar, DNS provider, CDN, database, deployment system, backup platform, and configuration files. For each account, record the person, role, business reason, approver, review date, and removal date if access is temporary.

• Administrator list: You have named owners for every privileged account, with no unexplained shared login.
• Dormant users: You have suspended or removed accounts that no longer support current work.
• Role fit: You have compared each person's actual permissions with current responsibilities.
• Password and MFA: You have required unique passwords and MFA or two-factor authentication wherever each service supports it.
• Approval record: You have preserved who approved elevated access, why it was needed, and when the decision occurred.
• Access retest: You have tested each role in practice rather than relying only on a visual settings review.

Weak example: “WordPress admin: shared by the marketing contractor and developer, password changed when needed.”

Strong example: “WordPress editor: Maya Chen, approved by the operations director on September 12, 2026, with MFA enabled and administrator access removed.”

Best use case

This review fits businesses with contractors, former employees, multiple vendors, or frequent site releases. It gives you permission evidence tied to current duties, so you can remove access that cannot be justified without accusing anyone of wrongdoing.

Best for

• Growing businesses: You need a repeatable approval trail as staff and vendors change.
• E-commerce teams: You must protect checkout, customer data, payment settings, and deployment access.
• Agency-managed sites: You need clear boundaries between your business owner, technical owner, and service provider.

Trade-offs and the decision rule

• What works: Fewer administrators reduce exposure, while time-limited access and an escalation path keep urgent repairs moving.

• What fails: Overly restrictive permissions can delay releases when nobody can approve an emergency change.

Remove access you cannot justify, retain the approval record, and provide temporary elevated access when necessary. Use it if you can retest every role and confirm that each permission still matches the work your business requires.

3. Patch, verify, and remove risky WordPress code

Are your WordPress updates current, trusted, and still compatible with your business? You need more than a green update notice. This audit checks core, themes, plugins, custom code, and their sources before you change anything.

Back up first, test in staging when possible, and approve a release window. After deployment, retest checkout, forms, analytics, email, and custom integrations. The change record proves what you updated, removed, and verified.

What to check in core, themes, plugins, and custom code

• Record versions: You have the current version, source, license, owner, and update date for WordPress core, every theme, and every plugin.
• Prioritize findings: You review known vulnerabilities first, then rank outdated, unsupported, abandoned, nulled, or unused components by business risk.
• Confirm trusted sources: You replace components from unofficial marketplaces with versions from the developer or a reputable commercial source.
• Control the release: You back up the site, test in staging, deploy during an approved window, and keep a rollback copy.
• Verify custom code: You test checkout, forms, analytics, email, APIs, and theme overrides after every relevant update.
• Retest and record: You document the result, removed components, broken dependencies, fixes, and final vulnerability status.

Plugins deserve particular attention. SentinelOne reports that plugins account for 90% of WordPress security issues, compared with 6% in themes and 4% in core software, according to its 2025 security audit. SentinelOne published those figures.

Outdated themes and plugins remain common entry points for attackers, according to Pantheon. Wordfence also advises keeping WordPress core, themes, and plugins current. Those sources support the same maintenance rule.

Weak record: “Updated plugins on June 4. Site looks fine.”

Strong record: “June 4, 2026: WooCommerce 9.8.1 updated in staging, checkout and Stripe tested, production deployed at 10:00 p.m., rollback package stored, and custom order export verified.”

Best use case

This cycle fits your business when updates affect revenue, customer data, or custom functionality. ShieldThemes can review custom code and maintain updates for growing businesses, although complex legacy integrations may still require your original developer.

Best for

• Revenue sites: You protect checkout, subscriptions, bookings, and lead forms from untested changes.
• Custom builds: You verify theme overrides, APIs, scripts, and integrations after patching.
• Lean teams: You preserve a clear record when nobody internally owns WordPress security.

Trade-offs and the decision rule

Testing takes time, and delaying a critical patch carries risk. Removing unused code reduces exposure, but you must confirm dependencies first. Use this cycle if you can preserve a rollback path and retest the business functions that matter most.

4. Prove that WordPress backups can restore the business

Could your team rebuild your WordPress site from its latest backup, or would it only see a successful job notification? You need proof that your store, forms, accounts, and content can return to service when the live site fails.

A useful backup includes the database, uploads, themes, plugins, custom files, and required configuration. It also sits away from the live site and its credentials. The pass condition is a documented restoration test, a named recovery owner, and an agreed data-loss window, not a green dashboard status.

What to verify in backup coverage and retention

• Complete contents: Confirm that the backup contains orders, customer records, posts, uploads, themes, plugins, custom code, and necessary configuration details.
• Separate storage: Verify that copies use separate credentials and cannot be deleted through the same compromised WordPress account.
• Defined schedule: Record when backups run, how long versions remain available, and which business data receives the most frequent protection.
• Protected copies: Check encryption during storage and transfer, restricted access, and a retention policy your business can understand.
• Restoration evidence: Document the test start time, completion time, errors found, corrective actions, and recovery-owner sign-off.

Weak: “The site backs up automatically every night.” Strong: “The WooCommerce store backs up orders and customer data nightly, keeps separate weekly copies, and records a tested restore in a staging environment.”

Best use case

This control fits any business that cannot afford uncertain recovery. An e-commerce store must restore orders and customer data consistently. A startup site may give priority to landing pages, analytics settings, and lead submissions. Ask who initiates recovery, which environment receives the restore, and how much recent data you can accept losing.

Best for

• Revenue sites: You protect checkout records, subscriptions, bookings, and customer details with a tested recovery path.
• Lean teams: You give one accountable owner the steps, access, and authority to begin restoration.
• Regulated or sensitive businesses: You preserve evidence of retention, access controls, and recovery decisions for internal review.

Trade-offs and the decision rule

Separate storage, longer retention, and regular restore tests add cost and administration. A provider's success notification still proves only that a backup job ran. Use this control when you can restore a usable site within your agreed recovery window and know exactly who starts the process.

5. Check file integrity, configuration, and hosting controls

A clean backup does not prove that your live WordPress files are trustworthy. Compare your current site and server against a known-good baseline, then preserve evidence before removing or changing anything suspicious.

Your site administrator can fix some findings. Hosting credentials, firewall rules, and server configuration may require a provider or developer. SSL/TLS encrypts data moving between your site and its users, according to Pantheon, but HTTPS alone does not prove that your application is secure.

What to inspect in files, configuration, and hosting

• Baseline comparison: Record approved WordPress core, theme, and plugin files, then compare current hashes or scan results against that version.
• Unexpected changes: Investigate unfamiliar files, modified templates, administrative scripts, and changes outside approved deployments before deleting anything.
• Permissions: Confirm that file and folder permissions prevent unnecessary writing, and document any exception rather than changing values blindly.
• Configuration: Check database credentials, debug settings, secret storage, HTTPS redirects, and certificate renewal without exposing secrets in tickets or logs.
• Hosting access: Review firewall rules, hosting-panel accounts, remote administration, SSH keys, and the owner responsible for each access path.

Weak example: Your wp-config.php file keeps debugging enabled on the production site, and a scan reports a changed template with no deployment record.

Strong example: Your production configuration disables debugging, stores secrets outside public files, and your approved baseline identifies the changed template for developer review.

When a scan flags SQL injection, cross-site scripting, or insecure file permissions, compare the result with your baseline and deployment records. If the change remains unexplained, preserve logs and consult your host or developer. Your team can also use this guide to remove malware from a WordPress site safely when the evidence points to compromise.

Best use case

This control fits your business when you need proof that application, server, and access changes were approved. You get a clearer escalation path instead of treating every scan alert as a deletion task.

Best for

• Growing stores: You can protect checkout, customer data, and deployment records.
• Regulated businesses: You can retain evidence of exceptions, reviews, and recovery decisions.
• Lean teams: You can assign hosting and development findings to named owners.

Trade-offs and the decision rule

Baseline maintenance takes time, and specialist fixes may add hosting or development cost. Use this control if every exception has a baseline comparison, preserved evidence, and a documented owner before your team changes the live site.

6. Turn WordPress security logs and practices into action

You may discover an unfamiliar login, changed file, or new administrator after the damage has started. Without useful logs, you cannot reconstruct what happened, decide what to contain, or prove which recovery steps your team took.

Connect monitoring with named decisions. Logs create the evidence, while a rehearsed runbook turns that evidence into containment, restoration, communication, and follow-up.

What to monitor and document before an incident

Verify that your site records successful and failed logins, privilege changes, file edits, plugin and theme changes, configuration updates, and unusual administrative activity. You also need a retention rule, protected log storage, alert ownership, and a documented process for reviewing suspicious events.

• Login activity: Your records show successful and failed logins, account names, timestamps, and useful location or device context.
• Administrative changes: You can identify who changed roles, permissions, settings, plugins, themes, or files.
• Alert ownership: Each high-risk alert has a named person responsible for triage and escalation.
• Incident runbook: Your documented steps cover containment, evidence preservation, investigation, restoration, communication, and follow-up.
• Recovery evidence: You record which backup, file comparison, or hosting action supported the restoration decision.

Weak example: “Review security alerts when possible.”

Strong example: “The operations lead reviews administrator login alerts, preserves the related logs, disables confirmed compromised accounts, and opens the incident record before restoration begins.”

Core WordPress security practices

The core practices are least privilege, MFA, timely updates, trusted components, tested backups, HTTPS, logging, monitoring, and rehearsed response. ShieldThemes can maintain the technical runbook and ongoing monitoring, although your business still needs clear owners for customer communication and risk decisions.

“A WordPress audit can support broader control evidence, but it cannot establish SOC 2 compliance by itself.”

What a SOC 2 compliance checklist covers

A SOC 2 compliance checklist is a broader control and evidence framework, not simply a WordPress inspection. Your site audit can support evidence for access control, change management, monitoring, and recovery, but you need wider policies, systems, reviews, and audit procedures to assess SOC 2 compliance.

If an incident involves altered files, the guide to restoring hacked WordPress files safely fits the same recovery workflow.

Best use case

Use this control when your business must show what happened and what you did next. Run a tabletop exercise using a simulated administrator compromise, then document the lesson learned and update the runbook.

Best for

• Growing stores: You can coordinate hosting, development, support, and customer communication during a checkout or account incident.
• Regulated businesses: You can preserve review records and control evidence without claiming that a site audit proves compliance.
• Lean teams: You can assign investigation, restoration, and communication tasks before an emergency creates confusion.

Trade-offs and the decision rule

Logging, retention, alert review, and exercises require time and may add hosting or monitoring cost. Use this control if every high-risk alert has a named owner, preserved evidence, a response decision, and a documented lesson learned.

WordPress security audit checklist comparison for businesses

A free WordPress website checker or plugin scan gives you useful signals, but it cannot show who owns an account, whether a change was approved, or whether your latest backup can restore the store. You need a working view of those gaps before deciding where to spend time or budget.

The table below compares six audit areas through four practical approaches. Use an automated scan as an input, then add manual evidence, restoration testing, or specialist support where the business risk demands it.

The six audit areas at a glance

Option	Best for	Strength	Limitation	Cost
Automated WordPress scanner or website checker	Fast identification of common technical signals	Repeatable scanning for vulnerabilities, suspicious files, and configuration issues	Does not prove account ownership, approvals, restoration capability, or incident readiness	Free or tool-dependent
Manual access and configuration review	Businesses with multiple users, contractors, or hosting services	Connects permissions, ownership, settings, and business requirements	Requires knowledgeable staff and can miss issues without supporting scans	Internal labor
Backup restoration test	Businesses that need evidence they can recover after compromise or failure	Proves whether database and files can become a usable site	Does not assess preventive controls such as MFA, patching, or firewall configuration	Existing backup cost plus testing time
ShieldThemes-assisted security audit	Startups and growing businesses needing review, remediation, and ongoing maintenance	Combines WordPress development knowledge with evidence, fixes, hosting, security, and maintenance support	Requires scoped access, coordination, and a professional services budget	Scoped professional service

What the table reveals about free and assisted audits

An automated checker is a sensible first pass when you need quick technical clues. You still need people to confirm ownership, business impact, approval history, and recovery evidence. A manual review adds that context, while a restoration test answers a narrower question: can you bring back a usable site after failure or compromise?

ShieldThemes can combine those activities with remediation and ongoing maintenance, though an assisted audit requires access, coordination, and a defined budget. The right answer is often layered. Start with the gap that could cause your business the most damage, then add the control that proves you can prevent, detect, or recover from it.

FAQ

What are the steps involved in a security audit checklist

A practical audit checklist starts with an inventory of sites, accounts, plugins, themes, integrations, and data flows. Review permissions, patch status, configuration, logging, backups, restoration, malware indicators, and response plans. Test important controls instead of accepting screenshots as proof, record owners and dates, then rank findings by business impact and assign a due date.

What are the best security practices for WordPress

Use named accounts with the least access each person needs, require multi-factor authentication for administrators, and remove accounts that no longer have a business purpose. Keep WordPress, plugins, themes, PHP, and hosting components patched. Take protected backups, test restoration, enforce HTTPS, monitor changes, and keep a written response plan for stolen credentials or altered files.

What does a security audit consist of

A security audit consists of reviewing assets, identities, permissions, software, configuration, network exposure, backups, monitoring, and incident response. It also includes evidence checks and practical tests, such as restoring a backup or comparing files with a known-good version. The final report should identify gaps, explain their business effect, name an owner, and set a review date.

What is SOC 2 compliance checklist

A SOC 2 compliance checklist is a working record of controls and evidence related to security, availability, processing integrity, confidentiality, or privacy. It may cover access reviews, change management, risk assessments, vendor oversight, monitoring, incident response, and business continuity. The exact scope depends on the service and audit period, so a WordPress checklist should support that scope rather than claim compliance by itself.

Start with the WordPress security control that can cause the most damage

A security audit often stalls when nobody owns the next decision. You may have a scan, a backup notice, and a list of updates, yet still lack one page showing what exists, who controls it, and when each item was verified.

Your sequence matters because later checks depend on earlier evidence. Start with ownership, then test the controls that protect access, code, recovery, and response.

The six-step action plan

1. Create the inventory: Record your WordPress site, plugins, themes, domains, hosting accounts, integrations, and exposed services in one inventory page with an owner and verification date.
2. Review access: Compare WordPress users, hosting users, domain access, and configuration credentials with current staff and contractors. Save an access approval record for every account that remains.
3. Patch and remove risky code: Update trusted components, remove unused plugins and themes, and record each change in a change log that includes testing results.
4. Test restoration: Restore your site and database in a separate environment or controlled location. Keep a restore report showing what returned and what still needs repair.
5. Inspect controls: Compare files with a known-good baseline, verify HTTPS, review permissions, check firewall settings, and confirm hosting controls. Save the baseline comparison.
6. Rehearse response: Walk through a stolen-admin or changed-file scenario, assign decisions, and record the result in a tabletop exercise record.

Start with the access and asset inventory page

Today, open your WordPress Users screen and your hosting account list. Create the first inventory page before buying another tool. Add each account, component, owner, purpose, and verification date, then mark anything nobody can explain.

• WordPress access: Every administrator and editor has a named owner and approved purpose.
• Hosting and domain access: Each account has a current user, recovery method, and business owner.
• Unclear items: Unknown accounts, services, and components have a recorded investigation owner.

That first page turns a broad checklist into accountable work. ShieldThemes can help with custom development, hosting, security remediation, or ongoing maintenance when your team lacks the capacity, but you can begin the audit independently with ownership first.

---

If you want a faster way to do this, ShieldThemes provides custom development, hosting, security remediation, and ongoing maintenance for startups and growing businesses, with practical guidance in its WordPress and e-commerce development blog when your internal capacity is limited.