• Pentest Report QA Process: Reviewer Checklist and Peer Review Workflow
  • Who this is for
  • What the pentest report QA process covers
  • Pentest report reviewer checklist: findings, evidence and remediation
  • Severity and CVSS scoring in the review workflow
  • Findings library and peer review workflow
  • How to speed up pentest report QA
  • Review and approval before the report is delivered
  • Pentest report QA tools for peer review
  • Frequently asked questions

Pentest Report QA Process: Reviewer Checklist and Peer Review Workflow

Last updated by Rachael Carder on 2026-11-06

The third Word copy of the report comes back with a comment on a finding your tester wrote two weeks ago. They're on another client's network now, and they have to load the old target back into their head to answer it. Every round of comments does that again.

Pentest report QA is the review a report gets before the client sees it:

1. A technical check of each finding and its evidence
2. A severity check
3. An editorial read and the agreed scope
4. A check against the client's format
5. A sanitization check for anything that shouldn't leave your team

All with a named sign-off. Most of it doesn't have to wait for the draft. Start review with the first finding, and the end pass shrinks to five checks.

Who this is for

Read this if:

• You run delivery or review reports at a consultancy of three or more testers
• Your clients, or a scheme like CHECK, expect a quality control process
• Reviews at your firm arrive as Word copies with comments in the margin

Skip this if:

• You test alone and nobody else reads your reports before the client does. For the report itself, start with how to write a security report.

What the pentest report QA process covers

A report goes through five passes, and each one asks a different question. Teams differ on who runs each pass and when. Here's each one at the earliest point it can run.

Only five checks need the whole report: the summary against the findings, severity across findings, format and scope, a last sanitization read of the whole document (appendices included), and sign-off. Everything else can run while the test is still going.

Before any of it, the author reads their own finding once and marks it ready. That's a self-check, not a review. The technical pass needs someone other than the author to follow the steps, and Adan Alvarez sets the bar well: "Evidence should be detailed enough that another engineer can follow the steps without extra help."

Each provider decides how many of these passes every report gets. Vonahi, which sells automated penetration tests, says its QA runs "on certain reports", triggered by conditions such as "identifying new security vulnerabilities, observing results that do not match expected outputs". For a consultancy whose clients dictate the format, we'd run all five passes on every report.

Pentest report reviewer checklist: findings, evidence and remediation

Most items cite the rule behind them, so when you send a finding back you're pointing at more than taste. The author's checklist in our report writing guide is the short version. This one is for the reviewer.

Technical: per finding, by a peer tester

• The evidence shows the exploit, not a scanner's guess. In Wiz's words, "Findings without proof of concept are suggestions, not validated risks."
• The steps let the client reproduce it. CREST's Defensible Penetration Test sets this as a minimum: "Sufficient information should be provided to allow the client to understand and replicate the issue themselves."
• Each piece of evidence sits under the finding it proves, for the host it names.
• The remediation names the fix for this system. Wiz's guide counts generic advice such as "apply patches" among the common mistakes.

Severity: per finding, then across findings at the end

• Every CVSS score comes with its vector string, which FIRST's CVSS v4.0 specification asks for "so others can understand how the score was derived", and with a label for the metrics used, such as CVSS-B for a Base-only score.
• Your firm's own rating leads and CVSS supports it. The NCSC's CHECK Scheme Standard rates findings HIGH, MEDIUM, LOW or INFORMATIONAL, with CVSS "in addition to (but not in place of) this rating".
• Any rating moved off its standard value says why.

Editorial: per finding, then the summary at the end

• Each finding says what it means for this client. PCI SSC's guidance is blunt: "Merely reporting lists of vulnerabilities is not helpful in this endeavor and does not meet the intent of the penetration test."
• The executive summary matches the findings: the same top risks, the same ratings, the same count. Halo Security calls a mismatch "another red flag" that "could be a sign that they've copied and pasted from a previous report."

Client format and scope: at the end, by the lead

• The report uses the client's template, section order and rating scale, not your house default.
• It includes "a statement of totality against the defined scope", another CREST Defensible Penetration Test minimum, and says plainly what wasn't tested. Alvarez again: "A professional report should also be clear about what was not tested."
• The rating scale is defined in the report. OWASP's testing guide: "Ensure that you detail the values you decide to use in an appendix."

Sanitization and sign-off: evidence per finding, the document at the end

• Screenshots, requests and appendices mask secrets. OWASP: "Any possibly-sensitive data should be masked, for example, passwords, personal information, or credit card details." CHECK goes further: the report "must not contain any sensitive data (as determined by the Customer), passwords or any Personally Identifiable Information (PII)."
• Raw tool output is trimmed. OWASP again: "Make sure to clean the output and not just dump it."
• No other client's name, host or screenshot appears anywhere, reused findings included.
• The author and the approver are named. Under CHECK, "the report must be signed off by the Primary CHECK Team Leader", and both names go in the report.

Severity and CVSS scoring in the review workflow

Ratings are the check you can't leave to each tester. In a study by Wunder and colleagues, 59 CVSS users rated a set of vulnerabilities, then rated the same ones again nine months later. 68% gave a different severity rating to vulnerabilities they had rated before, and for each vulnerability, between 34% and 55% of them changed their answer. That's one person disagreeing with themselves. Four testers on one report bring four sets of habits.

In the same study, 55% of CVSS users said their base scores are always or often reviewed by coworkers, and only 6% said never. So peer review of ratings is already common. A reviewer should make three checks.

1. Each rating against its evidence, per finding. Over-scoring is the expensive mistake. As Alvarez puts it, "Escalating a severity internally is far simpler than trying to downgrade one that was over-scored in the report."
2. Every move away from the standard rating is written down, per finding. The NCSC's penetration testing guidance says "Any deviation from associating a vulnerability with its standard rating should be documented and justified by the penetration testing team." CHECK asks reports to "explain any reduction in severity rating", and to weigh CVSS against the impact on the customer and the mitigations in place.
3. Ratings across findings, at the end. Sort every finding by rating and read the list top to bottom. Two missing HSTS header findings with different ratings, or a Medium with worse client impact than a High above it, only shows up in that list.

How to document a rating (the scale, the vector, CVSS-B) is in write down how you rated it, and our CVSS v4 guide for pentest teams goes through the metrics.

Findings library and peer review workflow

Most of a reviewer's time goes to text that was already right last month. Your SQL injection write-up gets reviewed in January's report, again in February's and again in March's, because nobody can tell which sentences in this copy changed.

A findings library fixes that when you treat each entry as reviewed content with its own state. The write-up (description, impact, standard remediation, references) is reviewed once, in the library, by whoever owns it. When a tester pulls it into a project, the peer reviewer checks only what this engagement added:

• the affected hosts and URLs
• the evidence and the steps to reproduce it
• the rating for this environment
• remediation that fits this client's stack

Run badly, a library makes things worse. A shared write-up spreads one stale line to every report that uses it, and it can include an old client's name or screenshot. The classic version is a client name or start date left over from the last report, because reports get copied and pasted together. Three rules keep a library from doing that:

1. Every entry has an owner, usually the lead or a senior for each service line.
2. Edits go back through review. A changed entry can't be used in a project until someone approves it.
3. Entries contain no engagement data. Client names, hostnames and screenshots belong to the finding in the project, where the reviewer checks them for that engagement.

Our page on consistency across testers covers how teams keep ratings and wording aligned as they hire.

How to speed up pentest report QA

QA is slow mostly because of waiting. Review can't start until there's a full draft, the draft arrives as one file, and the comments go back to a tester who has moved on.

Four changes cut the wait. None of them asks the reviewer to read faster.

1. Start review with the first finding. The tester marks a finding ready the day they write it, and a peer reviews it within a day or two, while the target is still fresh. You'll know it's working when most findings are approved before testing ends.
2. Put feedback on the finding. A comment attaches to the sentence it's about, not to page 14 of an emailed copy. You'll know it's working when no report file changes hands before delivery.
3. Export only what's approved. By default, exports leave out anything still in draft or review, so a half-checked finding doesn't reach the client. The export itself shows what's been reviewed, so nobody keeps a separate tracker.
4. Keep the end pass for the five whole-report checks. It's one read of the whole report, not a second technical review.

Our sample pentest report is an unreviewed export, and its review section lists four problems. Here's which pass catches each one, and when:

• The empty "n/a" evidence on two findings, and the NTP output under the Apache cookie finding: the technical pass, the day each finding is marked ready.
• The "possibly vulnerable" scanner wording: the editorial check on that finding, and it never arrives at all when the description comes from a reviewed library entry.
• The leftover template instructions and "Tester comments" placeholders: the client format pass at the end, because they sit in the conclusions and the methodology table, outside any finding.

Three of the four could be fixed before the test ends.

Review and approval before the report is delivered

The standards pentest teams work under don't tell you how to run report QA. Here's what CHECK, CREST, PCI SSC and NIST ask for.

• CHECK, the UK NCSC's assured penetration testing scheme, expects a quality control process without prescribing one. The NCSC does "not expect the Technical Lead to personally quality control every report, but we do expect the company to have and adhere to a quality control process, for which the Technical Lead is accountable." The one fixed step is sign-off by the Primary CHECK Team Leader, named in the report.
• CREST's Defensible Penetration Test (June 2023) is a specific type of test that CREST defines, not CREST accreditation in general. Its sign-off "provides a formal attestation that the CDPT was conducted in accordance with the CREST Accredited Penetration Testing Provider's Approved penetration testing methodology", and confirms "that the assessment addressed all elements identified during the scoping phase". It "must be undertaken by a suitably skilled or qualified individual, or by a company officer." That attests methodology and scope. It isn't a review of the report's content.
• PCI SSC's Penetration Testing Guidance (version 1.1, 2017, a non-binding information supplement) and NIST SP 800-115 (2008): we found no pre-delivery QA or peer review step in either.

The rest is yours: who reviews, when review starts, what goes on the checklist, and how approval is recorded. Write those down. When a CHECK assessor or a client's procurement team asks how you control report quality, you want a document you can hand over.

Approval is the last step. The named approver runs the end pass and signs, and it's the one point where a single person sees everything at once.

Pentest report QA tools for peer review

A reporting tool helps QA when it changes where review happens, and the report still has to come out in each client's format. Here's what to look for, and how Dradis Pro does each one.

The QA page shows the review screens, and the Issue Library page covers the library. If you're looking at the rest of the delivery workflow too, our guide to penetration testing management covers it.

Frequently asked questions