After the pentest: remediation, retest and close-out

A pentest only lowers risk when the fixes ship and someone checks them. The steps are: triage, assign, fix, verify, retest, close out.

Teams often stop after the first fixes. Cobalt's 2025 State of Pentesting Report, built on its platform data, reports that less than half (48%) of all findings ever get resolved, and 69% of the riskiest. It gives a median time to resolve of 67 days. These are one vendor's figures, but they show that findings stay open.

How do you triage the findings?#

Read the report first; our guide to how to read a penetration testing report explains each section. Then triage in one short meeting, with an engineer who knows the code and a person who can decide on risk.

For each finding, answer four questions:

1. Do we agree it is real? Reproduce it. If you cannot, ask the tester.
2. What is our priority? Severity is the tester's rating. Priority adds your context.
3. Who owns the fix?
4. When is it due?

Look for patterns. Three findings that share one root cause, such as a missing ownership check in a shared helper, may need one fix. Look at the "controls that held" list too, so your fix does not break working protections.

What should the first week look like?#

Contain the worst issues first. For a Critical or High finding that is easy to use, take a short-term step while the full fix is built: disable the feature, add a rule at the gateway, or limit access. Record the step. It does not close the finding.

Also check for signs of past abuse. Search your logs for the request pattern in the reproduction steps. If you find real use before the test, treat it as an incident under your own process.

How do you plan the fixes?#

Create one ticket per finding, or per root cause. Put these fields in each ticket:

Set due dates by severity and write the targets in your policy. PCI DSS 11.4.4 expects exploitable findings to be corrected in accordance with your risk assessment, and it does not name days. Choose targets your team can meet. When a date is missed, someone should decide what happens next.

How do you fix well?#

Fix the root cause. If the flaw was a missing ownership check on one endpoint, look for the same pattern on every endpoint that loads a record by ID. Add the check in one shared place if you can.

Add a test that fails before the fix and passes after. Use the reproduction steps from the report. These tests stop the flaw from coming back. Keep the controls that held as tests, too.

A fix that hides the symptom leaves the flaw open. Blocking one payload in a filter or hiding a button in the UI are examples, and the tester will usually find the bypass at retest.

How do you verify a fix before the retest?#

Run the report's reproduction steps against the fixed build, with test accounts. The result should differ from the original. Save the output with a date.

Check three things:

1. The original request no longer works.
2. A small variation does not work either: a different ID, another role, another content type.
3. Normal use still works. The control tests should still pass.

Run reproduction scripts only with authorization and with test-owned identifiers. Prefer staging.

When and how should you request a retest?#

Ask for a retest when a group of fixes is verified in your environment and deployed to the tested environment. Do not send each fix alone, unless a finding is urgent. Batches save time for both sides.

Send the tester:

• The list of finding IDs you want retested.
• The build or version that holds the fixes.
• Any change to accounts, hosts or scope since the test.
• Your notes on how each fix works.

A retest checks each fix and looks for nearby bypasses. The result should state, per finding, one of: fixed, partly fixed, not fixed, or not retested. A good result has new evidence, such as the original request and its new response. See retesting for what Excession Labs's retest result looks like. We can retest fixed findings. Ask about terms when you scope.

A tracker template#

Copy this table into your tracker. The rows are examples from a fictional app, Harbor Notes.

A finding marked "fixed" with no evidence is not closed, so keep a status column and an evidence column.

How do you close out?#

Close a finding when you have evidence that it is fixed, or a signed risk acceptance. Keep three things together: the original report, the retest result and the tickets with dates.

Then do a short review:

• What caused the flaws? Missing checks, no design review, no tests?
• Which fix should become a standard, such as a shared authorization helper?
• Which trigger should start the next test? See how often should you pentest.

If a customer or auditor asks for proof, share what fits the request. A summary or an attestation letter is often enough for a customer. See customer security reviews for what buyers ask. Ask the auditor what they need. A report alone may not meet a standard.

How do you stay fixed?#

Releases add new risk, so tie the next test to your release pace. A recurring plan tests the changed areas after meaningful releases, and checks that old fixes still hold.

Need a pentest you can act on?

Tell us what you need tested and why. We reply to agree scope, and testing starts only after written authorization.

Request a testSee the sample report