
Threat Model
Docs + Word8 pages
Free
A penetration test is only useful if its findings reach the people who can fix them, with enough evidence to act and a date to act by. This report template sets out the test in the order a reviewer needs it: the executive summary, the scope, the method, the findings by severity, the remediation plan with owners, and a glossary. Each finding is tied to a risk the business can understand.
The sample reports a test of Sandpiper Cloud's customer portal, which found no critical issues, two high issues and five medium ones. The two high findings must be fixed and retested before launch. Every name, system and figure is fictional. Replace the scope, findings and owners with your own results, re-rate each one on your scale, and record the approver and the risks formally accepted.
Click Make a copy in Google Docs, then confirm on the Google page. The copy is saved to your own Google Drive.
Redraw the data-flow diagram with your components, data stores and trust boundaries before the threats.
Re-rate each finding on your severity scale, and attach the evidence that proves it.
Assign an owner and an SLA date to every high and critical finding, then name the approver.
Delete the guide page, then share the report with the CISO and the engineering leads.
Yes. Sandpiper Cloud, Ravi Dhar, Alicia Fenwick, the portal, the findings and every date and figure are fictional. Replace them with your own results before the report leaves the security team.
Include enough to reproduce and fix the issue, such as the request and the response, and keep full exploit code in a restricted appendix. Readers who only need the risk should not have to read attack steps.
A risk that a named person with authority has agreed to live with, in writing, with a date and a review point. A residual risk without that name is simply an open finding.
More Google Docs templatesMore developer workflows templates

Docs + Word8 pages
Free
Slides + PowerPoint11 slides
Free
Docs + Word7 pages
Free