This chapter covers the critical distinction between technical and executive report sections in penetration testing reports, a key topic under CompTIA PenTest+ objective 4.1 (Report Writing and Communication). Understanding how to structure both sections is essential because the exam tests your ability to tailor reports to different audiences. Approximately 10-15% of exam questions in the Reporting and Communication domain will assess your knowledge of report structure, audience analysis, and content differentiation. Mastery of this topic ensures you can produce reports that satisfy both technical remediation teams and executive decision-makers.
Jump to a section
Imagine a construction project for a large office building. The architect produces two documents: a detailed blueprint and an executive summary for the investor. The blueprint is a technical, precise set of drawings showing every electrical circuit, plumbing line, load-bearing wall, and material specification. It includes exact measurements, tolerances, and code references. The electrician, plumber, and structural engineer each use the blueprint to understand their specific tasks. The executive summary, in contrast, is a one-page overview that highlights the project's total cost, timeline, square footage, and key risks (e.g., potential zoning delays). It uses plain language and avoids jargon. The investor does not need to know the gauge of wire or the PSI of concrete; they need to know whether the project is on budget and on schedule. In penetration testing, the technical report is the blueprint—it contains raw scan data, exploitation steps, proof of concept code, and detailed remediation instructions for the IT team. The executive report is the summary—it communicates business risk, compliance implications, and high-level recommendations to leadership. Just as the investor would be overwhelmed by the blueprint, a CEO would be confused by a list of CVEs. The pen tester must tailor the report to the audience, ensuring each version meets its purpose without omitting critical information.
What Are Technical vs Executive Report Sections?
In penetration testing, the final report is the primary deliverable. It must serve two distinct audiences: technical staff (system administrators, developers, security engineers) who will implement fixes, and executive leadership (CISO, CIO, board members) who need to understand business risk and allocate resources. The technical section provides granular detail—proof of concept, exploitation steps, affected hosts, and specific remediation instructions. The executive section summarizes findings in business context, focusing on risk exposure, compliance impact, and strategic recommendations. Failing to differentiate these sections can lead to miscommunication: executives may dismiss technical jargon, while technical teams may lack sufficient detail to remediate.
How They Differ in Structure and Content
Technical Report Section - Audience: IT staff, security analysts, system administrators. - Language: Technical terminology (e.g., SQL injection, buffer overflow, CVE identifiers, port numbers). - Content: Raw scan output, exploitation steps, proof of concept code, screenshots, affected IP addresses, service versions, and specific configuration weaknesses. - Remediation: Step-by-step instructions (e.g., 'Update Apache to version 2.4.51', 'Disable TLS 1.0 on web server 10.0.0.5'). - Format: Often includes appendices with full scan logs, command outputs, and code snippets.
Executive Report Section - Audience: C-level executives, board members, non-technical stakeholders. - Language: Business and risk terminology (e.g., 'critical vulnerabilities', 'compliance gap', 'financial impact'). - Content: High-level summary of findings, risk ratings (Critical, High, Medium, Low), number of vulnerabilities by severity, affected business units, and compliance implications (e.g., PCI DSS, HIPAA). - Remediation: Strategic recommendations (e.g., 'Implement a vulnerability management program', 'Increase security awareness training'). - Format: Often includes an executive summary at the beginning of the report, with graphs and tables showing risk distribution.
Key Components of Each Section
Technical Section Components - Vulnerability Title: Standardized name (e.g., 'Apache Struts2 Remote Code Execution - CVE-2017-5638'). - Affected Hosts: IP addresses, hostnames, and sometimes asset tags. - Vulnerability Description: Technical explanation of the flaw, including attack vector, impact, and CVSS score. - Proof of Concept (PoC): Detailed steps to reproduce the vulnerability, including commands, code, and screenshots. - Remediation: Specific actions (e.g., 'Apply patch MS20-1234', 'Change configuration parameter X to Y'). - References: Links to vendor advisories, CVE pages, or security bulletins.
Executive Section Components - Executive Summary: 1-2 page overview of the engagement scope, key findings, and overall risk posture. - Risk Scorecard: Table or chart showing number of findings by severity (Critical, High, Medium, Low) and by category (e.g., Web, Network, Social Engineering). - Business Impact: Description of how vulnerabilities could affect business operations (e.g., data breach, downtime, reputational damage). - Compliance Mapping: Which regulations or standards are impacted (e.g., PCI DSS 6.6, HIPAA Security Rule). - Strategic Recommendations: High-level actions (e.g., 'Establish a patch management policy', 'Conduct regular phishing simulations').
How to Write Each Section Effectively
For the Technical Section: - Use a consistent vulnerability template (e.g., title, description, PoC, remediation). - Include exact commands and output so a sysadmin can replicate the issue. - Prioritize remediation by risk to guide the fix order. - Avoid unnecessary jargon beyond what the technical audience expects.
For the Executive Section: - Start with a bottom-line statement: 'The overall risk is High due to 3 critical vulnerabilities in internet-facing systems.' - Use graphs (pie charts, bar graphs) to visualize risk distribution. - Translate technical findings into business language: 'An attacker could gain access to customer credit card data' instead of 'SQL injection in the login form.' - Limit detail—executives typically spend 5-10 minutes reading the summary.
Common Pitfalls and Exam Traps
Trap #1: Including PoC in the executive summary. Executives do not need to see exploit code; it can cause alarm or be misinterpreted. Always place PoC in the technical appendix.
Trap #2: Using technical jargon in the executive section. Terms like 'XSS', 'RCE', or 'buffer overflow' should be replaced with 'cross-site scripting', 'remote code execution', or 'memory corruption vulnerability' with a brief explanation.
Trap #3: Omitting risk ratings. Every finding must have a severity rating (Critical, High, Medium, Low) based on CVSS or a custom risk matrix. Executives rely on these to prioritize.
Trap #4: Providing vague remediation. Technical remediation must be specific. 'Patch the system' is insufficient; 'Update OpenSSL to version 1.1.1k' is correct.
Interplay with Other Report Sections
The technical and executive sections are not isolated; they reference each other. The executive summary may cite the number of critical vulnerabilities, which are detailed in the technical section. The technical section may include a risk rating that aligns with the executive scorecard. Additionally, the report often includes a scope section, methodology section, and conclusion. The executive summary is typically placed at the beginning, followed by the technical findings. Appendices contain raw data (scan outputs, PoC code, etc.) that support the technical section but are not read by executives.
Exam Relevance (PT0-002 Objective 4.1)
CompTIA PenTest+ objective 4.1 explicitly states: 'Explain the importance of communication during the penetration testing process.' This includes writing reports tailored to the audience. The exam will present scenarios where you must choose the appropriate content for a given stakeholder. For example, a question might ask: 'Which of the following should be included in the executive summary of a penetration test report?' The correct answer would be a high-level risk overview, not a list of CVEs or exploitation steps. Another question might ask: 'A system administrator needs to remediate a vulnerability. Which section of the report should they refer to?' The answer is the technical section or appendix. Expect at least 2-3 questions on this topic.
Identify the Audience
Before writing any part of the report, determine who will read it. For the executive section, the audience is non-technical decision-makers (CEO, CISO, board members). For the technical section, the audience is system administrators, security analysts, and IT managers. This step governs language, depth, and content. A common mistake is writing a single report that tries to satisfy both audiences, resulting in confusion. In practice, the pen tester should create two distinct sections or even two separate documents. The exam tests this by asking which audience should receive which type of information.
Gather and Organize Findings
After the penetration test, compile all findings from scanning, exploitation, and post-exploitation. Organize them by severity (Critical, High, Medium, Low) and by category (e.g., Web Application, Network Infrastructure, Social Engineering). For the technical section, include raw data: IP addresses, port numbers, service versions, CVSS scores, and proof of concept steps. For the executive section, aggregate findings into counts and percentages. For example, '3 Critical, 7 High, 12 Medium, 5 Low vulnerabilities.' This step ensures consistency between the two sections.
Write the Executive Summary First
Although counterintuitive, writing the executive summary first helps crystallize the overall risk posture. The executive summary should be 1-2 pages and include: engagement overview (scope, dates, methodology), key findings (number of vulnerabilities by severity), overall risk rating, business impact, and strategic recommendations. Use plain language and avoid technical detail. For example, instead of 'SQL injection in the login form,' write 'A vulnerability in the web application could allow an attacker to access the database containing customer records.' This summary sets the tone and guides the technical section.
Write the Technical Findings Section
For each vulnerability, create a detailed entry. Use a consistent template: title, affected hosts, description, proof of concept, remediation, and references. The proof of concept should include exact commands, code snippets, and screenshots. For example, for a SQL injection, show the vulnerable URL parameter and the payload used. The remediation must be specific: 'Apply vendor patch XYZ' or 'Implement parameterized queries in the login function.' This section is typically the longest part of the report and may span dozens of pages.
Create Appendices with Raw Data
Appendices contain supporting data that is too voluminous for the main body. This includes full Nmap scan outputs, Burp Suite logs, Metasploit session logs, password cracking results, and any scripts used. These appendices are primarily for technical staff who may need to verify findings or reproduce attacks. Executives rarely read appendices. The exam may ask which content belongs in an appendix (e.g., raw scan data) versus the main report (e.g., executive summary).
Review and Tailor Language
After writing both sections, review for audience-appropriate language. In the executive section, replace acronyms (e.g., 'RCE' with 'remote code execution'), define technical terms, and avoid mentioning specific CVEs unless they are widely known (e.g., Heartbleed). In the technical section, ensure that commands and code are accurate and that remediation steps are actionable. Also, check that the executive summary accurately reflects the technical findings—no exaggeration or minimization. The exam may present a poorly written report and ask you to identify the error, such as using technical jargon in the executive summary.
Scenario 1: PCI DSS Compliance Report for a Retail Company
A penetration testing firm is engaged to assess a retail company's e-commerce platform for PCI DSS compliance. The executive report is presented to the CISO and the board. It includes a risk scorecard showing 2 Critical, 5 High, 8 Medium, and 3 Low vulnerabilities. The business impact section highlights that the Critical vulnerabilities could lead to credit card data theft, resulting in fines up to $500,000 per incident and loss of payment processing ability. The strategic recommendation is to prioritize patching of internet-facing systems and implement web application firewall (WAF) rules. The technical report, given to the IT team, lists each vulnerability with affected IPs (e.g., 192.168.1.10), CVSS scores (e.g., 9.8 for a SQL injection), PoC steps (e.g., POST request with payload ' OR 1=1--), and specific remediation (e.g., 'Upgrade Apache Struts to version 2.5.26'). The IT team uses the technical report to create change tickets. A common issue is when the technical report omits exact patch versions, causing the IT team to apply the wrong fix.
Scenario 2: Red Team Assessment for a Financial Institution
A red team assessment for a bank includes both technical and executive reports. The executive report focuses on the overall security posture, including successful phishing campaigns (e.g., 30% of employees clicked a simulated phishing email) and network penetration (e.g., attacker reached the core banking database). The business impact is quantified in terms of potential financial loss (e.g., $2 million per hour of downtime). The technical report includes detailed attack chains: the initial phishing email used a malicious attachment 'invoice.pdf' that dropped a backdoor, the backdoor communicated with a C2 server at 203.0.113.5, and lateral movement exploited a weak SMB password on a file server. Remediation steps include implementing multi-factor authentication, blocking macro-enabled attachments, and conducting SMB hardening. The technical team uses this to close gaps. A pitfall is when the executive report downplays the severity of a vulnerability because the technical team did not fully exploit it, leading to underfunding of security initiatives.
Scenario 3: Web Application Pentest for a SaaS Provider
A SaaS provider undergoes a web application penetration test. The executive report highlights that the application has a high number of Medium vulnerabilities, suggesting a need for a secure code review and developer training. The technical report lists 15 cross-site scripting (XSS) vulnerabilities, each with the affected URL, parameter, and payload. The remediation for each XSS is to implement output encoding using a specific library (e.g., OWASP Java Encoder). The technical team fixes the issues but often misses one or two because the report does not clearly indicate which pages are affected. A best practice is to include a summary table in the technical section mapping each vulnerability to a specific page or function. The exam may test this by asking what additional information should be included in the technical report to improve remediation accuracy.
Exactly What PT0-002 Tests (Objective 4.1)
The exam focuses on your ability to distinguish between content appropriate for technical versus executive audiences. Specific objective 4.1 states: 'Explain the importance of communication during the penetration testing process.' Within this, you must understand report structure and audience analysis. Expect scenario-based questions where you are given a list of report elements and must choose which belong in the executive summary versus the technical appendix. Also, be prepared to identify errors in a sample report, such as including PoC in the executive section or using jargon like 'RCE' without explanation.
Common Wrong Answers and Why Candidates Choose Them
Wrong: Including raw Nmap output in the executive summary. Candidates think 'more detail is better,' but executives do not need port scan results. The correct answer is to include a summary of open ports or high-level findings.
Wrong: Using CVSS scores in the executive summary without explanation. Executives may not understand CVSS. Instead, use qualitative ratings (Critical, High, Medium, Low) or translate scores into business impact.
Wrong: Placing strategic recommendations in the technical section. Strategic recommendations (e.g., 'Implement a security awareness program') are for executives; technical staff need specific patch commands.
Wrong: Omitting proof of concept from the technical section. Some candidates think PoC is too sensitive to include, but it is essential for verification. The exam expects PoC in the technical section.
Specific Numbers and Terms That Appear on the Exam
The term 'executive summary' is always used, not 'management summary' (though they are similar).
Risk ratings: Critical, High, Medium, Low (or Informational). CVSS v3.0 scores are sometimes referenced (e.g., 9.0-10.0 = Critical).
The phrase 'business impact' is a key differentiator for executive reports.
'Proof of concept' (PoC) is a technical section requirement.
'Remediation steps' must be specific in the technical section (e.g., 'Apply patch KB123456').
Edge Cases and Exceptions the Exam Loves to Test
When the audience is mixed (e.g., both technical and executive at the same meeting). The report should have separate sections; the presenter can summarize the executive section while pointing to technical details as needed.
When the client requests a single-page report. This is unrealistic for a full pentest, but the exam may ask what to include. The answer is to focus on the executive summary with key metrics and a risk rating, and provide the full technical report as an appendix.
When the report is for a compliance audit. In that case, both sections must include compliance mappings (e.g., PCI DSS, HIPAA). The executive section should highlight which controls failed, while the technical section provides evidence.
How to Eliminate Wrong Answers Using the Underlying Mechanism
Ask yourself: 'Would a non-technical executive understand this?' If the answer is no, it belongs in the technical section. Similarly, 'Does a system administrator need this level of detail to fix the issue?' If yes, it belongs in the technical section. For example, a question might list 'A list of CVEs with descriptions' and ask where it belongs. CVEs are technical; they belong in the technical section. The executive section would say '3 critical vulnerabilities were found in web servers.' Use this filter to eliminate options.
The executive summary must be written in plain language and focus on business risk, not technical details.
Proof of concept (PoC) code and raw scan data belong in the technical section or appendices, never in the executive summary.
Risk ratings (Critical, High, Medium, Low) should be used consistently in both sections, but the executive section may aggregate them.
Technical remediation must be specific (e.g., 'Update Apache to version 2.4.51'), not vague (e.g., 'Patch the system').
The executive section should include strategic recommendations (e.g., 'Implement a vulnerability management program') that require budget or policy changes.
Always identify the audience before writing each section to ensure appropriate language and content.
Common exam traps: including PoC in executive summary, using jargon in executive section, and providing vague remediation in technical section.
These come up on the exam all the time. Here's how to tell them apart.
Technical Report Section
Target audience: system administrators, security analysts, IT staff.
Language: technical, includes commands, code, CVEs, port numbers.
Content: detailed vulnerability descriptions, PoC, affected hosts, specific remediation steps.
Format: often includes appendices with raw scan data and logs.
Purpose: provide actionable information to fix vulnerabilities.
Executive Report Section
Target audience: C-level executives, board members, non-technical stakeholders.
Language: business-focused, plain language, avoids jargon.
Content: high-level summary, risk scorecard, business impact, strategic recommendations.
Format: executive summary at beginning, often with graphs and tables.
Purpose: communicate overall risk and justify security investments.
Mistake
The executive summary should include all findings in detail.
Correct
The executive summary should only highlight key findings, overall risk, and strategic recommendations. Detailed findings belong in the technical section. Including all findings overwhelms executives and obscures the big picture.
Mistake
Technical reports should avoid risk ratings because they are subjective.
Correct
Risk ratings (Critical, High, Medium, Low) are essential in both sections. In the technical section, they help prioritize remediation. Ratings should be based on a consistent methodology (e.g., CVSS).
Mistake
Proof of concept (PoC) should be omitted from reports to prevent misuse.
Correct
PoC is a critical part of the technical section to validate findings. It should be included but marked as confidential. The client's technical team needs PoC to reproduce and verify the vulnerability before fixing it.
Mistake
The executive summary should be written in technical language to appear credible.
Correct
Executives prefer plain language. Using technical jargon (e.g., 'XSS', 'buffer overflow') can confuse them and reduce the report's impact. Translate technical terms into business consequences.
Mistake
A single report can serve both audiences without separate sections.
Correct
While a single report can contain both sections, they must be clearly separated (e.g., executive summary first, then technical findings). Mixing them leads to confusion. The exam expects you to know what goes where.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The technical section provides detailed, actionable information for IT staff to remediate vulnerabilities, including proof of concept, affected hosts, and specific patch commands. The executive section summarizes findings in business terms, focusing on risk, compliance, and strategic recommendations for leadership. The exam tests your ability to distinguish content for each audience.
It is acceptable to include CVSS scores if they are accompanied by a plain-language explanation (e.g., 'Critical (CVSS 9.8)'). However, it is more common to use qualitative ratings (Critical, High, Medium, Low) in the executive section and reserve raw scores for the technical section. The exam may present a scenario where a CVSS score is used without explanation, which is a mistake.
Yes, but only if they are high-level and non-technical. For example, a graph showing vulnerability severity distribution is appropriate. A screenshot of a command prompt or exploit output is not. The executive summary should be visually clean and easy to digest.
An executive summary is typically 1-2 pages, never more than 3 pages. It must be concise because executives have limited time. The technical section can be dozens of pages. The exam may ask about appropriate length in a given scenario.
Structure the report with a clear separation: start with the executive summary, then include a detailed technical findings section, and appendices. This allows each audience to read only the relevant parts. The exam expects this structure.
Only high-level strategic remediation should appear in the executive summary (e.g., 'Implement a patch management policy'). Specific technical steps (e.g., 'Run the command apt-get update') belong in the technical section. Including technical steps in the executive summary is a common exam trap.
The most common mistake is failing to tailor the report to the audience. This includes using technical jargon in the executive summary or providing vague remediation in the technical section. The exam will test your ability to identify and correct such errors.
You've just covered Technical vs Executive Report Sections — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?