Penetration tests & assessments

Run a penetration test or security assessment end to end: the scope you agreed, the window you tested in, who tested, the findings that came out of it, and the report you hand over. Each one is an engagement — that is the wording you'll see in the navigation.

It sits beside Exposure, which is what continuous scanning finds on its own — an engagement is the piece of work a person does, with a report at the end of it.

Typical workflow

Scope the engagement

Create the engagement, then add scope targets — a URL, a hostname, an IP range, or free text like "corporate Wi-Fi". Each target can be marked in or out of scope. Out-of-scope rows print as excluded and are left out of the counts.

Where a target is an asset you have already discovered, link it. A linked target is the only way to be certain its findings land on that row rather than on a similarly-named one.

Test accounts are recorded by identifier, role and notes — never a password. Exchange credentials with your client out of band.

Move it through its stages

An engagement runs scoping, to testing, to reporting, to delivered, to closed. You can step back if something reopens. Every stage change is recorded in the audit log with who made it and when.

Report findings

You attach findings to an engagement yourself, so nothing reaches a report that you did not put there. Each one is given a reference (F-01, F-02) when you attach it, and keeps that reference through remediation and any later retest, so a client can cite it months afterwards. The one thing that changes it is renumbering, below — and a report you have already delivered is frozen, so an earlier reference stays valid in the copy your client holds.

You don't start from a blank page. The vulnerability library holds reusable write-ups — description, impact, remediation guidance, CVSS and OWASP category — that you drop onto a finding and then edit for the instance you actually found. Reporting something a scan had already picked up does not leave you with two copies of it.

You can set the order findings appear in, and renumber to match — the one action that reassigns references, so do it before you deliver rather than after. The report reads in that order, so F-01 prints first even when it isn't the most severe — useful when your narrative needs to build up to the headline rather than open with it.

Generate the report

The report is a draft you can edit, built from the engagement:

• the scope table, with excluded rows shown as excluded;
• a severity matrix per scope target, whose totals add up to the finding count;
• a findings index, then each finding with its description, impact, reproduction steps, remediation and evidence;
• an OWASP Top 10 annex showing which categories the assessment actually covered;
• your positive observations — what was tested and found sound.

Narrative sections — disclosure notice, methodology, limitations, risk key, recommendations — arrive already written and are yours to edit. Export is print-to-PDF from your browser, the same as every other report.

Retest

A retest engagement links back to its predecessor, and its report links back to the report it re-tests. Each finding carries a retest verdict, and a fixed one drops out of the OWASP annex's open categories.

Running one with an agent

Every step on this page is available to your own AI agent — scoping, deciding what the engagement reports, moving it through its stages, writing it up. Two things stay yours: an agent suggests which findings belong but never attaches them, and releasing the report is a proposal you approve. Its work lands in the audit log the same way a person's does.