Reviewing a Report Before It Goes Out

QA in Pental is a review of the report as it stands, done inside the platform, on the same fields that produce the document. It is not a checklist somebody signs at the end. This guide covers the whole of it: getting work into review, doing the review, what each action means, finishing and delivering, and the round trip through Word for a reviewer who would rather work in the document.

If your firm does not run a QA step, switch the QA Queue module off in Settings, Feature Modules. A report is then ready to deliver as soon as its testing is finished, with no approval waiting for anybody, and anybody who can edit may deliver it.

Getting a report into review

Once testing is finished, Submit for QA on the engagement runs the report checklist (the same one the review’s Checklist tab shows: scores and their vectors, descriptions, remediation, evidence and the rest your firm requires) and lists anything missing, each with a way to fix it. With everything in place the report goes into the queue, straight to its reviewer if one is already named.

The QA Queue sorts every report into exactly one of six places, so a report is never in two lists at once:

Assigning is for organising, not for permission: anybody who can edit can review, including their own work, and the screen tells you plainly whose report you are looking at.

The review screen

The report is laid out in tabs that match what the document contains: Findings, Executive Summary, each written area your firm uses such as Notes, Scope, Caveats and Retest Summary, Appendices, and a Checklist. Custom areas you have added appear as their own tabs under whatever you named them.

Above them, a strip says how much of what was raised has been answered, and counts the rest: findings reviewed, suggestions waiting, open comments, accepted changes and findings. Suggestions and comments are counted separately because resolving a remark is not the same as deciding a change. A reviewer marks each finding reviewed as they go, and a finding edited since is shown as needing another look.

Counts that filter, and phases

On the bar above the findings, the counts are the filters. One click on “to review” narrows the list to the findings with an open comment or a suggestion waiting, and opens them; “open comments” and “suggested” narrow it to one kind; the findings count, or a second click, puts everything back. A menu beside them adds Not reviewed, Needs attention and Incomplete, the box filters by title, and Next (or the n key) walks through what is waiting and on to the next phase that has any.

On an engagement with more than one phase, the findings are grouped by phase in the engagement’s order, with a strip of phases above them, each showing its count and how many are waiting, to show one phase or all of them. Tick findings, or a whole phase at once, and a bar answers them together: Accept or Reject the suggestions on them (for the lead, an administrator or a senior), Resolve their comments, Mark reviewed or Unmark, and Mark as draft or Mark as final. Accept all and Reject all on the main bar deal with everything waiting.

Three things you can do to a field

Every field in every section offers the same three actions, which is the whole vocabulary of the review:

Suggest change and Apply now are both under Edit, which opens the field in place: the value becomes the editor, and the comments beside it stay where they are. A box under the editor takes a reason, which travels with the suggestion.

Commenting on the exact words

Select a passage in a field and click Comment, and the comment is anchored to that passage: the words are marked in the text and the comment card sits beside them in the margin, the way Word does it. Selecting nothing comments on the field as a whole, and the box tells you which you are about to do.

Selection works while you are editing as well, so a reviewer who has opened a field to fix one sentence can still leave a remark about another.

A comment can be replied to, resolved, reopened and edited. A thread and its replies are one comment throughout: resolving the thread resolves the replies with it, replying to a resolved thread reopens it, and the count says one, not four.

What the colours mean

One meaning per colour, everywhere on the screen:

• Blue is a remark. Somebody has said something about this.
• Amber is waiting on a decision. A suggestion nobody has accepted or rejected yet.
• Red and green are the words themselves: what went, and what arrived.

A change is shown as the words that actually moved, with the untouched middle of a long field folded away and openable. A change to a URL or a hostname is compared character by character rather than word by word, so three changed characters do not strike out the whole address.

Deciding

A suggestion can be accepted, which writes it, or rejected, which does not. Accept all and Reject all deal with everything waiting in one go.

Both are reversible. An accepted change offers Put it back, which restores the previous wording and marks the change rejected, warning you first if the field has been edited since it was accepted. A rejected change offers Reopen, which puts it back on the list to decide again without touching the text.

Evidence is compared and read on the review screen but cannot be accepted as a change, because the entry holds a flattened reading of the blocks and writing it back would replace your screenshots with a sentence. Evidence is edited in the finding itself.

Two people reviewing at once

Nothing in the platform stops two people working on one report, and the review screen is built for it. You can see who else has the report open and which field they are in, live. If somebody else is already editing the field you open, it says so.

When two people save the same record, only the fields you actually changed are written, so two reviewers working on different fields of the same finding never collide. If you both changed the same field, your save stops and shows you both versions side by side, with the choice of keeping yours or taking theirs. Nothing is overwritten without somebody deciding.

Reviewing in Word instead

A reviewer who would rather work in the document downloads it from the review screen, and the review travels with it. Suggestions arrive as real tracked changes, authored and dated. Comments arrive as real Word comments, anchored to the words they were written about rather than dropped at the top of a section.

That works on the report you generated and on a report somebody has already edited and uploaded, because whichever file Download hands back is the one somebody is about to open. There is also a clean copy, without the review, which is what you use when producing the PDF for the client.

Edits made in Word come back the other way: upload the edited document, and every difference is listed for you to tick or ignore before anything is written, including comments Word added and tracked changes nobody has accepted yet. An unaccepted tracked change in the document arrives as a suggestion in the review rather than being applied.

Finishing

The button at the top of the review says what it will do. While anything is still open, a suggestion undecided or a comment unresolved, the reviewer’s button is Send back to the lead’s first name, with the count: the report goes back to its lead with the feedback. With nothing open it is Approve, and for somebody who may deliver, Approve and deliver signs it off and sends it to the client in one go.

Back with its lead, the report waits for the changes. Once no suggestion is left undecided, Resubmit to QA returns it to the reviewer. Reopen QA puts a signed-off report back under review before it goes out, without touching anything in the review itself.

Who may deliver

With QA on, Deliver Report is for the report’s lead once QA has approved it, and for its QA reviewer, an administrator or a senior whatever QA’s state, sent back for changes included, once testing is finished. With the QA Queue off, anybody who can edit delivers a finished report. Either way, anything still marked as a draft holds delivery up and is listed with a way to fix it.

Sending a delivered report back

A delivered report can be taken back by anybody who may deliver it. Send back to QA, on the review or the engagement, says what happens before it does: the client stops seeing the report and the sections released with it straight away, and nobody is emailed. It goes back into review with its findings, comments and review so far kept. You can say what needs changing, which opens the review as a comment only your team sees, choose the reviewer, and hide the findings shown to the client as well, which delivering again shows again. Delivered again, it is an ordinary delivery. With the QA Queue off, the engagement’s button reads Take back instead, and the report returns to ready to deliver.

A reviewer checking scores can test them against CVSS 4.0 examples for common findings and the firm’s severity levels; the platform overview shows where QA sits between testing and the client portal.