Access, confidentiality, and what leaves an engagement.

What gets published, and what never does

Most of the case studies on this site name a sector rather than a client. That is a policy, not a gap in the writing, and it is worth stating exactly:

• A client is never named alongside a security finding. The two incident-response case studies describe the phishing kits, the DNS record, the blockchain-hosted payload and the live backdoor in full — attached to “industrial supplier” and “creative agency”. If your incident were written up, it would read the same way.
• No credentials, API scopes, hostnames or internal tool names appear in anything published, ever.
• A client is named only with written permission. Two are, and both agreed to it. Everything else is anonymised by default rather than on request.
• No invented numbers. Where a metric has not been measured, it is omitted rather than estimated — which is why there is no “projects delivered” counter anywhere on this site.

These rules are enforced by a check that fails the build, not by memory: a case study carrying a client name without the permission flag set cannot be deployed.

NDAs

I sign yours. Mutual NDAs are normal for the audit and compliance work and are not treated as a negotiation. The confidentiality rules above apply whether an NDA exists or not.

Incident response engagements

Where the work is forensic, evidence handling is part of the deliverable: malware samples preserved, the DNS zone captured before any change, cron tables and login history recorded, and every command run written into the report so you can reproduce the findings yourself rather than take them on trust.

If remediation needs access I do not have — a CDN dashboard held by your team, for instance — the deliverable is a proven diagnosis and a precise remediation path, and I say so up front rather than at the end.

What this practice does not hold

Stated plainly, because a procurement review will find out anyway and the answer is better coming from here:

• No SOC 2, ISO 27001 or equivalent certification. These audit an organisation with staff, formal controls and a compliance budget. This is an individual practice. If your procurement process requires a certified vendor, that is a real constraint and I would rather you know now.
• No cyber liability insurance policy is published here. Ask if your process needs specifics.
• No subprocessors. Work is not subcontracted or offshored to a team you have not met. Whoever you speak to is who does the work.

What does exist is a documented track record, a verifiable identity, platform ratings issued by clients rather than by me, and published software on a first-party marketplace. That is a different kind of assurance from a certificate, and for engagements of this size it is usually the more useful one.