Pentest Reporting and Management Platform The Whole Engagement, from First Scope to Final Retest.

Phased, Scheduled and Assigned in One View.

Each engagement is phased the way you sold it, given its dates and a lead tester, and laid out on the testing calendar, and the client's test credentials arrive encrypted rather than in an email thread.

• Phased engagementsExternal, internal, retest, or whatever shape the work takes. Each phase carries its own type, scope, test days, checklists and retest setting, under one engagement and one report.
• Assignment and statusEach engagement has a lead tester and its dates, and it can start and complete itself on them rather than waiting for someone to remember to move it.
• Who is free, at a glanceThe testing calendar lays the week out tester by tester, shows who is available, and lists the assessments nobody leads yet, each with a tester to assign it to.
• Client credentials, collected safelyAsk the client to submit access credentials before the start date and they arrive encrypted, one-time view, attached to the engagement rather than sitting in an email thread. Testers send them to your password manager without copying a thing: 1Password, Bitwarden, Passbolt and Keeper in one click from your own gateway, KeePass straight into their own file, HashiCorp Vault from their browser.
• Your testing source addressesKeep your public testing IPs on file and a client sees them on the engagement before testing starts, so they can allow them without a separate email. The report states them too.
• Access your database decidesExternal testers see only the engagements they lead or that are handed to their team, and clients only their own organisation and the findings you release, enforced by your database rather than by hiding buttons. Roles by seniority decide the rest.

Paste the Evidence. Get the Finding.

Writing up a finding is the part of the job that is unavoidable, repetitive, and the same twelve vulnerabilities every quarter in slightly different words. Drop your evidence in and one button drafts the rest of it.

Generate All from Evidence

Not a field at a time. One action reads the evidence you captured and fills in everything the finding needs, in order, skipping anything you have already written.

1. 01The evidence, explained. A line above each screenshot, request, block of code, output or table saying what it shows, and a caption beneath each screenshot, so every step after it reads evidence that says what it shows.
2. 02The title, derived from the evidence if you have not written one, so everything downstream has something to anchor to.
3. 03A library match, if your firm has written this weakness up before. Your house wording arrives first, and the model works around it rather than over it.
4. 04Description and remediation, in your voice, from the evidence rather than from a generic template.
5. 05CVSS, with the vector worked out from what the evidence actually shows rather than typed from memory.
6. 06CWE and category, classified from the finding as written.
7. 07Affected assets, pulled from what the evidence names.
8. 08Your custom fields, each one using the prompt you wrote for it.
9. 09References last, because they draw on the title, category, CWE and description that now exist.

Everything Is Still Yours to Change

A Library That Stops You Writing SQL Injection for the Hundredth Time.

The best description of a vulnerability your firm will ever write should be written once. Save any finding to the library, insert it into the next engagement with its scoring and remediation intact, and adjust the specifics. Your house wording stays your house wording, and it gets better every time someone improves it.

QA as a Workflow, Not a Favour.

Work moves through review states with comments attached to the thing being reviewed, against a checklist your firm writes. Nothing reaches a client because someone forgot it had not been checked.

• Review statesDraft, in review, approved. Who reviewed what is on the record, and release waits for approval.
• Comments in placeFeedback lands on the finding or on the passage it quotes, not in a side channel that evaporates.
• Suggested editsA reviewer proposes new wording on the field itself. It shows as tracked insertions and deletions with the reason beside it, and is accepted or rejected in one click.
• Or review it in WordDownload the report from the review, mark it up with tracked changes and comments, and upload it back. The tracked changes arrive as suggested edits and the comments as review comments, on the findings they belong to.
• Your own QA checklistWrite the checks your reviewers make on every report once, in Settings. Each review lists them, the report cannot be approved until every one is ticked, and each tick records who made it and when.
• An AI reviewer, if you want oneOff until you turn it on. It reads your checklist, every finding and section, and the Word report uploaded on the engagement, then leaves comments and suggested edits for your reviewer to keep or reject, on your own AI key or a local model. It ticks nothing and changes nothing itself.
• Nothing half-finished goes outA report with a finding or a section still marked as a draft cannot be approved or delivered, and the review lists what is left.

Checklists and Runbooks, Attached to the Phase They Belong To.

Methodology usually lives in a document nobody opens and in the heads of whoever has been there longest. Here it is a set of templates you write once and attach to the phases you run, so what was covered is a record rather than a recollection.

• Progress is visibleEach attached template shows what has been ticked and what is left, on the phase, while the work is happening rather than in a retrospective.
• Share it, or do notMark a template client-visible and it appears in their portal, so a client who wants to see your methodology can. Everything else stays internal.
• Your standards, not a presetEvery template is yours to write, name and order. Nothing is imported from a framework you do not follow.
• The question it answersWhen a client or their auditor asks what was actually tested, the answer is attached to the engagement rather than reconstructed from memory.

Two Ways to Produce a Document. Both of Them Yours.

Start with the built-in PDF, generated from your branding with no Word skills needed. Move to a fully custom Word template whenever you want, and the platform fills it in. Mix them freely: a custom report template and the built-in attestation letter is a perfectly normal setup.

Edit It in Word, and the Portal Follows

Everyone generates a document. The problem starts afterwards: the report gets edited in Word, delivered, and the platform is out of step with what the client actually received. Pental reads the edited document back in.

1. 01Generate from your template. Every value the generator writes is marked in place as it goes, invisibly, so the document knows what it is made of.
2. 02Edit it in Word like any other document: rewrite prose, restyle it, move screenshots, add or drop findings.
3. 03Upload it back. The platform shows you, item by item, exactly what differs between the document and the assessment.
4. 04Tick what you want applied. Nothing is written that was not shown to you first, and nothing is deleted unless you ask for it.

• The whole findingTitle, severity, CVSS and vector, affected hosts, references, description, remediation, evidence with its screenshots, and every custom field you have defined, each matched by its own marker rather than by guessing at titles.
• Formatting countsHeadings, bold, lists, code blocks, links, alignment, table shading and captions come back as they are in the document, including formatting Word holds on a style rather than on the text itself.
• Phases preservedA multi-phase report puts each finding back under the phase it belongs to, resolved against the phases your assessment actually has.
• It creates what is missingA finding in the document that is not yet in the assessment can be created from it, with its fields and screenshots. An existing one is updated, never duplicated.
• Deleting is deliberateEmpty an area in Word and it offers to clear it. A finding the document no longer carries gets an explicit keep-or-delete choice, never a checkbox that could be misread.
• The delivered file, keptUpload the final signed-off PDF against the assessment so the artefact the client received and the working copy behind it live in the same place.

How templates are mapped, and how the AI drafts within them, is covered on the AI page

The Report's Shape Is a Setting, Not a Constraint.

Two firms testing the same application produce different documents, because they work differently. The parts of the platform that decide what a report contains are yours to configure.

• Custom assessment sectionsDefine the sections your report carries, reorder them, switch off the ones you do not use, and add your own, each with its own AI prompt so it is written the way your firm writes it.
• Custom finding fieldsAdd your own fields to a finding and your own sections to an assessment, choose the style each one takes, from a coloured dropdown to yes or no, and give every one its own AI prompt. Likelihood, business risk, whatever your methodology carries.
• A prompt for everythingEvery generated field and every section has its own editable prompt, used verbatim, with a reset to the shipped default. There is no hidden prompt anywhere in the product.
• Severity, your paletteYour own labels and colours for critical through informational, applied consistently from the editor to the client portal to the rendered document.
• Assessment typesSet the engagement types your firm actually sells, so a phase is labelled the way your own reports describe it.

A Portal Your Clients Sign into, Wearing Your Brand.

Clients get standing accounts on your domain, locked to their own organisation. Between engagements it is where their whole history with you lives: every report you have ever released, the findings and their current state, the attestation letters their auditors ask for. During an engagement it is where they send their test credentials, follow progress and receive findings. All of it under your brand.

• A standing record, not a one-offEvery engagement you have run for that client stays available to them: reports, findings, retest outcomes and attestation letters, in one place they can return to a year later without emailing you for a copy.
• Their view, your controlA client sees its own record, its own assessments and only the findings you have released. That boundary is enforced in the database, not by hiding buttons.
• The reason they come backWhen their auditor asks for last year's report, or a customer asks for evidence of testing, it is already there under your name. That is a renewal conversation you did not have to start.
• Comments on the engagementQuestions and answers sit on the engagement itself, where the client reads its findings, rather than in a separate email thread.
• Retest requestsThe client can ask for the retest from the finding they are reading, and the request arrives in one list for your team, with the outcome recorded on that finding.
• Feedback that compoundsStructured feedback at the end of an engagement, with a nudge towards a Google review when it is glowing.

Tool Output In. Tickets Out, and Back.

Findings come from your testers' evidence or from the output of the tools they already run, and go to the tracker your client's engineers already work in, with the ticket's state read back into Pental.

• Scanner output, as findingsSixteen formats, Nessus, Burp Suite, OpenVAS, Qualys, Nmap, OWASP ZAP, Nuclei and SARIF among them. Results with the same title become one finding listing every affected host, in your library's wording, and a later scan adds hosts rather than duplicating findings.
• Issue trackers, both waysJira, ServiceNow, Azure DevOps, GitHub, GitLab and Linear, Jira Cloud and Data Center or Server alike: a ticket in one click or as each finding is released, its state read back every hour, and a closed ticket asks your team for a retest rather than closing the finding. Any other system can take findings from a one-way webhook.
• Email alerts and single sign-onEmail notifications with a switch for each event, security alerts when a device signs in for the first time or a second factor or role changes, and Google or Microsoft sign-in on your own branded page.

Every integration

The Parts You Feel Every Day.

• One timelineEvery engagement keeps an activity trail: created, lead assigned, testing started and completed, submitted for QA, taken on, approved, delivered, credentials received, and every retest asked for and recorded. When a client asks what happened and when, the answer is on screen.
• Dashboards by roleWhat is in flight, what is blocked, what is due, laid out for the work each role does.
• Modules you can switch offNot using the library, the testing calendar, feedback or the dashboards? Turn the module off and it leaves the interface entirely, for your team and your clients.
• Sign-in your policy will likeEmail and password by default with a mandatory second factor, passkeys and authenticator apps, Google and Microsoft SSO, or emailed one-time codes if you prefer passwordless. The detail lives on the security page.
• Storage without a meterEvidence, files and reports live inside your own database, with no storage tier to outgrow. Unlimited, because it is your database.
• Full backup and restoreExport the whole portal as one archive: clients, assessments, findings, the library, users, settings and branding, plus every uploaded file. Restore it into a fresh project if you ever need to.
• Notifications you chooseEach event has its own switch, from a critical finding raised to a report released to a new device signing in, so the platform is as loud or as quiet as your team wants.

Questions About the Platform.