Engagements

Scope. Test. Report. Retest.

Nothing is touched before the scope is agreed in writing. Nothing is closed before the fix has been checked.

The process

Four stages, one owner

  1. Scope

    We agree in writing what we are allowed to test.

    Which systems are in scope, which roles and environments we test against, what is off limits, and who has to authorise it. Nothing is touched before that is settled.

  2. Test

    We attack the application by hand, the way someone else would.

    Authentication, authorisation, input handling, business logic and the client side, worked through by hand. Tooling helps with coverage; it does not decide what counts as a finding.

  3. Report

    You get what we found, how bad it is, and how to fix it.

    Each finding carries the request that triggers it, the risk it creates for the business, and what it would take to close it, ordered so there is a queue to work through.

  4. Retest

    Your team fixes it. We check that it is really fixed.

    Once your engineers have made the change, we go back at the findings in the report and confirm each gap is closed rather than moved somewhere else. Included for fifteen days after the report, then 50% of the original assessment price for days 16 to 30.

If a system belongs to a platform, supplier, or other third party, their written authorisation is needed too.

The report

A finding your engineers can close

Every result is verified by hand and ordered by real risk, not copied from a scanner export.

  • What we found

    The vulnerability in plain terms, and where it lives.

  • How we exploited it

    The path actually taken, not the name of a category.

  • How to reproduce it

    The requests and account state needed to see it happen.

  • Why it matters

    What it would let someone do to your data, users, or revenue.

  • How to fix it

    The check that is missing, and where it belongs.

  • Whether the fix worked

    The result after we retest the finding.

Finding 03 — Broken object-level authorisation example entry · not a real engagement
  1. Low
  2. Medium
  3. High (this finding)
  4. Critical
  • What we found A member of one workspace can read another workspace's orders.
  • Where GET /api/v2/orders?workspace= — the identifier is trusted from the caller.
  • How we exploited it Signed in as a member, changed one identifier, and read the response.
  • Reproduce Two accounts, two workspaces, one request. Steps and payloads attached.
  • Why it matters Every order, customer name and total in the estate, to any signed-up account.
  • How to fix it Check workspace membership in the handler, not in the client that calls it.

Retested and closed — included for fifteen days

Retesting

Fix it. We check.

Remediation is your engineers' work. We go back at the reported findings and confirm the gaps are closed rather than moved.

  • Within 15 days

    Included. Fix the findings, tell us they are in, and we verify them.

  • Days 16 to 30

    The same findings, at 50% of the original assessment price.

  • After 30 days

    Usually a new assessment, because the application has moved on.

Ready to scope a test?

Send a paragraph about the application, its users, and what worries you.