White-Label Pentest Reports: Writing in a Partner’s Template

A white-label pentest report is one you write for another consultancy, in their template and under their name, for a client who hired them. The testing is the same work you always do. What changes is everything the client sees: the fields each finding carries, the names of the severity levels, the order and titles of the sections, the voice, and the name on the cover. Getting those right from the first day of the engagement, rather than by find and replace on the last, is what separates a partner who sends you more work from one who rewrites your report before it goes out.

What the partner’s template actually fixes

Ask for the template and for a recent report written in it, with anything confidential taken out. The template shows the layout; the report shows how they fill it, which is the part a template cannot tell you. Between them they fix:

• The fields of a finding. Some firms carry a business impact or a likelihood beside the description; some have no references field at all; some put affected assets in a table and some in a sentence.
• The sections and their order. An attack narrative before the findings, a methodology appendix, a separate retest record, or none of these.
• The severity scale. How many levels, what each is called, how each is defined, and whether CVSS is shown, and which version.
• The branding. Their logo, colours, legal name, contact details and document control on the cover and in the footer.
• The format of what goes out. A Word file they finish themselves, or a final PDF that goes straight to the client.

Map your fields to theirs before you test

The expensive mistake is to test in your own format and convert at the end, because by then the evidence for a field they have and you do not was never written down. Map the two field sets on day one:

Their template has	What to do
A field you also have, under another name	Use their name throughout, in your notes as well, so nothing needs renaming later
A field you do not have, such as business impact	Write it as you test, while the context is fresh, not from memory at the end
No field for something you always record	Keep it in your working notes, or fold it into the description if it matters to the reader
A required field	Treat a finding without it as a draft, exactly as their own testers would

The same goes for the sections. If their report opens with a narrative of the attack path, keep a timeline during testing; it is far easier to write from timestamps than to reconstruct. What a penetration test report should contain is a useful checklist for spotting what their template leaves to the writer.

Severity: their words, your evidence

A partner’s scale may have four levels where yours has five, call informational findings notes or observations, or define high differently. Use their scale for every finding and agree the edge cases before you start, not in review: what a finding you would rate critical becomes on a scale with no critical, and whether a missing security header is low or informational in their house style.

Where CVSS is shown, the score still decides the qualitative rating, which runs from low at 0.1 to critical at 9.0 and above in both CVSS 3.1 and 4.0. If their scale stops at high, agree whether a 9.8 is reported as high with the score beside it, or whether the score is left out. Either is defensible; changing approach halfway through a report is not. Penetration testing severity levels covers building a scale and its definitions.

Write in their voice, not just their layout

A report that looks right and reads wrong is still noticed by the client, who has read the partner’s reports before. Match the small things: whether they say recommendation or remediation, whether findings are written in the present tense, how they refer to the client, whether they name individual hosts in the executive summary, and the standard wording of their caveats and limitations. A findings library helps here only if the entries are rewritten into their voice; pasting your own house wording into their report is the most common giveaway.

QA against their standard

Review the report in their template, against their checklist if they have one, with their required fields treated as required. A reviewer who checks it against your own standard will pass things their reviewer sends back, and the round trip costs a day. If the partner reviews it as well, agree who signs off what, so two reviews do not pull the wording in two directions. A QA process for reports that survives a busy month sets out a review that adapts to a template.

Delivering through them

Agree who sends the report, in what format and when, and who answers the client’s questions about it. Usually the partner sends it and fields questions, and you stay available to them. Keep the delivered version: the retest will be reported in the same template, under the same name, months later, and its findings should line up with the originals. A letter of attestation, if the client needs one, normally carries the partner’s name as well, because it is their engagement. Subcontracting a test and keeping the report yours covers the arrangement from the other side, and what white-labelling actually buys a testing firm covers whether it pays.