How the snapshot collects, and what it never touches

Document id: data-processing-note Draft version: dpn.draft-0 Written for: the person in your organisation who will be asked “is this safe to let them do?” — an IT manager, a hospital systems administrator, a hosting provider, or a consultant advising you. Companion documents: privacy-policy.md (what we do with your data), acceptable-use-and-authorisation.md (what changes once you authorise us to go further).

1. The one-paragraph version

For a domain we have not verified you control, we read four kinds of public record: your DNS records, the mail settings those records describe, public certificate transparency logs held by third parties, and the public domain registry entry. We never connect to your website or servers, never log in, and never test your defences. A person then reads what we found and writes you a report. There is also an optional password check, and that runs entirely inside your own browser.

2. What we will not tell you

We will not tell you that nothing of ours ever reaches anything of yours. That claim is false, and you would be right to distrust anybody who makes it.

Reading DNS means asking whichever name servers are authoritative for your domain. If you run those name servers, or your hosting provider does, then our lookup arrives at a machine that belongs to you or to them, and it may well be logged there. That single lookup is the only contact a free snapshot involves, and it is indistinguishable from the lookup every mail server on the internet performs to find you.

That is the honest boundary. Everything below describes what sits on each side of it.

3. What we actually query, query by query

#	What we read	Who answers the query	What it tells us
1	DNS records for your domain: A, AAAA, MX, NS, TXT, CNAME, SOA	Your authoritative name servers, via a resolver — see section 2	Where your website and mail resolve, who runs your DNS, what records exist that nobody remembers creating
2	Mail posture, derived from DNS only: your SPF record and the records it includes; your DMARC policy at `_dmarc.<your domain>`; DKIM selectors, looked up as DNS names	Your authoritative name servers	Whether somebody can send email that convincingly appears to come from your domain
3	Certificate transparency logs	A third-party log service. Your systems are not involved in this query at all	Every HTTPS certificate ever issued for your domain is written to a public, permanent log by design. Those entries often name hosts a business never meant to publish — a staging server, an old booking system, an admin panel
4	The public domain registry entry (RDAP)	The registry or registrar operating the registry service. Your systems are not involved	Your registrar, when the registration expires, and whether the domain is locked against transfer. A domain that quietly expires, or moves without your knowing, takes your website and your email with it

Queries 3 and 4 read registries. They are the same kind of act as looking a company up in a public register, and your infrastructure never sees them.

Open technical point, flagged rather than smoothed over. Some of our marketing copy lists MTA-STS among the mail settings we read. The MTA-STS DNS record (_mta-sts.<your domain>) is a DNS lookup and belongs in row 2. The MTA-STS policy file is fetched over HTTPS from mta-sts.<your domain>, which is a web request to a server of yours and is therefore outside what a free snapshot may do. We read the DNS record and we do not fetch the policy file. [COUNSEL: no legal question here, but note that our public copy must be corrected to match this paragraph before publication, or the copy will overstate what we collect. Tracked as an engineering and copy fix.]

4. What a free snapshot never does

Not as a matter of policy that could be quietly changed, but as a matter of what the software can represent. On a domain you have not verified:

No TLS handshake with your servers. We do not connect to port 443 to inspect your certificate or your cipher configuration.
No HTTP or HTTPS request to your website. We do not fetch your home page, your headers, your robots.txt, or anything else.
No port scanning, of any port, on any host of yours.
No login attempt, no credential testing, no password spraying, no attempt to authenticate to anything.
No exploitation, no fuzzing, no injection testing, no attempt to make any system of yours behave unexpectedly.
No subdomain brute-forcing against your name servers. We read what your records and the public logs say. We do not generate thousands of guessed names and fire them at your DNS.
No email sent to anybody at your domain as part of the check.

If a check would require connecting to your systems, it does not run until you have proved you control the domain, or given us written authorisation. See acceptable-use-and-authorisation.md.

5. Why we are strict about this, in one paragraph of law

Kenya’s Computer Misuse and Cybercrimes Act 2018, as amended in 2025, distinguishes reading published information from touching somebody else’s system. Kenya has no responsible-disclosure safe harbour, and systems that may be designated critical information infrastructure — hospitals and payment systems among them — carry the heaviest penalties. Cold-probing a hospital to generate a sales lead is not a risk we are willing to take with somebody else’s licence to operate, or with our own.

[COUNSEL: verify the framing and the penalty figures before publication. We have deliberately not printed section numbers or shilling amounts in this document; please supply the ones you are willing to stand behind, or confirm that we should keep it general as it is here.]

6. How this is enforced, rather than promised

Three properties of the system, described so that you can hold us to them:

The intake record cannot represent anything else. A free snapshot request is written with a mode field that has exactly one permitted value, passive. Widening it is a visible database migration in a code review, not a configuration change or a checkbox.
The response we return to your browser states the ceiling. Every accepted request comes back with passive_only: true, the list of permitted sources, and the sentence we use to describe them. Those fields are typed so that no request field, no configuration value and no code path can emit a response saying anything different. If you keep that response, you have our contemporaneous statement of what we were permitted to do.
The person doing the work reads the same ceiling. The worksheet the operator works from restates the permitted list and the customer-facing wording, so the human running the checks reads what they may run before they run it.

7. What you can verify for yourself

You do not have to take our word for any of this:

Your own DNS logs. If you run your authoritative name servers, our queries appear there as ordinary lookups of your public records. Nothing else of ours will appear anywhere — no web request in your access logs, no connection in your firewall logs.
The certificate transparency logs are public. Search them yourself for your own domain. Anything we report from that source, you can see too.
The registry entry is public. So is your DNS. Every fact in a free report is a fact any stranger could have looked up. That is the entire point of the exercise: we are showing you the view that is already available to everybody, including to people who do not mean you well.
Ask us for the raw evidence. Every finding in a report is traceable to the record that produced it, and we will show you.

8. The password check, and why it is safe

The site offers an optional check of whether a password has appeared in a known public breach. It is the one part of the site that touches a secret, so here is exactly what happens.

In your browser, and only in your browser:

You type a password into the box. It stays in the page. Nothing is submitted.
Your browser computes a SHA-1 fingerprint of it using the browser’s own cryptography, not ours.
The page takes the first five characters of that 40-character fingerprint. The remaining 35 characters never leave your device, and neither does the password.

On the wire, from your browser, not from us:

Your browser asks a public breach index — Have I Been Pwned, at api.pwnedpasswords.com — for every leaked fingerprint beginning with those five characters. There are just over a million possible five-character prefixes, and any prefix matches hundreds of leaked passwords, so the request narrows you down to a very large crowd and no further.
The request is made with no cookies, no credentials, and no referring page. The page also asks the service to pad its reply to a uniform size, so the size of the response cannot be used to work out which prefix was asked for.

Back in your browser:

The page compares the returned list against the remaining 35 characters locally, and shows you the answer.

What that means in practice. The password never leaves your device. The full fingerprint never leaves your device. We see none of it — there is no page on our site that accepts a password and no field in our system that could store one. Have I Been Pwned sees your IP address and your browser’s user agent, exactly as any website you visit does, because your browser is talking to them directly. They do not see your password, your full fingerprint, your domain or your email address, and nothing connects their view of you to your request to us.

If you would rather that service saw nothing at all, do not run the check. Nothing else depends on it.

One deliberate limitation. Because the check happens on your device, whatever it tells us is something you told us, not something we observed. It is recorded in your report as a self-reported note, clearly labelled, and it does not affect your rating. That is the honest treatment of a fact we cannot verify.

9. How the findings are stored

What	How it is held
Your email address	Encrypted in the database, with the key held outside it. What the database row contains is an envelope. A separate keyed fingerprint of the address lets us recognise a repeat request without decrypting anything.
Your IP address	Never stored. A keyed one-way hash is stored instead — keyed, not plain, because a plain hash of an IP address can be reversed in seconds.
Secrets found in public sources	Removed automatically before storage, by software, not by a person remembering. Where a public source happens to contain a credential or a key, the stored record carries the redacted form and a receipt proving the redaction happened.
The evidence behind each finding	Kept so that a finding is reproducible from the record that produced it. Free-tier raw material is kept for 30 days; the report itself for 12 months. See `privacy-policy.md` section 7.
Logs	Built to refuse an email address, an IP address, or a user agent. The logging call raises an error rather than writing the line, so a mistake fails during testing instead of leaking quietly.
Access	Limited to the people doing the work.

10. What changes when you authorise more

Two genuinely useful checks are missing from the free snapshot on purpose: what your live website actually serves, and how your TLS is configured. Both require connecting to your systems.

They unlock in one of two ways:

You prove you control the domain — a DNS record, a file on your web server, or a code sent to an address such as admin@yourdomain.co.ke. About ten minutes. Those checks then run and are still free.
You sign a written authorisation for a paid engagement. That document is acceptable-use-and-authorisation.md: it names the hosts, the techniques, the time window and the person who can stop it.

Until one of those exists, the checks stay switched off.

11. If you would rather we never looked

Email {{CONTACT_EMAIL}} from an address at the domain, or tell us how else you can show you control it, and we will record it and decline future requests for that domain — including requests from somebody else claiming to be you.

Questions about anything in this note: {{CONTACT_EMAIL}} · {{PHONE}} {{LEGAL_ENTITY}}, {{POSTAL_ADDRESS}} · ODPC registration {{ODPC_NUMBER}}