Active testing only with written authorisation
~/tholim_
Policy · last reviewed 2026-05-02

Editorial & disclosure policy

The rules we follow before anything is published, sent to a client, or shared in public. They exist to protect the people we work with, the broader ecosystem, and our own ability to keep doing the work.

§01

Authorisation discipline

Active testing — anything beyond a single HTTPS GET to a publicly resolvable endpoint — is performed only against domains for which Tholim holds a signed authorisation from the verified owner.

Domain ownership is verified before active testing begins. Acceptable proofs: DNS TXT token, file at /.well-known/tholim-verify-{token}.txt, or a registrar / hosting-panel screenshot reviewed by us. Each authorisation file is timestamped and retained for the engagement lifecycle.

Surface scans (passive reconnaissance against public sources) do not require permission, because they query third-party services rather than the target's origin. We document the boundary explicitly in every report.

§02

Client anonymisation

Published case studies and engagement-ledger entries are anonymised. We omit client names, exact domains, distinctive copy, screenshots, dates more granular than the year-month, and any combination of details that would let a reader identify the assessed party.

A finding is only published once the client has remediated it and explicit clearance has been obtained. The shortest interval we accept between remediation and publication is the period required for verification re-scans to come back clean.

If a client requests indefinite suppression of a case, we honour it. The default is non-publication; consent is opt-in.

§03

No exploit code, no zero-day pre-disclosure

We do not publish working exploit payloads, attacker-ready scripts, or step-by-step weaponisation instructions for live targets. Educational content is defender-focused: what the class of issue is, how to detect it, how to fix it.

For previously undisclosed vulnerabilities discovered during our work, we follow coordinated-disclosure standards (typically 90 days, extended on vendor request, shortened only on confirmed exploitation in the wild). No public write-up is released before the vendor patch ships and customers have a reasonable migration window.

Already-disclosed CVEs may be discussed retrospectively, but our write-ups still avoid copy-paste exploit code where the underlying systems remain widely deployed and unpatched in the field.

§04

Data we hold, and for how long

Surface-scan reports are stored in our cache for 24 hours so a repeat run on the same domain does not re-hit upstream rate limits. After 24 hours the row is overwritten on next request.

Engagement deliverables (PDFs, raw tool output, evidence captures) are retained for the duration of the engagement plus 12 months, then deleted. Earlier deletion on written client request.

Email addresses provided for report delivery are used only to deliver the requested report and follow-up on engagement enquiries. They are not added to any newsletter, advertising network, or third-party CRM.

We do not store credentials, tokens, or any authentication material from the assessed environments — these never leave the engagement scope.

§05

Reporting issues to us

If you discover a security issue in any Tholim property — this site, our open-source tools, or an engagement deliverable — please report it to security@tholim.com. PGP key available at /.well-known/security.txt.

We acknowledge submissions within two working days and aim to ship a fix within 30 days for high-severity issues. We will credit reporters in the resulting advisory unless asked otherwise.

§06

Take-down requests

If you believe a published case study or other content on this site identifies you or your organisation in a way that the policy above should have prevented, contact hello@tholim.com with the URL and the specific concern.

We respond within two working days. Where the concern is valid, we remove or further anonymise the content immediately and document the change in our internal policy log. We do not require legal demand letters for good-faith take-down requests.

§07

Policy versioning

This policy is reviewed at least quarterly. Material changes are dated at the top of this page. Earlier versions remain available on request.

Substantive narrowing of any client-protective clause is communicated in advance to engaged clients and does not apply retroactively.