Poor client communication is often treated as a soft-skills issue.
In a penetration testing business, it is a margin issue.
The cost rarely appears as a clean line item. It shows up as rework, delayed reports, awkward severity debates, repeated clarification calls and senior people being pulled into projects they were not meant to deliver.
A single unclear conversation may not matter much. Across a team, repeated every week, the cost becomes significant.
Most offensive security leaders can point to projects that looked profitable on paper but became painful in delivery. The tester did the work. The vulnerability was real. The report was eventually issued. But the project consumed more senior time, more QA effort and more management attention than expected.
That is where margin quietly disappears.
Margin is lost in the gaps between delivery stages
Penetration testing delivery is not just the test itself.
There is scoping, scheduling, access management, testing, evidence capture, report writing, QA, debrief, retesting and sometimes follow-up support. Communication sits between each of those stages.
When communication is weak, small gaps become delivery friction.
A vague scope leads to unclear expectations. Poor access notes delay the test. Weak evidence slows QA. An unclear finding creates client challenge. A rushed debrief leaves the client confused. A confused client comes back with more questions.
None of this feels dramatic at the time. It is just another email, another call, another report review, another senior tester asked to “take a quick look”.
But the commercial effect is real.
If a fixed-price project needs an extra half day from a senior consultant, the margin has changed. If a report takes three review cycles instead of one, the margin has changed. If a delivery manager spends two hours calming down a client because the finding was poorly explained, the margin has changed.
The client may never see that cost. The business still carries it.
Scoping gaps become delivery pressure
Poor communication often starts before the tester is assigned.
A sales conversation may capture the obvious technical scope: number of applications, IP ranges, API endpoints, user roles, environments and test windows. That is necessary, but it is not always enough.
The real issues often sit in the assumptions.
What does the client expect the test to prove? Which systems matter most? Are there fragile environments? Are there known access issues? Is the client expecting a compliance-style test, a deep technical review, or something closer to assurance for a board-level risk?
If those questions are not handled properly, the tester inherits the ambiguity.
That can create pressure during delivery. The tester may find that the environment is not ready, credentials do not work, user roles are missing, or the client expected coverage that was never priced.
At that point, someone has to absorb the problem.
Sometimes the tester works late to keep the project on track. Sometimes the delivery manager negotiates a compromise. Sometimes the business gives away extra effort because the client expectation was not managed clearly enough at the start.
This is not just a delivery issue. It is a pricing issue.
If the scope does not reflect the work required, the margin was already at risk before testing began.
This is why poor scoping damages pentest delivery. The problem often appears during testing, but the commercial damage usually starts much earlier.
Weak findings create QA and report rework
A technically valid finding can still be expensive to process.
The tester may have found the issue correctly, but the write-up might not explain the risk clearly. The evidence may be thin. The recommendation may be generic. The severity may be asserted rather than reasoned. The business context may be missing.
That creates work downstream.
QA reviewers have to ask more questions. Senior testers rewrite sections. Delivery managers delay report issue. The client receives the report later than expected, or receives a report that creates avoidable challenge.
Common signs include:
- findings that describe the technical behaviour but not the risk
- recommendations that do not tell the client what to change
- severity ratings with weak justification
- screenshots without enough context
- assumptions presented as facts
- vague wording such as “may allow” without explaining the realistic path
Each one creates drag.
The tester may only need twenty minutes to fix a finding, but the reviewer has to spot the issue, comment on it, wait for the update, check it again and sometimes rewrite it anyway. Multiply that across several findings, several testers and several reports, and QA becomes a hidden delivery cost.
This is one of the reasons senior people become bottlenecks.
They are not only checking technical accuracy. They are compensating for unclear communication.
This is also why good QA in a penetration testing team needs to test more than formatting and spelling. It should check whether the finding is evidenced, proportionate, clear and usable.
Poor severity explanations turn into escalations
Severity is one of the most common places where communication affects margin.
Clients challenge ratings for different reasons. Sometimes they have valid context the tester did not have. Sometimes an internal team wants a finding lowered because remediation is difficult. Sometimes a risk owner wants it raised because the affected function is business-critical. Sometimes the client simply does not understand how the rating was reached.
The problem is not the challenge itself. Challenge is normal.
The problem is when the tester cannot explain the judgement clearly.
A good severity discussion separates evidence, context and professional judgement. It should be clear what was proven, what was assumed, what the likely impact is and what conditions would change the rating.
Without that clarity, the conversation often becomes defensive.
The tester repeats the finding. The client repeats their objection. A manager gets involved. A senior consultant is asked to review the issue. The report may be amended, but the team loses time and confidence in the process.
This is where consulting skill protects margin.
A tester who can explain severity calmly and clearly is less likely to create unnecessary escalation. They may still change the rating if the client provides new context, but the conversation is controlled, evidenced and defensible.
That matters commercially because every avoidable escalation consumes senior time that was not priced into the project.
Senior people become the unpaid buffer
Most pentest teams have a small number of people who quietly protect delivery quality.
They rewrite poor findings. They join awkward client calls. They deal with scope disputes. They explain technical risk to non-technical stakeholders. They correct weak recommendations. They smooth over misunderstandings between sales, delivery and the client.
This is useful in the short term, but it hides the real cost.
The business may think a project was delivered within budget because the tester’s booked time looks reasonable. In reality, senior people may have absorbed the communication failure around the edges.
That time is rarely measured properly.
It may appear as internal support, informal mentoring, QA, management overhead or just “helping out”. The commercial problem is that those senior people are usually the most expensive and scarce people in the team.
If they are repeatedly used as a buffer for poor client communication, they cannot focus on higher-value work.
That affects more than one project. It affects sales support, complex delivery, team development, service improvement and retention.
Senior people can tolerate this for a while. Eventually, it becomes frustrating. They feel as though they are carrying the same problems repeatedly, often without the business recognising the cost.
This is how senior pentesters become the delivery bottleneck. The team still delivers, but too much work is being routed through the most experienced people.
The client experience also affects repeat work
Poor communication does not only damage delivery margin. It can affect future revenue.
A client may accept the final report, but still leave the engagement with doubts.
They may feel the tester did not understand their environment. They may feel findings were difficult to interpret. They may feel the debrief was too technical, too vague or too defensive. They may feel they had to work too hard to get clear answers.
That matters when renewal time comes.
Many clients do not buy penetration testing purely on technical depth. They buy confidence. They want to know that the provider understands the environment, can explain risk clearly and will not create unnecessary noise.
Strong technical work can be undermined by weak communication.
This is especially important for providers trying to move beyond transactional testing. If the goal is retained work, broader accounts, strategic relationships or advisory-led delivery, communication quality becomes part of the product.
The report is not the only deliverable. The client’s confidence is part of what they bought.
What offensive security leaders should measure
If communication problems are affecting margin, they need to be made visible.
This does not require a large measurement programme. A few practical indicators can expose where time is being lost.
Useful measures include:
- number of QA review cycles per report
- time from test completion to report issue
- volume of client clarification questions after report delivery
- number of severity disputes
- amount of unplanned senior involvement
- report sections rewritten during QA
- retest friction caused by unclear recommendations
- unbilled time on fixed-price projects
- projects requiring management intervention
These measures will not tell the whole story, but they give leaders somewhere to look.
If the same testers repeatedly need heavy QA support, that is a coaching signal. If the same service line creates repeated severity disputes, the rating guidance may need work. If certain sales conversations regularly become delivery issues, scoping needs to improve.
The aim is not to blame individuals. The aim is to understand where communication is creating operational cost.
Once visible, the problem becomes easier to address.
For a broader view, leaders should also measure penetration testing team performance across quality, rework, client friction, senior dependency and delivery margin.
What this means for pentest team performance
Poor client communication is not just an irritant.
It affects delivery quality, senior capacity, report turnaround, client confidence and project margin.
The fix is not to turn testers into salespeople. It is to develop better consulting behaviours across the delivery team. Testers need to ask clearer questions, explain findings properly, separate evidence from assumption and handle client challenge without becoming defensive or vague.
For offensive security leaders, this is one of the practical constraints on scaling a team.
You can hire more testers. You can improve tooling. You can introduce AI into parts of the workflow. But if the team cannot communicate clearly with clients, the business will still lose time in rework, escalation and senior rescue.
That is where margin gets eroded.
Not in one obvious failure, but in the repeated small costs that nobody priced.