Penetration Test Remediation
You have a report, a retest date, and nobody in the building who can do the work in between.
This is the most common position I get called into, and it is not a failure of planning. Testing is easy to buy and easy to schedule. The work between the report arriving and the retest passing is engineering with a regulatory paper trail attached, and almost nobody has that sitting spare.
The report is not the hard part
The report is thorough. Every finding has a severity, a description, and a recommendation. It reads like a plan.
Then you look for who is going to do it. Your engineering team can read the findings, but a line like “insufficient entropy in session token generation” is not a ticket. Somebody has to translate it into a change, decide whether the recommended fix suits the architecture, and know which findings actually matter to you rather than to a generic threat model.
If a managed provider runs your infrastructure, their contract is uptime and support. Application-layer findings sit outside it, and a provider without a security practice will quietly deprioritize them rather than say so.
So the report ages. I have seen findings from one test still open when the next year’s test rediscovers them.
The firm that tested you cannot close its own findings
This is the part worth understanding properly, because it is structural rather than a scheduling accident, and it is not going to resolve itself if you wait.
An assessor who remediates their own findings and then retests them has no independence left. Anyone reading that retest downstream - a regulator, an enterprise customer’s security team, an acquirer doing diligence - can see the circularity immediately. The firm marked its own homework, so the retest establishes nothing.
Good testing firms know this and decline the work. That is not obstruction. It is them protecting the only thing that made their report worth having in the first place.
Which leaves the findings with you, and the two groups who might plausibly act on them are usually not equipped to. That gap is permanent, it exists at every company that buys a test, and it is the entire reason this service exists.
That is the intended use. You keep your independence as the assessor, I close the findings and produce the evidence, and it comes back to you for retest. Your client does not have to change vendors and you do not have to compromise the engagement.
What remediation actually involves
Not all of it is code. The parts that get skipped are the parts a reviewer looks hardest at.
Triage, and the severity argument
Every finding gets a verdict, not just the ones that get fixed. Severity in the report is the assessor’s view of generic risk without full knowledge of your system. Where you know something they did not, that gets argued and the report gets corrected - not quietly downgraded in your own tracker.
The fix itself
Most fixes are small. The work is knowing which change is correct for your architecture, whether the recommended control is even implementable as written, and not introducing a regression while making it.
Documentation a reviewer can follow
What was found, what changed, how the change was verified, and who approved it. Written as it happens. Reconstructing it afterwards from memory is far harder and reads that way to whoever is assessing you.
Accepted risk, written down
Not every finding should be fixed. A risk that is accepted with a rationale in writing is a decision. The same risk left undocumented is an oversight, and the difference is entirely visible to a regulator or an acquirer.
Driving through retest
Closure is confirmed by the same firm against the same scope. I manage the evidence back to them and stay on it until the retest is clean, which is the point at which any of this is worth anything to you.
The findings that are not real
A scanner reads an artifact it does not fully understand and reports the shape of a problem rather than a problem. Disproving one takes about as long as fixing an easy one and produces no visible change, which is exactly why it gets skipped. It still has to be done, and written down.
Where this comes up
Medical device companies
Going into a 510(k) with testing that has to be scoped, run, and driven to closure before the submission goes out - or coming out of one holding a deficiency letter that asks for exactly this. Penetration testing gets its own scrutiny in that review, and the evidence has to be traceable rather than asserted. If a letter is what you are holding, start with FDA cybersecurity remediation instead.
Health software and SaMD vendors
Facing enterprise security review, a customer’s questionnaire, or the security section of a renewal. The findings are usually application-layer and cloud configuration, and the buyer on the other side wants closure evidence, not a remediation plan.
Regulated firms generally
Legal, financial services, anyone whose customers audit them. The common thread is that somebody outside the company will eventually read the closure record, which changes what the closure record has to be.
Scoped against your report
This is fixed-price project work: a defined scope, milestones, and an end date, on the same terms as any other project engagement. The report tells us the scope, so it can be quoted properly rather than estimated vaguely.
What the engagement produces is a closed report, the documentation behind each disposition, and a retest you can hand to whoever asked for it. If ongoing security ownership turns out to be the actual need, that is a fractional arrangement and a separate conversation - not something to bundle into this.
Everything I build, change, and document is yours.
Questions I get asked first
Can the firm that tested us just fix the findings too?
Most reputable firms decline, and they are right to. An assessor who remediates their own findings and then retests them has no independence left, and anyone reading that retest downstream can see the circularity. Some firms offer remediation through a separate team, which helps but does not fully resolve it.
How long does remediation take?
It depends far more on decision-making than on engineering. The fixes are often small. Establishing who owns each finding, what the accepted risk is, and which changes need formal verification is what consumes the calendar.
We have a retest date. Is that enough time?
Usually, if the work starts now and triage happens first. The common failure is spreading effort evenly across a report instead of sorting by severity and then regrouping by application, so the same codebase gets opened once rather than five times.
Do you work with our existing testing firm?
Yes, and it is the normal arrangement. They keep their independence as the assessor, I close the findings, and the evidence goes back to them for retest. Nobody has to change vendors for this to work.
Written on this
Send me the report
Tell me what you are holding and when the retest is. I will tell you whether the date is realistic and what closing it involves. If the honest answer is that you can do this in-house, I will say so.