Privacy Policy — Reconesys

Document id: privacy Draft version: privacy.draft-0 Published version string: [COUNSEL: set on sign-off — stored against every customer's consent record and served by GET /v1/public/meta. Once published, a version string may never be reused for different wording.] Effective from: [COUNSEL: set on sign-off] Applies to: the website at {{SITE_ORIGIN}}, the free exposure snapshot, and the reports and correspondence that follow from it.

The short version

This table is a summary, not the policy. The numbered sections below are what governs. If the two ever disagree, the numbered sections win and this table is wrong and must be corrected.

Question	Answer
Who holds my data?	{{LEGAL_ENTITY}}, trading as Reconesys, a Kenyan company. We are the data controller.
What do you take from the form?	Your domain, your work email address, and optionally your business name and sector.
What do you take that I did not type?	A keyed hash of the IP address your browser connected from — never the address itself — and your browser’s user agent string.
Do you get my password?	No. The password check runs inside your browser. There is no page on this site that accepts a password, and there is no field in our system that could hold one.
Do you use cookies?	No cookies at all. No analytics, no advertising pixel, no session recorder, no A/B tool. One item is stored in your browser to remember whether you chose the light or dark theme, and it never leaves your device.
Who else sees my data?	Nobody, other than our own staff and the small number of suppliers listed in section 8. We do not sell, rent or share your data for anybody else’s marketing, ever.
Does my data leave Kenya?	`[COUNSEL: answer once hosting is decided — see section 9. This row must be filled in truthfully before publication.]`
How long do you keep it?	See section 7. In short: your contact record until 24 months after we last hear from you; the report and its evidence for 12 months; the record of what you consented to for longer, because it is the proof that you asked us.
Can I get it deleted?	Yes. Email {{CONTACT_EMAIL}} and we will do it, normally within 30 days.
Who do I complain to?	Us first, at {{CONTACT_EMAIL}}. Then the Office of the Data Protection Commissioner — section 12 has their details.

1. Who we are

{{LEGAL_ENTITY}}, trading as Reconesys, of {{POSTAL_ADDRESS}}, Kenya.

Email: {{CONTACT_EMAIL}}
Telephone: {{PHONE}}
ODPC registration: {{ODPC_NUMBER}}
Website: {{SITE_ORIGIN}}

We are the data controller for the personal data described in this policy. That means we decide what is collected and why, and we are answerable for it.

[COUNSEL: confirm whether we are required to appoint a Data Protection Officer under section 24 of the Act and the associated regulations, given our size and the sectors we serve (health and hospitality). If we are, this section must name the DPO and give a direct contact route. If we are not, advise whether we should appoint one voluntarily and say so here — we think it is a trust signal worth having, and hospital IT managers will look for it.]

[COUNSEL: until the ODPC certificate is issued, {{ODPC_NUMBER}} must not be rendered as a number. No wording anywhere may state or imply that our registration is complete before it is.]

2. What this policy covers

This policy covers the personal data we handle when you:

visit {{SITE_ORIGIN}};
submit the intake form to request a free exposure snapshot;
receive a report from us, or correspond with us about one; or
buy a paid service from us.

It also explains, in section 6, what we do about personal data that appears in public records we read about a domain — which may include data about people who never contacted us at all.

3. What personal data we collect

3.1 What you type into the form

Data	Required	What it is for
Domain name	Yes	The subject of the report. It is normally a business identifier rather than personal data, but where a domain is a person’s own name we treat it as personal data.
Work email address	Yes	Where the report goes, and how we answer you.
Business name	No	To put on the report cover. See the note below.
Sector	No	To prepare a report that makes sense for your kind of business, and so that we know which sectors are asking.
Country	Defaulted to Kenya	Context for the report.
Report language	Defaulted to English	English or Kiswahili.

Open item, stated because a privacy notice that overstates is as bad as one that understates. At the time of writing, the optional business name is accepted by our intake system and then discarded — it is not written to our records and is not passed to the person who prepares your report. Either we start keeping it (and this table says so) or we stop asking for it. The engineering decision is tracked as an open item and must be resolved before publication. [COUNSEL: note that we will correct this row rather than publish an inaccurate one.]

3.2 What your browser sends, which we keep

Every browser tells every website these two things. We keep them, in the following form:

Data	What we actually store	Why
The IP address you connected from	A keyed hash, never the address. The address is put through a keyed one-way function on arrival and only the result is written down. The address itself is never stored, never logged, and never included in anything sent to a person.	It lets us tell that two requests came from the same source, so we can spot abuse and stop one source flooding the free tier. It does not let us, or anybody who obtained our database, work backwards to the address.
Your browser’s user agent string	Stored as your browser sent it.	It lets us tell a flood of identical automated submissions apart from real people.

Why a keyed hash and not just a hash. A plain hash of an IP address is reversible in seconds on an ordinary laptop, because there are only about four billion of them. Ours uses a secret key held separately from the database, so the stored value is not reversible by anybody who obtains the database alone. [COUNSEL: confirm that this description is accurate enough for a regulator, and whether a keyed hash of an IP address remains "personal data" under the Act — we assume it does, and we treat it as such throughout, which is the conservative position.]

3.3 The record of what you agreed to

For each of the five statements on the intake form, we store:

whether you agreed to it;
the exact time you agreed; and
the version identifier of the exact wording you were shown, so that we can reproduce the sentence you actually agreed to, years later.

We also store which version of our Terms of Service and of this Privacy Policy were in force when you submitted.

Two of those statements carry legal weight rather than product meaning: that you are authorised to request an assessment of the domain, and that you understand this is not a penetration test. If we are ever asked who authorised an assessment, that record is the entire answer, which is why it exists and why it is kept carefully.

3.4 The rest of the record

A reference number for your request, and the times it was created and acted on.
The status of your request as we work through it.
What we found about your domain, and the report we wrote.
Emails between us, in our mailbox, if you write to us.

3.5 What we do not collect

Stated as plainly as we can:

We never collect your password. The password check on the site runs entirely inside your browser. The password never leaves your device and neither does the full fingerprint of it. There is no page on this site that asks you to send us a password, and there is no field in our system that could store one. See data-processing-note.md for exactly how the check works, and section 8 for what the third-party breach index can see.
We never store your IP address. Only the keyed hash described above.
We set no cookies, and we load no analytics, advertising, session-recording or A/B-testing tool. See cookie-and-consent-note.md.
We do not collect special categories of personal data — health, biometric, genetic, sex life, race, ethnicity, political opinion, religion, or trade-union membership — and we ask you not to send them to us. If you write to us about a patient, a guest or an employee, please describe the situation without identifying them.
We do not buy contact lists, and we do not enrich what you give us with data bought from anybody else.

4. Where the data comes from

Almost all of it comes from you, directly. The two exceptions are the two items in section 3.2, which come from your browser as a normal part of connecting to any website, and the material in section 6, which comes from public records.

5. Why we use it, and our lawful basis for each purpose

Under section 30 of the Data Protection Act 2019, we must have a lawful basis for each purpose. Here they are, one per row. [COUNSEL: verify the section reference and that each basis below is the right one — in particular rows 3 and 4, where we have chosen legitimate interests over consent, and row 6, where the Act's treatment of "commercial use of personal data" under section 37 may require consent for anything beyond the delivery of the thing asked for.]

#	What we do	Personal data used	Lawful basis	Notes
1	Prepare and send you the report you asked for	Email, domain, business name, sector, language	Your consent (`service_delivery`), and performance of a contract at your request	You give this consent by ticking the first box. Without it we cannot send you anything.
2	Answer you when you write to us about your report	Email, reference number, correspondence	Performance of a contract, and our legitimate interests in running a service people can ask questions about
3	Stop abuse of the free tier: flooding, automated submissions, repeated requests for the same domain	Keyed hash of source IP, user agent, domain, timestamps	Our legitimate interests in keeping a free, unauthenticated service available and in not being used to generate reports about third parties	We minimise this deliberately: a hash rather than an address, and a network prefix rather than a device for the rate counters.
4	Keep a record of the authorisation you gave us, and of the consents you gave	Consent record, wording versions, timestamps, email hash	Compliance with a legal obligation (we must be able to demonstrate consent), and our legitimate interests in being able to show who authorised an assessment	This is the record that answers “who told you that you could look at this domain”.
5	Keep the report and the evidence behind it, so we can answer questions about it later and so you can rely on it	Domain, findings, report, reference	Performance of a contract, and our legitimate interests in standing behind our own work	See section 7 for how long.
6	Send you occasional practical guidance on data protection and security in Kenya	Email	Your consent (`marketing_contact`), given separately and unticked by default	You can withdraw it in one click on any such email, or by emailing us. Withdrawing it does not affect anything else.
7	Refer to your business as a case study	Business name, and whatever we agree with you	Your consent (`case_study_use`), given separately and unticked by default	This consent is only permission for us to ask. We will not publish anything about you without agreeing the specific words with you first.
8	Meet our own legal, tax and regulatory obligations, and establish or defend legal claims	Whatever is relevant	Compliance with a legal obligation, and our legitimate interests

We do not make automated decisions about you. Every report is written and reviewed by a person before it is sent. Nothing about you is decided by software alone.

[COUNSEL: confirm that this statement satisfies section 39 of the Act on automated individual decision-making, and that our rate limiter — which can refuse a submission automatically — does not count as a decision producing legal effects. Our view is that refusing an anonymous free-tier form submission with a "try again later" message does not, but we would rather you said so.]

6. Personal data in the public records we read

When we look at a domain, we read public records. Some of those records can contain personal data about somebody — most often the contact details a registry publishes for whoever registered the domain, and occasionally a name inside a certificate entry.

What we do about that:

We read those records only for the domain named in the request, and only to prepare the report for that domain.
Secrets and credentials found in public sources are removed automatically before anything is stored, by software rather than by a person remembering to do it.
We do not build a database of individuals, we do not combine records across domains to profile anybody, and we do not sell or publish any of it.
If you are named in a record we read and you want to know what we hold, or want it deleted, email {{CONTACT_EMAIL}}. You have the same rights as anybody else in this policy, and you do not have to be our customer to use them.

[COUNSEL: this is the weakest part of the draft and needs your view. Reading a public registry entry that contains a registrant's name is a collection of personal data from a source other than the data subject. Please advise (a) which lawful basis applies — we assume legitimate interests; (b) whether the Act requires us to notify that person, and if so within what period and whether any exemption applies where notification would be disproportionate; and (c) whether the answer changes when the registrant is the customer who asked us, which is the usual case.]

7. How long we keep it

[COUNSEL: every period in this table needs your confirmation. We have proposed each one and given the reasoning. Where a statutory minimum applies, tell us and we will lengthen it; where a period is longer than we can justify, tell us and we will shorten it.]

What	Proposed period	Reasoning
Your contact record: email address (encrypted), domain, sector, reference, status, timestamps	24 months from the later of your last request and our last contact with you, then erased	Long enough to recognise a returning customer and answer a question about an old report; short enough that we are not sitting on a list of businesses that stopped talking to us years ago.
The keyed hash of your source IP address, and your user agent	With the contact record above, then erased	It exists to spot abuse against the record it sits on; separating its lifetime from that record’s would serve no purpose.
The record of what you consented to and attested	`[COUNSEL: set — we propose 6 years]` from the date of the request	It is the evidence that you authorised the assessment. We propose the limitation period for a contract claim in Kenya, so that we can still answer the question for as long as somebody could still ask it.
The report we sent you, and the findings behind it	12 months	Long enough to answer “what did you say in March, and has it changed”; short enough that we are not indefinitely holding a description of somebody’s weaknesses.
The raw material behind a free report (record extracts we captured)	30 days	We need it while the report is being written and briefly afterwards. After that the report itself is the record.
Server logs	30 days	Operational. Our logs are built so that an email address, an IP address, or a user agent cannot be written into them; the software refuses the log line rather than writing it.
The operator worksheet a lead is written into (see section 8)	`[COUNSEL: set — we propose 30 days]` from the date the report is delivered	This is the one place a plaintext email address is written to disk at launch, because a person has to reply to it. It should not outlive its purpose.
Rate-limit counters	Up to 24 hours	Held in memory against a keyed hash of a network prefix, and discarded when the counting window closes.
Accounting and tax records for paid work	`[COUNSEL: set — we understand the Tax Procedures Act requires 5 years]`	Statutory.

How deletion actually happens, stated honestly. At launch we are a small team running a deliberately simple service, and these periods are applied by a person on a scheduled review, not by an automated deletion job. The automated lifecycle described in our internal specifications is not part of the launch service. We would rather tell you that than imply a machine is doing it.

[COUNSEL: advise whether stating this is wise or unwise. Our instinct is that it is honest and defensible — the obligation is to erase, not to erase by any particular mechanism — but if a manual process is a compliance weakness in your view, say so and we will build the job before launch.]

8. Who else sees your data

We do not sell your data, we do not rent it, and we do not share it with anybody for their own marketing. Ever.

These are the only other parties involved:

Who	What they get	Why	Status
Our own staff and contractors	Everything needed to prepare and send your report	A person prepares every report	Bound by confidentiality; access limited to those doing the work
Our hosting and infrastructure provider	Whatever sits in our database and on our servers	We have to run the service somewhere	`[COUNSEL: name the provider and its location once hosting is decided. This row cannot be published empty.]`
Our email provider	Your email address, and the report we send you	To send you the report and to answer you	`[COUNSEL: name the provider and its location. At launch, a person sends the report from an ordinary mailbox; that mailbox provider is a recipient of your data and must be named.]`
Have I Been Pwned (`api.pwnedpasswords.com`), operated by a third party	Not your data from us. If, and only if, you choose to run the password check, your browser contacts them directly. They see your IP address and your user agent, exactly as any website you visit does. They never see your password, the full fingerprint of it, your domain or your email address, and nothing links their view of you to anything you submitted to us.	The public breach index the check compares against	Named here and on the page itself, because you cannot consent to a third party you were not told about
Professional advisers, and authorities	Only what is legally required	Legal obligation, or establishing or defending a claim

The operator worksheet. At launch, when you submit the form, your request is written as a line in a working file that the person handling requests reads. That file contains your email address in readable form, because a human has to reply to it. It is stored so that only that account can read it, it is never served over the web, and nothing else in our system writes an email address to disk. It is mentioned here because a privacy notice that describes an encrypted database and omits the working file is not describing what happens.

[COUNSEL: confirm that each of these must be named as a processor or recipient, whether a written processing agreement is required with each under section 42 of the Act, and whether Have I Been Pwned should be described as a recipient at all given that we never transmit anything to them — our view is that it is not a disclosure by us, but that we must disclose the fact of it, which is what this row does.]

9. Whether your data leaves Kenya

[COUNSEL: this section cannot be published until hosting is decided, and it must then be answered truthfully. The Act restricts transfers of personal data outside Kenya — we understand sections 48 and 49 to be the operative ones — and requires either an appropriate safeguard, or a specific condition, or the data subject's consent after being informed of the risks. Please confirm the sections, the permitted grounds, and what we must publish here.]

Our intention is to host in Kenya where we reasonably can. Where a supplier is outside Kenya, we will say so in the table in section 8 and set out the basis for the transfer here.

One transfer happens without us: if you run the password check, your own browser contacts a service that is not in Kenya. That is your browser’s connection, not ours, we send nothing to it, and nothing about it is linked to your request. If you would rather that connection never happened, do not run the check — nothing else on the site depends on it.

10. How we protect it

Your email address is encrypted in our database, with a key held outside the database. What the database stores is an envelope, not an address. Separately, we store a keyed one-way fingerprint of the address so that we can recognise a repeat submission without decrypting anything.
Your IP address is never stored, in any form other than the keyed hash described in section 3.2.
Our logs are built to refuse an email address, an IP address, or a user agent. The software raises an error rather than writing the line, so a stray log statement fails in testing instead of quietly leaking for six months.
Secrets found in public sources are removed automatically before storage.
Access is limited to the people doing the work, and the working file described in section 8 is readable only by the account that owns it.
The website loads nothing from anybody else. No third-party script, no font from a content network, no tracking pixel. The only outbound request the page can make, other than to us, is the password check — and only if you run it.

No security is perfect, and we will not claim ours is. If a breach affects your personal data we will notify the ODPC within 72 hours where the law requires it, and we will tell you directly where the law requires that too, and in plain language.

[COUNSEL: verify the breach-notification duty and its triggers — we understand section 43 of the Act to require notification to the Commissioner within 72 hours where feasible, and notification to the data subject where the breach is likely to result in real risk of harm. Confirm the thresholds, the form of the notification, and whether the 72 hours runs from awareness.]

11. Your rights

Under the Data Protection Act 2019 you have the rights below. They are free to exercise, and we will not ask you why.

Right	What it means	How to use it
To be informed	To know what we hold and what we do with it	This document, and ask us anything not covered
Access	To get a copy of the personal data we hold about you	Email {{CONTACT_EMAIL}}
Correction	To have inaccurate or incomplete data corrected	Email {{CONTACT_EMAIL}}, telling us what is wrong
Deletion / erasure	To have your data deleted where we no longer have a good reason to keep it	Email {{CONTACT_EMAIL}}
Objection	To object to our processing, including processing based on our legitimate interests	Email {{CONTACT_EMAIL}}
Portability	To receive the data you gave us in a structured, commonly used, machine-readable form, or to have it sent to somebody else where that is technically feasible	Email {{CONTACT_EMAIL}}
To withdraw consent	To take back a consent you gave, at any time. Withdrawal does not undo what was lawfully done before it	One click on any guidance email, or email {{CONTACT_EMAIL}}
To complain	To complain to us, and to the Office of the Data Protection Commissioner	Section 12

[COUNSEL: verify this is the complete rights set under the Act — we understand it to be section 26, with procedures in the General Regulations 2021 — and correct any right we have described loosely.]

How we handle a request. Write to {{CONTACT_EMAIL}}. We will acknowledge it, and we will need to be reasonably sure you are who you say you are before we hand over or delete anything — usually by replying from the address we hold, which is normally enough. We aim to answer within 30 calendar days. If a request is unusually complex we will tell you, and say how long it will take.

[COUNSEL: confirm the statutory deadline for responding to an access or erasure request under the Act and the General Regulations. Our working default is 30 calendar days and we would rather publish the statutory figure than our guess at it.]

What we cannot delete. If you ask us to delete everything, we will — except where we must keep something to meet a legal obligation, or to defend a legal claim. In practice that means we may keep the record that you authorised an assessment, and any accounting record for work you paid for. We will tell you exactly what we kept and why.

Asking us never to assess your domain. You can ask us not to assess a domain, whether or not you have ever used the service. Email {{CONTACT_EMAIL}} from an address at that domain, or tell us how else you can show you control it, and we will record it and decline future requests for it.

12. Complaints

Please tell us first, at {{CONTACT_EMAIL}}. We would rather fix it than have you take it further, and we will answer.

You can also complain to the regulator at any time, and you do not have to come to us first:

Office of the Data Protection Commissioner (ODPC) [COUNSEL: insert the current official address, telephone, email and complaints portal URL, verified at the date of sign-off. We have deliberately not written them from memory — a wrong address for the regulator in a privacy policy is a real failure, not a typo.]

13. Children

Our services are for businesses. The site is not directed at children and we do not knowingly collect personal data from them. If you believe a child has given us personal data, tell us at {{CONTACT_EMAIL}} and we will delete it.

14. Changes to this policy

We may update this policy. When we do, we publish the new version at {{SITE_ORIGIN}} with a new version identifier and the date it takes effect. For a change that materially affects how we use data we already hold, we will tell you by email before it takes effect.

The version in force when you submitted a request is stored with your record, so both of us can look up which one applied.

Appendix A — Everything a request leaves behind

An exhaustive list, so that “we tell you what happens to each piece” is a checkable claim rather than a comforting one.

Item	Stored as	Section
Domain	As you typed it, canonicalised	3.1
Work email address	Encrypted, plus a keyed fingerprint used to recognise repeats	3.1, 10
Business name	Currently discarded on receipt — open item	3.1
Sector	Plain text, optional	3.1
Country, report language	Plain text	3.1
Source IP address	Keyed hash only. Never the address.	3.2
User agent	As sent	3.2
Five consent decisions	Each with its own timestamp and wording version	3.3
Terms and Privacy versions in force	Version strings	3.3
Reference number, status, timestamps	Plain	3.4
Findings and the report	Secrets removed automatically before storage	3.4, 6
Password	Never collected. No field exists that could hold one.	3.5

Build note, not for publication. This appendix is exhaustive against LeadRecord in apps/api/store.py and the worksheet line in apps/api/notify.py. If a field is added to either, it is added here in the same commit, or the claim of exhaustiveness becomes false. The previous version of the marketing copy failed exactly this way: it claimed to list everything and omitted the hashed source address and the user agent.