May 2026: Before Kickoff and After the Report

Most of our work so far this year has been about the middle of an engagement: testing, writing and review. In May we turned to the edges. What has to be true before a team starts testing, and what has to happen once the report is delivered.

Findings that route themselves

We started the month with the full write-up on Workflow Integrations and routing findings into ServiceNow (opens in a new tab). It follows on from the spotlight in March, and goes into how the pieces fit together.

A connection points Neuron at a ServiceNow instance. Push profiles decide what a finding becomes there: which table it lands in, how long titles are shortened, how severities translate into the values the other system expects. Routing rules then decide which findings go where, based on things like severity, client and assessment. A rule can fire on its own the moment a finding is approved, so critical issues for one client open records for that client’s remediation team without anyone copying text by hand.

Two details reflect how we think about this. Nothing is pushed before it has passed review, because a ticket is a commitment to the client. And there is a tool to test rules against made-up values before they ever touch a live queue, because routing logic you cannot predict is worse than none.

A schedule that lives with the work

The other end of the engagement is staffing. Who is testing what, and when, usually lives in a spreadsheet or a calendar that knows nothing about the engagements themselves. When dates slip, the spreadsheet is the last place to find out.

Our engagement scheduling spotlight (opens in a new tab), published early in May, shows the alternative. The schedule sits next to the engagements it describes. Managers drag an engagement to new dates or drop it on a different tester, and conflicts show up before the change is committed. Overload becomes visible before kickoff instead of during it.

Retests as records

Later in the month we published a spotlight on retests in Neuron (opens in a new tab). Retesting is easy to treat as an afterthought: a status column that flips from open to fixed. That loses most of what a client actually needs to know. When was it retested, by whom, against what scope, and with what evidence?

In Neuron a retest is its own record within the engagement, with separate dates, scope, ownership and evidence for each round. The original engagement stays as it was, and the retest builds its own timeline beside it. For clients who come back quarter after quarter, that history is the point.

Why the edges matter

None of this is the most visible part of a penetration test. But a late start, a ticket that never gets raised or a retest nobody can account for all land on the same people: the leads who answer to clients. Making those steps part of the platform, rather than something kept in a side document, is a large part of what Neuron is for.

The product stories behind this update are on neuron.ws/news (opens in a new tab). If you would like to see how scheduling, retests and ticketing fit your team, book a Neuron demo (opens in a new tab).