How to Prepare a WordPress Site for Audit

An audit rarely begins with a technical question. It begins with an uncomfortable business question: who is responsible for this site, and can they prove it? To prepare a WordPress site for audit, you need more than a list of plugins and a screenshot of a green uptime dashboard. You need evidence that the site is owned, controlled, maintained, and recoverable.

That matters whether the trigger is a client security questionnaire, an insurer, a board request, a legal review, an acquisition, or the aftermath of an incident. WordPress is often treated as a marketing asset until it becomes the intake form for a law firm, the donation engine for a nonprofit, or the checkout path for an e-commerce business. At that point, “someone handles it” stops being an answer.

What an audit is really testing

Most audits are not asking whether WordPress is good or bad. They are testing whether your organization can explain how it manages risk. The reviewer may use security language, but the underlying concerns are straightforward: unauthorized access, lost data, unplanned changes, unsupported software, weak recovery procedures, and unclear accountability.

The site itself is only part of the picture. A WordPress install can look tidy while critical access sits in a former employee’s personal email, backups have never been restored, hosting is managed through an unknown agency account, and production changes happen directly on the live site. That is not an operations model. It is a collection of hopes with admin privileges.

Your preparation should create a defensible operating record. It does not need to be theatrical or packed with screenshots nobody will read. It does need to be current, specific, and connected to how the site is actually run.

Start with ownership and system boundaries

Before reviewing plugins, establish what the WordPress site includes and who owns each part. Document the production domain, hosting environment, DNS registrar, SSL certificate management, content delivery or security services, transactional email provider, form processing, payment services, analytics, and any systems the site sends data to.

This is where many businesses find the first problem: the website is not one system. A donation form may send information to a CRM. An e-commerce order may pass into an ERP. A lead form may notify a sales team through an automation built years ago by a contractor who is no longer reachable. The audit scope should reflect those connections, especially where personal, financial, or confidential information crosses a boundary.

Name an accountable business owner and an operational owner. The business owner decides what risk is acceptable and what the site must support. The operational owner maintains the record, coordinates changes, and knows what happens when something fails. They may be the same person in a smaller organization, but the responsibilities should still be clear.

Build an access register

An access register is a plain record of who can enter the systems that run the site, why they need access, and what level of access they hold. Include WordPress administrators, hosting users, domain and DNS administrators, database access, code repository access, and relevant third-party accounts.

Do not stop at named users. Record shared accounts, service accounts, agency access, emergency access, and accounts tied to former employees. Shared credentials are sometimes unavoidable with legacy tools, but they should be treated as a known risk with an owner and a plan to remove or contain them.

Review administrator accounts against current roles. Remove accounts that no longer have a business purpose. Require strong sign-in protections where the platform supports them, particularly for WordPress, hosting, domain, and email accounts. An audit trail is much more credible when the people listed in it still work with you.

Create a real inventory, not a plugin dump

A plugin list is useful, but it is not an inventory by itself. Auditors and internal stakeholders need to know what each component does, whether it is actively maintained, who approved it, and whether the business still needs it.

Document the WordPress core version, active theme and child theme, active plugins, inactive plugins, custom code, mu-plugins, and major integrations. For each material component, capture its purpose, owner, source or vendor, update status, and any known risk or dependency. If a plugin processes form submissions or controls checkout behavior, it deserves more attention than a dormant visual editor.

Inactive plugins and unused themes are common clutter. They may not be running, but they are still code sitting on a production server. Remove what is not needed after confirming it will not affect a rollback process or a custom dependency. The goal is not a perfectly minimal install for its own sake. The goal is to reduce unknowns.

Custom code needs special care. If the site relies on theme edits, custom snippets, or a plugin written for your organization, identify where the source code lives and who can maintain it. If the only copy is on the production server, you have a continuity problem disguised as a website.

Prove that change is controlled

The fastest way to make a WordPress site difficult to defend is to make changes directly in production and rely on memory afterward. Marketing urgency is real. So are campaign launches. That does not make uncontrolled updates less risky.

Document a practical change process that matches the site’s importance. For a revenue-critical site, updates should be assessed, tested outside production when feasible, approved by the appropriate owner, deployed, and checked after release. Maintain a change log with the date, what changed, why it changed, who approved it, and what was tested.

A staging environment is valuable because it gives the team a place to find conflicts before visitors do. It is not magic. Staging can drift from production, integrations may behave differently outside the live environment, and some changes still require careful production validation. The point is to make production the last place you learn whether an update breaks a form, payment flow, or membership login.

Emergency changes are different, not exempt. If a vulnerability or outage requires immediate action, document the reason, the action taken, and the follow-up review. A short record made during a stressful incident is better than reconstructing the story three months later from Slack messages and browser history.

Make backups and recovery auditable

A backup that has never been tested is not a recovery plan. It is a file with good intentions.

Document what is backed up, how frequently, where backups are stored, who can access them, how long they are retained, and whether the backup includes both files and the database. WordPress sites commonly fail in ways that make one without the other insufficient. A database backup without uploaded media or custom code may not restore the site you think you have.

More importantly, record restore testing. Note the date of the test, the environment used, what was restored, whether the site functioned, and any gaps found. A full production restore may not be appropriate every month, particularly for a complex commerce or membership site. But a documented recovery exercise should be proportionate to the business impact of failure.

Your recovery documentation should also answer a few operational questions: who has authority to declare an incident, who performs the restore, what happens to orders or form submissions created after the backup point, and how the business communicates an outage. Technical recovery without business coordination often creates a second problem.

Prepare evidence for security and monitoring

Security evidence should describe actual controls, not vague assurances. Record how updates are reviewed and applied, how administrator access is protected, how suspicious activity is monitored, where logs are retained, and how security issues are escalated.

Do not claim controls you cannot demonstrate. If monitoring only confirms that the homepage loads, say that. If logs exist only at the hosting layer and are kept for a limited period, document that reality. Honest gaps are easier to manage than invented certainty that falls apart under a follow-up question.

For sites handling sensitive submissions, document the form fields collected, where that data goes, who can access it, and whether notifications send sensitive details through email. A contact form can create more exposure than a large site if it routes legal, health, or financial information into unmanaged inboxes.

You should also retain an incident record, even if the site has had no major incident. Define how suspected compromise, broken SSL, failed deployments, malware alerts, and availability issues are reported and handled. The process can be concise. What matters is that the next person does not have to invent one during a bad afternoon.

Use a short audit packet people can actually review

A good audit packet is organized for a non-specialist reader. It should show the operating model, the current state, the evidence behind key claims, known gaps, and the plan for those gaps. Do not bury the useful facts in a 70-page technical export.

At a minimum, assemble these materials:

• A system overview showing the site, owners, hosting, domain, and major integrations.
• An access register and administrator review record.
• A software and custom-code inventory with update status and ownership.
• Change, backup-restore, monitoring, and incident records.

Add dated evidence where it supports a claim: restore-test notes, change approvals, monitoring reports, security review records, and screenshots only when they clarify something. Set a review cadence so the packet does not become a historical artifact the moment the audit ends.

Treat gaps as operating work

Most organizations will find gaps. Maybe the site has no staging environment, a former vendor owns DNS, custom code has no repository, or backups exist without restore testing. None of those findings automatically require a rebuild. They do require a prioritized operating plan.

Fix the items that could cause immediate loss of control first: ownership, privileged access, recoverability, and critical vulnerabilities. Then address the items that make future maintenance fragile, such as undocumented integrations and production-only changes. A site can be imperfect and still be responsibly operated, provided the risks are visible, assigned, and actively managed.

An audit should not be the only time your organization asks whether WordPress is under control. Keep the record current, test the recovery path before you need it, and make accountability obvious. When the hard question arrives, you should be able to answer it without starting a scavenger hunt.