Trust is a posture, not a badge.
We are asking to test your most sensitive systems, so it is fair to ask the same questions of us. This page states plainly how we handle your data, how to report a vulnerability in our own systems, and what we do and do not claim.
Confidentiality
NDA before scoping. Minimum necessary data handling. Encrypted evidence storage with a named access list and agreed destruction timeline.
Integrity
Findings are reproducible and evidenced. Test windows, actions taken and scope changes are recorded for the engagement file.
Least disruption
Testing is rate-limited and windowed to avoid availability impact. Destructive techniques require explicit written approval.
Transparency
You get the raw truth: what we tested, what we could not test, what we assumed, and what remains unverified.
Found a vulnerability in our systems?
Tell us before you tell anyone else. We will acknowledge your report, keep you informed while we fix it, and credit you if you would like the recognition. We will not pursue legal action against researchers who act in good faith within the boundaries below.
How your data is treated during an engagement.
| Area | Practice |
|---|---|
| Agreements | Mutual NDA and a signed rules-of-engagement document before any testing begins |
| Access | Named testers only; credentials issued per engagement and revoked at closure |
| Evidence storage | Encrypted at rest and in transit, access-restricted, retained only as long as needed for retest and audit |
| Test data | Test accounts and synthetic records preferred; production personal data is not extracted or copied out |
| Third parties | No client data is shared with subcontractors without prior written approval |
| Deletion | Evidence destroyed on the timeline agreed in the engagement contract, with written confirmation |
| Incident handling | Any accidental exposure during testing is reported to your named contact immediately, in writing |
Claims we can evidence, and tools we rely on.
We only publish a compliance claim when we hold the certificate or report that supports it.
| Framework | Status |
|---|---|
| ISO/IEC 27001 | Alignment only — certification not held |
| SOC 2 Type II | Not held |
| Cyber insurance | Details to be confirmed |
| GDPR / data processing | DPA available on request |
| Service | Purpose |
|---|---|
| Cloud hosting provider | Hosting of infrastructure and evidence storage — provider to be named |
| Business email provider | Engagement communication and report delivery — provider to be named |
| Analytics (this website) | Aggregate, privacy-respecting measurement only — provider to be confirmed |
Replace with your real subprocessor list, including locations and safeguards.
What happens after you report a vulnerability.
A disclosure policy is only credible if the process behind it is published too. This is exactly what happens to a report that arrives in our inbox.
Acknowledgement
We confirm receipt within two business days and give you a named contact who owns your report until it closes.
Triage and reproduction
We reproduce the issue in a controlled environment, determine whether it affects customer data, and classify severity. If we cannot reproduce it we say so and ask for what we are missing.
Remediation
Fixes are scheduled by severity: critical within days, high within the current cycle. You keep your named contact and get updates without having to chase.
Verification and credit
We confirm the fix with you, agree the disclosure date, and publish credit with whatever name or handle you prefer.
Publication
If the issue was material we publish a short advisory after the fix ships, so the same mistake is harder for anyone else to make.
Questions we have not answered here?
Security questionnaires, DPAs and due-diligence packs are handled by a named contact, not a form letter.