Writing a Finding

The technical observations — the findings — are the substance of the report. A finding documents a specific weakness that let you penetrate further into the environment, and it provides the detail the client needs to understand, reproduce, and fix it. The vast majority of findings trace back to one of three root causes: authentication (weak, default, or missing credentials), configuration (something set up insecurely), or patching (out-of-date or unsupported software). Keeping those three families in mind helps you both classify a finding and, later, recommend the right fix for it.

A finding is not a diary entry and it is not a vibe. It is a structured artifact. The discipline of the next section — always filling the same slots, in the same order — is what makes a report consistent across dozens of issues and credible to a reader who was not there when you found them.

Every credible finding carries the same set of fields. Each one exists to answer a specific question, and leaving one out leaves the reader guessing:

The title deserves a moment of its own. A vague title forces every reader to dig into the body just to learn what the finding is about; a precise one lets an executive scan the findings list and grasp the engagement at a glance. If you can read your titles top to bottom and understand the shape of what went wrong, you have written them well.

Abstract structure clicks when you see it filled in. Here is a complete finding from a sample engagement against the practice client Valley Veterinary Ventures, written the way it would appear in a real deliverable:

One of the most common mistakes is padding a report with things that are not findings. "You are not using up-to-date SSL ciphers." "Host XYZ is running telnet, which isn't encrypted." On their own, these are best-practice deficiencies — the kind of thing you would report if you were hired to run an audit or a vulnerability assessment, but not, by themselves, penetration-test findings.

The distinction is demonstrated risk. A pentest is an attack simulation; a finding shows that a weakness led somewhere — that you used it to gain access, escalate, or move. "Telnet is running" is an observation. "Telnet was running, I captured plaintext credentials on it, and used them to log into the domain controller" is a finding. If you cannot connect a weakness to an outcome you actually achieved or could clearly achieve, it belongs in a hardening recommendation or an appendix, not in the findings.

Spend enough time testing and you will meet the same handful of issues across client after client. Because they recur, you build reusable templates for them — but always review and customize each one for the specific environment. The usual suspects:

• Weak authentication / password policy — short minimums, no complexity or passphrase guidance, no check against breached-password lists, infrequent or absent MFA, and weak or missing password hashing. The most common family of all, because attackers prefer to walk in the front door.
• Insufficient patching — out-of-date or end-of-life software at the OS or application layer (an unsupported Apache Tomcat, say). Often medium impact, but capable of rising to remote code execution.
• Default credentials — the factory accounts that should never survive deployment but constantly do: admin/admin, cisco/cisco, root/toor, pi/raspberry. Especially common on IoT and networking gear; severity hinges on where the device sits and what it can reach.
• Default web pages — the untouched "It works!" install page. No direct exploit, but it signals incomplete setup and invites an attacker to look harder for what else was left half-configured. Scanners like Nikto surface these quickly.
• Undetected malicious activity — in a stealth engagement, documenting what the defenders did not catch is itself the finding: the nmap sweeps, brute-force attempts, vulnerability scans, or the phishing click that opened a reverse shell, all of which sailed through unnoticed.
• Historical account compromises — credentials for the target that already appear in public breach data, surfaced during reconnaissance. Present the exposed usernames and emails to the client — but always obfuscate the passwords, because the report will be passed around.

Reviewers who read a lot of reports see the same failures repeatedly. Learn them so your own findings never become the example:

• Contradicting your own notes. A finding that claims you "reversed weak password hashes" when your appendix says the application stored passwords in cleartext is worse than no finding — it destroys trust in the whole report. Proofread the body against the appendix.
• Claiming you fixed it. You do not remediate the client's systems for them. A finding that says you "located and fixed the vulnerable code to reduce exposure" is a red flag — would you trust someone who shows up, tells you there is a problem, and then quietly changes your production code? Identify and recommend; do not touch.
• Leaving placeholder junk in. "Fixing the configuration will no longer allow evil connections by evil connection for configuration of server." Real, un-edited, shipped. Replace every placeholder with a real identification and read it aloud before delivery.
• Reporting your own mishaps as findings. "Our scan crashed the cluster, so we switched tools." That is a note for the engagement log, not a finding about the client's security.
• Vague copy-paste. A template reused without customization reads as exactly that. The template saves you time on structure; the specifics are still yours to write.

You can practice composing a finding — and watch a quality checker flag several of these mistakes in real time — in this phase's hands-on Report Builder.

Every field in a finding is downstream of one thing: the notes and screenshots you captured during the test. This is not a detail to leave to memory. Engagement access is frequently time-boxed — you may have only a couple of hours against a host, and once that window closes you cannot go back to rescan or grab the screenshot you forgot. A finding is only ever as strong as the evidence you captured in the moment.

So build a workflow and use it relentlessly: a reliable note-taking tool and a fast screenshot habit, capturing as you go. Be quick but detailed — record the command, the host, the timestamp, and the result for anything that might become a finding. The tester who writes great reports is usually just the tester who took great notes.

Next: the same engagement, written two ways — the executive summary for the boardroom and the technical detail for the engineers.