Handing a Penetration Test to Another Tester Mid-Engagement

To hand over a penetration test mid-engagement without losing a day, give the second tester a coverage list that separates "tested, nothing found" from "not tested", the working credentials with their roles, the loose ends, and a thirty-minute live call, then tell the client and amend the authorisation if it names individuals. Most handovers cost a day not because the work is hard to explain, but because what a tester carries in their head for a week was never written anywhere.

What is actually lost

Findings survive a handover. They are written down, rated and evidenced. What does not survive is everything around them:

• Which areas have been covered and found nothing, as against not looked at yet. This is the big one, and it is why the second tester re-tests things.
• The credentials that work, which of them are for which role, and which one the client reset on Tuesday.
• The three things that looked interesting and have not been chased.
• The one endpoint that returns a 500 for a reason nobody has worked out.
• What the client has already been told, verbally, in a stand-up on Wednesday.

Write the negative results down

Testers record what they find. Almost nobody records what they checked and cleared, because it feels like writing down nothing. It is the single most useful thing in a handover, and it is also what lets you answer "did you test X" three months later without hedging, which is the subject of proving what you tested when a client asks.

It does not have to be prose. A checklist per area with a date and a name against each line is enough, and it doubles as the evidence for your own coverage claims.

The handover itself

Thirty minutes, live, with both testers and the notes open. Not a document thrown over a wall, because the questions the second tester has are not the ones the first thought to answer.

Cover, in this order: what the target is and what matters about it, what is done, what is in flight, what is not started, the access situation, and anything the client has been told. Access last is deliberate, because it is the part most likely to have changed since Monday and it is worth checking live rather than reading out.

Tell the client, and fix the paperwork

Somebody new is going to appear in their inbox and possibly in their logs. Tell them before that happens, with the name, and confirm the authorisation covers the new person. If your authorisation letter names individuals, it now needs amending, and finding that out after the traffic starts is a bad afternoon.

Say it plainly and without apology. Handovers are normal in professional services and clients handle them fine when they are told; what they mind is finding out from a log.

Access does not transfer by itself

Three things break quietly when the person changes. Credentials issued to a named tester were authorised for that person, so ask the client to issue fresh ones or to confirm in writing that the replacement may use the existing accounts. Source addresses change too: if the client allowlists testing IPs at a firewall or web application firewall, the new tester's traffic will be blocked or, worse, flagged as an attack by a security team nobody told. And any VPN or jump-host account tied to the first tester's identity needs the same treatment as the credentials.

When the first tester steps away, their access should end with their involvement, in the same way it would at the end of the engagement. The habits in handling evidence and client credentials safely apply here unchanged: credentials live in one controlled place, not in a chat thread the second tester scrolls back through.

Who writes the report

Decide this at the handover, not at the end. The two workable answers are that the second tester writes everything, using the first tester’s notes, or that each writes their own findings and one person edits the whole for voice. What does not work is both writing separately and stapling it together, which produces the two-voice document a client notices immediately.

The lead named on the report should be whoever will answer questions about it in three months. Usually that is the second tester, and if it is not, the first needs to still be reachable.

Planned handovers are a different problem

Everything above assumes the handover is unwanted. Some are not: a job that deliberately runs across two testers for coverage, or a long engagement where a specialist takes one phase. Those go wrong differently, and the failure is overlap rather than gaps.

Two testers working the same target without a boundary produce duplicate findings with different ratings and different wording, and somebody spends an afternoon merging them badly. Draw the line up front and draw it by area rather than by time: one takes authentication and the user-facing application, the other takes the API and the infrastructure. Time-sliced handovers are what produce the coverage question, because neither tester owns anything end to end.

Then agree one person as the report owner from day one. The owner settles the severity calls where they disagree, edits for one voice, and is the name a client comes back to. The other tester writes their findings into the same structure rather than into a separate document, which sounds obvious and is the step that gets skipped every time it is not stated.

The version most firms need

If this is the first handover you have had to do, the minimum that avoids the lost day is: a coverage list with cleared items marked, current credentials with roles, a short list of loose ends, and a thirty-minute call. Everything else is refinement.