Write your first security report people will read

Most first security reports fail in a predictable way: they preserve the tester’s process. The reader must then reconstruct the risk. And the report remains unfinished. Readability is a security control because it determines whether a finding reaches the person who can fix it.

Start a security report with the decision. Separate executive consequence from technical proof. Verify every finding manually. Give each owner a concrete fix. Then edit for accuracy, clarity, and consistency before delivery. The report’s job is action, not a diary of your testing.

First, identify the people who must act and design the reader’s path. You’ll write one finding end to end and choose proof. Then edit in passes and run a contradiction check before sending.

In this article

• Reports fail when the reader has to do the analysis
• Decide who must act before you write
• Put the decision at the top, then preserve the evidence underneath
• Write every finding so a stranger can understand and act
• Evidence should prove the claim, not decorate the page
• Edit in passes because the first draft is supposed to be bad
• Avoid the shortcuts that make a report unreliable
• Run this final read-before-send checklist

Reports fail when the reader has to do the analysis

A report can be technically correct and still fail its purpose. In first reports, the usual imbalance is predictable: pages of scanner narration and too little explanation of the decision the reader needs to make. (For the scanning side, see our guide to choosing pentesting tools.)

Most report templates teach you where to put information. They rarely teach you what deserves the reader’s attention. And the document should preserve the work needed to understand a confirmed risk. It should also show how to reproduce it, fix it, and verify the result. Dead ends, every command, and every screenshot belong in your working notes unless they help the reader interpret the final result.

Hack The Box puts the writing problem neatly: “Writing is a technology. One that’s been invented independently at least four or five times in humanity’s history.” Your first report does not need to prove that you were born a security writer. It needs a repeatable method.

A report that makes the reader reconstruct the attack path is not thorough; it is unfinished.

Decide who must act before you write

A report serves two audiences with different stopping points. Leadership needs the decision quickly. Engineers need the detail that follows.

Reader	Needs first	Needs in the layers below
Executives and security leads	Consequence, affected business area, and mitigation priority	Exposure, limitations, and the decision required
Technical teams	Affected component, verified condition, and remediation direction	Parameters, root cause, reproduction steps, and evidence

Use one report with layered detail. Summarize the decision once and connect it to the technical finding. Keep one version of the risk.

Consider this fictional, illustrative example: an unauthenticated /admin/export endpoint returns customer records. This endpoint and its behavior are invented to demonstrate report writing.

For an executive, the finding might read:

The application’s /admin/export endpoint returned customer records without requiring an authenticated session. The owner should restrict the endpoint to authorized users and review whether existing export links remain valid after authorization is added.

For an engineer, the same finding needs the tested method, request, response, authentication state, affected data, reproduction steps, and remediation detail. The executive version answers, “What decision should we make?” The technical version answers, “What condition must we change, and how will we verify it?”

Executives need the consequence and decision, not a tour of the attack chain. Technical teams need the attack chain because it tells them what to change.

UpGuard recommends translating board-level cyber risk into “dollars and cents.” Use that approach only when the engagement supports a defensible number. This process won’t tell you the true business cost when the engagement didn’t measure records or downtime. It also did not measure recovery expense; in that case, I’d rather report a precise exposure than manufacture a dollar figure.

Report the verified exposure and identify what the client should decide. Precision beats theatrical arithmetic.

Put the decision at the top, then preserve the evidence underneath

Leadership should be able to understand the exposure before opening a packet capture or tool transcript. Draft the detailed findings first, then write the executive summary once the facts and remediation are stable.

The document should follow the reader’s journey:

1. Executive summary: Explain what was assessed and its principal consequences. Cover the important findings and required decisions or mitigations. Include an incident or threat summary only when the engagement involved an incident or identified threat.
2. Scope and limitations: Define the systems and environments assessed. Include dates, exclusions, test accounts, and conditions that limit interpretation.
3. Methodology: Describe the assessment approach briefly. Name standards or tools when they clarify coverage.
4. Findings overview: Show how many findings there are and how their severity is distributed. Use the same labels throughout.
5. Detailed findings: Give each confirmed weakness its condition, impact, evidence, remediation, and boundaries.
6. Remediation and retest status: State the recommended actions and whether fixes were verified, pending, or outside the engagement.
7. Appendices: Move detailed requests and tool output here. Put terminology and other supporting material here too.

That is enough architecture for most penetration testing reports and security assessment reports. The rest is reader flow.

The fictional /admin/export issue belongs in the summary as a decision:

The assessment confirmed an access-control weakness in the application’s /admin/export endpoint. The endpoint returned customer records without an authenticated session. Remediation requires server-side authentication and authorization checks, followed by a review of whether existing export links remain valid.

The detailed finding then supplies the proof and implementation context. This order gives each reader a usable entry point: leadership sees the decision, owners see the action, engineers see the condition, and auditors can check the record.

CVSS is useful metadata, not a substitute for explaining business impact. A severity number cannot tell an owner what to fix first.

If your organization uses CVSS, state that scoring system and include the score and vector where required. Explain the technical rating using the relevant attack conditions and privileges. Include user interaction and affected security properties. Keep that score separate from business priority. If the organization applies a local severity adjustment because of asset criticality and data sensitivity. Also note exposure or compensating controls, say so and explain the reason. A local priority is an organizational decision; it is not a disguised CVSS score.

Write every finding so a stranger can understand and act

Title the finding with the condition and target:

Unauthenticated access to customer exports in /admin/export

“A access-control issue” gives the reader a category and nothing else. A useful finding answers seven questions.

• What happened?
• Where did it happen?
• How was it verified?
• Why does it matter?
• How serious is it under the stated method?
• What should happen next?
• What are the boundaries of the evidence?

TrustedSec defines plain language as language that “can be understood by a listener/reader the first time it’s encountered” and says its aim is clarity and accessibility, not “dumbing down” content. That is the right standard for technical security writing.

Plain language is technical writing that does not force the reader to translate every sentence. Use a concrete subject and verb. Replace “it” with the endpoint or control when the pronoun could be ambiguous. Name the service or account when needed. Expand abbreviations on first use. “Operations team” helps more readers than “Ops,” and “headquarters” is clearer than “HQ.”

Before and after

Weak, deliberately weak

The application has a high-severity issue that could allow unauthorized access.

This sentence hides the endpoint, access condition, affected resource, and action. “Issue” says almost nothing. “Could potentially” adds fog rather than useful uncertainty.

Stronger

The /admin/export endpoint returned customer records without requiring an authenticated session. An unauthenticated user could download the export URL and access the records. Restrict the endpoint to authenticated, authorized users, then review whether existing export links remain valid after authorization is added.

The first sentence states the verified condition. The second states the demonstrated access path. The third gives the owner an ordered remediation requirement. The example remains fictional and illustrative.

Use passive voice when it makes the condition clearer. “The account was disabled during retesting” is perfectly serviceable when the actor is irrelevant. Avoid passive constructions that hide the owner or action.

State the root cause when you know it. If you verified missing authorization at the endpoint but did not establish which framework component caused it, report the access-control condition. Guessing about middleware or development process weakens the finding.

Remediation should name the control and its location. “Apply security best practices” is how a finding gets filed, admired, and ignored. For this fictional endpoint, require authentication and server-side authorization checks, then review existing export links. If those links remain valid after authorization is added, invalidate or replace them. Those are remediation requirements, not observations about what the test already proved.

Finally, describe the expected verification result. An unauthenticated request should receive an authorization failure, and a permitted user should retrieve only the records their role allows. Retesting must establish that result; a recommendation is not a retest.

Evidence should prove the claim, not decorate the page

Scanner output can point you toward a finding, but manual verification makes it evidence. If you did not manually verify the finding, do not present it as a confirmed weakness.

Put the method, URL or parameter, and authentication state in text. Include the response and expected result. Use the screenshot to make the decisive visual fact easy to confirm. Screenshots supplement reproduction steps. They do not replace them.

For the fictional /admin/export finding, the written steps should explain how to make the request safely in the designated test environment and what response establishes the condition. The screenshot should show the relevant request and response, with the successful access result visible.

A useful screenshot gives context, shows the relevant step, and makes the achieved objective clear. Zoom into the proof. Add a box, circle or arrow when it reduces search time. Remove unrelated commands. Redact credentials, tokens, personal information, and client data.

Caption the fictional illustration: “Unauthenticated request returns customer export; token, names, and values redacted.” A caption like that tells the reader where to look. A full desktop, ten unrelated commands, and one tiny line of evidence do the opposite.

State whether the evidence came from production, staging, or a designated test environment. If testing stopped after confirming access, say so. A precise boundary prevents the reader from inferring a larger exposure than the assessment established.

Edit in passes because the first draft is supposed to be bad

Editing is part of the assessment. It is more than administrative polish. Every unclear sentence adds a question the reader must answer before assigning or fixing the issue.

Draft the findings first. Leave at least 15 minutes before editing; a day or two is better when the schedule allows. Hack The Box offers advice worth keeping: “Some of the best writing advice I’ve ever gotten is to write the first draft badly, and come back to fix it later.” Edit the findings, write the executive summary, then run one final consistency pass across the whole report.

Use five passes:

1. Accuracy. Check scope, assets and endpoints against the test record. Check affected data, evidence references, severity, remediation and retest claims too.
2. Reader test. Mark every consequence and decision in the summary. In each finding, mark every missing asset, proof reference, owner action, or reproduction detail.
3. Language. Replace vague nouns, unclear pronouns, unexplained acronyms, and unnecessary tool narration. Cut process detail that does not help interpret the result.
4. Consistency. Reconcile finding counts and severity labels. Then check terminology, capitalization, acronym usage and list order. Check every table, chart, summary, and cross-reference.
5. Presentation. Check headings, tables and page breaks. Review screenshot legibility, redactions, navigation and exported PDF formatting.

Read the report aloud. Then read a section from the bottom upward. Reverse reading interrupts the narrative flow and exposes repeated, incomplete, or awkward sentences that your brain skips in normal order. Change the font or background if the page has become visually invisible to you.

Use a checklist instead of trusting memory. Ask another person to read it if available: a non-author can test the business explanation, while a technical peer can test reproduction. One outside reader is better than none.

Avoid the shortcuts that make a report unreliable

The common failures are mundane: wrong scope, unverified output, missing retest status, and a reader nobody identified. Treat these as process checks.

• Scope drift: Confirm hosts and applications first. Then check accounts, dates, environments and exclusions. Don’t imply coverage for systems the engagement did not assess.
• Scanner dependence: Manually check automated findings, record what you observed, and label unverified output as a lead.
• Missing retest status: State whether a fix was tested, when it was tested, and what result was observed. If retesting was outside the engagement, say so.
• Reflexive compliance mapping: Map findings to NIST, ISO, CMMC, PCI, or another framework only when the engagement requires that coverage and the testing supports it. A control reference does not prove compliance.
• Stakeholder mismatch: Confirm the audience and severity scale before writing. Check the required format and decision deadline too. A technically accurate finding still needs an identified owner and next action.

These are general reporting recommendations reflected in guidance from Indusface and GuidePoint Security, rather than measured universal outcomes. Use them to challenge your workflow, not to attach unsupported statistics to your report.

Run this final read-before-send checklist

Copy this into your internal QA ticket:

Decision

• Executive summary is near the front.
• Executive summary states the consequence and required decision.
• Scope and exclusions are explicit. So are dates, environments and limitations.
• Each recommendation identifies an owner action.

Evidence

• Every finding names the asset and condition. It also states the impact, severity method, remediation and evidence reference.
• Confirmed findings were manually verified.
• Unverified leads are labeled clearly.
• Reproduction steps identify authentication state and expected result.
• Screenshots show context and proof.
• Credentials, tokens, PII, and client data are redacted.
• Retest status says whether the fix was verified.

Consistency

• Finding counts match in prose, tables, and charts.
• Severity labels and local priority decisions are consistent.
• Acronyms and capitalization match. So do terminology and list order.
• Compliance references appear only where the engagement supports them.
• A non-author read the business explanation, if available.
• A technical peer checked reproduction, if available.

Before sending, ask whether the decision-maker can prioritize the issue, the owner can assign it, and the engineer can verify the fix. If any answer is no, the report is still part of the assessment.