Engagement
Nothing starts without your signature
Offensive testing is only legitimate when it is authorised, scoped, and bounded in writing. This page is the whole arrangement: what we agree before we begin, what happens in what order, and what becomes of your data when it is over.
Rules of engagement
What we agree before anything runs
These go in the agreement, not in a conversation. They are the same rules a manual penetration testing firm works under, and they exist to protect you rather than us.
Written authorisation comes first
Nothing runs until the agreement and a signed authorisation to test are both in place. Without them we have no legal basis to touch your systems, and we will not — however keen either of us is to get started.
Named scope only
We test the targets listed in the agreement and nothing else. That deliberately excludes third-party services you depend on: authorising a test of those is their provider's decision, not yours or ours.
An agreed testing window
You tell us when testing may run and we stay inside it. If your business has hours where load matters, they go in the agreement.
A named contact on both sides
One person on your side who can answer a question or call a halt, and one on ours. No engagement should depend on reaching whoever happens to be online.
Nothing destructive
No denial-of-service, no deleting or corrupting data, and no degrading your service to prove a point. If demonstrating a finding safely is not possible, it gets described rather than executed.
Proof, not extraction
When a finding involves reaching data that should not be reachable, we take only what demonstrates the issue and record that in the report. We do not pull datasets, and we do not keep them.
We stop and call you
If we find something critical — or evidence that somebody else got there first — testing pauses and you hear about it directly. You do not wait for a report to learn that.
Production is your decision
A staging environment that mirrors production is safer and usually enough. If you want production itself tested, we agree the constraints in writing before anything runs.
The signed agreement is what governs an engagement. If anything on this page conflicts with what we put in front of you to sign, the agreement wins.
The flow
Four steps, in this order
From first contact to a report in your hands. Step one is not negotiable and nothing before it happens.
- 01
Sign the agreement and the authorisation to test
The engagement agreement sets the commercial terms; the authorisation names the targets and the window. Both are signed before we do anything at all — this is the step that makes everything after it lawful.
Nothing happens before this. Not recon, not a port scan, nothing.
- 02
A discovery call
We work out what matters: which parts of the application carry real risk, which roles and tenants exist, what is deliberately public, and what would genuinely hurt if it broke. In white-box engagements this is the hour of your engineers' time we ask for.
Business-logic flaws are invisible without this conversation.
- 03
You provide the environment and access
Test credentials for each role we need to exercise, network reachability, and any allowlisting your WAF or provider requires. For white-box engagements, source access as well.
By default nothing is installed on your side — no agent, no collector. Running it inside your own environment is possible on request.
- 04
The first report
Anywhere from a day to several weeks. A contained application in black-box mode is quick. A large system, a white-box engagement, or findings that need additional validation before we are willing to put them in writing all take longer.
You get a real estimate after the discovery call — not before it.
Timing
How long the first report takes
A day at the fast end, several weeks at the slow end. What decides it is not our queue.
Contained app in black-box mode at the fast end; a large system, white-box, or findings that need a chain built and re-tested at the slow end.
The application's complexity
Surface area, how many roles and tenants have to be exercised, and how much of the behaviour only appears once you are several steps into a flow.
The mode
White-box covers more ground and therefore takes longer: static analysis, live testing, and the work of reconciling the two against each other.
How much validation it needs
Some findings take one attempt to prove. Others need a chain built, tested, and re-tested before we are willing to put them in writing. We would rather be late than wrong.
You get an estimate after the discovery call, once we have seen what we are dealing with. An estimate given before that call would be a guess dressed up as a commitment.
Your data
The environment is destroyed. The report is all that survives.
The safest place for your source code and your traffic is somewhere that stops existing. There is no platform holding your code, because there is no platform.
- A fresh environment per test
- Every scan gets its own isolated container. It is not shared with another customer, and it is not reused for your next test either.
- Your filesystem is never mounted
- In white-box engagements a copy of your source goes into the container. The container has no route back to where that source came from.
- It is destroyed when the test ends
- The container and everything inside it — the copied source, the captured traffic, the working notes, the exploit code — is torn down when the engagement finishes.
- The report is the only thing that leaves
- One interactive report. No artifact bundles, no CSV dumps, no copy of your code sitting in a platform waiting to be breached.
- Nothing is used for training
- Your code and your findings do not train a model, ours or anyone else's.
- Nothing is left behind
- No agent in your environment, no residual account, no callback. When the engagement is over, the only trace of it is the report and the agreement.
▸ container created · isolated · never shared
▸ source copied in · never mounted
▸ testing proxy · browser · shell · analysers
✓ report exported
✗ container destroyed
✗ source gone
✗ traffic gone
✗ exploits gone
✗ notes gone
▸ remains the report, and nothing elseThe deliverable
One interactive report
Not a dashboard you have to keep a licence for, and not a folder of raw output for somebody to sift through.
- Findings ordered by severity, each with its CWE and its computed CVSS 3.1 score.
- The evidence behind each one — what was sent, what came back, and what that proves.
- The reproduction script, inline and copyable, so your engineers can re-run it after the fix and see it fail.
- The proposed fix as a diff against the responsible lines, in white-box engagements.
- An executive summary that a non-engineer can act on, and a methodology section an auditor will accept.
The free scan does not produce this report. It returns a summary — scores and counts by severity — so you can see whether there is anything worth acting on before you spend anything. Either mode can be used at either tier. What each tier includes →
Start with the discovery call
Tell us what you would want tested. We will send the agreement and the authorisation, and nothing runs until both come back signed.