Two Testers, One Pentest Report: Writing Without Overwrites

Several testers can write one pentest report at the same time if the report is a set of findings with one owner each, kept in one place everybody writes into, rather than a Word file passed between them. Split the work by phase or by area, agree severity rules and house wording before anyone writes, and give one lead the executive summary and a final pass for voice. When a team report goes wrong, the testing is rarely the cause: two people save over each other, copies multiply, and the client receives a report written in three voices.

How teams split the work

Most engagements with more than one tester use a mix of three splits.

Split	Works well when	Watch for
By phase	The engagement already has phases, such as external infrastructure and a web application, and each tester suits one.	The same weakness found in both phases, written up and rated twice.
By area or finding	Two testers share one large target: one takes authentication and the interface, the other the API and hosting.	Boundary cases: an access control flaw in the API that shows through the interface needs one owner.
A lead who owns the summary	On top of either split. One person writes the executive summary, settles disagreements and reads the whole report last.	A lead who is testing full time and reaches the summary the evening it is due.

Write the split down on day one, on the engagement record rather than in a chat thread: it answers "whose is this?" for every finding that follows. A tester leaving part way through is a different problem with its own checklist, covered in handing a penetration test to another tester mid-engagement.

What goes wrong with one shared file

The default in many firms is one Word document on a shared drive, and it fails in the same five ways.

• The last save wins. Two testers each take a copy of the report on Monday, one adding web findings and the other infrastructure. Whoever saves theirs back last replaces a file that never contained the other's work. Depending on how the file is shared, the result is a silent overwrite, a read-only copy somebody edits anyway and saves under a new name, or a sync client's conflicted copy that nobody merges.
• Copies emailed around. To dodge the collision, each tester writes in their own file and emails it to the lead, who pastes the sections in. Every paste brings its own styles, and a correction made after sending lives only in the tester's copy.
• Two "final" versions. The lead changes a severity in the master while the tester fixes a hostname in their copy and sends it again. By delivery there are two files called final, each with corrections the other lacks.
• Inconsistent voice and severity. One tester writes "we identified", another "the tester observed", a third uses the passive throughout. One rates missing security headers low, another informational, in the same report.
• Duplicated findings across phases. Weak TLS configuration appears in the external phase as a medium and in the web application phase as a low, with different remediation, because each tester found it on the hosts in front of them.

None of this is carelessness. It is what happens when a report is treated as one document with several authors, when it is really a set of records that one document is made from.

One owner per finding

The rule that prevents most of the damage is simple: every finding has exactly one author, named on it, and only the author changes its facts. The author owns what was observed, the evidence, the affected assets and the first rating. Anyone else with something to add, the lead included, comments on the finding or suggests a change rather than quietly rewriting it.

Ownership also settles duplicates. Agree up front that one weakness is one finding, with every affected host or endpoint listed against it, owned by whoever raises it first. When the second tester meets the same weakness, they add their hosts and evidence to the existing finding instead of opening a new one. A weakness that genuinely needs two findings, because two different teams will fix it in two different ways, is the lead's decision, not an accident of who found it where.

Make the check cheap. Search the engagement's findings by title before raising a new one, and spend ten minutes mid-week with each tester reading out their titles. A duplicate caught while it is a draft costs a minute; caught in review, it costs an afternoon.

Agree the house rules before anyone writes

Consistency in a team report does not come from editing at the end. It comes from three things agreed before testing starts, so everyone writes to the same standard from the first finding.

• A style sheet. One page: the client's name exactly as they write it, their product and system names, "we" or "the tester", tense, how hosts and URLs are written, how a title is phrased (the weakness and where, not the tool that found it) and what a remediation must contain. It takes an hour to write and saves that hour on every report.
• A findings library. House wording for the weaknesses you raise every month, so two testers describing the same misconfiguration start from the same description and remediation, and write only what is specific to this client. Building a findings library your team actually uses covers growing one without a project.
• Severity rules. Which CVSS version, when an environmental adjustment is allowed, how missing headers and verbose banners are rated, and what counts as informational. Write down the calls your team keeps arguing about, against agreed severity levels, so the same weakness gets the same rating whoever found it.

One source of truth, reviewed where it is written

The fix for overwrites is not a better naming convention for files. It is one place where the findings live, which every tester writes into directly and which the report is produced from. A finding corrected there is corrected for everybody, and there is no master copy to paste into, because the document is generated rather than assembled.

Review belongs in the same place. A reviewer who marks up a PDF or a Word copy creates another version of the truth, and somebody then has to carry each change back by hand, which is where corrections go missing. Reviewing on the same fields that make the document means an accepted correction is already in the next export, and every comment stays attached to the finding it is about, the habit behind a QA process that survives a busy month.

If the report must still pass through Word at the end, for a client's layout or a last edit, make that the final step after review, done once, by one person.

The lead's pass for one voice

Even with a style sheet and a library, three testers produce three voices. The lead's job at the end is an edit for voice, not a second review of the facts.

1. Read the findings in severity order, across testers. Two similar mediums should read alike: the same title pattern, the same depth, the same shape of remediation.
2. Compare the ratings side by side. A sorted list of every finding with its score and vector shows the outliers no single author would notice.
3. Merge what slipped through. Any duplicate still standing becomes one finding, with the affected assets combined.
4. Write the summary last. The executive summary is drawn from the final findings by the person who has now read all of them. Writing an executive summary that gets read covers what it should say.
5. Send factual doubts back. If the lead questions an observation, it goes to the finding's owner as a comment. The lead changes wording, not facts.