Questions we actually get asked.

A scanner reads a version string and tells you what might be wrong. It hands you a list of hypotheses and leaves the triage to you — which is where about 40% of most teams’ security time goes, before anyone has fixed anything.

We do the triage. An agent tries each candidate, safely, and a person puts their name on the verdict. Roughly 91% of raw findings never reach you, because they were not real. What does reach you arrives with the request, the response and a screenshot, so the argument with your dev team lasts ten seconds instead of a sprint.

The other half of the difference is scope. A scanner checks the list you gave it. We go and find the list — certificate transparency, DNS, cloud ranges, code hosts, the storage bucket somebody forgot about in 2021 — and re-check it every six hours. A CVSS 9.8 that nobody can reach is a rumour. An open admin panel on a subdomain you had forgotten is a Tuesday.

No, and we would rather you did not buy it as one.

A penetration test is scoped, time-boxed and carried out by named humans, usually once a year, and it ends in a signed report. We run continuously, across everything you expose, and tell you what is true this week. Different jobs. If someone sells you one as the other, ask which week their report covers.

You can still get one through us. A penetration test can be added to any subscription and run on a schedule. Because we have already mapped your surface, the scope in the RFP is drawn from what you actually have rather than what someone remembers having. We write the RFP, put it out to several providers at once, and help you compare what comes back on equal terms. Their findings then land in the same place as ours — verified, tracked, and re-tested on deploy — instead of a PDF in a drive folder nobody opens until the auditor asks.

We do not perform the test ourselves, so we have no reason to want it to find a lot, or a little.

No. MDR and SOC services watch your endpoints and your logs for somebody who is already inside. We watch what you expose to the outside, and prove what somebody could reach before they get there. The two barely overlap: your MDR contract almost certainly excludes your own product, which is the largest attack surface you own and the only one you fully control.

We work business hours, on purpose. If you need somebody awake at three in the morning you need an MDR as well — and we sit upstream of it, leaving them fewer ways in to watch.

It means a narrow brief and a hard rule: prove it without breaking it. An agent takes one candidate finding, tries to confirm it with read-only techniques, and records the request, the response and a screenshot. Destructive classes are off by default and stay off unless you sign something specific.

Nothing reaches you on an agent’s authority alone. A person reads the evidence and signs the verdict — which is also why there is a name to give your auditor when they ask who reviewed it.

Not to start. The free attack surface review needs nothing from you — if we can reach it from the internet, so can we, and that is rather the point of the exercise.

Once you are on a plan, per-change assurance needs read-only access to your repositories and CI. No agents, no pipeline changes, roughly one day of your team’s time to set up.

You hear about it on Saturday. Agents run all week; people verify during business hours. When an agent confirms something critical out of hours, the alert and its evidence go to you immediately, flagged as agent-confirmed and not yet reviewed, so you can act without waiting for us. The written verdict and the fix guidance follow on the next business day.

We are not a 24/7 service and we do not claim to be one. Be suspicious of anyone our size who does.

You can try. We will say no, in writing.

Authorisation is part of onboarding, not an afterthought. You sign a standard agreement that lists what is in scope — domains, repositories, environments — and confirms you have the authority to have it tested. Nothing outside that scope is touched, and adding to it is a signed change, not a support ticket. For the free review we also verify ownership with a DNS record before anything runs.

Supplier systems are tested under your contractual rights over that supplier, with the supplier told. Never quietly.

That is most of why people buy it. ISO 27001 auditors now sample individual changes (A.8.29, A.8.32) rather than accepting a policy document, and the evidence either exists on the day they ask or it does not. DORA and NIS2 push the same question down from your regulated customers, in the form of supplier questionnaires you have to answer.

What we produce is dated evidence per change and per release — what changed, what was reviewed, by whom, what ran, what was re-tested. That is what those questions are actually asking for. We audit financial institutions under DORA and NIS2 ourselves, so the evidence model was built from the asking side of the table.

Yes. That is what they are for. Two reports come out of the same evidence: a management report — exposure, trend, what is past its SLA and whose name is on it — and a technical report with the findings, the reproduction steps and the re-test results. Both are on the platform page, in full.

On the higher plans we also sign an annual assurance letter, for the customer who is asking harder questions than a questionnaire.

One thing you ship, plus the surface that serves it: its repositories, its domains and subdomains, its environments. A SaaS application with a marketing site and a staging environment is one product. Two applications that happen to share a login are two.

Plans are sized in products because that is the unit your exposure actually grows in — never per developer, per endpoint, or per finding we raise.