Map the whole system
Define the website, infrastructure, identities, integrations, critical journeys, responsible owners, and production-safety constraints before testing begins.
Evidence-led WordPress security assessment
WordPress security audits that turn uncertainty into an owned plan.
A WordPress security audit is a scoped investigation of the application, access, infrastructure, recovery controls, and operating practices behind a website. Osiris separates confirmed evidence from assumptions, explains the consequence of each material finding, and creates a prioritized path to remediation and verification.
Classify the evidence
Correlate scanners, checksums, configuration, access, logs, files, database content, and live behavior without treating every signal as a verdict.
Prioritize by consequence
Connect each material finding to reachability, business impact, confidence, ownership, remediation, dependencies, and residual risk.
Verify the resulting state
Test approved corrections against explicit claims, preserve a readable record, and establish the baseline that ongoing stewardship must maintain.
A direct answer
The answer is not another security score
A security plugin can report a vulnerable version, an unfamiliar file, or a change in behavior. It cannot automatically explain whether the signal is exploitable in this environment, whether another control reduces its consequence, whether the same weakness exists elsewhere, or which owner should act first.
An Osiris WordPress security audit turns technical evidence into decisions. We examine the website as a connected operating system: WordPress core, themes, plugins, custom code, identities, database content, scheduled activity, hosting, PHP, DNS, TLS, caching, backups, logging, recovery, and the workflows that matter to the business. The scope is agreed before testing so production remains protected and the conclusions match the real environment.
- Evidence is classified before consequential change
- Findings connect components to plausible consequence
- Leadership and technical owners receive usable outputs
- Remediation and verification are explicitly scoped
When to begin
An audit is useful when trust or ownership is unclear
A security audit is appropriate when a website is business-critical but its history, ownership, or current posture is uncertain. That uncertainty often follows a vendor handoff, acquisition, rushed launch, years of deferred maintenance, hosting move, unsupported software, or an incident that was cleaned without a defensible root cause.
It is also useful before a major platform change. A PHP upgrade, infrastructure migration, ecommerce launch, authentication change, or new integration can expose inherited assumptions. Auditing first establishes a baseline against which the release can be verified.
- Unexplained administrators or recurring file changes
- PHP in writable media paths or unusual scheduled tasks
- Search spam, redirects, warnings, or repeat reinfection
- Unsupported runtimes, stale privileged code, or untested backups
Application and access
Integrity is wider than WordPress core
We inventory WordPress core, active and inactive themes, plugins, must-use plugins, custom components, drop-ins, and relevant generated files. Official checksums can verify known releases, but a passing checksum does not account for unauthorized extra files, database manipulation, stolen credentials, or vulnerable custom code. Commercial and bespoke components may lack public checksums, so provenance, expected behavior, supportability, privilege, and ownership matter.
Access review reaches beyond WordPress administrators. Hosting panels, SSH and SFTP accounts, application passwords, deployment keys, database users, DNS administration, CDN accounts, email services, repositories, and third-party integrations can each become a persistent route into the environment.
- Core, plugins, themes, must-use code, and custom components
- Authentication, authorization, input, output, and privileged actions
- Administrators, sessions, application passwords, and service access
- Database content, scheduled activity, and persistence paths
Infrastructure and recovery
A control is useful only when the system enforces it
WordPress sits inside PHP, the web server, filesystem ownership, operating-system packages, TLS, DNS, caching, delivery rules, logging, monitoring, and connected services. The audit identifies which layers are visible within the approved access and which remain provider-owned or outside scope. It distinguishes an application vulnerability from a host or control-plane trust problem because the recovery decision can be very different.
Backups are evaluated as recovery controls, not reassurance labels. Frequency, retention, isolation, access, monitoring, and restore testing determine usefulness. A complete archive is not automatically a known-clean archive, and a restore that has never been tested is an unverified dependency.
- Effective upload and execution controls
- PHP, web server, ownership, permissions, and runtime support
- DNS, TLS, cache, CDN, firewall, logging, and monitoring
- Backup provenance, isolation, retention, and restore readiness
Define authority and scope
Identify environments, owners, critical workflows, data sensitivity, known symptoms, approved testing depth, and explicit exclusions.
Establish the baseline
Record software, access, expected customizations, configuration, available logs, recovery posture, and representative live behavior.
Investigate and classify
Separate confirmed compromise, exploitable vulnerabilities, missing controls, maintenance debt, recovery gaps, and informational improvements.
Sequence the response
Assign immediate containment, remediation, modernization, monitoring, ownership, dependencies, and review dates according to consequence.
Verify approved corrections
Test the integrity, access, controls, critical journeys, recovery path, and monitored baseline that support the final conclusions.
Hand over the operating baseline
Document verified controls, remaining risks, responsible owners, monitoring priorities, and review triggers so the findings remain useful after the audit. Ongoing maintenance is agreed separately.
What the engagement leaves behind
Outputs for decision-makers and implementers
The engagement can include a scope and system map, concise executive risk brief, technical findings register, sequenced remediation roadmap, recovery-readiness assessment, and verification record. Each material finding identifies the evidence, affected component or control, confidence, plausible consequence, recommendation, dependency, accountable owner, and validation criterion where practical.
Raw exports may support the record, but they are not presented as the strategic conclusion. Your team should be able to see why an item matters, who owns it, what happens next, and how completion will be demonstrated.
Two starting points, one evidence standard
A posture audit is designed for an operating website without a confirmed active incident. It maps the environment, identifies material exposure, evaluates recovery readiness, and creates a prioritized hardening plan. This is often the right starting point for inherited sites, reputation-sensitive workflows, custom WordPress platforms, and organizations preparing for long-term maintenance.
An incident-led audit begins with a credible symptom or confirmed event. The immediate priorities may include visitor safety, evidence preservation, access containment, service continuity, or clean-source reconstruction. If active compromise is established, the work can transition into our WordPress malware removal and incident response service. Both paths require observed evidence, stated confidence, a named consequence, an accountable owner, and a validation step.
What the service does not promise
No responsible provider can guarantee that a WordPress website will never be compromised. An audit is a time-bounded assessment of approved scope and available evidence. Historical certainty may be impossible when logs are missing, accounts were shared, systems were overwritten, or third-party platforms are outside the engagement.
A general security audit is not automatically a penetration test, compliance certification, legal opinion, accessibility conformance audit, or exhaustive line-by-line review of every custom component. Those activities can be discussed when they match the organization's needs, but they should never be implied by vague language. Osiris states what was observed, what is inferred, what remains unknown, and what would be required to answer the next question.
Anonymized evidence shows why boundaries matter
Our core integrity recovery, trusted reconstruction, and virtual host recovery case studies show why an audit must follow the trust boundary rather than stop at the first visible symptom. The fleet security-signal triage case study demonstrates that similar-looking alerts can require different responses after review.
For a detailed educational framework, read what a useful WordPress security audit actually covers. If the website already shows evidence of compromise, start with how to respond when a WordPress site is compromised.
Begin with the facts you have—not credentials
Send the public URL, what prompted the review, known symptoms or recent changes, important business workflows, the current hosting arrangement, and the person authorized to approve access and remediation. Do not submit passwords, private keys, customer data, or sensitive indicators through the public form.
Osiris will use that context to define a production-safe scope, the access required, the appropriate depth of review, and whether the next step is a posture audit, incident triage, remediation, or ongoing WordPress security and maintenance.
WordPress security audit FAQ
Questions to answer before the work begins.
Scope varies, but a useful audit can examine WordPress integrity, plugins, themes, custom code, privileged access, database and scheduled activity, upload and execution controls, hosting configuration, PHP, DNS, TLS, logging, backups, recovery readiness, and operating practices. The approved scope identifies which layers are accessible and whether code review or remediation is included.
No. A scan identifies known patterns, versions, or behaviors. An audit interprets that evidence in the context of the application, access model, infrastructure, business consequence, compensating controls, and recovery capability. Scanning is useful, but its output is not automatically a confirmed vulnerability or a prioritized plan.
A focused site may require several business days. Custom code, multiple environments, shared infrastructure, integrations, incomplete access, or signs of active compromise can extend the work. The reliable estimate comes after defining the systems, testing depth, production constraints, and required outputs.
Only when the scope authorizes them. A posture audit can remain read-only through discovery and reporting. If an urgent risk or active compromise is established, Osiris may recommend containment, but consequential changes should be approved, recorded, recoverable where practical, and validated. Remediation can be included or scoped separately.
The minimum access depends on the question. WordPress administrator access may be sufficient for a limited review, while filesystem, hosting-panel, database, DNS, or SSH access may be required for deeper controls. Temporary individual accounts and least privilege are preferred. Credentials should never be submitted through the public form.
No. Checksums and scans answer specific questions. They may not detect unauthorized extra files, database injections, stolen credentials, malicious scheduled tasks, unsafe custom code, vulnerable integrations, or compromise outside WordPress. They become stronger evidence when combined with access review, provenance, server-control testing, live behavior, and recovery validation.
Custom plugins can be included when the scope calls for code review. The depth should be explicit because a configuration assessment is different from reviewing authentication, authorization, input validation, output escaping, database use, file handling, remote requests, secrets, dependencies, and privileged workflows line by line.
The findings become an owned remediation and verification plan. Confirmed compromise and exploitable high-consequence issues come first, followed by hardening, dependency modernization, access governance, recovery improvements, and ongoing operations. Osiris can implement approved corrections or support the organization's technical team, then help maintain the resulting baseline.
The scope determines the cost: the number of websites and environments, custom code, integrations, available evidence, testing depth, urgency, and required deliverables. Remediation and ongoing maintenance should be identified separately in the proposal. Share your public website URL and reason for the review so Osiris can define the work before quoting; do not send credentials through the enquiry form.
