What Happens After a Penetration Test

After a penetration test, name one owner for the report, confirm the critical findings are already handled, book a debrief with the engineers, triage on exploitability as well as severity, fix classes rather than instances, record what you accept, and retest once the fixes are deployed. Most of the value of a test is created after it finishes, and most of it is lost there too: a report that sits unread for six weeks has cost 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.

1. 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.
2. 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.
3. 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. Agreed vulnerability remediation timelines make the order defensible.

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. When a client accepts the risk instead of fixing it covers the testing firm's side of the same decision.

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, as how to run a retest properly describes.

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, handled well on both sides when it follows the pattern in when a client disputes a finding.

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.

Before you file the report, 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.