Sample audit report
Sample WordPress Security Audit Report
A 22-page worked example written in the form of a completed engagement: one VPS running WHM/cPanel and eight WordPress installations, twelve findings, and a retest that closed eight of them and left three open with dates. The client, the hosts, the findings, and the evidence are invented — the structure, the severity reasoning, and the closure standard are the ones used on real work.
Published Last reviewed
Free PDF · no email address, form, or account required
- Scenario
- One VPS, WHM/cPanel, and eight WordPress installations
- Findings
- 5 high, 6 medium, 1 low — each with evidence and an acceptance test
- Outcome
- 8 resolved and verified, 3 open with dates and owners, 1 risk accepted
- Basis
- A fully fictional worked example — no client data, no live audit
Structure
What the delivered report contains
Ten numbered parts, written so a non-technical sponsor can follow the risk while the responsible engineer can follow the fix.
- Executive summary: initial and residual posture, business impact, the findings that matter most, and the decision the sponsor has to make
- Scope and engagement: systems assessed, access supplied, methods, safe-test boundaries, exclusions, and a dated chronology
- Asset inventory: every site with its business purpose, hosting account, PHP version, and the recovery targets it is held to
- Architecture and methodology: where the trust boundaries fail, how far a compromise travels, and the rating model in use
- Findings register: one table carrying every finding, its rating, its final status, and its page
- Twelve findings in full: observation, impact and prerequisites, evidence, remediation, acceptance test, and retest disposition
- Action plan: dated deliverables, each with a named owner and the criterion that closes it
- Positive controls and coverage: what passed, what each passing check does not prove, and where review stopped
- Retest record and evidence index: the final disposition of every finding, the closure standard, and how evidence is handled and retained
Anatomy of a finding
Every finding answers the same seven questions
Figure 1 · Anatomy of a finding
Every finding answers the same seven questions.
What was found
- 1 · Rating and ownershipSeverity, affected systems, accountable role
- 2 · ObservationWhat was found and what demonstrated it
- 3 · ImpactWhat it allows, and the prerequisites
- 4 · EvidenceA normalized extract with its own ID
What closes it
- 5 · RemediationThe change, its owner, the cautions
- 6 · Acceptance testWritten when the finding is raised
- 7 · RetestVerified, open with a date, or accepted
- 01
Rating and ownership
A high, medium, or low rating with the affected systems, the accountable role named, and the timestamp the condition was observed.
- 02
Observation
What was actually found and what demonstrated it — effective configuration, a bounded behavioral check, or targeted source inspection.
- 03
Impact and prerequisites
What the weakness allows in practice, and what an attacker would first need. Exposure is never written up as proof of compromise.
- 04
Evidence
A normalized extract carrying its own identifier, so every claim in the report traces back to the record behind it.
- 05
Remediation
The specific change, who owns it, the operational cautions, and a reference to vendor documentation where one applies.
- 06
Acceptance test
The check that has to pass before the finding can be called closed — written when the finding is raised, not after the fix.
- 07
Retest / final disposition
Resolved and verified, open with a target date, or accepted by a named approver with a review trigger.
Sample finding · HOST-01
Four sites share one filesystem identity
Severity: High. Affected: four independently maintained production sites running under a single cPanel account. A controlled PHP process in one of them read a configuration-adjacent marker file under a second site and modified a designated test file under a third. Equivalent tests into the other four hosting accounts were denied — the report states that limit rather than implying the boundary failed everywhere.
Impact and prerequisites: the weakness needs something first, namely code execution or equivalent access in one of the four sites. Once that exists, the same identity reaches sibling content and the configuration secrets beside it. Separate directories and separate databases do not stop movement inside one account, which is the part most owners assume is already handled.
Remediation: move each site into its own cPanel account and PHP-FPM identity, separate the deployment and database credentials, then re-verify ownership, scheduled jobs, redirects, mail routing, and backup coverage. Acceptance test: a process in each migrated site can no longer read another site’s configuration marker or write its files, and all four pass smoke, scheduled-job, and restore checks. Retest status: open — the staging migration passed, production had not moved, and reduced deploy access is recorded as interim mitigation rather than closure.
More sample findings
Representative entries from the findings register
| ID | Risk | Finding | Remediation direction |
|---|---|---|---|
| VPS-01 | High | SSH reachable from any external address, root login by password permitted, and the root credential shared by two staff. | Named key-based administrator accounts; direct root and password login disabled; SSH restricted to the approved network. |
| WHM-01 | High | WHM publicly reachable while root and a reseller account had no enrolled second factor — the server-level MFA toggle was on. | Enroll both privileged accounts, restrict WHM to approved networks, and review API tokens separately from browser MFA. |
| WP-01 | High | A plugin-generated backup archive sat in a public uploads directory and returned to an unauthenticated request. | Deny access, correct the backup destination, rotate the exposed database password and salts, and have the data owner assess disclosure. |
| WP-02 | High | A custom booking export route shipped an always-allow permission callback, returning reservation records without authentication. | Enforce an explicit export capability on the server; treat nonces as CSRF protection, not as authorization. |
| DATA-01 | Medium | An internet-reachable staging clone relied on a noindex directive rather than authentication, and held a CSV of copied guest contact records. | Gate staging behind authentication, replace copied personal data with generated records, and isolate staging mail. |
| CFG-01 | Medium | A WordPress debug log under a publicly served path returned stack traces, filesystem paths, and applicant email addresses. | Disable production debugging, move required logs outside served paths, and stop the form handler recording personal data. |
| INFO-01 | Low | Component version information disclosed in public response metadata, with no exploitable issue established from it. | Reduce unnecessary headers where operationally safe — recorded as worth less than staying patched. |
Positive controls
Positive controls: what passed, and what a passing check does not prove
Listing working controls stops a later “fix” from breaking them — and each one is written with the limit of what it actually proves, because a passing check is easy to over-read.
- All eight frontends redirected HTTP to HTTPS with valid certificates — a dated observation, not a renewal guarantee
- The database accepted local application connections only; the public database port was unreachable in the external check
- Marker tests across the four separate hosting accounts were denied — the boundary held everywhere except inside the shared account
- Bounded login-failure tests triggered the configured rate controls, which did not substitute for MFA or for offboarding
- Core checksum checks reported no mismatches, an outcome that attests to core files and nothing about custom plugins
- Daily account backups completed for all five hosting accounts, while independence and recovery time remained unmet
Retest record
The retest record: eight closed, three open, one accepted
| Finding | Agreed action | Final disposition |
|---|---|---|
| VPS-01 · Root SSH password access | Named key-based accounts; root and password login disabled; SSH restricted | Resolved — acceptance checks passed |
| WP-01 · Public events backup | Archive removed, destination corrected, database password and salts rotated | Resolved — acceptance checks passed |
| WP-02 · Unauthorized booking export | Export capability enforced server-side, related routes reviewed | Resolved — acceptance checks passed |
| HOST-01 · Shared filesystem identity | Migrate the four sites into separate hosting accounts | Open — staging passed, production due 2 October |
| BCP-01 · Recovery inside one provider account | Independent backup destination plus a timed restore drill | Open — destination approved, restore not yet run, due 6 October |
| MON-01 · Local-only security events | Forward events off-host and route alerts to a named responder | Open — forwarding installed, delivery not demonstrated, due 29 September |
| INFO-01 · Public version metadata | Reviewed and knowingly retained | Accepted — named approver, review due 22 December |
Audit or incident report?
Audit report vs incident report: what each one documents
An audit report like this example documents weaknesses found before an incident, with remediation, acceptance tests, and retesting. An incident report documents an active compromise: evidence preservation, persistence mapping, containment, eradication, and proof of recovery.
Both deliverables share the same evidence standard. To see the incident side documented at full depth on real work across a 30-site infection, read the ClickFix report.
Common questions
Common questions about the report
Is this a real client report?
No, and it says so on every page. It is a fully fictional worked example: the client, the staff, the hosts, the findings, the evidence, and the retest outcomes are invented, and no live audit was performed. What matches a delivered report is the structure, the severity reasoning, and the closure standard.
Why publish a worked example instead of a redacted real audit?
A real audit report cannot be redacted far enough to be safe and still be worth reading — the architecture, the order the weaknesses appear in, and the timeline identify a client even with the name removed. A worked example carries the format at full depth with nothing left in it to leak.
Will my report look exactly like this?
The structure will. The content follows your scope — a single WooCommerce store, a multisite network, and an eight-site shared VPS produce very different findings, and the report length follows what is actually found.
Do I receive anything besides the document?
Yes. Delivery includes a walkthrough with the responsible stakeholders, so severity, ownership, and sequencing are agreed rather than guessed from the page.
Can the findings be fixed and retested afterwards?
Yes. Remediation can be performed directly where agreed or handed to your team as guidance, and each agreed fix is retested against the acceptance test written when the finding was raised — including the items that stay open, as the retest record above shows.