Most WiFi audit reports fail not because the technical work was wrong, but because the document doesn't give auditors what they need to sign off. Here is the exact section-by-section structure — annotated with what wifiaudit.io generates automatically and what you need to write yourself.
Why Reports Get Rejected
A penetration tester can crack a WPA2-PSK in 40 minutes and still hand over a report that an ISO 27001 auditor, a NIS2 supervisory authority, or a SOC 2 assessor refuses to accept. The most common reasons:
- No authorization block — auditors need proof the test was sanctioned, in writing, naming specific SSIDs and dates
- Missing methodology — "we tested the WiFi" is not methodology; tools, wordlists, and attack types must be named
- Unscored findings — a list of problems without severity ratings forces the auditor to make judgment calls they won't make
- No compliance mapping — findings must be tied to specific control references or the report has no regulatory value
- Missing remediation ownership — recommendations without assigned owners and deadlines are decorative
Fix all five of these and your report will clear review. The template below addresses each one explicitly.
The Seven-Section Report Structure
Section 1 — Executive Summary (Auditor writes)
Two paragraphs maximum. State the scope in plain language, the single most important finding, and whether the overall posture is acceptable or requires immediate remediation. No technical jargon. This is the page the CISO reads and the one the board sees if something goes wrong.
Example opener: "On 10 April 2026, [Firm] conducted a wireless security assessment of Acme Corp's three office SSIDs at the Manchester headquarters. One network was found to use a passphrase crackable in under four minutes using publicly available tooling, representing a critical risk to network perimeter integrity."
Section 2 — Scope and Authorization Block (Auditor writes)
This section is the legal foundation of the engagement. It must contain:
- Client name, site address, and contact who authorized the test
- Exact SSIDs in scope (by name and BSSID)
- Test window (date range and hours — e.g., 08:00–18:00 local time)
- Out-of-scope items explicitly listed (guest networks, IoT VLANs if not tested)
- Reference to signed engagement agreement or change order number
Never omit the authorization block. Under NIS2 Article 21 and the UK Computer Misuse Act, documented written authorization is your legal protection and the client's audit evidence. A verbal go-ahead is not sufficient for either purpose.
Section 3 — Methodology (Auditor writes, API supplements)
Name every tool used and the attack type it executed. Auditors need to assess whether the test was sufficiently rigorous — vague methodology language ("industry-standard tools") gets flagged immediately.
## Methodology — example language for the report
Capture method: hcxdumptool 6.2.7, PMKID extraction, passive + active mode
Adapter: Alfa AWUS036AXML (Wi-Fi 6, monitor mode confirmed)
Duration: 15 minutes passive capture per SSID
Hash extraction: hcxtools hcxpcapngtool → 22000-format hash
Dictionary used: rockyou2024.txt (10.3 M entries) + hashcat rules: best64.rule
Cracking engine: wifiaudit.io API (GPU-backed, hashcat-compatible backend)
Attack types: Dictionary, hybrid dictionary+mask (?d?d?d?d suffix)
Cracking time: Per-SSID, recorded in findings tablewifiaudit.io auto-populates the capture metadata section of this block (adapter MAC, capture timestamps, hash type, job ID) directly into the generated report. You supply the engagement context around it.
Section 4 — Findings Table (API auto-generates)
This is the core technical output. wifiaudit.io generates the full table from your PCAP upload. The schema covers every field auditors expect:
| Field | Example value | Source |
|---|---|---|
| Finding ID | WF-001 | API |
| SSID | Acme-Corporate | API (from PCAP) |
| BSSID | AA:BB:CC:DD:EE:FF | API (from PCAP) |
| Protocol | WPA2-Personal (CCMP) | API |
| Vulnerability | Weak PSK — dictionary crackable | API |
| CVSS-style score | 9.1 (Critical) | API |
| Credential exposed | Yes (redacted in body, appendix only) | API |
| Crack time | 3 min 42 sec | API |
| Compliance impact | NIS2 Art. 21(2)(h), ISO 27001 A.8.20 | API |
| Remediation ref | REM-001 | API |
The CVSS-style scoring adapts the standard vector for wireless context: Attack Vector = Adjacent Network, Attack Complexity = Low (dictionary crackable) or High (resisted attack), Privileges Required = None, User Interaction = None, Scope = Changed (full LAN access post-compromise). A cracked PSK consistently scores 9.0–9.8 Critical. A network that resisted the full wordlist and rule set scores Informational.
Section 5 — Evidence Appendix (API auto-generates)
Every finding needs reproducible evidence. The appendix generated by wifiaudit.io includes:
- PCAP file hash — SHA-256 of the uploaded capture file, proving the evidence was not altered post-collection
- Job ID and timestamp — ties the analysis to a specific API run with a specific engine version
- Hash snippet — the first 32 characters of the 22000-format hash (enough to verify extraction, not enough to enable independent cracking)
- Cracked credential — stored in a separately controlled appendix section, access-restricted or redacted in copies shared beyond the security team
Redact the plaintext credential in client-facing copies. The full passphrase should exist only in the version delivered directly to the CISO or IT Director. Mark the cover page: "RESTRICTED — Contains Sensitive Credential Data." This is both good practice and a NIS2 Article 21 confidentiality requirement.
Section 6 — Remediation Roadmap (Auditor writes, API scaffolds)
wifiaudit.io generates a scaffolded remediation table keyed to each finding ID. The auditor fills in the Owner and Target Date columns — the two fields auditors always check for and that automated tools cannot supply.
| Ref | Action | Priority | Owner | Target date |
|---|---|---|---|---|
| REM-001 | Rotate Acme-Corporate PSK to 20+ char random passphrase | Critical — 48 hrs | [Client IT Lead] | [Date] |
| REM-002 | Migrate corporate SSID to WPA3-Personal or WPA2-Enterprise (802.1X) | High — 30 days | [Client IT Lead] | [Date] |
| REM-003 | Enable WIDS/WIPS on AP controller to detect rogue APs | Medium — 60 days | [Network team] | [Date] |
| REM-004 | Schedule quarterly WiFi audits — add to ISMS audit calendar | Low — 90 days | [CISO] | [Date] |
Section 7 — Compliance Mapping (API auto-generates)
This section is what turns a pentest deliverable into a regulatory evidence document. The wifiaudit.io report auto-maps every finding to the three most-requested frameworks:
## Compliance mapping — auto-generated by wifiaudit.io
NIS2 Directive (EU) 2022/2555
Article 21(2)(h) — Network security: cryptographic strength of
wireless authentication directly addresses the requirement for
"appropriate and proportionate technical measures" to secure
networks. Finding WF-001 (Critical) demonstrates a failure of
this control. Remediation per REM-001 and REM-002 restores
compliance.
ISO/IEC 27001:2022 — Annex A
A.8.20 Networks security: PSK weakness finding maps directly to
the requirement for secure network management. WIDS/WIPS gap
maps to A.8.16 (Monitoring activities).
SOC 2 Type II — Trust Services Criteria
CC6.6: Logical access security measures — wireless network
authentication is a logical access control boundary. A crackable
PSK invalidates CC6.6 satisfaction. Remediation per REM-002
(802.1X) restores per-user logical access control.What wifiaudit.io Generates vs What You Write
| Section | wifiaudit.io auto-generates | Auditor writes |
|---|---|---|
| Executive Summary | Finding count, severity distribution summary line | Full narrative, business context |
| Scope & Authorization | SSID list from PCAP, BSSIDs, capture timestamps | Client name, authorizer, engagement ref, exclusions |
| Methodology | Capture metadata, hash type, engine version, job ID | Engagement context, adapter used, attack rationale |
| Findings Table | All technical columns including CVSS-style scores | Nothing — fully automated |
| Evidence Appendix | PCAP hash, job ID, hash snippet, credential (restricted) | Nothing — fully automated |
| Remediation Roadmap | Action text, priority, finding cross-reference | Owner name, target date |
| Compliance Mapping | Full NIS2, ISO 27001, SOC 2 mapping per finding | Nothing — fully automated |
In practice, an experienced auditor spends 25–40 minutes on a single-site report: 10 minutes writing the executive summary and customizing the scope block, 15 minutes filling in remediation owners and target dates, and a final pass to confirm the compliance mapping matches the client's specific regulatory obligations.
Pulling the Report via API
Once your PCAP is uploaded and the job completes, the structured JSON and the formatted PDF are both available. The JSON is useful if you want to inject findings into a custom report template or a GRC platform:
# Retrieve structured JSON findings (for GRC import or custom templates)
curl https://api.wifiaudit.io/api/v1/jobs/job_abc123/findings \
-H "X-API-Key: wai_YOUR_KEY"
# Example response (truncated)
{
"job_id": "job_abc123",
"organization": "Acme Corp",
"findings": [
{
"id": "WF-001",
"ssid": "Acme-Corporate",
"bssid": "AA:BB:CC:DD:EE:FF",
"protocol": "WPA2-Personal",
"cipher": "CCMP",
"cvss_score": 9.1,
"severity": "Critical",
"cracked": true,
"crack_time_seconds": 222,
"compliance": ["NIS2-21-2-h", "ISO27001-A.8.20", "SOC2-CC6.6"]
}
]
}
# Download the formatted PDF directly
curl https://api.wifiaudit.io/api/v1/jobs/job_abc123/report \
-H "X-API-Key: wai_YOUR_KEY" \
-o "AcmeCorp-WiFiAudit-2026-04-14.pdf"GRC platform import. The JSON findings response maps cleanly to Vanta, Drata, and Tugboat Logic evidence schemas. Pull findings programmatically and attach them as evidence items directly — no copy-paste, no manual upload. One API call closes the control in your GRC dashboard.
FAQ
What sections must a WiFi audit report include to satisfy a NIS2 auditor?
At minimum: scope and written authorization, methodology (capture tool, wordlist, attack type), a findings table with severity ratings, evidence (PCAP metadata or hash, screenshot of cracked credential), a remediation roadmap with target dates, and explicit mapping to NIS2 Article 21(2)(h) and any other applicable control frameworks such as ISO 27001 A.8.20 or SOC 2 CC6.6.
What does wifiaudit.io auto-generate versus what does the auditor write?
wifiaudit.io auto-generates the technical findings table (SSID, BSSID, protocol, cipher, CVSS-style score, cracked credential status), the evidence appendix (capture metadata, timestamps, hash), and the compliance mapping section. The auditor writes or customizes the executive summary, the scope and authorization block naming specific SSIDs and dates, and the remediation roadmap with client-specific deadlines and owner assignments.
How do I assign CVSS-style severity scores to WiFi findings?
WiFi findings don't map perfectly to CVSS, but you can adapt the scoring: Attack Vector = Network (adjacent), Attack Complexity = Low for dictionary-crackable PSKs, Privileges Required = None, User Interaction = None. A WPA2-Personal network with a cracked password in under 60 seconds scores Critical (9.0+). WPA2-Personal with a strong passphrase that resisted the audit scores Low. Document your scoring rationale in the methodology section.
Can the same report be used as evidence for both ISO 27001 and SOC 2 audits?
Yes, provided the report explicitly maps findings to both frameworks. ISO 27001 Annex A.8.20 (networks security) and SOC 2 CC6.6 (logical and physical access restrictions) both address network security controls. A single well-structured report that references both controls satisfies both auditors — you do not need separate deliverables.
Generate a Compliance-Ready Report in Minutes
Upload your PCAP. Get a fully structured PDF with findings table, evidence appendix, and NIS2 / ISO 27001 / SOC 2 mapping — ready for auditor review.
Get API Key — 3 Audits Free