Questions that come up before the contract does

The smallest thing I take is a Recon - a time-boxed review of one defined surface, priced as a range on the prices page. Below that, the scoping, the paperwork and the context-loading cost more than the work returns, so you will usually get a narrower question suggested back rather than an invoice. Everything above that floor is quoted against scope, not against a day rate.

Lead time is normally a few weeks, and a slot is held once the statement of work is signed, not before. A Recon runs in days, a scoped assessment runs in weeks, a retainer runs until one of us ends it - the turnaround window for each tier is on the prices page and the exact dates go into the contract. If you have a fixed deadline, say so in the first message: moving a start date is easy, compressing a test is not.

Yes, and it is signed before technical detail moves in either direction. Mutual NDA first, statement of work second, access third - that order does not change, including for a scoping call. If your legal team has paper of their own, send it; it gets read rather than swapped for mine.

One person does the testing and writes the report, and that person is named in the contract. Nothing is quietly passed to a marketplace, a body shop or an unnamed associate. If a scope genuinely needs a second specialist, you are told who they are, told exactly what they would see, and asked in writing before they get access - and they sign the same NDA.

Not by name. Clients are under NDA, and the point of that arrangement is that their security work does not become my marketing - the clients page is anonymised for the same reason, deliberately. What is available instead is a redacted sample report and a technical call where your engineers push on method rather than on reputation. Where a client has separately agreed in writing, a private reference call can be arranged; it still never appears on this site.

A written report, encrypted to your key, where every finding carries impact, evidence and reproduction steps an engineer can run without a phone call. Scanner output is not a finding and never appears as one. Critical issues do not wait for the document - they go out the day they are confirmed, through the channel agreed in the scope; if you have no key of your own, mine is on the contact page and we settle a channel before work starts.

Distribution is whoever you name in the statement of work. Nobody else receives it, including me once the retention period ends.

No. Written scope, signed by someone with the authority to sign it, or there is no engagement - and that includes the friendly versions: a verbal yes in a meeting, a message from one engineer, a screenshot of a ticket. If the paperwork is not in place, nothing gets touched.

The rule points back at me as well: unsolicited testing of shellcode.gg infrastructure is not authorised either. If you have found something here, the submit page is the way to say so.

Governing law and venue are named in the contract before work starts rather than assumed afterwards, and they are open to negotiation while the statement of work is being drafted. I will not sign a scope whose testing would be unlawful for either side in the jurisdictions involved - computer-misuse and data-protection statutes come before the test plan. If the target handles regulated data, or sits somewhere with its own rules about security testing, raise it during scoping: it changes evidence handling, and occasionally it changes the answer.

Rules of engagement are agreed before anything runs: what is off-limits, what rate limits apply, who sits on the emergency contact list, and what condition stops the test. If something degrades, testing stops first and you get a call rather than an email, followed by a written account of what was sent and when.

Destructive proof-of-concept is not run against production. Proof either happens against a lab copy or stops at the point where the impact is demonstrated - a screenshot of a database you could have dropped is worth exactly as much as dropping it.

Cover and liability limits are a contract question, and they get answered during contracting rather than advertised on a web page. If procurement needs evidence of cover at a specific limit, raise it while the statement of work is being drafted - it is a normal condition, and far easier to meet before the scope is fixed than after. Ask through the contact page and you get a direct yes or no.

A fixed quote, agreed in writing before work starts - scope drives the number, so you are not billed against a meter you cannot audit. Engagements are 50% up front with the balance due on delivery of the report; retainers bill monthly. If scope changes mid-flight it is re-quoted in writing before the extra work happens, which is why the invoice never contains a surprise. The ranges each tier starts from are on the prices page.

Yes - BTC or XMR, or a normal invoice with bank details if your finance team prefers paper. Quotes are fixed in USD and a crypto payment settles at the rate on the invoice date, so exchange movement is not an argument two weeks later. Whichever rail you use, the invoice, the scope and the report all reference the same engagement id.

Yes. You are buying the work and the evidence that it was done properly, not a bug count - and a clean result against a well-scoped target is itself a finding. The report states what was tested, how, and what was not reachable in the time bought, which is the part an auditor and the next budget round actually need.

If a scope turns out to be thin early on, you hear about it while there is still time to move the hours somewhere more interesting rather than at the end.

One retest of the findings in the report is included: same scope, same targets, confirming the fixes hold and that they have not moved the problem somewhere else. It runs inside a window named in the statement of work, and it covers the original findings rather than whatever shipped afterwards. New functionality, a new version or a widened surface is new work, quoted the same way the first pass was.