Your Report Template Should Decide Your Finding Fields

The finding fields your testers fill in should be exactly the ones your report template prints, under the names it prints them, and nothing else. Every field collected but never printed is effort the client never sees, and every field printed but never collected is an empty heading on delivery day or a scramble to fill it the night before. The template is what the reader holds, so let it decide the form, not the other way round.

How the form and the template drift apart

Nobody sets out to collect the wrong fields. The drift happens because two different people own two different things. Whoever looks after the Word template changes it when a client asks for a likelihood rating, a partner sends their own layout, or a new kind of work needs a section of its own. Whoever set up the reporting tool chose the fields of a finding years ago and has not looked at them since. Neither change is wrong on its own. Together they leave a form that asks for things the report has stopped printing, and a report with headings the form never asks for.

Old fields are the stickiest. A references field that one client wanted stays on the form for every engagement after it, testers keep filling it in out of habit, and the template quietly dropped it a year ago. Multiply that by the handful of fields a firm adds over the years and a tester spends a real part of every finding writing text that nobody will read.

The three failures, and what each costs

• Collected, never printed. Time spent writing, reviewing and correcting a field the client never sees. Worse, reviewers learn to skip it, so the day a template prints it again, it is full of text nobody checked.
• Printed, never collected. An empty heading under every finding, which reads as unfinished work. The usual rescue is someone typing it into the final copy by hand, which then disagrees with the findings it was meant to describe.
• The same field under two names. A form that says Remediation and a report that says Recommendation invites testers to write for the wrong heading: a list of developer tasks reads oddly under a heading that promises advice.

None of these is a disaster on one engagement. Across a year of reports they are the difference between a report that reads as one firm’s work and one that reads as assembled. What a penetration test report should contain covers which fields a finding needs in the first place.

Audit the template, not the form

Start from the document the client receives, because that is the thing that has to be right. Open the template and list every field it prints for a finding, and every section it prints for the engagement as a whole. Then put that list beside what the form asks for, and decide each difference:

Difference	Usual decision
On the form, not in the template	Take it off the form, unless the template should print it and has lost it
In the template, not on the form	Add it to the form, with a note saying what a good entry looks like
Under different names	Use the template’s name on the form, so testers write for the heading the reader sees
Printed always, optional on the form	Make it required, so a finding without it is not finished

The last row matters more than it looks. If the template prints a field on every finding, the finding is not done until it is filled, and the form should say so rather than leave the reviewer to notice. If the template prints it only when there is something to print, it can stay optional.

One field, one meaning, whatever the template

Firms with several templates, one for each kind of work or one for each partner, face the same question in a harder form. The answer is not a separate form for each template. Define each field once, with one meaning and one writing note, and let each template switch on the fields it prints and give them its own names. A business impact field then means the same thing on a partner’s report as on your own, one findings library serves both, and moving an engagement between templates moves words between fields rather than losing them. Should each type of pentest have its own report template? covers deciding how many templates you need, and building a findings library your team actually uses covers keeping entries reusable across them.

Turning a field off without losing what was written

Taking a field off the form should hide it, not delete what is in it. Engagements already finished may have been written with it, a later template may print it again, and a client may ask next year for the likelihood rating you used to give them. A field switched off should keep its contents on every finding, out of sight and out of the report, and bring them back when it is switched on again. The same goes for a section of the report.

Keeping them in step from now on

The audit is a one-off; the habit is what keeps it true. Three things help:

• Change the template and the form together. A template change that adds or removes a field is not finished until the form matches it, on the same day.
• Test with a real engagement. Fill the template from a recent engagement’s findings, not an empty one, and look for empty headings and text under the wrong one.
• Give the template one owner. One person who signs off a change to either, so the two never belong to different people again.

A report template that renders the same every time covers building the template itself so that it fills cleanly.