Privacy Policy

This policy explains how Datalyst Africa ("we") handles personal data in the course of operating the Datalyst Africa audit preparation assistant. Our contact point for privacy questions is munyaradzi@datalystafrica.com, and our registered address is Corner Rotten Row & Pennefather Road, Harare City Library, Harare, Zimbabwe. We do not currently have a dedicated Data Protection Officer — a business of our size and processing scope is not required to appoint one under Zimbabwean law. Direct any data protection query to the email above.

This distinction matters, because our obligations differ in each case:

• Our customers (the organisations that buy the platform) — for their own account data we are the controller. This policy describes what we do with it.
• The people who use an assistant for a customer's audit — that customer's staff and their external auditors. For the engagements, requests, evidence and conversations in an organisation's account we are a processor acting on that organisation's instructions. The organisation decides what is collected and why, and its own privacy notice governs it.

If you are an employee or an auditor and want your data removed or corrected, contact the organisation that invited you. They can action it themselves in their dashboard, and we support them doing so. An organisation may be legally required to keep audit records, so some erasure is a decision for them rather than an automatic one.

• Account data: name, email address, hashed password, role, and an optional phone number for alerts.
• Organisation data: your name, plan, billing state, and branding you upload.
• Content you supply: policies, control summaries, request lists, documents and FAQs you add to the knowledge base, and the instructions you give your assistant.
• Configuration: the tools, channels and integrations you connect. Credentials for those are encrypted at rest and never shown back to you or anyone else.
• Usage and billing records: request counts, token volumes, cost estimates, payment references and invoices.
• Audit records: who did what in your account, including anything our setup staff did on your behalf.
• Support correspondence: tickets you raise with us and our replies.

To operate the assistant we store, on behalf of the organisation that deployed it:

• The people on each engagement: name, email address, organisation and role. Email addresses are what people verify with; a six-digit code is sent to the address held on file.
• Requests and their status, comments (with whether the external auditors may see them), checklist items and walkthrough preparation.
• Evidence files exactly as supplied, with who supplied them, when, a fingerprint (SHA-256) and a classification. Evidence may contain financial, payroll, bank or other personal information that the organisation chooses to supply. It is stored privately and reached only through short-lived, access-checked links.
• Imported trial-balance figures the assistant may quote with their source and date.
• The conversation itself — the messages exchanged and metadata such as outcome and sentiment trend.
• Restricted integrity cases, kept separately and visible only to the people the organisation designates.
• A durable identifier for a returning person, stored as a one-way hash rather than as a raw email address or cookie value.

The assistant is designed not to present something as a fact the person stated unless they actually stated it, not to claim an action succeeded unless it was confirmed, and never to quote a figure that is not in a stored dataset.

• To provide the service — tracking requests, collecting and indexing evidence, answering questions and sending reminders.
• To bill accurately, and to show usage against a plan allowance.
• To keep the platform secure, including detecting attempts to manipulate the assistant's instructions.
• To support you, investigate faults, and improve reliability.
• To meet legal and accounting obligations.

Where the law requires a lawful basis, ours is performance of our contract with you, our legitimate interest in operating and securing the platform, and compliance with legal obligations. Your own basis for the data of your staff and auditors is yours to determine.

To generate a reply, the relevant conversation content and the retrieved extract of your knowledge base are sent to a third-party AI provider. We route across more than one provider for reliability. These providers process the content to return a response and are contractually restricted from using it to train their models.

Evidence files are not sent to AI providers for analysis. Restricted material is never typed into the conversation, so it is not part of what is sent. We do not use your content, or your people's conversations, to train general-purpose AI models.

We share data only with service providers that make the platform work:

• AI model providers, to generate replies.
• Cloud hosting, database and file-storage providers, to run and store the service.
• Our payment provider, to take payment. We never see or store your full card details.
• Email and SMS providers, to send the notifications you have enabled.
• Error monitoring, to detect faults.

Our current sub-processors:

• Railway Corporation — application, database and cache hosting for the API, background workers and dashboard (European Union region).
• Cloudflare, Inc. — private evidence and document storage (R2), and bot-verification on our sign-in forms (global network, United States-headquartered).
• Google LLC — email delivery for sign-in codes, upload links and alerts through Gmail; "Sign in with Google"; and, where a customer connects it, Google Calendar (United States).
• Anthropic PBC, OpenAI, L.L.C. and Google LLC — AI model providers used to generate assistant replies (United States).
• Functional Software, Inc. (Sentry) — error monitoring; we configure it to exclude personal content (United States).
• Paynow (Zimbabwe) — payment processing, only for customers on a paid plan (Zimbabwe).

We do not sell personal data, and we do not share it for advertising.

The application and database run in a European Union region; stored files and some providers listed above operate from other regions, including the United States. If you have a regulatory requirement for data to stay in a particular region, tell us before you go live — we record that requirement against your account, but you should not assume data is physically relocated unless we have confirmed that in writing.

Where data crosses a border, we rely on the standard contractual data-processing safeguards each provider listed above already has in place, rather than a bespoke agreement of our own.

• Each organisation's data is isolated at the database level, not only by application code, so one organisation cannot read another's. Within an organisation, access is checked per engagement on every request.
• External auditors can reach only the engagements they were invited to and only the evidence that was explicitly shared with them. Removing them takes effect immediately.
• Evidence is append-only: files are never overwritten, a retraction keeps the file and records why, and every read of restricted evidence is logged.
• Credentials and channel access tokens are encrypted at rest.
• Passwords are stored only as salted hashes.
• Access to production data is limited to staff who need it, and staff actions inside a customer's account are logged and attributable. Our setup staff do not read restricted cases or restricted evidence by default.
• Traffic is encrypted in transit.

No system is perfectly secure. If a breach affects your data we will notify you without undue delay, and regulators where required.

Conversation and memory data is kept for the retention period configured on your account, then deleted automatically. The default is 365 days. An engagement can carry its own retention rule, and an organisation can erase an engagement and its evidence on request.

Account, billing and audit records are kept for as long as you are a customer and then for as long as we are legally required to keep them — typically 6 years for accounting records, in line with Zimbabwean tax record-keeping requirements. Audit logs are kept deliberately, because they are the record of who changed what.

Depending on where you are, you may have the right to access, correct, export, or delete your personal data, to object to or restrict processing, and to complain to a regulator. To exercise any of these, contact munyaradzi@datalystafrica.com. We will respond within 30 days.

If you are a member of the public who has chatted with one of these assistants, our data deletion page explains what is held about you and how to have it erased.

The regulator for our jurisdiction is the Postal and Telecommunications Regulatory Authority of Zimbabwe (POTRAZ), the Data Protection Authority under Zimbabwe's Cyber and Data Protection Act.

The dashboard stores a session token in your browser so you stay signed in, and remembers small interface preferences. The chat widget stores an identifier so a returning visitor's conversation can continue. We do not use advertising or cross-site tracking cookies.

The platform is sold to organisations and is not intended for children. We do not knowingly collect data from children.

If we change this policy in a way that materially affects how we handle your data, we will tell you before it takes effect. The date at the top always reflects the current version.