What to Do After You Get a Pentest Report: Remediation Workflow, Jira Templates, and Tracking

Do not create Jira tickets for every finding the moment you get the report. Triage first.

What triage means:

Pentest findings are scored by the pentester based on the standalone vulnerability, not on your specific environment. A finding rated Critical by the pentest firm may be Low risk in your environment because the affected system is isolated, not internet-accessible, or protected by compensating controls. Conversely, a Medium finding may be Critical in your environment because it sits on a Tier 1 system with no compensating controls.

The triage questions for every Critical and High finding:

1. Is the affected system internet-accessible, or only accessible from a trusted internal network?
2. Does exploiting this finding require credentials, physical access, or a prerequisite that an attacker is unlikely to have?
3. Does any compensating control partially or fully mitigate this risk? (WAF, network segmentation, monitoring, MFA)
4. What data or systems can an attacker reach if they successfully exploit this?
5. Is there a known public exploit or active exploitation of this vulnerability in the wild?

Adjusted severity matrix:

Document your triage decisions. You will need to explain to the auditor, the pentest firm on retest, and your CISO why you treated a Critical as a P3. The reasoning matters as much as the outcome.

The most common reason pentest findings stay open indefinitely: the ticket says 'remediate SQL injection in user search endpoint' with a link to the 80-page report and nothing else. An engineer picks it up, has no context, opens the report, reads 80 pages, closes it, and moves the ticket back to the backlog.

What a good pentest remediation ticket contains:

Title: [P1] SQL Injection in /api/users/search — exploitable without auth

Severity: Critical (P1 — fix within 14 days)
Affected component: /api/users/search endpoint, UserSearchController.java:147
Pentester finding ID: FIND-003 (page 34 of the report)

What the pentester found:
The search parameter accepts unsanitized user input that is concatenated 
directly into a SQL query. Using a standard sqlmap payload, the pentester 
exfiltrated the full users table including hashed passwords.

Proof of concept (from the report):
  GET /api/users/search?q=test'+UNION+SELECT+username,password+FROM+users--
  Response: {"users": [{"username": "admin", "password": "$2b$10$..."}]}

Why this matters:
This endpoint is unauthenticated and internet-accessible. An attacker can 
exfiltrate all usernames and password hashes without any credentials. 
If any users share passwords with other services, this enables account takeover.

How to fix it:
1. Use parameterized queries / prepared statements for all database queries
   (do NOT use string concatenation or format strings with user input)
2. In Java with JDBC: use PreparedStatement with ? placeholders
3. Apply input validation to reject inputs containing SQL metacharacters 
   as a defense-in-depth layer
4. Review all other query construction in UserSearchController and adjacent 
   controllers for the same pattern

Verification:
The pentester will retest this specific finding. To pass retest:
- The payload above must no longer return database contents
- A parameterized query implementation must be visible in code review

Owner: [Backend Engineering Team]
Deadline: [Date 14 days from report delivery]
Retest date: [Date 30 days from report delivery]

Ticket fields that prevent escalation confusion:

• Pentest finding ID and page number: Engineers should never have to read the full 80-page report to understand one ticket
• Proof of concept reproduced in the ticket: The exact payload or request the pentester used, copy-pasted from the report
• Why it matters in business terms: Not 'SQL injection is bad' but 'an attacker can steal all user credentials without logging in'
• Specific fix with code-level guidance: Not 'fix the SQL injection' but 'use parameterized queries; here is how'
• Verification criteria: What the engineer needs to demonstrate to pass the retest

Your CISO and engineering leadership need to know what was found without you triggering an all-hands meeting every time the word 'Critical' appears.

The 5-slide leadership deck structure:

Slide 1: What we tested (scope) One sentence each: what systems were in scope, what type of assessment (external network, web application, social engineering), and what the test period was. Do not bury the audience in methodology.

Slide 2: What we found (risk summary) A simple table:

Note: do not show raw critical counts without context. A '3 Critical findings' headline with no context causes panic. The table above shows that 1 is already mitigated and 2 are actively being fixed.

Slide 3: The two things that matter most Pick the two findings that represent the most real-world risk. One paragraph each. Frame in business terms: not 'unauthenticated SQL injection in the user search endpoint' but 'an attacker without an account could extract all customer credentials from our database using a standard technique.' Include the adjusted priority and the fix deadline.

Slide 4: Remediation timeline A simple Gantt-style view or milestone list: which findings are being fixed by when, who owns each stream, and when the retest is scheduled.

Slide 5: What we are changing permanently The systemic fixes: the process changes that prevent the same class of findings in the next pentest. Not just 'we fixed the SQL injection' but 'we are adding parameterized query enforcement to our code review checklist and SAST rules.' This is the slide that demonstrates the pentest created lasting security improvement, not just a one-time fix cycle.

A Google Sheet or Notion page that dies after week two is not a tracking system. You need a register that:

1. Has a single owner per finding
2. Shows current status at a glance
3. Has visible SLA deadlines with automatic aging
4. Can be filtered by team, status, and priority

Minimum columns for a pentest remediation register:

Weekly status update cadence:

Send a brief weekly email to the engineering leads and your CISO:

Subject: Pentest Remediation Status — Week [N] of [Total]

P1 findings: 2/3 remediated (1 in review, ETA Thursday)
P2 findings: 4/7 remediated (3 in sprint, on track)
Overall: 6/47 findings closed this week, 31 remaining

Retest scheduled: [Date]

At risk: FIND-019 (P2, SQL injection in payment module)
Owner: [Team] — ticket has been open 18 days with no update.
Needed: owner escalation by EOW.

This email serves three purposes: accountability for owners, visibility for leadership, and a paper trail for the auditor.

A retest is not the same as re-running the original pentest. It is a targeted verification: the pentester runs the same proof-of-concept from the original report against each finding and confirms it no longer succeeds.

Before the retest:

• Every P1 and P2 finding should be remediated and the evidence documented (PR links, config screenshots, deployment logs)
• For each finding, the person who fixed it should be able to explain to you in 2 minutes what they changed and why it fixes the issue -- not just 'we updated the library'
• Run the proof-of-concept payloads yourself before the retest. If the pentest firm's P1 SQL injection payload still works in staging, it is better to find that before the retest than during it
• Brief the engineering owners: tell them the retester will be re-running specific payloads and may ask technical questions about what changed

For accepted and deferred findings:

Any finding you accepted or deferred without fixing needs documented rationale:

• Why was it accepted? (Compensating controls, risk tolerance, cost of fix exceeds risk)
• Who approved the risk acceptance? (Named person with authority to accept the risk)
• When does the acceptance expire? (Risk acceptance should not be permanent for high-severity findings)
• What compensating controls reduce the risk in the interim?

The pentest firm will note accepted findings in the retest report. An accepted Critical finding with no documented rationale is an audit finding. An accepted Critical finding with documented compensating controls and a 90-day review commitment is a defensible risk decision.

Post-retest:

Once the retest report comes back, close all verified-remediated findings in your tracking register and mark them with the retest date. Update your pentest history log with the dates and outcome. This log becomes the evidence for your SOC 2 pentest controls and for the next pentest's scoping discussion ('these were findings last year -- confirm they remain fixed').

A 2025 Vonahi study found that 41% of critical findings in follow-up pentests were findings from the prior pentest that were marked 'remediated.' This happens because the fix addressed the symptom (one specific endpoint) but not the root cause (the pattern that created the vulnerability everywhere).

When a finding recurs, ask two questions:

1. Was the original fix incomplete? (Fixed the specific instance but not the same pattern in adjacent code)
2. Did the underlying cause get addressed? (Fixed the SQL injection in the search endpoint but never audited the other 30 query construction patterns in the codebase)

Root cause-driven remediation:

For every P1 and P2 finding, after the specific instance is fixed, identify and document the root cause:

The systemic fix column is what prevents the finding from recurring. It is also the most valuable output of the pentest -- you are getting paid to discover root causes, not just to fix individual instances.