Security practice / Practice case
The Leverage Between
Penetration Tests
How a consulting rotation turned the work around a test into a service the team could share.
In short Much of a test's value shows up after the report. Giving those questions a shared route changed what the team could do next.
Published Updated 8 min read
01 / From the tester's chair
I knew the old pattern from the tester's chair. The test ended. The questions did not.
Here's a typical one, a composite of many. Two weeks after a report goes out, an application owner writes: "We fixed the authorization finding. Is our fix enough, and can you retest it this week?" It's a good question. It's also four questions at once: what the finding actually established, whether a design change is sound, what evidence a retest needs, and who schedules it. The natural move is to send it to the tester who found the issue. Sometimes that's exactly the right person. Just as often, that tester becomes the front door for work that belongs to another workflow or another team, while they're already deep in the next test.
When I became a technical lead, I had a chance to fix a problem I'd lived. I proposed a consulting rotation: one tester on duty for a defined turn, with a backup and a way to call in peers or a lead when a case needed another view. Everyone else could concentrate on scheduled testing. The idea was still theoretical when I brought it forward, and an excellent, supportive leader gave me room to make the case on its merits and build it. It was a team decision, and a leverage decision. I can't offer a controlled study, but I can tell you what the service numbers did.
Before the rotation, our retest commitment was about a month, and it routinely ran right up to the wire, because the tester who owned it was deep in their next engagement. With the rotation we brought it down to a few days, and it has stayed there. In practice the turnaround is often quicker, because someone is always watching the queue. Questions by email usually get a same-day reply. And the rotation has never gone unstaffed, which matters more than it sounds: before, a tester's time off meant the fallback routes kicked in and the service splintered.
What this piece offers is the shape we arrived at, told through that one question: how to design the lane a post-test question travels, from the closing meeting to a recorded outcome. The roles and channels are generalized, typical ones, not a map of any particular organization. If you want the reusable version, the consulting guidebook in the Open Practice Framework turns this lane into a template you can adapt.
02 / Security practice
Give people the route before they need it
Our application owner's question started long before they typed it. It started at the closing meeting.
That meeting is the best chance to explain what the finding establishes, what the owner carries forward, what evidence a fix will need, and how to ask for a retest or a closure review. It's also where you say, out loud, where questions go after today. When people already know the route, the first follow-up arrives in the right place instead of in one tester's direct messages.
So when the owner writes, the message lands in a shared inbox, not a personal one. Questions differ in urgency and in the kind of help they need, so there's more than one door. The inbox handles ordinary finding and process questions. Scheduled drop-in time takes pressure off it when something is easier to work through live than in another long reply. Formal retest and closure requests go through the vulnerability-management record, with the evidence attached. A chat message can be a heads-up that something is coming; it works badly as the only record, and worse as a quiet new commitment.
None of those doors works without a schedule behind it. A shared inbox nobody owns is just a slower personal one, and drop-in time with no one assigned is an empty room. The rotation is what makes a named person responsible for both today.
The on-duty tester picks up our owner's question. They're more than a mailbox monitor. They have enough offensive-security depth to explain how the authorization flaw was found, what the evidence supports, and how a tester would check a fix. They can offer general remediation direction without pretending to own the application's design. Their first answer is about scope: the finding showed that one role could reach another role's records through a specific request; the retest will check that path and its close neighbors, and here's what the record needs before it can be scheduled.
03 / Security practice
Be clear about whose work it is
The owner's second question, is our fix enough?, is where the lane meets its edge.
Whether a design change is sound for the application as a whole isn't the on-duty tester's call. It needs a better partner, not a more available pentester. A secure-code advocate can help a team change how it builds. A security partner on the business side, or an architect, can help shape a durable fix that fits the application and its standards. Vulnerability management owns the path to closure. A secrets or policy question goes to its specialist owner, and if a third-party product has to change, the business partner who manages that relationship belongs in the plan.
So the on-duty tester does two things. They answer what they can answer: what the finding means, what a convincing fix would have to prevent, what the retest will try. And they hand the design question to the architect with the evidence attached, so the owner isn't forwarded into a fresh round of "can you explain the finding again?" The job is to make the offensive-security evidence useful to those people, then keep the handoff visible to everyone involved.
04 / Security practice
A second service to the team
The same rotation turned out to serve the testers, not just the customers.
The first benefit is quiet relief. Testers stop fielding daily pings about every open finding they've ever reported, because someone else is handling them. The rest of the team gets to put its attention where it belongs: the test in front of them, their methodology, and their own learning.
While our owner's fix is being designed, the original tester is finishing a different report. The on-duty tester, during staffed hours, can review a finding and its evidence, check a report as a whole for technical accuracy before delivery, join another tester for a difficult customer conversation, or pick up a bounded urgent request the normal routes can't absorb. The author of a finding still owns the test work. The reviewer asks whether a reader could reproduce the reasoning, and whether the report claims more than the evidence shows.
Peer review earns its keep as a real exchange. Scripted checks catch missing sections. A knowledgeable peer asks about missing conditions, challenges a severity, suggests a follow-on attack, or wonders whether the same flaw lives in another endpoint. When our owner's retest comes up, that habit matters: the retesting tester tries the original path and its variants, because a peer once asked "does this only fail for that one role?"
05 / Security practice
Staff the rotation, then make room for reality
Rotations change hands, and our owner's question can easily outlive one tester's turn. The handoff raises ordinary but important questions. What context or commitments haven't made it into the record? Does the next tester have authorized access to the right environment, or does access need provisioning again? What's waiting in the inbox and the retest queue, and which service clocks are already running? A short open-work handoff, confirmed coverage and a visible backup are part of the service.
Those clocks deserve care. A first acknowledgment, a researched answer, a retest after readiness and a closure review are different clocks, each with a start, a stop and an owner. A fast "we received this" is nice; useful guidance is what people come back for. Someone also needs to watch the aging work behind the dashboard, because a thoughtful exchange makes people willing to use the service again, and a careless one sends them back to side channels.
Then something arrives that doesn't fit the cadence: a critical finding on an externally facing system, a severity change, or a campaign that needs several testers at once. That escalation has its own owners and playbooks. For the consulting lane, the rule I settled on was simple: an exception gets a visible trigger, staffing that fits the work, and a route back to planned testing, so "urgent" doesn't quietly become a permanent bypass.
Our owner's story ends quietly, which is the point. The architect approves a revised design. The retest is scheduled through the record, with the deployed fix and access already confirmed. The tester checks the original path and its variants, finds them closed, and records what was tested and what wasn't. The owner gets an answer they can act on, and the tester who found the issue was never pulled off their next engagement to give it.
06 / Fit the service to the work
When should your consulting model change?
The rotation worked because one assigned tester could cover the lane while the rest of the team kept testing, with a backup and an escalation path when a case needed another view. A smaller practice with manageable follow-up, capable issue owners and a strong vulnerability-management partner might need no dedicated consulting lane at all. The useful test is whether requests get tracked, answered and handed off without repeatedly interrupting the person who found the issue.
That balance moves with volume and complexity. More engagements across more application teams produce more findings to validate and carry to closure. Agentic testing may add throughput, and with it more candidates needing human triage before delivery. Clear intake, linked case context and some automation can absorb part of the reconstruction and routing. If unresolved requests, retests, escalations or after-hours demand outgrow the rotation, a dedicated service may be worth the investment. Round-the-clock coverage is a separate capacity and risk decision, and I'd treat it that way.
07 / Carry the question forward
What would you build next?
If you follow our owner's question end to end, the slow part was never the reply. It was rebuilding context: the original report, the vulnerability record, the retest request, the access owner, the architect's decision. A single post-test question can touch all of them, and the costly part is getting that context to the person who can act. Automating the reply while those seams stay broken would only make the same service faster at being incomplete.
That's the question I want to explore next: what this desk looks like rebuilt with agents, where a request arrives with its related record, its scope and its missing evidence already linked, and a person still makes every call that matters. It's big enough to be its own piece, The Consulting Desk, Rebuilt With Agents, and it's coming.
Until then, the most useful exercise I know costs nothing. Pick one real question from the end of a recent test and follow it to its resolution: what had to be reconstructed, who could decide, what survived each handoff, and whether the customer could move forward. That path will tell you more about what to build than a faster reply button. The consulting guidebook in the Open Practice Framework is there if you want a template for the lane.
A practice-design essay drawn from a lived service, not a measured performance study.