Penetration testing remediation: plan, timeline and retest

By The PenTest Index · Retest terms and rule text checked October 9, 2026

Penetration testing remediation is the work that follows the report: decide whether to fix, mitigate, accept or dispute each finding, then have the fixes retested. Your own risk decisions set the fix dates, but the free retest has a hard stop. Astra's Pentest Expert and Pentest Auto windows close 30 days after findings are reported; its Enterprise window closes after 90 days. Find your date first.

Most teams do not need to buy anything new to do this well. You need a plan, an owner for each finding, and the retest you already paid for, used before it expires.

Penetration testing remediation in five steps

Do these in order, and do the first one today.

1. Find your retest clause. Work out the last day you can ask for a retest. Jump to the dates.
2. Give every finding one decision: fix, mitigate, accept or dispute. See the four choices.
3. Name an owner and a date for each one. Copy the plan.
4. Fix it, then test your own fix before the tester sees it.
5. Request the retest and keep the proof. Copy the request.

How long do you have? Start with the retest deadline

You are working to three different dates, and the one people miss is the retest cutoff.

An included retest can be limited by the last day you may request it, the date the fix must be ready, or the date the retest must happen. Miss the applicable condition and you may pay again or have no outside proof at all.

What six providers publish about retests

We read each provider's own page on October 9, 2026. To make the windows concrete, we worked out the relevant date where the published term gave enough information for one made-up engagement: findings reported and testing finished on Friday, October 23, 2026, final report delivered Friday, October 30, 2026. These are the providers' published terms, not your contract.

Listed A to Z. This is not a ranking, and "published" does not mean we tested the service. Sources: Astra rescan rules, BreachLock pricing, Cobalt retest rules, HackerOne customer and tester retest pages, Syslifters procedure, Triaxiom retest terms. Astra and HackerOne do not explain whether the first or final calendar day counts. Syslifters and Triaxiom do not state a separate request deadline for their fix or retest windows. Cobalt gives its contract cutoff as 23:59 UTC. Ask your provider to confirm the exact date.

Four things in that table change what you should do:

• Astra counts batches, not tries per finding. Two manual rescans means two rounds. Astra's own advice is to fix at least half of your critical and high findings before using one. Its unlimited automated rescans only cover findings its scanner found, so they will not confirm a fix for something a person found.
• Cobalt's two pages disagree. Its pricing FAQ promises "unlimited on-demand retesting throughout your contract term." Its help article limits free retesting to 6 or 12 months and closes requests 10 days before the contract ends. Say your contract ends December 31, 2026: the cutoff is December 21 at 23:59 UTC, and a fix ready on December 23 is too late. The help article's own example also calls January 3 to June 3, 2026 "6 months." Get your retest end date in writing.
• HackerOne's $50 is a floor per retest, not a total. HackerOne says to weigh the effort involved when you set the fee.
• "Reported" needs a date. Astra starts its window when vulnerabilities are reported, which may differ from the end of testing or final report date.

Which terms fit which team?

• Your fixes need a full release cycle or a vendor patch: 30 days is tight. You want 90 days or more, or an extension agreed in writing now.
• You fix in small batches: unlimited per-finding retests suit you better than one or two counted rounds.
• Your annual contract ends soon: the contract cutoff may arrive before the advertised window does.
• Someone needs proof by a date: count back from their date, not from the window.

Already a customer? Check the rules for the test you bought.

Read Astra's rescan rules

Read Cobalt's retest rules

Read HackerOne's retest rules

If your provider is not in the table, or your test came bundled through a compliance platform or reseller, send whoever sold it this one question:

For this engagement, how many retests are included, what is the last date we can request one, what event starts that clock, and what does a retest cost after that date? Please confirm in writing.

Work out your own dates

Put in what your agreement says. Leave a box empty if you do not know; the tool will tell you what to ask instead of guessing.

A worked example. Say the window starts October 23, 2026 and runs 30 days. Your provider says a retest takes 7 days, and your customer wants proof by December 1. The last request day is November 22. December 1 minus 7 days is November 24, so the window is the tighter of the two. Request by November 22, and aim earlier so a failed fix can get a second look.

Do you have to fix every finding?

No. Every finding needs a decision, and a fix is only one of four.

• Fix. Remove the weakness.
• Mitigate. Put something in front of it that lowers the risk while the real fix waits, such as a firewall rule. Write down what is still exposed.
• Accept. A named person with the authority signs for the risk, with a reason and a review date.
• Dispute. You think the finding is wrong or out of scope. Ask the tester to look again and keep it open until they answer.

Think of a home inspection that lists 30 items. You fix the wiring. You put a bucket under the slow leak until the plumber comes. You live with the squeaky door. You argue the one the inspector got wrong. What you do not do is throw the list away.

One condition matters here. An accepted risk still shows. Cobalt, for example, says findings marked Accepted Risk appear in the remediation section of the final report. If a customer or auditor will read that report, ask them in writing whether open or accepted findings are a problem before you accept anything. Accepting a risk inside your company does not cancel a duty you owe someone outside it.

What order should you fix findings in?

Start with what an outsider can reach and easily use, even when its label is lower than something buried deep inside your network.

The severity in the report is the tester's starting view. They rated the weakness, not your business. So add three facts of your own: can it be reached from the internet, what data or money does it touch, and does another finding chain through it?

Then fix causes, not samples. If the tester showed one page that leaks another customer's records, the same mistake may sit in three other pages built the same way. NIST's testing guide tells teams to work out the root cause of each finding for this reason (NIST SP 800-115, section 8.1).

We are not going to hand you a chart that says "critical in 7 days, high in 30." No rule we read sets one for every company, which the next section shows. Write your own numbers into your policy and then keep them.

What do PCI DSS and other rules say about remediation deadlines?

Less than most guides claim. The texts we could read ask for two things: fix according to risk, and check the fix.

We read the PCI DSS clause in the PCI Security Standards Council's Self-Assessment Questionnaire D for Merchants (PCI DSS v4.0.1, October 2024). Other sources: PCI SSC guidance, CISA.

So where do your dates come from? From your own written policy, and from whoever needs the proof. Your auditor, assessor, customer or regulator decides what they will accept. Nobody else can promise it, including us.

Who fixes the findings: you or the pentest company?

You do. The tester explains each finding and checks the fix.

That split is on purpose. Your team owns the code and the servers. And a tester who repairs a weakness and then grades the repair is checking their own homework. This is our judgment, not a rule, and small teams sometimes have no choice.

Name these people for every finding. One person can hold more than one job.

If nobody on your side can make the changes, a retest will not help. You need hands, not another test. Ask your developer, IT provider or a security firm for a quote to do the fixing, and ask who will then check their work.

Pen test remediation plan template

Copy this and fill in one block per finding. It works in a spreadsheet, a ticket or a shared document.

REMEDIATION AND RETEST RECORD

Finding ID and title:
Report name and version:
Severity as reported:
What is affected (systems, versions, user roles):
Decision (fix / mitigate / accept / dispute):
Why this priority:
Fix owner:
Approver:
Who will check it:
Root cause:
Planned change:
Stopgap in place, if any:
Fix date, and why that date:
Retest cutoff, and what starts the clock:
Proof needed by, and who needs it:
What was changed, where, and when:
Our own check and result:
Retest requested on:
Retest result, date, and what was tested:
Status:
Still open or left over:
If accepted: reason, who signed, review date:

Keep passwords and keys in systems built to hold secrets, and keep step-by-step attack details in the protected report or another approved evidence system, not this record. This record is a planning aid, not permission to test; written authorization has to cover the actual targets and activities.

Use these status words, and use them strictly. They are our suggestion, not a standard.

What a filled-in plan looks like

This example is made up. Northwind Ledger is a pretend 30-person software company with one web app, an API and two included retest rounds that must be requested by November 22, 2026.

One of four is verified fixed. That is the honest count, and it is the count Northwind gives its customer.

F-01 took three tries, and that is the useful part:

• Nov 3. The first fix goes live and the developer's own checks pass. Status: ready for retest. Not fixed.
• Nov 5. The tester cannot log in to the second test account. Status: blocked. Nobody writes "passed."
• Nov 6. The retest runs. The page the tester first reported is now safe, but the bulk export still leaks another customer's records. Status: still open. One of the two retest rounds is gone.
• Nov 12. A second fix covers the export. This time the team checks every path that touches customer records before asking.
• Nov 13. The second retest passes on both paths, for both test accounts. Status: verified fixed, in staging.

Two lessons. Fixing the one example in the report is not the same as fixing the cause. And staging is not production: the customer may want proof of what is live, so Northwind asks them.

How do you request a retest?

Send the finding numbers, what you changed, and what the tester needs to check it. Vague requests burn retest rounds.

Please retest findings [IDs] from [report name and version].

We deployed [change reference] to [environment and version] on [date].

What should now happen: [what must be blocked, and what must still work].

Please include [user roles, accounts, paths or systems] within the agreed scope.
Differences from the environment you tested: [list, or none].

Test access will be provided through [approved channel]. Our testing
authorization and limits are in [reference].

Please confirm how many retests this uses, any extra fee, when you will run it,
and when we will receive [updated report or agreed evidence].

For each finding, please record what you tested, the result, the date, the
scope and anything you could not check. We need this by [date].

Send it through the channel your provider uses. On some platforms, changing a finding's status to "ready" does not by itself start a retest, so make sure someone confirms they received the request.

Can you retest one finding before the rest are ready? Sometimes. HackerOne's help page says you can request retests for single findings, even while testing is still running. Astra counts each manual rescan against a small quota, so batching is smarter there. Ask your provider which model you are on.

What proof do you get back?

You should get each finding marked fixed or not, with the date and what was checked. The PCI SSC guidance suggests a retest report show the original test date, the retest date, the original findings and the retest results. Stated speeds differ: Cobalt says its testers retest within seven days of your request, and HackerOne says results usually arrive within 72 hours once a tester picks up the request. Those are the providers' stated norms, not promises for your job.

After the last retest, remove the test accounts and any tools the tester left behind. The same PCI SSC guidance calls for it.

Is a rescan the same as a retest?

Not always. A rescan runs a scanning tool again. A retest has someone, or something, repeat the original attack. A scan can confirm a missing patch. It usually cannot confirm that one customer can no longer read another's data. Look at what was actually checked and what evidence comes back, not at the name. More on that difference: penetration testing vs vulnerability scanning.

What if the retest window closed, or a retest was never included?

Ask for an extension in writing first. It usually beats buying a new test. Then work down this list.

1. Extension. Astra and Cobalt both say to ask your customer success manager. Neither publishes a price for it.
2. A paid retest from the same provider. HackerOne publishes how its works: you set a fee per retest, minimum $50, while your service is active. Most providers quote it.
3. Check it yourself and write it down. NIST's guide lists an audit or signed documentation as ways to verify a fix. That may satisfy your own management. It may not satisfy an outside reader, so ask them.
4. Leave low-risk items for your next scheduled test. Record that choice as an accepted risk with a date.
5. Verification from another firm. Some sell it as its own service. HALOCK, for one, describes retesting earlier findings by trying to reproduce them and then updating the original report. Its page gives no price, and does not say whether it will work from another firm's report. Ask both.

View HALOCK's remediation verification service

Is a retest enough, or do you need a new penetration test?

A retest primarily answers one question: are the old findings gone? It is not a new search across the full assessment scope.

If your changes do call for a wider test, write down what was tested before, what changed, who needs the report and by when. Then every provider prices the same job, and their answers line up. Our free tool builds that checklist with you. Choose "To check that earlier findings were fixed" on the first question. There is no sign-up and nothing is sent to providers.

Build your scope checklist

Still choosing a provider for the first time? Three numbers decide how remediation will go: how many retests, how many days, and what starts the clock. See how to check them in a proposal under is a retest included, and when does it expire? and compare published retest terms on our comparison of penetration testing companies.

Quick answers

Is remediation the same as mitigation?

No. Remediation removes the weakness. Mitigation lowers the risk while the weakness is still there. Record them differently, because a reader of your report will treat them differently.

Can we check our own fixes?

Yes, and you should before asking for a retest. Whether your own check counts as proof depends on who is asking. PCI DSS, where it applies, says penetration testing is repeated to verify corrections. For a customer or auditor, ask what they accept.

Does a clean retest mean we will pass the audit?

No one can promise that. A clean retest shows the listed findings were not found again, in the scope that was checked, on that date. Your auditor or customer decides whether that is enough. Send them these questions for your report recipient before you treat the job as done.

How we checked

We read each provider page and rule document linked on this page on October 9, 2026, and did the date arithmetic ourselves. The offer terms in the provider table are what each provider publishes about itself; the calculated dates are ours. We did not buy or run any of these tests, and we have not confirmed any term with a provider in writing. Where a page was silent, we say "not stated" instead of guessing. Our method is described in how we check offers, and how we make money explains our funding. Payment plays no part in who is listed or in what order.

Sources

All checked October 9, 2026.

• Astra, "Best Practices for Using Your Rescan Quota": https://help.getastra.com/articles/1348385025-best-practices-for-using-your-rescan-quota
• BreachLock, penetration testing pricing: https://www.breachlock.com/pricing/penetration-testing-pricing/
• Cobalt, "Remediate Findings": https://docs.cobalt.io/articles/remediate-findings-22WPR0Fnlv
• Cobalt, pricing page FAQ: https://www.cobalt.io/platform/pricing
• HackerOne, "Manage Pentest Retesting" (March 24, 2026): https://docs.hackerone.com/en/articles/8541386-manage-pentest-retesting
• HackerOne, "Retesting Pentests" (June 13, 2025): https://docs.hackerone.com/en/articles/8481554-retesting-pentests
• Syslifters, "Overview of our pentesting procedure": https://handbook.syslifters.com/pentesting-procedure
• Triaxiom, penetration testing service page: https://www.triaxiomsecurity.com/penetration-testing/
• HALOCK, "Penetration Testing Remediation Verification": https://www.halock.com/penetration-testing/remediation-verification/
• PCI Security Standards Council, Self-Assessment Questionnaire D for Merchants, PCI DSS v4.0.1 (October 2024), Requirement 11.4.4: https://docs-prv.pcisecuritystandards.org/SAQ%20%28Assessment%29/SAQ/PCI-DSS-v4-0-1-SAQ-D-Merchant.pdf
• PCI Security Standards Council, Information Supplement: Penetration Testing Guidance v1.1 (September 2017): https://www.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (September 2008): https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf
• CISA, BOD 19-02 (revoked): https://www.cisa.gov/news-events/directives/bod-19-02-vulnerability-remediation-requirements-internet-accessible-systems-revoked