Reporting a Critical Finding During a Penetration Test

When you find something critical during a penetration test, confirm it is real and reachable, call the contact agreed in the rules of engagement, and follow the call with a short written summary, without waiting for the report. What counts as critical, and who gets called, should already have been decided before the test started.

Picture Tuesday afternoon of a five-day test. You have just confirmed that an unauthenticated request returns other customers' records. The report is not due until Friday week, and nothing about the next twenty minutes should involve deciding what your firm's policy is.

Decide this before the engagement, not during it

The out-of-band notification threshold belongs in the rules of engagement, agreed with the client while nobody is under pressure. What counts as immediate, who is called, on what number, and who is called if that person does not answer.

Without it you are making a judgement in the moment, on somebody else's behalf, about a risk they understand better than you do. The client who wanted to be called at midnight and the client who wanted this handled in the Friday summary are both reasonable, and you cannot tell which you have by looking at them.

Ask for two names and two routes. The single named contact will be on a plane on the day it matters, and an escalation that stalls because one person did not pick up is an escalation that failed.

Confirm enough to be right, not everything

There is a temptation to fully explore before raising it, because nobody wants to make the call and then retract. That instinct is correct for severity and wrong for timing.

Establish that the behaviour is real, reproducible, and reachable from where you claim. That is enough to notify. Full impact, blast radius and root cause can follow, and the client will make different decisions with four hours of warning and a partial picture than with a complete picture on Friday.

Be explicit about the state of your knowledge when you call. "Confirmed reachable without authentication, we have not yet established how many records are exposed or how long it has been this way" is honest, actionable, and does not commit you to a number you will have to correct.

Say it in a form they can act on

A phone call gets attention and leaves no record. An email leaves a record and may sit unread for hours. Do both: call, then send a short written summary immediately afterwards, and say on the call that it is coming.

• What you found, in one sentence, in consequences rather than vulnerability class.
• Where, precisely enough for their team to look at it now.
• What you did and did not do. Testers have been accused of causing what they reported.
• What you would do first if it were yours, offered as an opinion rather than an instruction.
• What you are going to do next, and whether you are pausing.

Whether to keep testing

The default should be to continue, and to say that you are continuing. The exception is where continuing risks harm: an unstable system, a finding that suggests an active intruder, or a data exposure where further probing means touching more real records than you already have. Testing in production without breaking it covers where those lines usually sit.

Where you stop, say why and what it costs. Days spent waiting for a decision are days not spent testing, and a client deciding at ten in the morning rather than four in the afternoon may recover most of a day.

The finding still has to be written properly

An urgent finding raised by phone frequently arrives in the report thinner than the ones nobody rang about, because the conversation felt like the delivery. It was not.

The written finding is what survives, gets forwarded, and gets audited. Write it to the same standard, and add the notification itself to the record: when you called, who you spoke to, what you told them, and what they said they would do. In six months that timeline is the part somebody needs, and nobody will remember it.

The threshold is harder to write than it looks

"Critical findings will be reported immediately" sounds like a policy and is not one, because critical is a label you apply after a judgement rather than a category you can recognise on sight. A threshold that works describes situations rather than scores.

• Unauthenticated access to data belonging to more than one customer.
• Anything that lets an attacker execute code on a system holding production data.
• Credentials for a production system found somewhere they should not be, including in your own findings.
• Evidence that the weakness is being exploited by somebody who is not you, which needs the separate handling described in when you find signs of a prior compromise.
• Anything on a life safety or payment path, where the client's tolerance is different from their tolerance elsewhere.

Write those into the rules of engagement, and let the client add to the list. What comes back is often revealing: an organisation that adds "any finding affecting the pension calculation" is telling you something about their risk that no severity model would have produced.

Handling the one that turns out to be less than you thought

Occasionally you raise something urgently and it deflates. The records were synthetic, the endpoint was on a test instance somebody forgot to mention, the exposure was behind a control you could not see from where you were standing.

Correct it as quickly as you raised it, in the same channel, with the same seriousness. Firms hesitate here because retracting feels worse than the original call, and it is the opposite: a client who has watched you escalate and then correct yourself learns that your escalations are judgements rather than reflexes, which is exactly what they need to know the next time you ring.

Do not delete it from the report either. A finding that was raised, investigated and downgraded is a legitimate part of what happened that week, and it is often the clearest evidence that the process worked.