Growing a Pentest Consultancy Past Ten Testers: What Breaks

Somewhere around ten testers, the habits that ran a small pentest consultancy stop working. The founder can no longer review every report, scheduling lives in one person’s head, findings are written in ten house styles, and every client depends on whoever happens to be free. Fix those before the next hire, because a tester added to a firm that cannot review, schedule or deliver at its current size makes everyone a little less productive, including the new tester.

Review stops being one person’s job

In a small firm the founder or the most senior tester reads every report before it goes out. It works because volume is low and the reviewer wrote half the findings anyway. Past ten testers the same person is the queue: reports wait for them, they review at night, and the standard drifts with their energy.

The fix is to make review a process several people can run to the same standard. That needs written criteria for what a finished report contains, a shared queue where everybody can see which report is waiting and who has taken it on, and a way to send a report back with remarks that the tester answers one by one. A second reviewer for the reports that matter most, such as a first engagement with a large client, is worth the time. Pentest report QA: a process that survives a busy month covers the detail.

Scheduling becomes a job of its own

With four testers, everybody knows who is on what next week. With twelve, the knowledge lives in one person’s head or one spreadsheet, and the failures are predictable: a tester booked onto two engagements, an engagement that should have started yesterday with nobody assigned, a client whose credentials arrive the morning testing begins.

Put every booking in one calendar the whole firm can see, with engagements that have no lead visible to whoever assigns work. Let engagements start and complete on their dates without somebody remembering to move them, and remind the client automatically when credentials for an authenticated test are still outstanding. Scheduling testers and automating engagements shows one way to set it up.

Findings drift into ten house styles

Every tester writes the common findings a little differently. In a small firm the founder’s edits keep them close; at scale the same issue appears in five wordings with three different ratings, and a client who receives reports from two of your testers notices before you do.

Agree how the findings you write most often should read, keep them in a shared library your testers start from, and write down how severity is decided so that two testers rate the same evidence the same way. The library is only useful if it is easier to use than writing from scratch; building a findings library your team actually uses covers keeping it that way.

Templates multiply

Growth usually means more kinds of work and more partners, and each wants its report its own way: a cloud review that needs different sections from a web test, a partner who resells your testing under their name, a client whose procurement team mandates a layout. One template stretched over all of them grows conditional sections until nobody understands it. A template for each kind of work, sharing one set of finding definitions, keeps each simple; should each type of pentest have its own report template? covers deciding how many.

Overflow, and the people who absorb it

Demand in testing arrives in peaks, around financial year ends, audits and product launches. Hiring for the peak leaves testers idle the rest of the year, so many firms of this size bring in associates or a partner consultancy for overflow. That works when the associate sees only the engagements handed to them, writes from your library and your template, and sends their report through your own review before the client sees it. It fails when they get access to everything, or when their report goes straight to your client in their own style.

Scoping needs an owner

In a small firm whoever answers the enquiry scopes the work, often a tester between engagements. At ten testers that produces quotes written to three different standards, some generous and some that leave a tester trying to cover a fortnight’s work in a week. Give scoping and the client relationship a named owner, with a written way of turning a client’s answers into days, and have a tester sanity-check anything unusual. The estimate a client agrees to is the budget every report on that engagement is written against, so it is worth getting right before the work starts.

Measure the few numbers that matter

A firm of this size has enough engagements for a handful of measures to mean something, and few enough people that the measures stay cheap. Four are worth tracking every month:

• Utilisation. Days billed against days available, per tester, so you hire on evidence rather than on how busy it feels.
• Report turnaround. Days from the end of testing to delivery, which is what clients actually experience.
• Reports sent back from review. How many, and why, which tells you where your writing guidance is not working.
• Retest turnaround. Days from a client asking for a retest to the result, since a slow retest leaves a fixed issue looking open in their records.

The trend in each matters more than any single month, and none of them needs a dashboard to start: a spreadsheet updated at the end of each month is enough to see which way they are moving.

Knowledge that walks out of the door

A ten-person firm has lost a tester by now, and found out how much of its process lived in that person. Write the recurring procedures down as runbooks: kick-off, escalating a critical finding during a test, handling client data, the retest, close-out. Keep a checklist for each kind of test so coverage does not depend on who is testing. Checklists and runbooks for every phase of a pentest covers what to start with.

None of this is glamorous, and it is all cheaper to put in place at ten testers than at twenty, when every gap above has become a habit.