Writing Pentest Reports (TryHackMe)

In penetration testing, your most important deliverable isn't the shell you popped or the number of vulnerabilities found — it's the report. A professional pentest report communicates your findings, their impact, and recommended fixes in a way that resonates with technical teams, security stakeholders, and business leaders alike.

This room introduces the core principles of impactful reporting, guiding you through the structure, tone, and audience targeting needed to deliver actionable, client-ready documents. Whether you're reporting on a web application, internal network, or cloud environment, your ability to write clearly and effectively can determine whether your work leads to real security improvements — or gets ignored.

You’ll explore how to:

• Tailor your report to different audiences

• Write strong summaries and vulnerability descriptions

• Provide clear, contextual remediation advice

• Conduct QA to ensure clarity, professionalism, and accuracy

By the end of this room, you’ll understand that writing well is not an afterthought — it's a critical skill in offensive security.

Introduction

You’ve completed a penetration test. The artefacts from your tools are saved, and the shells are gone. But your most important deliverable remains: the report.

This room focuses on how to write professional, client-ready penetration testing reports that communicate what happened, why it matters, and what to do about it. You will not just learn how to explain vulnerabilities but also how to speak to both business and technical audiences.

We’ll break the process down into three core ideas:

• Why reporting matters - Reports are the only lasting output of your engagement. Teams change. Systems are updated. Reports stay.

• Who you’re writing for - Understand the different audiences (executives, developers, security engineers) and how to communicate with each.

• What makes a good report - Learn the structure, writing style, and remediation guidance to ensure your report is as useful as it can possibly be.

Scenario

You have just finished a penetration test for a client. Now, it is time to put everything you discovered into a clear, professional report that highlights the risks and helps the organisation move forward. The quality of your report will determine how seriously your findings are taken — and whether they lead to real change.

Prerequisites

No prior reporting experience is needed.

Learning Objectives

By the end of this room, you will be able to:

• Understand the purpose and long-term value of a pentest report

• Identify the different audiences of a report and tailor your language and focus points accordingly

• Communicate technical findings with business context and risk impact

• Write actionable, prioritised remediation guidance

• Apply a clean, professional tone and reporting style

• Perform basic QA checks to ensure consistency and accuracy

• Practise writing complete report sections based on real assessment data

Answer the questions below

I am ready to learn about writing a professional pentest report!

The Anatomy of a Pentest Report

Audience, Lend Me Your Ears

Every good report is built around a clear, logical format. This structure helps you present findings in a way that makes sense to both business and technical stakeholders. Before we can dive into the anatomy of a good report, we first need to understand the different audiences that your report should aim to address:

• Technical Stakeholders - Ultimately, your report aims to aid the technical team in understanding the root cause of the discovered vulnerabilities and what steps they will need to take to remediate them. If you performed a pentest of a web application, this will most likely be the developers of the application. If you assess a network, your report will most likely need to provide guidance to the IT Support team. As this is the most crucial audience, you would usually find that around 70-90% of your report is specifically aimed towards this audience.

• Security Stakeholders - Usually, it isn't the developers or IT support team that requests the pentest. More than likely, the organisation's security function was involved in ensuring a security assessment was performed as part of the go-live process. This team won't be directly responsible for remediating the vulnerabilities but will be working very closely with those that are. As such, sections of the report will have to provide guidance to the security personnel to better help them prioritise remediation efforts and make sound judgement calls on which risks have to be addressed before the system goes live and which can be accepted. While this team will usually review your entire report, at least 10-20% of the report should speak to this audience directly.

• Business Stakeholders - "Security must enable business, not fight against it." A common phrase you would hear in the pentesting field. Usually, someone other than the developers and security personnel are paying for the assessment. Furthermore, these individuals are usually much less technical and more business-driven. A key piece of your report needs to speak to this audience to help them better understand the business impact of your findings. What could the actual real-life impact be if they choose not to remediate the vulnerabilities? At least 5-10% of your report should speak to this audience in a manner that is abstracted from the technical work.

Sections of the Report

Now that we understand the audience our report needs to speak to, let's take a look at the three main sections that you would require:

Section	Target Audience	Description
Summary	Business & Security Stakeholders	This is the high-level view of the assessment. It explains what was tested, what was found, and why it matters — all in business terms. In certain cases, you would create an executive summary that speaks directly to the business stakeholders only in business terms and then a more detailed Findings and Recommendation section to aid security stakeholders in their prioritisation efforts.
Vulnerability Write-Ups	Technical Stakeholders	This is the technical heart of the report. Each issue discovered during the test gets its own write-up, which will include details on the vulnerability, how it can be replicated, and the actions required for remediation.
Appendices	Security Stakeholders	The appendices provide supporting details that don’t fit in the main report. This could include elements such as the detailed testing scope, methodology, or artefacts that were left over from testing. These appendices are usually used by the security stakeholders to help them better understand the coverage that was achieved during the engagement and the next steps that would be required once remediation has been performed.

Why this matters

A well-structured report makes it easier for your audience to take action. Business leaders can assess risk, and technical teams can start remediation. If your report lacks structure, even good findings might be ignored. In the next tasks, we’ll closely examine each of these sections.

Answer the questions below

1. Which stakeholder should 80% of your report be aimed towards?

2. Which section of the report is for extra information that can sometimes help security stakeholders better understand what coverage was achieved and the next steps that should be followed?

Report Section 1: Summary

The summary plays a critical role in helping readers quickly understand the results of your assessment without needing to dive into the technical details. It connects your work to real-world business and security impact. The summary typically appears at the start of the report and should allow a reader, even someone without a technical background, to answer these questions:

• What did we test?

• What did we find?

• What does it mean for our business or system?

• What should we do next?

Ideally, you should write the summary last. If you haven't written the other sections, it will be hard to accurately summarise your findings.

Summary of a Summary

In some cases, a single summary section is not enough to meet the needs of both business and security stakeholders. When this happens, it’s common to break the summary into two parts:

• Executive Summary - Written for business stakeholders, this version avoids technical jargon and focuses on business risk. It highlights the overall security posture and key concerns in a way that helps business stakeholders understand the impact of the findings and the actions that should be taken immediately.

• Findings & Recommendations - Written for the security team, this section details common vulnerability themes and attack chains. Vulnerabilities have risk ratings that are measured in isolation as if none of the other vulnerabilities existed. However, you may often find that the combination of two or more lower-risk vulnerabilities could still have high business impact. This is the section where you are able to highlight this to security stakeholders, helping them reprioritise remediation to address these issues. This section often draws links between issues and identifies systemic problems, allowing security stakeholders to use this information to help developers avoid future mistakes.

Summary Structure

Regardless of whether you split the summary into two or keep it as one, a good summary should cover the following:

• Overview - What was tested? What type of system or application is it? What were the goals of the assessment? What was the scope, and how much coverage could be achieved?

• Results - What did the assessment uncover? Was the system secure? If not, what categories of issues were found?

• Impact - What is the real-world impact if the issues remain unaddressed? How could the system be exploited by a real-life threat actor?

• Remediation Direction - At a high level, what actions should the organisation take next? Does this require major investment, or are the issues mostly quick fixes?

The summary sets the tone for the entire report. If it’s too technical, business stakeholders will disengage. If it’s too vague, security teams won’t know what to do next. Knowing how and when to split the summary ensures your message reaches the right people, and leads to real action.

Summary Challenge

Click the View Site button to start the challenge of writing a summary.

A web application pentest was performed for TryBankMe, TryHackMe's new subdivision that will focus on banking. TryBankMe needed a security assessment of its flagship application, which allows users to create accounts and perform general banking tasks. The pentest found that the application was mostly secure, but a race condition vulnerability could be exploited in the transaction system to cause an infinite money glitch.

Select from the provided sentences to construct the optimal summary and get your flag!

Answer the questions below

1. What is the value of the flag?

   to get the appropriate matches, each box gets upto 100 points and the most accurate match the better. To make the right matches, reread the Summary structure in the notes i.e overview, results, impact and remediatuon direction, to understand what each section entails and try to go through the options. Also the challenge has no limitation of trying to find the highest mark so keep matching as you learn

   

Report Section 2: Vulnerability Write-Ups

The largest section of your report will be the vulnerability write-ups. Each write-up should explain what the vulnerability is, where it was found, how it was discovered, and most importantly, how it should be remediated. This section is primarily written for the stakeholders who are going to fix the issues, such as developers or system administrators. However, others, such as security analysts and project managers, may also review these sections to track remediation, provide support, or validate severity.

Structure of a Good Write-Up

To make your write-ups clear and actionable, you should follow a consistent structure for each one. Here's a format that works well:

• Title - A short, descriptive heading (e.g. "Unauthenticated SQL Injection in Login Form")

• Risk Rating - A risk rating for the discovered vulnerability. Vulnerabilities should always be rated in isolation, as if all other vulnerabilities did not exist and should either use the client's risk rating matrix or a public one, such as CVSS.

• Summary - A brief explanation of the vulnerability and its potential impact in plain language.

• Background - Provide additional context to explain the vulnerability and why it matters. This is especially important if the reader is unfamiliar with it. Remember that the developers who will fix the vulnerability are potentially not security experts, so more guidance to help them understand the root cause of the vulnerability will aid them in remediating the issue accurately.

• Technical Details & Evidence - Where and how the issue was found. Include requests, responses, payloads, and screenshots or code snippets if needed.

• Impact - What an attacker could realistically do with this vulnerability. This shows that you are not just providing the vulnerability without thinking about how a real threat actor could leverage it in the specific system or application where you found it. For example, it is common to say with XSS that the threat actor would steal the user's cookie to perform session hijacking. But what if the application uses tokens instead? Does that now mean that the impact is lower? Make sure to contextualise the impact to the specific system that you are testing.

• Remediation Advice - Clear, actionable steps to resolve the issue. It is critical to ensure that your remediation advice will address the root cause of the vulnerability. While you may want to provide additional measures that will aid in further mitigation, your first recommendation should address the vulnerability at its core. Consider, for example, SQL Injection. While sanitisation and input validation can help mitigate the vulnerability and make it harder to exploit, parameterisation is required to address the vulnerability at its core. This ensures that regardless of the input, there can be no confusion between the SQL command and user-supplied input. Always ensure that your recommendation will fully resolve the vulnerability, not just mitigate its impact. If you wish to provide further defence-in-depth controls, make sure to mention that these cannot be implemented in isolation.

• References - (Optional) Links to relevant vendor documentation or guidance to support the fix.

The Golden Thread

Although we are giving explicit sections here, at a certain point, reporting becomes so natural that you are able to create the entire write-up without requiring these exact headings or sections. Once you understand the structure of a good vulnerability write-up, you will be able to have a golden thread flow through your write-up meaning that readers will be able to follow, understand, and know what to do next without requiring explicit headings and sections. In certain cases, this can greatly help with the flow of your writing. However, in other cases, for example when your report will be ingested by vulnerability management software, having discrete sections is often still beneficial. Ideally, you should tailor your report structure to the specific client's needs.

Context Matters

Your report should never feel like it was copied from a textbook or another client’s report. The most valuable reports are those that explain vulnerabilities in the context of the specific system you tested. This means your write-up should answer questions such as:

• Where exactly was this vulnerability found? - Be specific by including the endpoint, parameter, or feature where the issue occurred.

• What assumptions are required for the vulnerability to be exploited? - Does the attacker need credentials? Does it only affect admin users? Is it only exploitable during a certain workflow?

• How does this affect this client’s environment? - If it’s a hospital system, could it leak patient data? If it’s an e-commerce site, could it affect transactions?

• What steps should this client take to fix it? - Go beyond generic fixes. If you know they’re using a specific tech stack, tailor your advice. If you know that they are using C# with MS SQL, show an example of how to fix SQL Injection specifically in C# for MS SQL database connections.

Example: SQL Injection Write-Up

Below is an example of a SQL Injection write-up:

Title: Unauthenticated SQL Injection in Login Form

Risk Rating: High (CVSS 3.1 Base Score: 8.6)

Summary: An unauthenticated SQL injection vulnerability was identified in the login form of the TryBankMe application. This could allow an attacker to bypass authentication or extract sensitive customer information.

Background:

SQL Injection occurs when user-supplied input is unsafely included in SQL queries without proper parameterisation. The SQL interpreter is unable to discern SQL commands from the user-supplied input, leading to confusion that allows a threat actor to inject directly into the SQL command itself. This vulnerability is commonly exploited to bypass authentication or extract sensitive data.

Technical Details & Evidence:

The login form at /login was vulnerable to SQL Injection via the username field. Using Burp Suite, the following HTTP request was intercepted and modified:

POST /login HTTP/1.1
Host: trybankme.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 45
username=' OR 1=1--&password=randomvalue

The application responded with a 302 Found redirect to the authenticated user dashboard:

HTTP/1.1 302 Found
Location: /dashboard
Set-Cookie: sessionid=abc123xyz456; Path=/; HttpOnly

This confirmed that authentication was bypassed using a classic SQL Injection payload.

Impact:

An attacker could log in as any user without valid credentials. Furthermore, even though the injection points were a blind-injection, a threat actor could leverage error-based injections to enumerate the information from the database.

Remediation Advice:

Parameterised queries should be used for all database operations involving user input. For example, in a .NET application using MS SQL as the database, the login query should be altered to look like this:

using (SqlConnection connection = new SqlConnection(connectionString))
{
  string query = "SELECT * FROM Users WHERE Username = @username AND Password = @password";
  SqlCommand command = new SqlCommand(query, connection);
  command.Parameters.AddWithValue("@username", inputUsername);
  command.Parameters.AddWithValue("@password", inputPassword);
  connection.Open();
  SqlDataReader reader = command.ExecuteReader();
  if (reader.HasRows)
  {
      // Login successful
  }
}

As shown in the example above, the user input is distinctly split from the SQL command, ensuring that the SQL engine cannot be confused.

References:

• https://tryhackme.com/room/sqlinjectionlm

Your vulnerability write-ups are the section that most readers will spend the most time in, especially those tasked with fixing the issues. Clear structure, solid evidence, and practical guidance make the difference between being ignored and being taken seriously.

Write-Up Challenge

Now it is time to put your reporting skills to good use and create the vulnerability write-up for the race condition in TryBankMe. Click the View Site and get reporting!

Answer the questions below

1. What is the flag?

   for this challenge it’s much detailed as compared to the previous one, try to understand what every section of the report

   

Report Section 3: Appendices

Appendices are especially useful for security stakeholders and future testers who may need to validate what was done, verify the scope, or follow up after remediation. There isn't usually a fixed format for appendices, and the format may vary from project to project. However, there are two main appendices that you should always aim to include in your report.

Assessment Scope

The assessment scope appendix should be used to establish how close the assessment was to what was originally scoped in the Rules of Engagement document. It may be that changes were made during the project or that it was impossible to gain coverage of the entire scope for various reasons. The assessment scope appendix is the perfect place to provide this information which can help security stakeholders understand the next steps. For example, if you were only able to gain coverage of 80% of the scope, a complete reassessment for the remaining 20% will probably be required, depending on how many vulnerabilities were discovered during the initial test.

Assessment Artefacts

The assessment artefacts appendix provides you with an opportunity to list out any changes that you may have made during your testing. While you should always aim to perform your own cleanup, it is often impossible to fully remove all artefacts created due to security testing. This is crucial information as some of these artefacts may be potentially malicious. For example, you may have uploaded a webshell by leveraging an unrestricted file upload vulnerability. In the worst possible case, two years later everyone forgets about the file and the pentest, only to rediscover it and raise it as an actual security incident! This appendix allows you to provide these artefacts and recommendations on which of these artefacts need to be removed and how they should be removed.

You should think of the appendices as your audit trail. It shows your work, backs up your findings, and allows for informed follow-up, long after the initial assessment is over.

Answer the questions below

1. Which appendix will be vital for the blue team to discern if activity is from a pentest or an actual attack?

Styling Guides and Report QA

Writing a report isn’t just about getting information on the page; it is about communicating that information clearly, objectively, and professionally. It is the only part of your pentest that will stand the test of time. Long after you have moved on to a different career or the entire project team has changed, the report will still be relevant.

Writing Clearly

Clarity is one of the most important qualities of a good report. You should always aim to avoid ambiguity by using simple and direct language that makes your point obvious. Your writing should be understandable even to readers who do not have deep knowledge of the system. If your meaning is unclear or buried under unnecessary complexity, your findings are less likely to be taken seriously, or even fixed.

Professional Writing

A pentest report is a formal document. Use the same tone and style that you would in any other business-critical communication. This means:

• Be objective - Stick to the facts. Avoid exaggeration, emotional language, or assumptions about intent.

• Avoid informal writing - No slang, no jokes, and no "we pwned the login page."

• Be consistent - Use the same terminology, formatting, and structure throughout the report. Avoid switching between different spellings or terms for the same thing.

General Best Practices

Follow these simple rules to improve the professionalism and readability of your writing:

• Write in past tense -E.g. "The vulnerability was discovered during authentication testing."

• Do not use first-person language - Avoid "I," "we," "our," and "us." Write as a neutral observer.

• Mask sensitive information - Never include real passwords or other private data unless explicitly authorised. If you have a screenshot to show impact of a vulnerability, make sure to blur any sensitive information.

• Use clean, formal phrasing - Avoid contractions and overly casual terms. "The attacker gained unauthorised access" is better than "we broke in."

Quality Assurance (QA) Process

Even experienced testers can make mistakes. This is why every report should go through a proper review process:

• Read your own work - Step away from the report and come back to it later with fresh eyes. Look for unclear sentences, inconsistencies, or missing context. It can usually help to read your writing out loud for yourself.

• Get someone else to read your work - A peer reviewer should check that your findings are understandable, actionable, and professionally written.

QA isn’t just about fixing typos. It’s about making sure the report reflects well on both you and your pentesting team.

You can have the best technical findings in the world, but if your report is sloppy, emotional, inconsistent, or unclear, it will not have the impact it should. Good writing helps good security work get the attention it deserves.

QA Challenge

Now that you understand what to look for, click View Site to start your QA Challenge. In this challenge, you have to QA an appendix that has five mistakes. Identify the five mistakes and supply the correct reason to get your flag.

Answer the questions below

What is the value of the flag?

for this section you have to select item and pick the mistake which might be the style, spelling mistakes or unprofessional aspect, just like the previous challenge try to understand what makes up a good report and also try as much as possible to pick what could be wrong till you get the right match as it’s a way to learn

Conclusion: Publishing the Report

Writing professional pentest reports is just as important as finding the vulnerabilities themselves. A clear, structured, and well-written report is the final product of your assessment and often the only lasting evidence that the work was done.

In this room, you learned how to:

• Structure your report to meet the needs of multiple audiences

• Write an effective summary that communicates business risk

• Develop detailed, contextualised vulnerability write-ups

• Present clear remediation advice tailored to the client’s environment

• Maintain clarity, objectivity, and professionalism in your writing

• Apply quality assurance processes to ensure your report is ready to deliver

Final Thoughts

Good reporting helps your findings make an impact. It turns technical detail into action, and gives organisations the insight they need to improve their security posture.

Take the time to write well — because if it’s not in the report, it didn’t happen.

A pentest is only as valuable as its report. No matter how many vulnerabilities are uncovered or how deep the compromise goes, if findings aren’t clearly communicated, they may never lead to remediation.

This room has emphasized that good reporting bridges the gap between technical findings and business decisions. You’ve learned how to:

• Address the specific needs of business, security, and technical audiences

• Write detailed, contextual, and actionable vulnerability write-ups

• Structure and polish your report using professional tone and formatting

• Use summaries, appendices, and QA processes to maximize clarity and trust

In the real world, reports persist long after your test ends. They influence board decisions, shape budgets, and guide technical fixes. Take the time to write reports that are clear, accurate, and actionable — because if it’s not in the report, it didn’t happen.