What this template is for
A penetration-test report is the most expensive document a security programme produces and the one most likely to sit unread. The findings are valuable; the PDF is not. This template breaks the PDF into actionable Jira tickets - one per finding - each with its own SLA, owner, and retest.
Closing the loop is the explicit goal. A finding is not closed because someone said it was fixed; it is closed because the retest passed and the evidence is attached to the ticket.
When to use it
Use this template:
- For every Critical, High, Medium, and Low finding in an external pen test
- For internal red-team or purple-team findings of equivalent severity
- For bug-bounty submissions that pass triage (treat them like pen-test findings)
Informational findings can be batched into a single review ticket if there are many.
Sub-task breakdown
The retest sub-task is the one that distinguishes a real remediation programme from a checkbox one. STM Issue Templates lays down the standard sub-task set including the retest, so the closure gate is built into every finding ticket. The Disposition field captures whether the team chose Fix, Mitigate, or Accept Risk - for Accept Risk, link to a compliance-exception-request ticket.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | PT-2026-014 - Stored XSS in admin notes textarea | Yes |
Finding ID (custom) | PT-2026-014 | Yes |
Report Reference (custom) | Acme Sec Q2 2026 report, finding #14 | Yes |
Severity (custom) | Critical / High / Medium / Low / Informational | Yes |
CVSS Score (custom) | 7.4 | Yes |
Affected Asset (custom) | admin.example.com - /admin/users/:id | Yes |
Exploit Path (custom) | Authenticated admin can inject JS into another admin's view | Yes |
Remediation Recommendation (custom) | Server-side HTML escape on render; CSP headers | Yes |
SLA (custom) | 30 days (High severity) | Yes |
Remediation Owner | @platform-tl | No |
Retest Owner (custom) | @security-eng | No |
Disposition (custom) | Fix / Mitigate / Accept Risk (with exception) | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Confirm the finding is reproducible against the current production version
- Assess scope - other endpoints with the same pattern
- Set SLA based on severity and exploitability
- Open patch ticket(s) and link as Implements
- Verify fix in staging with the same exploit path
- Schedule retest with the pen-test vendor (or internal retest)
- Close with retest evidence attached
Common questions
What is a Jira pen test finding template?
It is the ticket per finding that takes a pen-test result from PDF to closure. Each finding gets its own ticket with CVSS, exploit path, remediation recommendation, SLA, and retest sub-task. The ticket is the working artefact - patch tickets link to it, retest evidence attaches to it, and audit can reconstruct the full lifecycle months later.
Should every pen test finding become a Jira ticket?
Yes - even Informational findings. Tracking them all in Jira (with appropriate severity-driven SLAs) prevents the common failure where a Low-severity finding in the report becomes a Critical CVE six months later because nobody reopened the PDF. Informational findings can be batched into a single review ticket, but they should still be tracked.
How do you SLA pen test findings?
By severity and exploit difficulty. Common targets: Critical 7 days, High 30 days, Medium 90 days, Low 180 days. Exploit difficulty modifies the SLA - a Medium-severity finding that requires no authentication may be treated as High. The SLA field on the ticket records the agreed deadline so accountability is explicit.
How do you keep pen test remediation on track?
The retest sub-task is the closure gate; without it, 'fixed' is self-reported and unverified. [STM Issue Templates](/stm/) can auto-create the standard sub-task set (confirm, scope, SLA, patch, verify, retest, close) on every new pen-test finding so the workflow is consistent regardless of which engineer picks up the ticket.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →