We closed Module 5 with an idea that now becomes the axis of the whole of Module 6: the technical work is done; the work of turning it into value for TechNova begins. During the reconnaissance, scanning, exploitation, and post-exploitation phases we captured a mountain of raw material: commands, outputs, timestamps, artifacts, the compromise chain, and the map of the internal network 10.10.10.0/24. None of that is worth anything to the client while it stays in your notes folder. The report is the deliverable that gives the pentest its value: it is what TechNova paid for, what its leadership will read, and what its engineers will use to remediate and reduce risk.

This first lesson is about how to document each finding so that it is reproducible, traceable, and actionable, and about how a pentest report is structured. We are not getting into how to score severity with CVSS yet (that is 06-02), nor how to write remediations in depth (06-03), nor how to present the results in the closeout meeting (06-04). Here we build the brick the report is raised with: the well-documented finding. And a warning that runs through the entire lesson: the report contains real, exploitable vulnerabilities of TechNova; it is a highly confidential document and is treated as such from the very first field note.

1. Document during the test, not after
2. Anatomy of a finding
3. Reproducible evidence and proof of concept (PoC)
4. Traceability: from finding to raw evidence
5. Field notes and the logbook
6. Handling sensitive evidence and confidentiality
7. Structure of a pentest report
8. Finding template: TechNova's SQLi from start to finish
9. Common Mistakes and Tips
10. Exercises
11. Conclusion

The most expensive mistake a novice pentester makes is leaving the documentation until the end. When you are two weeks into a test, have compromised five machines, and have pivoted across half the network, it is impossible to reconstruct from memory which exact payload worked against producto.php?id= on a Tuesday afternoon. Documentation is done in the moment, while the evidence is fresh and the terminal still shows the output.

The practical rule: every time you achieve something relevant, an enumerated service, a confirmed vulnerability, an access obtained, you capture the evidence right then and jot down the minimum needed to reconstruct it later (asset, time, command, result). The final report is written up when you finish, but it is fed throughout the entire engagement.

A finding is the report's basic unit: it describes one specific weakness in one specific asset. A good finding answers, without the reader having to ask: what it is, where it is, how you demonstrated it, what damage it causes, and what to do about it. These are its fields:

Each of these fields has a purpose. Missing any one and the finding loses its usefulness: without the asset, no one knows where to fix it; without reproduction steps, the client cannot validate it; without business impact, leadership does not understand why to prioritize it.

Evidence is what turns a claim into a fact. "The site is vulnerable to SQLi" is an opinion; a screenshot of the server's response returning the MySQL version in reply to your payload is proof. Best practices for capturing evidence:

• Reproducible: include the full command/request and the verbatim output. Whoever reads the report should be able to repeat the step and get the same result.
• Minimal but sufficient: show just enough to prove the point. Do not dump 4,000 rows of a table; a single row that demonstrates access to sensitive data is enough.
• With context: note the date, time, source host, and target asset on each piece. A screenshot without context is worthless as proof.
• Without causing real harm: the PoC demonstrates the problem, it does not exploit it destructively. You extract a sample record to prove access, you do not dump or exfiltrate the client's entire database.
• Sensitive data masked: if the evidence contains real personal data of TechNova customers, redact it (anonymize) in the report: juan.****@***.com. You demonstrate access without spreading the data.

The proof of concept (PoC) is the specific, controlled sequence that demonstrates exploitability. In a professional report the PoC is enough to convince, not enough to cause harm: it shows the path, it does not hand over a ready-made weapon to abuse.

Traceability means that every claim in the report can be followed back to the raw evidence that supports it. It is what makes your work auditable and defensible: if TechNova (or a third party) questions a finding, you can show the original screenshot, the tool's log, and the exact time.

A simple but effective traceability scheme:

In practice this takes shape by naming evidence files consistently (TN-001_sqli_product_response.png), storing them in a folder per finding, and referencing them from the report. That way, the finding ID is the thread that ties the field note, the evidence, and the recommendation together.

Field notes are your raw record during the test. We already stressed the logbook in Module 5 from the ethics angle (leaving an auditable trail); here we look at it from its usefulness for the report. A useful logbook entry captures, for each relevant action:

With timestamps, source, target, action, and a reference to the evidence, any entry later becomes part of a finding or of the attack timeline. The logbook also protects the pentester: it demonstrates that you stayed within the authorized scope.

The report and its evidence are sensitive material: they document how to compromise TechNova's real systems and may contain its customers' data. Treating this lightly is a serious professional failing. Principles:

• Confidential by default: the report is classified as confidential and is only shared with the interlocutors authorized in the contract.
• Encryption at rest and in transit: notes, screenshots, and the report are stored encrypted and delivered over a secure channel (never by unencrypted email). Secure delivery is detailed in 06-04.
• Minimization: do not capture more sensitive data than needed to prove the finding; mask what you do capture.
• Retention and destruction: agree with the client how long you keep the evidence, and destroy it securely when that period expires.
• Access control: only the engagement team accesses the evidence; no copies on unencrypted personal devices or in unauthorized cloud services.

Remember: leaking a pentest report means handing an attacker an exact map of how to get in. Confidentiality is not bureaucracy, it is part of the service.

A professional report serves two audiences at once, and that is why it is organized into two large blocks (communicating to each audience is worked on in 06-04). Typical structure:

The golden rule: the executive summary reads without technical knowledge; the technical detail reads with it. A director must understand the risk without knowing what a SQL injection is; an administrator must be able to reproduce and fix the problem from the technical detail.

We bring everything above together into a reusable template, documenting the engagement's flagship finding: the SQL injection in producto.php?id= that we exploited in Module 4.

This template is self-explanatory: whoever reads it knows what is happening, where, how to test it, what is at stake for TechNova, and where to start fixing it. Notice that the PoC demonstrates access (a single sample row) without dumping bulk data or causing harm: sufficient evidence, controlled impact.

• Documenting from memory at the end. Critical details are lost and the evidence stops being reproducible. Capture in the moment, always.
• Evidence without context. A screenshot without date, host, and asset proves nothing. Note the context on each piece.
• Dumping the client's real data into the report. Mask sensitive data: demonstrate access, do not spread the data. A leaked report should not be an added data breach.
• A finding that mixes two problems. One finding = one weakness = one asset. If there is SQLi and XSS, those are two findings with two IDs.
• Vague titles. "Security problem on the website" helps no one. Be specific: "SQL injection in producto.php".
• [Ethics] Treating the report as any old document. It contains real, exploitable vulnerabilities; encrypt it, control it, and deliver it over a secure channel.
• Tip: write the impact thinking about who decides the budget. "Extracts the database" is technical; "exposes every customer's data" is business. Both matter, each in its section.

Exercise 1. During the test you discover that the store's admin panel (https://tienda.technova.lab/admin/) is accessible without authentication and displays customer orders. Write a complete finding following the anatomy in section 2 (title, asset, description, impact, reproduction steps, evidence, and a summarized recommendation). Assign it an ID.

Exercise 2. A colleague hands you this note: "the site has bugs, we need to fix it". Explain why this note is useless as a finding and list which fields it is missing to become one.

Exercise 3. You are about to include in the report a screenshot that shows the full usuarios table with 12,000 real emails and hashes of TechNova customers. Explain what you do before including it and why, relating it to handling sensitive evidence.

Solution 1. Example finding:

• ID: TN-2026-014
• Title: Admin panel accessible without authentication
• Affected asset: https://tienda.technova.lab/admin/
• Description: The /admin/ directory does not require authentication; any user who knows or guesses the path reaches the panel and views customer orders. This is an access-control failure (broken authorization).
• Impact: An unauthenticated attacker gains access to customers' personal and order data. For the business: a data breach, regulatory non-compliance, and reputational damage.
• Reproduction steps: (1) browse to https://tienda.technova.lab/admin/; (2) observe that the panel loads without asking for credentials and lists orders.
• Evidence: screenshot of the panel with customer data redacted (TN-014_admin_no_auth.png).
• Recommendation (summary): require authentication and role-based authorization across all of /admin/; deny by default. Reference: OWASP A01:2021 (Broken Access Control), CWE-284.

Solution 2. The note is useless because it is not reproducible, not traceable, and not actionable: it does not say what fails, where, or how to demonstrate it. It is missing every field of a finding: ID, specific title, affected asset, problem description, severity, business impact, reproduction steps, evidence/PoC, and recommendation. As it stands, TechNova can neither verify nor fix anything.

Solution 3. Before including it, I mask the sensitive data (anonymize the emails and include no real hashes) and reduce the evidence to a single sample row that is enough to prove access, not the whole table. Reason: evidence must be minimal but sufficient and must not turn the report into a data leak. Extracting and dumping 12,000 real records exceeds the necessary PoC, increases the risk if the report leaks, and may violate data protection. I demonstrate access without spreading the data, and I store the evidence encrypted with restricted access.

We have turned Module 5's raw material into the report's fundamental unit: the well-documented finding. We saw its full anatomy (title, asset, description, impact, reproduction steps, evidence/PoC, severity, and recommendation), the importance of capturing reproducible evidence in the moment, the traceability that ties every claim to its raw evidence, the role of field notes, and, very much front and center, handling sensitive evidence: the report contains TechNova's real vulnerabilities and is treated as confidential material from start to finish. We also fit the finding within the report's structure, with its executive summary for the business and its technical detail, and we left a reusable template applied to TechNova's SQLi.

We now know how to document each finding; the next step is to prioritize them. In the template we wrote "Severity: Critical | CVSS 9.8" and promised to justify it. That is exactly what the next lesson does, 06-02: Risk Classification and CVSS, where we will learn to calculate and read a CVSS vector, to translate the score into a rating, and, above all, to distinguish technical severity from business risk for TechNova. Documenting is having the pieces; classifying is knowing which to attack first.