Approach
Authorization is the first deliverable.
Security work starts with a document that says what is allowed, on which systems, for how long. Everything else follows from that. This page is the short version of how I work; the sample scope is the long one.
Five rules
-
Passive first, and often only
A public HTTP response tells you a great deal: server software, language version, framework, and sometimes the exact patch level. Reading it is the same thing your browser does when it loads the page. Most of what I report comes from that alone.
-
Written scope before any access
Every host named. Every action permitted, ticked. A start and end date. Signed by someone with authority to bind the asset owner. For public entities, that is often procurement rather than an individual employee, and I will wait for it.
-
Fixes over findings
A list of problems is not a deliverable. The work is done when the exposed build is at a supported one, verified from outside, with a rollback path documented in case something breaks later.
-
Plain language, no fear
Your email will be forwarded, printed, and possibly read aloud at a public meeting. I write for that audience: what is true, what it costs, what the fix is. No countdown timers, no “urgent” subject lines, no screenshots of red text.
-
Collect little, keep less
I do not need your user data, your customer records, or your database. Findings are confidential, shared only with the contact named in the scope, and deleted at the end of the retention period we agree on.
What I will not do
Stated here so nobody has to ask.
- Test, scan, or probe a system that is not named in a signed scope — including “just a quick check” for a prospect.
- Run exploitation or denial-of-service testing against production, at any price.
- Access, copy, or retain data beyond what is needed to confirm a version or a fix.
- Publish findings, name a client, or use a client as a reference without written permission.
- Send unsolicited bulk email, buy contact lists, or use a lookalike domain.
- Claim certifications, clearances, or past clients I do not have.
For public-sector buyers
The parts that are usually discovered too late.
- Paperwork
- W-9 and a certificate of insurance through my broker on request. I will complete your vendor registration form rather than ask you to work around it.
- Procurement
- Small engagements often fall under your bid threshold and can proceed on a purchase order. If a formal quote or a fixed scope is required first, say so on the first call.
- Budget cycle
- I will ask when your next budget goes in. It is a better question than any pitch, and it usually decides the timeline.
- Public records
- Assume our correspondence is discoverable. I write every email as though it will be read by someone who is not an engineer.
- Notifications
- If I find something that looks like an active compromise rather than a patch gap, I will tell you immediately and stop work. Remediation of an incident is not covered by a patching scope.
Data handling
Findings are stored on an encrypted disk, shared only with the contact named in the scope, and deleted within the retention period stated in that document. This website keeps no analytics, sets no cookies, and loads nothing from a third party. Server logs are short-lived and are not used to build profiles.
If a deliverable needs to carry something sensitive, I will send it encrypted and agree the method with you before the engagement starts.
Have a scope in mind?
Send the domain and the name of the organization that owns it. We can start with the free attestation and decide the rest afterwards.