Penetration Testing Delivery Software: Getting Consultant Hours Out of Report Writing

Why the report, not the test, is the constraint on a testing practice

A penetration testing firm sells consultant days. It does not sell exploits, it sells a document that a client can take to their board, their auditor and their engineering team. Which means the economics of the practice are governed by a number most firms do not measure: how many of the hours in a fortnight long engagement go into writing rather than testing. Every practice lead we have worked with in this sector guesses that number is too high and none of them can prove it, because the writing happens inside Word on individual laptops where nothing is measurable.

The shape of the problem is familiar. A consultant finishes testing on Thursday. They open the firm's report template, which is a Word document with styles that break when anyone pastes into it. They write up eleven findings, half of which they have written up thirty times before, in slightly different words each time. Screenshots come from a local folder, cropped by hand, occasionally still showing a client hostname that should have been redacted. Severity is assigned by feel and then argued about in QA. The report goes to a senior for review, comes back with comments, and ships four days later than the client expected.

Then, six months on, the client asks whether the issues were fixed. Nobody has a structured record of what was found last time, so the retest becomes an exercise in reading the old PDF and manually comparing. Multiply that by two hundred engagements a year and the cost is not a nuisance, it is the reason the practice has to hire to grow.

Problem 1: the finding library is in people's heads and in old reports

The same twenty five findings account for a large share of everything a general web application practice reports. Missing security headers, verbose error handling, weak session expiry, insecure direct object references, outdated components with known vulnerabilities. Each consultant has their own preferred wording, their own remediation advice, and their own view on severity, which means two reports from the same firm in the same month can describe the same issue in noticeably different terms and score it differently.

That inconsistency is a quality problem before it is an efficiency problem. Clients who use two of your consultants notice. Auditors who see two of your reports notice. And when a consultant leaves, their better wording leaves with them.

PlexTrac and AttackForge both solve this properly with reusable finding libraries and are genuinely good at it. Dradis has done it in the open source world for years and is very flexible if you have the appetite to run it. So the honest question for a firm this size is not whether the capability exists but whether the capability is your product. For most firms it is not, and they should buy. For firms whose methodology and taxonomy are the differentiator they sell against, it is, and that changes the calculus.

A custom build makes the library structural: a finding template carries the description, the technical detail placeholders, business impact framing per client sector, remediation guidance per technology stack, references, and the firm's own scoring inputs. A consultant instantiates it and fills the specifics. Consistency stops being a QA gate and starts being a default.

Problem 2: scoring is a firm's methodology, and generic scoring undersells it

Most tools centre on CVSS, which is the right base and the wrong finish. A CVSS base score is a property of the vulnerability, not of the client's exposure. An internal only administrative interface with a default credential and a public facing one carry the same base score and are not remotely the same risk to that business. Every good practice knows this and applies its own risk matrix on top, weighting likelihood and business impact in a way it can defend to the client's board.

That matrix is a real intellectual asset and it is exactly what generic tools flatten. They will let you override a score, but they do not let you encode the reasoning, so the reasoning goes back into a paragraph a consultant writes by hand and a reviewer argues with.

A build encodes the matrix as inputs and rules: asset exposure, data classification, exploit complexity, existing compensating controls, and the firm's mapping to a final rating. The consultant answers the inputs, the rating falls out, and the report explains the reasoning in the firm's own language automatically. Two consultants now score the same issue the same way, and the client gets a defensible answer to why this issue is high for them and medium for someone else.

Problem 3: evidence is scattered, unredacted and perishable

Evidence is screenshots, request and response pairs, terminal output, proof of concept commands, and occasionally a video. It lives on the consultant's machine during the test, gets pasted into the document at write up, and is gone from any structured record afterwards. Two things go wrong.

The first is disclosure risk. Screenshots frequently contain more than intended: real customer data in a table, a session token in a URL bar, an internal hostname the client did not want in a document that goes to their auditors. Redaction happens by hand and depends on a tired consultant noticing at 6pm on a Friday.

The second is retest. When you come back in six months, the value of the old evidence is being able to reproduce the test exactly. If the evidence was a cropped image in a PDF, you cannot. If it was a stored request with headers and a documented reproduction step, you can, and the retest takes an hour instead of a day.

A build captures evidence as structured artefacts attached to the finding, with the reproduction step as a first class field, automated detection of common sensitive patterns before the report renders, and per client retention rules because you should not be holding a bank's evidence indefinitely. It also gets evidence off individual laptops, which is a question your own clients will start asking you in their supplier assessments.

Problem 4: retests and trend reporting are the thing clients actually pay for next

The single most commercially valuable question in this business is: are you getting better. A client who has run four engagements with you over two years wants to know whether their median remediation time improved, whether the same class of issue keeps recurring in the same team's code, and whether the money they spent on training changed anything. That is a report you can charge for and it is the foundation of a retainer rather than a one off.

It requires findings to exist as data across engagements, mapped to a stable taxonomy and to the client's own assets. Firms that write reports in Word cannot produce it at all. Firms using a delivery platform can produce it within the platform's model, which may or may not match how the client thinks about their estate.

A build lets you map findings to the client's asset inventory and their own service ownership, so trend reporting reflects their organisation rather than your engagement structure. It also makes the retest a workflow rather than a new engagement: fixed, not fixed, risk accepted, superseded, each with evidence and a date. That record is what turns a testing supplier into an embedded one.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, here is the honest shape. A focused first release covering the finding library, structured evidence, the firm's scoring model, report generation to your Word and PDF templates, and retest tracking runs $60,000 to $130,000 and ships in 10 to 16 weeks. A full platform adding client portals with the client's own SSO, scanner and tooling ingestion, ticketing integration, engagement scheduling and consultant utilisation runs $150,000 to $350,000 phased over 6 to 12 months.

What drives price up specifically in this sector: report rendering fidelity, because matching an existing Word template exactly, with your styles, headers, tables and appendices, is far more work than anyone expects and clients notice every deviation. Client portals with per client SSO, since each enterprise client wants their own identity provider. Multi tenancy, which must be built as a hard boundary from day one because one client seeing another's findings ends the firm. Scanner ingestion, as each tool's output format is its own parser. And any requirement to hold evidence under a client's data residency terms.

What keeps price down: shipping the finding library, evidence and report generation first and leaving the portal until consultants have adopted the tool. A portal on top of a platform your own people avoid is wasted money.

Build versus buy, and when PlexTrac still wins

Buy if you have fewer than about 10 consultants. PlexTrac is the mature answer for exactly this workflow and does the core well. AttackForge is strong on workflow and automation. Dradis is capable and open source if you have engineering appetite. Faraday leans more toward continuous vulnerability management than consultancy delivery, and Cobalt is a testing marketplace rather than a delivery tool for your own team, so compare those against what you actually need rather than against a feature grid.

Build when two or more of these are true. Your methodology and finding taxonomy are what you sell against and a generic library dilutes them. You are large enough that per consultant and per portal user licensing has become a line item worth a build. You need client portals branded and authenticated as the client's own environment rather than as your vendor's. You have a commercial model your tooling cannot express, such as retainer day drawdown or credit based testing. Or you have data residency and evidence handling obligations that a hosted platform cannot meet for your regulated clients.

Our position, stated plainly: most testing firms should buy, and we will say so before quoting. The firms that should build are the ones where the report is genuinely a differentiated product and the practice is big enough that a week of writing time saved per consultant per quarter pays for the platform. That is an arithmetic question with a clear answer, and you should do the arithmetic before anyone writes code.

How to choose a developer for pentest delivery software

Ask them how they would enforce tenant isolation. The right answer involves separation at the data layer with tests that prove it, not filtering in application queries. This is the one requirement where a mistake ends client relationships, and a developer who treats it as a normal access control problem should not get the work.

Ask to see report generation against your actual template. Not a demo template, yours, with its styles, its appendix structure and its table formats. This is where these projects most often disappoint, and thirty minutes of proof beats any assurance.

Ask where AI fits and listen for restraint. Drafting a finding narrative from structured evidence in your house voice, and rewriting technical detail into a business impact paragraph, are useful and safe because a consultant reviews before it ships. Generating findings, inventing impact or assigning severity without a human is not acceptable, and a developer who offers it has not understood what your signature on a report means.

Ask who owns the code and get it in writing before kickoff, along with where evidence is stored and under whose accounts. You should own the repository and the infrastructure. At Digital Heroes the client owns the code from the first commit, and for a platform holding client vulnerability evidence we would expect your own team to run a review against it before go live, which is the least we would want if we were the client.