How to Write a Security Assessment Report

Why Report Quality Matters

Your assessment report is often the only artefact the client keeps after the engagement. Executives use it to justify security budgets. IT teams use it to plan their fix schedule. Compliance auditors use it as evidence for certifications and regulatory requirements. If the report is unclear, incomplete, or poorly structured, the entire engagement loses value regardless of how thorough your assessment was.

Good reports also generate referrals. When a CISO shares a clear, actionable report with their peers, it reflects well on your consultancy and leads to new business.

Report writing is also the part of the engagement that consultants most often underestimate. A two-week penetration test with 20 findings can easily require two to three full days of report writing if done manually. This is time that cannot be billed to new engagements, making report efficiency a direct factor in your consultancy's profitability. Understanding the structure and having a repeatable process in place before you start testing makes the entire workflow faster and more predictable.

Essential Report Sections

Every professional security assessment report should include these sections. The structure applies to pentests, vulnerability assessments, compliance audits, and red team reports alike.

The exact depth of each section will vary by assessment type and client expectations. A quick vulnerability scan report might have a brief executive summary and minimal appendices, while a comprehensive red team engagement will require a detailed narrative of the attack path. Regardless of scope, maintaining this consistent structure helps clients know exactly where to find the information they need.

Writing Clear Findings

The most common mistake is writing findings that only another security professional would understand. Your audience includes developers, project managers, compliance officers, and executives.

• Use descriptive titles. Instead of "XSS", write "Stored Cross-Site Scripting in User Profile Bio Field".
• Explain the impact. What could an attacker actually do? Steal session cookies? Redirect users? Access admin panels?
• Provide reproduction steps. Number each step. Include exact URLs, payloads, and expected results. Someone else should be able to verify the finding.
• Give actionable remediation. Instead of "sanitise input", specify which encoding to use, which library to implement, and link to documentation.
• Include evidence. Screenshots with annotations, HTTP request/response pairs, and code snippets make findings verifiable and credible.

A helpful technique is to write findings as you test rather than batching them at the end. Logging each finding immediately with a brief description, the affected URL, and a screenshot captures context while it is fresh. This reduces the risk of forgetting details and makes the report writing phase much faster. Tools with built-in finding templates and automated findings management can help standardise this workflow across your team.

Structuring the Executive Summary

The executive summary is the most important page of your report. It is the page that gets shared with the board, forwarded to the risk committee, and used to justify the next round of security spending. Write it last, after all findings are documented, so you have the complete picture.

Start with a one-paragraph scope summary: what was tested, when, and the approach used. Follow with the overall risk assessment in one sentence. Then list the top three to five most impactful findings in business language, not technical jargon. Finally, include strategic recommendations that connect the findings to actionable next steps.

Many consultants make the mistake of listing every finding in the executive summary. Resist this. The detailed findings section exists for comprehensive coverage. The executive summary should tell a story: "We tested your web application and found two critical issues that could expose customer data. We recommend addressing these before your product launch next month." This framing gives decision-makers the context they need to act.

Severity Ratings and CVSS

Use CVSS 3.1 for objective severity scoring. The vector string makes your rating transparent and defensible. Map CVSS scores to severity labels consistently:

For a deeper dive into CVSS scoring, see our guide on CVSS 3.1 Scoring Explained. Mapping findings to the OWASP Top 10 categories alongside CVSS scores gives clients a consistent taxonomy for tracking trends across engagements.

Common Report Writing Mistakes

Even experienced consultants fall into these traps. Being aware of them helps you produce consistently professional reports.

• Writing for other pentesters instead of the client. Your audience is developers, managers, and executives. If the client needs a glossary to read your report, you have written it for the wrong audience.
• Copy-pasting generic descriptions. Clients can tell when a finding description was copied from a database without being adapted to their specific environment. Tailor every description to include the client's actual URLs, endpoints, and data context.
• Omitting positive findings. Reporting only on weaknesses misses an opportunity to acknowledge what the client does well. Include a section on security strengths or positive observations. This builds trust and gives a balanced picture.
• Inconsistent formatting. Mixed date formats, different heading styles, and varying levels of detail between findings make the report look unprofessional. Use a template and stick to it for every engagement.
• Delivering late. Report delivery is the client's measure of your professionalism. Agree on a delivery date during scoping and meet it. If you need more time, communicate early rather than going silent.

Delivery Best Practices

How you deliver the report matters as much as what is in it. A poorly delivered report diminishes the value of excellent testing.

• Do not email PDF reports. Use a secure delivery platform like a client portal where clients can access findings, track remediation, and download reports with proper access controls. This applies to all assessment types.
• Present findings in a call. Walk the client through the executive summary and critical findings before sending the full report. For compliance audits, include the auditor or compliance lead in this call. This gives the client a chance to ask questions and understand the context behind each finding.
• Follow up on remediation. Schedule a retest or check-in 30 to 60 days after delivery. For compliance engagements, align follow-ups with certification timelines. Following up demonstrates ongoing value and often leads to repeat business.
• Offer a retest window. Include a retesting period (typically 30 to 90 days) as part of your engagement. This incentivises the client to remediate quickly and gives you the opportunity to verify fixes and update finding statuses.

Automate Report Generation

Tools like SecPortal can generate executive summaries, technical reports, and remediation roadmaps automatically from your logged findings using AI. This works across all assessment types: pentests, vulnerability assessments, compliance reviews, and red team exercises. It saves hours of manual writing while maintaining professional quality. You can also deliver reports through a branded client portal where clients track remediation progress in real time. For a deeper look at how AI is changing the reporting workflow, see our guide on AI in security reporting.