How poor client communication erodes pentest margin

A fixed-price test can use more time than the project record suggests. Access queries, repeated report corrections and extra client calls all add effort, including time from people who were never assigned to the engagement. Recording that work and understanding why it happened helps you decide what to improve, what to charge for and what to absorb deliberately.

By Simon ChapmanPublished Updated Last reviewed

Discuss your teamAll articles
Penetration testing team reviewing client notes, report feedback and delivery timelines
Pentest team performanceBy Simon Chapman

The short version

  • Include informal senior support when reviewing the effort spent on an engagement.
  • Record the cause of extra work so a clarification request is not automatically counted as a defect.
  • Use review records to distinguish correction time from time spent waiting.
  • Agree the treatment of additional scope before undertaking it.

The tester finishes the booked days on a fixed-price application test. On paper, the engagement looks close to plan. Then a senior consultant spends an extra half day helping with the report, and a delivery manager spends two hours resolving a disagreement. The quote allowed for reporting and review, but not all of that extra work.

Those figures are illustrative. They show how easily a project can cost more than the assigned tester’s timesheet suggests.

To work out which parts were avoidable, the team first needs to see where the extra time went.

Where the additional work begins

In this example, the proposal includes testing two user roles. Only one account works when the test starts. The access request named the roles, but nobody confirmed that the accounts had been checked in the test environment.

The tester spends time investigating the failure. The delivery manager contacts the client, and both sides need to agree which work can proceed. Once the second account arrives, the tester revisits a workflow they could only partly assess earlier.

An access failure can happen despite reasonable preparation. Here, the missing confirmation is something the team can address. Assigning responsibility for checking the prerequisites before the start would give the client time to resolve the problem or agree a change to the dates.

The scoping article covers the information needed to make that decision. The commercial consequence in this example is time spent handling a dependency that the price assumed would already be resolved.

The tester records a genuine weakness, but the finding does not identify the permissions of the account used. The reviewer cannot tell whether the behaviour crossed an access boundary, so they return it for clarification.

The paragraph might take the tester twenty minutes to fix. Around that sit the reviewer’s time finding the omission and checking the revision against the evidence. If the evidence is no longer available, someone may also have to arrange access again.

Suppose the report passes through three review cycles instead of the one allowed for in the quote. Record the work done in those cycles, including any senior rewrite. Also record where the report waited for someone to respond. Waiting affects the delivery date, but it should not be counted as labour unless someone was actually working or blocked from assigned work.

OWASP’s reporting guidance describes reports that technical and executive audiences can understand. Applying that guidance during drafting helps reviewers assess the finding without reconstructing the engagement from scattered notes.

The debrief reopens the explanation

The client challenges the severity because the report does not explain a condition required for exploitation. A senior consultant joins another call and reviews the finding with the tester. This is where the illustrative extra half day could be spent, including preparation and amendments.

The client may have useful information, and some follow-up is part of the service. The cost becomes avoidable where the report omitted information already known during testing, or where nobody recorded an earlier decision.

It helps to keep those causes separate. New information from the client deserves an evidence review. A tester who cannot explain a conclusion may need coaching. Extra test coverage needs a scope decision. Calling all of it poor communication would make it harder to choose a useful response.

Account for the whole engagement

Use the project record to bring the extra work together. Include support given informally by senior testers and work done after report issue. Apply the business’s normal cost assumptions consistently when assessing margin.

Additional work Record needed
Access clarification Time spent, dependency missing and when it became known
QA correction Material defect, correction time and reviewer effort
Client discussion Reason for the discussion and whether it changed the assessment
Work beyond the agreed scope The request, approval and any agreed fee or schedule change

Avoid counting the same work under several categories. The purpose is to understand the engagement’s actual effort and which decisions created it.

That extra half day costs the business something even if there is no additional invoice. Absorbing it may be a sensible commercial choice for the agreement or account. Knowing what you are absorbing lets you make that choice deliberately.

Change the point that caused the repeated cost

Review a sample of completed engagements before choosing a response. If missing access repeatedly creates additional setup work, improve the readiness check. If reports repeatedly omit preconditions, use those defects in drafting guidance and coaching.

After making a change, compare the relevant work on later engagements. Read the figures alongside differences in scope and complexity. The team performance framework defines measures for unplanned recovery work and senior intervention that can support this review.

For our example, I would start with an account check before testing and a check that the report explains the access conditions. The next project record can show whether those changes helped, including the time spent by people who were never assigned as the tester.

Sources and further reading

These references add context to the points linked in the article. The practical recommendations are Simon's guidance unless another source is named.

Get help with a recurring delivery problem.

If this sounds familiar, tell us what is happening in your team. We can talk through where the work is getting difficult and what would help.