Skip to main content
B‑52
Run a scan
A finished run, opened in the dashboard

See a completed run before you scope one

The walkthrough opens the demo tenant and reads one assessment from the findings list down to the request and response behind a single finding. You get the shape of the output, the evidence format, and an honest answer on what your own estate would take.

Ask for a walkthrough Read how a run works instead

What we open

Four screens, in the order they matter

The dashboard is where your team would live, so that is what the walkthrough is: your team, reading someone else’s run.

  1. Screen one

    The findings, with the request that produced each one

    Severity, and underneath it the request that triggered the finding and what came back. This is usually the point where a demo stops being abstract for an engineer in the room.

  2. Screen two

    The chain, in the order it was walked

    The same findings arranged as the route through them, so an item that would sort as low on its own shows the weight it actually carries in sequence.

  3. Screen three

    The run, while it is still running

    What has been covered on the current scope and what is still outstanding, which is the screen a security manager keeps open rather than the one they present.

  4. Screen four

    Remediation, through to a verified fix

    Each finding tracked to a retest, and closed on the retest rather than on somebody asserting that it was fixed.

About the demo tenantCaution
  • Every finding, figure and target in the demo tenant is synthetic. None of it is a customer’s data and none of it is a measured result.
  • The workflow, the evidence format and the retest cycle are the product as it ships.
  • Your own run is scoped from your own targets. Nothing from the demo tenant carries into it.

We say this before the call rather than during it. A screen full of invented numbers is the easiest way for a platform demo to mislead, and the figures in a tenant nobody tested are worth exactly what they cost to type.

What is not synthetic is the method: the same six phases, the same exploit artefact on every finding, and the same QA gate sitting after reporting.

Before the call

Three things worth bringing

A walkthrough with nothing of yours in it is a product tour. These three turn it into an evaluation you can act on.

01 One target you know well
Bring an application whose defects you already know about. Watching a platform work on something you understand is worth more than watching it work on a demo shop.
02 Whoever owns the filing
If the output ends up in front of a regulator, the person who signs it should see the evidence format before the scope is agreed, not after the report arrives.
03 Your pipeline, if that is the plan
A run can fail a build on a severity threshold you set. If that is the shape you want, bring the pipeline it would sit in and we will walk the gate rather than the dashboard.

Ask for a walkthrough

Tell us what you want to see and we will open that rather than the standard tour.

If you would rather not wait

A scan is $500 and covers one application or one target. Card payment, no call, and the report comes back with the same evidence you would have seen on the walkthrough.

If it has to be signed

Say so on the form. A filing needs an empanelled auditor in the engagement, which means the expert-verified or the human-led model, and it is cheaper to know that before the scope is written than after the report is delivered.

Send the scope instead