A security finding becomes useful when someone can understand it, reproduce it safely, and decide what to fix. A scanner label or a dramatic screenshot is rarely enough. A good report connects an observed behaviour to an expected control, explains the conditions required, and separates demonstrated impact from speculation. Clear reporting is a technical skill that ethical hacking learners should practise alongside testing.
This guide describes a finding template for an authorized assessment of a fictional training application. The example uses synthetic records and supplied accounts. It does not claim an actual vulnerability in Softenant or any other organisation. The deliverable is a report that a developer and a business owner can both use without exposing unnecessary sensitive information.
Begin with a precise title
A title should name the affected control and the relevant feature. Student account can read another student’s private submission is more useful than critical hacking vulnerability. It communicates the account boundary and affected data without overstating the scale. Avoid including exploit secrets or private identifiers in a title that may appear in a broad ticket list.
Assign a stable finding identifier. The identifier allows discussions, code changes, and retest evidence to refer to the same issue even if wording changes. Record the assessment date and environment version so future reviewers know which application state the finding describes. An undated report quickly becomes ambiguous during active development.
Summarise the problem in plain language
The opening summary should explain the expected restriction and the observed exception. For the fictional example, private submissions should be visible only to their owner and assigned instructor. During an authorized lab check, one supplied student account could read a synthetic submission owned by the other supplied student account.
Keep the summary factual. Do not claim that all records, every account, or production data are affected unless that scope was actually established. Explain why the observation matters while preserving the boundary between demonstrated access and potential consequences. The reader should understand both the problem and the limits of the evidence.
Record scope and prerequisites
List the affected environment, feature, account role, and resource state. Include whether a login is required and whether a specific configuration or workflow is necessary. A problem affecting draft submissions may differ from one affecting published examples. These conditions help developers reproduce the behaviour and avoid dismissing a valid finding because they tested a different state.
State the authorization and synthetic-data context in the assessment record. The finding itself can reference that scope rather than reproducing the entire agreement. Record any blocked tests or unavailable roles. Missing coverage should remain visible; it should not be silently converted into an assumption that other paths are safe.
Write minimum reproduction steps
Use numbered, deterministic steps with supplied test accounts and records. Describe what to open, which agreed action to perform, and what result to inspect. Include enough detail for a developer with access to the lab to reproduce the observation. Avoid unnecessary requests or unrelated exploration that distracts from the failing control.
After the steps, state the expected result and actual result separately. In the example, expected means access denied without private submission content; actual means the synthetic text was returned to the other student. This separation prevents readers from having to infer the problem from a long request log.
Attach focused evidence
Useful evidence may include a redacted request and response, a screenshot of synthetic content, a timestamp, and a reference to the relevant test case. Highlight the exact field or behaviour that supports the claim. A large attachment containing thousands of unrelated lines makes the important observation harder to review.
Remove session cookies, access tokens, passwords, and private records before distributing the report. Keep protected originals only where the assessment process requires them. A public portfolio should use an owned lab and sanitised examples. Permission to assess a system does not automatically authorize publication of its findings or architecture.
Explain impact without exaggeration
Describe what the demonstrated access allows in the tested scenario. Reading another student’s private work affects confidentiality; modifying it would affect integrity, but that should not be claimed as observed if modification was not tested. State the distinction clearly. Potential consequences can be discussed as possibilities with their necessary assumptions.
Assess severity using the organisation’s agreed method. Consider required privileges, exposure, affected data, reach, and business context. If a scoring framework is used, record the chosen inputs and rationale. A number without its reasoning can appear objective while concealing unsupported assumptions about access or impact.
Recommend a control, not a guess
A useful recommendation explains the missing security property. For an ownership issue, the application should consistently verify that the authenticated actor is permitted to access the requested resource. Developers can then choose the appropriate implementation within their architecture. A tester should avoid prescribing a specific code patch without understanding the relevant code and data model.
Include related regression cases. The repair should deny the prohibited access while preserving legitimate access for the owner and assigned instructor. If the same permission pattern appears in exports or edit actions, recommend reviewing those paths within an agreed scope. This makes remediation more complete than changing one screen.
Track remediation decisions
Record the responsible team, status, target review date, and relevant change reference. Possible statuses include open, being fixed, ready for retest, fixed, partially fixed, and accepted risk according to the organisation’s process. Do not mark a finding fixed merely because a developer says a change was deployed.
If the owner chooses a temporary mitigation, document what it changes and what remains. Restricting a feature may reduce exposure without correcting the underlying permission check. The report should distinguish mitigation from a verified permanent repair so later teams do not assume that the original issue disappeared.
Retest on the correct version
Confirm the environment and deployed change before retesting. Repeat the original permitted scenario, then selected neighbouring positive and negative cases. Use the same synthetic-data design where possible so comparisons remain meaningful. A test against an old build cannot determine whether a new repair works.
Capture fresh evidence and link it to the original finding. If the original failure is no longer reproducible but related cases still fail, describe the repair as partial. If the environment is unavailable or the account cannot log in, mark the retest blocked. Neither condition proves that the security control is correct.
Provide an executive summary
The summary should explain the assessment scope, major confirmed risks, overall limitations, and next actions in ordinary language. It should not contain raw tokens or lengthy technical payloads. A business owner needs to understand which decisions require attention and which conclusions remain uncertain.
Keep the technical section available for developers. One report can serve both audiences when it uses a short summary followed by structured findings. Separate observations that are informational from demonstrated vulnerabilities. This helps teams prioritise without ignoring useful configuration or process improvements.
A portfolio exercise
Create a fictional finding from a controlled lab observation. Include the title, scope, prerequisites, steps, expected and actual results, sanitised evidence, impact, recommendation, and retest plan. Then ask another learner to reproduce it using only the report. Revise any step that requires an undocumented assumption.
Next write two retest outcomes: one where the repair works and one where legitimate users are also blocked. Explain why the second result is not a satisfactory fix. This exercise demonstrates that security work includes functional correctness, clear communication, and evidence-based closure, not merely finding an initial failure.
Frequently asked questions
Should scanner output be copied directly into a report?
Treat it as a lead for validation. Confirm the relevant behaviour, remove irrelevant material, and write a finding supported by the authorized assessment evidence.
Can a screenshot prove the entire impact?
Usually it proves only a specific observation. Add prerequisites, steps, and a careful explanation. Avoid extending a narrow screenshot into an unsupported claim about all users or records.
When is a finding closed?
When the agreed process has evidence that the required control works on the intended version, including relevant legitimate-use checks, or when the responsible owner formally records another accepted disposition.
Reference: OWASP guidance on reporting.