Retests, and Your Client’s Jira, ServiceNow or GitHub
Clients ask for a retest of a finding in one click, or by closing its ticket in their own tracker. Your team retests it from one list and records the outcome on the finding.
A retest is where a test turns into fixed issues, and it is usually run from an email thread and a spreadsheet. In Pental it lives on the finding: the client asks for it there, your team picks it up from one list, and the outcome is recorded on the finding the client is looking at.
Which findings can be retested
When you create an engagement, each phase says whether the client can ask for a retest. A phase that includes one shows the client a Request Retest button on its open findings; a phase without one does not, so nobody asks for work that was never sold.
The client asks
Once something is fixed, the client opens the finding and presses Request Retest, or ticks several and asks for them together. A request is only a request: it changes nothing about the finding until one of your testers acts on it, and the finding shows Awaiting retest in the meantime.
Or their own tracker asks
Clients can connect their own tracker at the foot of their dashboard: Jira, ServiceNow, Azure DevOps, GitHub, GitLab or Linear. A finding then becomes a ticket in one click, with its details and how to fix it, and their engineers work it in their tracker as usual. Closing the ticket asks you for a retest rather than closing the finding: the fix is checked before anything is closed, and once it is, the finding is closed and so is the ticket.
Your team can connect a client’s tracker for them too, from the client’s record, choosing the lowest severity that is raised (Medium and above, to begin with) and whether a ticket is raised automatically as each finding is released. Every tracker is read back each hour, and Sync now does it at once.
Your team retests
Retest Requests, in the sidebar whenever something is waiting, with a count, lists everything clients have asked for. Begin Retest opens the finding with a place for what was found this time, and Remediated or Not Remediated records the outcome. The client sees it on the finding straight away, and a retest summary for the engagement can be drafted from the outcomes, in the report’s Retest Summary section.
For running the retest itself well, see how to run a penetration test retest properly, and for a client who decides not to fix something, when a client accepts the risk instead of fixing it.
Try a Retest Both Ways Round
Sign in as a client user of your own on the trial, ask for a retest, and pick it up from Retest Requests.
Also Worth Reading
What Your Clients Actually See in the Portal
The client portal shows a client their own engagements, the findings you release, the documents you deliver and the checklists you share, and nothing else. What is on each screen, and what controls it.
WorkflowImporting Scanner Output as Findings
Bring a Nessus, Burp, OpenVAS, Qualys, Nmap or SARIF export into a phase of an engagement as findings: one for each issue with every host listed, in your library’s wording where it has the issue, and nothing written until you have seen it.
WorkflowChecklists and Runbooks for Every Phase of a Pentest
A library with one checklist for each kind of phase, suggested on matching phases, ticked by your testers, shown to the client if you choose, and moved in and out as Excel, Word or JSON.
Setup guide
Prefer to watch it?
The whole setup recorded, with chapters you can jump to: registering, your own domain, your own database in any of three places, your own mail server, branding, the first sign-in, updating the database on Supabase Cloud, and moving the database if you change your mind.
- 0:00 · Registering, signing in, and the free trial
- 0:51 · Your name and your firm’s name
- 0:57 · Custom domain
- +6 more