An audit should explain consequence
A long vulnerability export is not a security strategy. A useful audit connects findings to the platform, the organization, and plausible impact. It distinguishes exposed software from exploitable conditions, identifies compensating controls, and prioritizes remediation by consequence rather than generic severity alone.
The application is only one layer
Review should include WordPress core, themes, plugins, custom code, accounts, roles, file permissions, secrets, database access, scheduled tasks, forms, integrations, hosting, DNS, TLS, delivery controls, logging, backups, and recovery readiness. The goal is to understand how the system behaves as a whole and where trust boundaries are weak or unclear.
Security and performance become manageable when ownership, evidence, and response paths are explicit.
The output must be usable
Leadership needs a concise view of material risk. Technical owners need evidence, affected components, remediation guidance, dependencies, and validation criteria. A strong audit ends with a sequenced plan: urgent containment, near-term hardening, operational improvements, and items that should be monitored rather than treated as emergencies.
Verify WordPress core, themes, plugins, and custom code
Application review should distinguish official files from unauthorized additions, known customizations, generated artifacts, and expected premium-plugin checksum exceptions. WordPress core can be verified against published checksums, but extra files inside core directories still require investigation because replacement does not necessarily remove them. Themes and plugins should be assessed for version, support status, privilege, known vulnerabilities, unexpected modifications, abandoned components, and unnecessary functionality. Custom code deserves direct review of authentication, authorization, input handling, output escaping, database queries, file operations, remote requests, secrets, and update behavior. The goal is not to label every variation as malware. It is to establish which code is trusted, which is explained, which is vulnerable, and which requires quarantine or replacement from a known-good source.
Inspect access as carefully as software
Compromise often persists through credentials rather than files. Review WordPress administrators, application passwords, API keys, SFTP and SSH users, hosting-panel accounts, database access, deployment tokens, DNS providers, analytics, email services, and third-party integrations. Ask whether each identity is current, necessary, uniquely attributable, protected by strong authentication, and limited to the access it needs. Shared administrator accounts weaken accountability. Former vendors and staff should not retain production access. Secrets stored in repositories, page builders, logs, or email can outlive the project that created them. An audit should also examine how emergency access is granted and revoked. Least privilege is not a one-time configuration; it is an operating practice that requires periodic review as people, vendors, and systems change.
Test upload, execution, and persistence pathways
WordPress needs writable areas for media, caching, updates, and other legitimate functions. Attackers value the same paths when uploaded or injected code can execute. A security audit should identify PHP-like files in uploads, unexpected must-use plugins, scheduled tasks, modified loaders, hidden files, configuration directives, and server rules that can create persistence. It should safely verify whether executable files placed in upload directories are actually blocked at the web-server or application boundary. Merely adding an `.htaccess` rule is insufficient if the server does not honor it. On OpenLiteSpeed, Nginx, managed hosting, or container platforms, the correct control may live elsewhere. Verification matters: the expected result is that test code cannot execute, the homepage remains healthy, and the control survives reload or deployment.
Examine infrastructure and the delivery edge
The WordPress application sits inside a larger system. Hosting configuration, PHP versions, file ownership, permissions, TLS, DNS, CDN behavior, web application firewalls, caching, object storage, email delivery, and logging all affect security. The audit should identify unsupported runtimes, exposed management interfaces, overly broad filesystem access, insecure secrets, weak origin protection, and conflicting controls. It should also confirm that security headers and edge rules behave on real responses rather than existing only in a dashboard. Infrastructure review is especially important when multiple sites share a server, because one account’s compromise can influence the risk of others depending on isolation. Findings should distinguish what Osiris can remediate directly, what the hosting provider owns, and what requires a business decision.
Evaluate backups and incident readiness
Security controls reduce likelihood; recovery controls reduce impact. An audit should inspect backup frequency, retention, isolation, monitoring, encryption, access, and restore testing. It should determine whether the organization can identify a trustworthy point before compromise and whether recovery would include databases, files, configuration, DNS, and required external dependencies. Incident readiness also includes named decision-makers, secure communication, evidence preservation, escalation contacts, and criteria for taking a site offline. Teams should know how to separate confirmed facts from assumptions and how to notify stakeholders without creating confusion. A plan that exists only as an old document is not readiness. The audit should test whether people can locate the plan, access the backups, and make consequential decisions under pressure.
Look for cloaking, spam, and database manipulation
Some WordPress compromises are designed to remain invisible to ordinary visitors. Attackers may serve different content to search crawlers, inject gambling or pharmaceutical pages, alter options, create hidden administrators, manipulate scheduled tasks, or use redirects that activate only for certain referrers or devices. Review should compare responses across user agents and request conditions, search the database for suspicious content patterns, inspect recent posts and options, check cron hooks, and examine logs for known malicious filenames or unusual requests. Different page hashes do not automatically prove cloaking because personalization and caching can vary output. They do justify focused investigation. Evidence should be correlated across files, database content, logs, and live behavior before conclusions are stated.
Prioritize findings by exploitability and consequence
A useful report separates active compromise, high-confidence malicious artifacts, exploitable vulnerabilities, missing controls, maintenance debt, and informational improvements. Priority depends on exposure, required access, available exploit code, business impact, data sensitivity, detection capability, and recovery readiness. A medium-severity issue on an internet-facing privileged plugin may matter more than a critical issue in disabled software. Remediation steps should include validation criteria so completion can be demonstrated: checksums pass, unauthorized files are quarantined, uploads PHP returns a blocked response, administrators are reviewed, the homepage remains healthy, and monitoring sees the new baseline. This evidence-led approach helps leadership fund the right work without manufactured urgency.
What to ask a WordPress security provider
Ask how the provider distinguishes compromise from normal customization, how production-safe testing is handled, and whether findings include evidence and business context. Ask who responds when an incident occurs, what access they require, how sensitive information is protected, and whether remediation is verified. Confirm that backups, hosting, DNS, access, custom code, database content, and recovery are included where relevant—not only plugin vulnerability scans. Ask what happens after the audit: who owns each action, how risk acceptance is recorded, and whether ongoing monitoring and maintenance are available. Responsible providers will not guarantee that a site can never be compromised. They should explain how they reduce likelihood, limit impact, shorten detection time, and create a practiced recovery path.
