Turn a pentest report into work by holding a triage meeting within days, creating one ticket per finding with an owner and a due date, rating each in your own context, and booking a retest before the report is filed away. Reports that sit in a folder fix nothing.
Read and rate
Step 1: Read it together
Within a few days of receiving the report, hold a short meeting with the testers if possible, plus engineering owners. Ask the testers to walk through the top findings and say which ones they chained. Ask what they would fix first. Ask which findings are the root cause of others.
Step 2: Rate in your context
Testers usually score findings with a standard severity system. For CVSS, FIRST says the Base score measures severity, not risk, and should be supplemented with threat and environmental analysis. Use the tester's rating as input, then adjust for your setup: exposure, data involved, compensating controls.
Record both ratings. If you downgrade a finding, write the reason in the ticket.
Tickets and deadlines
Step 3: One finding, one ticket
Each ticket should hold:
- Title and tester's reference number.
- Affected component and location.
- Impact in one sentence.
- Steps to reproduce, copied from the report.
- Recommended fix, and the fix you chose.
- Severity as reported and as adjusted.
- Owner, due date and a retest note.
Group findings that share a root cause under one parent ticket, so you fix the cause once.
Step 4: Set deadlines you will meet
Choose targets by severity band, and write them down. Do not borrow numbers you cannot meet. A missed deadline that everyone knew was fictional damages trust more than a longer target kept honestly. Share the dates with leadership.
Step 5: Decide what you will accept
Not every finding gets fixed. For each one you leave open, choose a response. OWASP's list is mitigate, eliminate, transfer or accept. Accepting needs a named owner and a date to revisit. Write the decision down, since customers and auditors may ask.
Fix and retest
Step 6: Fix and verify
Fixes need testing too. Ask the developer to add a regression test where practical, so the flaw does not return. When the ticket is done, the person who raised it, or a second reviewer, confirms the fix using the original steps.
Step 7: Retest
Book the retest at the start. Ask the testers to confirm each fix against their original proof of concept. Update the report or add a retest letter. Keep both together.
Step 8: Learn from patterns
After closing the work, look at the list as a whole:
- Which classes of bug appear more than once?
- Could a threat model, a code review rule or a pipeline check catch them earlier?
- Which finding took the longest to fix, and why?
Feed the answers back into design reviews and your secure coding guidance.
What to share outward
Customers often ask for a summary of a pentest. Share a short summary, not the full report, unless an agreement requires otherwise. Tell them the date, scope, who tested, and the status of findings, without giving details that help an attacker.
Quick check
Should every finding be fixed?
No. Each needs a decision. Some are fixed, some mitigated, some accepted with a named owner. Every one needs a record.
How soon should we retest?
Once the high priority fixes ship. Waiting for every low finding delays proof on the ones that matter.
Sources
Last reviewed: 19 October 2026.
