Skip to content
How we test

We show our work. Here is what that means.

What a finding contains, what we test against, where a tool stops and a person starts, and what we ask before we quote. If anything here is vaguer than you need, ask and we will answer it specifically.

The question

With us

When do I see the first finding?

Week six, with the report

Day one, as soon as it is confirmed

When can my team start fixing?

After the engagement has closed

Week one, while testing continues

What does a retest cost?

A second engagement

Included, on request

When can I get the report?

When it is written, at the end

Any time, in the format you need

The anatomy of a finding

This is one finding.

Not a report - one finding, exactly as it appears in the platform. Every field it carries, and why each one is there. Yours will look like this.

A Vexil finding opened beside the findings list: a critical SQL injection rated CVSS 9.8 with its affected URL, description, impact, recommendation, an OWASP reference and a proof-of-concept request and response, with Details, History and Comments tabs.

What each field is for.

Title
what it is, in your engineers’ words
Affected asset
the specific endpoint of the application
Severity
computed from the vector, never chosen by hand
Evidence
the request, the response and screenshots, attached to the finding
Request
the raw exchange, so your engineer can reproduce it
Response
what came back, unedited except for a client’s data
Impact
what it costs you, not what the CVE says
Remediation
for your stack, not “apply vendor patches”
Retest
a tester’s verdict, not your self-assessment

This is the format, not a client’s work - it is written against the demonstration environment we run for the purpose, and a real finding also carries screenshots of the issue alongside the request and response. We don’t publish client findings, redacted or otherwise. If you want to see a real one, email us and we’ll send a redacted sample.

Methodology

What we test against

Named with versions, so the coverage claim is something you can check rather than something you have to take on trust.

OWASP WSTG v4.2
Web application testing - the 11 categories, from configuration through to client-side.
OWASP ASVS
Verification depth: what "tested" means for a given control, at a stated level.
OWASP API Security Top 10 (2023)
Authorisation, object-level access and the flaws that only exist in APIs.
OWASP MASVS
Mobile, from the binary through to the backend it talks to.
PTES
The shape of the engagement itself - intelligence, modelling, exploitation, reporting.
NIST SP 800-115
The technical assessment framework auditors most often recognise by name.

Tooling and people

Where a scanner stops.

We run tooling for coverage. Then a person exploits what it found, chains it with what it missed, and confirms every finding by hand before it reaches you.

Scanner

Finds what is there

  • Open ports and services
  • Publicly known vulnerabilities (CVEs)
  • Default passwords
  • Weak TLS, missing headers
  • Outdated software

Fast, and worth running.

Tester

Finds what is broken

  • One customer reading another’s data
  • A regular user granting themselves admin
  • A password reset that takes over an account
  • A price changed in the browser and trusted
  • Two safe steps chained into an attack

This is where the real risk is.

Claiming a test is 100% manual would not be true, and you should not believe anyone who says it. What matters is which half does which job.

Rules of engagement

What we will and will not do to your systems

  • We agree the window before we start

    Testing dates, out-of-hours windows if you need them, and the systems that are explicitly out of scope. All of it in writing, signed by someone who can authorise it.

  • We do not knowingly break your production system

    No denial of service, no destructive payloads, no automated exploitation that could corrupt data. Where proving an issue would cause damage, we prove it far enough to be certain and stop there.

  • You get a contact who can stop the test

    A named tester and a number, from the first day to the last. If something looks wrong at two in the morning, you call and it stops.

  • Your data leaves when the engagement does

    Evidence is kept for the retest and the period we agree with you, then destroyed. Findings never appear in another client’s report, and no client work is ever published.

Scoping

What we ask on the scoping call.

All of it, so there is nothing to prepare for and no surprise in the price. Thirty minutes is usually enough.

  1. What is being tested, by URL or by hostname?

    Scope is a list of things, not a description. “The production environment” cannot be tested or quoted.

  2. How many distinct user roles are there, and can we have one of each?

    Most of what matters is behind a login, and a role we cannot sign into is a role we cannot test.

  3. Is there an API, and is it documented?

    An API is usually a larger surface than the interface in front of it, and it is where authorisation flaws live.

  4. Are we testing production, or a staging copy?

    It changes what we are allowed to do. A staging copy that differs from production changes what the results mean.

  5. Is anything explicitly out of scope?

    Third-party services, a payment provider, a legacy host somebody else owns. Better named now than discovered mid-test.

  6. Who is asking for this, and what will they accept?

    An auditor, a customer’s questionnaire or an insurer each want a different format. It decides the report, not the testing.

  7. When does it need to be finished?

    A date somebody else set is the most common reason a test is booked, and it decides whether we are the right firm for it.

  8. Who do we call if something goes wrong at 2am?

    Testing a production system carries a small risk of disruption. We agree the kill-switch contact before we start, not after.

What you receive

One engagement, exported for whoever is asking

The same testing, rendered for the person who has to read it. Generated on demand rather than quoted as extra work.

  • Comprehensive

    Your engineering team

    Every finding at every severity, with full technical detail, evidence and remediation guidance.

  • Executive summary

    Leadership and the board

    Risk posture and the findings that matter at that altitude, with informational and low-severity observations excluded.

  • PCI DSS v4.0

    Your QSA

    Findings mapped to PCI DSS requirement areas, with the software weakness classes the standard enumerates at 6.2.4.

  • SOC 2

    Your auditor

    Findings mapped to the Trust Services Criteria, for the security evidence an examination asks for.

  • ISO/IEC 27001:2022

    Your certification body

    Findings mapped to Annex A control areas, supporting the technical testing evidence the standard expects.

  • HIPAA Security Rule

    Your compliance officer

    Findings mapped to the Security Rule safeguards, for the evaluation requirement under §164.308.

A penetration test is evidence that may support an assessment. It is not a certification or an attestation, and no report produced here claims to be one. Your assessor decides what satisfies the standard.

We don’t publish client reports. Email us and we’ll send a redacted one

Fair questions

What people ask before booking

Is this an automated scan or a manual penetration test?

Manual. Certified testers work through your application by hand, chaining multi-step issues and abusing business logic - the things a scanner cannot reach. Automated scanning is available inside the platform between engagements, and its results are kept separate from the findings a tester wrote so you always know which is which.

How much does a penetration test cost?

It depends on scope, which is why we quote after a 30-minute call rather than publishing a figure. What drives the number is the number of applications, how many distinct user roles need testing, whether an API and a mobile client are in scope, and whether internal network testing is included. What we can commit to before you speak to us: the price is fixed before work starts, it is priced on scope rather than hours, and if we find more attack surface mid-engagement we tell you rather than invoice you.

How long does an engagement take?

Typically five to ten working days from kickoff to final report. Because findings publish to the platform as they are confirmed, your engineers usually start fixing critical issues within the first two days rather than waiting for the report.

Do you charge extra to retest after we fix something?

No. Retests are included in the engagement. You mark a finding fixed and request a retest from the same screen; a tester verifies it by hand and records whether it passed or failed.

Will the report satisfy our SOC 2 or ISO 27001 auditor?

The platform generates reports mapped to PCI DSS v4.0, SOC 2 Trust Services Criteria, ISO 27001:2022 Annex A and the HIPAA Security Rule, grouping findings under each framework’s own requirement areas. A penetration test is evidence that may support an assessment - it is not a certification, and your assessor decides what satisfies the standard. In practice this is the technical testing evidence those standards ask for.

Where is our data stored, and will you sign a DPA?

The platform and your engagement data are hosted in the United Kingdom, which the European Commission recognises as providing adequate data protection. Findings are visible only to the people on your engagement. Test credentials and raw evidence are purged within 30 days of close; your findings and reports stay in the platform while your account is active so reports can be regenerated and retests requested. For EU and UK clients we act as your data processor and will sign a Data Processing Agreement on the Standard Contractual Clauses on request, at no charge.

Tell us what needs testing.

A sentence is enough. If somebody asked you for this, paste what they sent and we’ll tell you whether a test answers it. Either way you get the scope and what it would cost. No obligation and no sales sequence.