What Happens After a Penetration Test
The report is the halfway point. How to triage what came back, what to fix first, what a retest proves, and what to tell the customer who asked for the test in the first place.
Most of the value of a penetration test is created after it finishes, and most of it is lost there too. A report that sits unread for six weeks has cost you the full price and delivered nothing.
The first week
Read the executive summary and the findings list, and do three things before you do anything technical.
- Assign an owner. One named person accountable for the whole set, not a distribution list. Reports without an owner are the ones that go quiet.
- Check the criticals are already handled. A good tester will have told you during the test. If a critical is a surprise on delivery day, raise that with them as well as fixing it.
- Book the debrief. An hour with the tester and the engineers who will do the work is the highest-value hour in the whole engagement, and it stops the round of email that otherwise follows.
Triage on exploitability, not only severity
Severity is the tester’s judgement of the weakness. Your priority is a different calculation, and the honest inputs are: how reachable is it, what does an attacker get, how much data is behind it, and how long is the fix.
A medium on an internet-facing endpoint that leaks other customers’ data usually outranks a high on an internal tool three people use. Say so in your own record rather than silently reordering, because the next reader needs to know it was a decision.
Turn every finding into a ticket in your own system on the day the report lands, even the ones you will not fix. A finding with no ticket has no owner, no date and no trail, and it is the one that appears again in next year’s report.
Fixing, and the two traps
The first trap is fixing the instance rather than the class. A tester found the flaw on one endpoint because they had five days; the same pattern usually exists on others. Ask whether the finding describes a mistake or a habit, and search for the habit.
The second is fixing the symptom the report described. If remediation says a parameter is not validated, validating that parameter closes the example. Validating input at that boundary closes the finding.
What you are not going to fix
Some findings will be accepted, and that is a legitimate answer. Record four things: who accepted it, what they were told, why, and when it will be revisited. The last one is skipped most often and is what makes acceptance permanent by default.
Do not close the finding. Accepted and closed are different states, and a closed finding tells a future reader it was dealt with when it was weighed and kept. That distinction matters enormously if anything ever goes wrong.
The retest
A retest proves the specific findings are gone. It does not re-test the system, and a report that implies otherwise is doing you no favours.
Ask what it covers, whether it exploits again or only inspects the change, and what happens to findings you have accepted rather than fixed. Do it once the fixes are actually deployed to the environment that was tested, not once they are merged, and expect the tester to state clearly which findings were re-examined and which were not.
Telling the customer who asked for it
If the test exists because a customer or an auditor asked, they rarely want the technical report and often should not have it. What satisfies them is usually an attestation: what was tested, by whom, when, and a statement that identified issues were remediated and verified.
Hand over the full report only when you have decided you are content for a list of your weaknesses, some of which you have accepted, to sit in somebody else’s document store. That is a commercial decision and it deserves a moment’s thought rather than a reflex.
When you disagree with a finding
Sometimes the tester is wrong, or right about the mechanism and wrong about the impact in your environment. That happens, and it is a normal conversation rather than a complaint.
Take it back with specifics: what the compensating control is, why it applies, and evidence it is actually in place. A firm worth using will re-rate or withdraw a finding when shown something they did not have. What does not work is arguing severity in the abstract, because both sides are then defending a judgement rather than examining a fact.
Whatever the outcome, get it written into the report rather than agreed on a call. A finding downgraded by email and left at its original rating in the document is the version an auditor will read in a year.
Feed it back into how you build
The most valuable output of a test is not the list. It is the pattern. Two authorisation findings on different endpoints say something about how permission checks are added in your codebase, and that is fixable in a way that individual tickets are not.
Take the two or three most common causes into whatever you already do: a check in code review, a test in the pipeline, a note in the definition of done. A finding that cannot recur is worth more than a finding that was fixed, and it is the only way the second test comes back shorter than the first.
Then close the loop
Before you file it, write down two things for next time: what the test could not cover and why, and which findings were repeats of last year’s. The second list is the one that tells you whether you have a remediation problem or a testing problem, and nobody keeps it.
Findings keep their state rather than disappearing into a closed list, so an accepted risk stays visible with the reason and the review date attached. A retest records what was re-examined and what was not, and the client portal shows the customer their own findings and documents without anything being emailed as an attachment.
Pental Is Built by the People Writing This
Engagement management for testing firms, on a database you own, under your brand, with the AI running on your key.