Security and encryption

Version 1.2 · Last updated: 2 November 2026

This note explains in plain words how SalamaTalk protects a report, who can read it, and what we do not claim. It is written for an organisation's security reviewer. It is not a substitute for an independent audit — see the last section.

This page describes what is protected, not how the software is built. Key-management internals, password-hashing parameters, rate-limit thresholds, backup handling and deployment mechanics are deliberately not published here, because a public page that lists them is a map for an attacker. A security reviewer at a prospective customer can request the technical specification under a confidentiality agreement at info@salamatalk.com, and we will answer any control question directly.

1. In transit

Every page and API call is served over TLS. A report, a reply and an evidence upload travel from the browser or app to the server encrypted in transit. No report content is sent by email.

2. At rest

Report text is encrypted before it is written to the database, using AES-256 authenticated encryption. The keys are held in the hosting provider's secret store — never in the source code, the repository or a configuration file on disk — and can be rotated without making older reports unreadable. Database backups are encrypted and expire after 14 days.

3. The Android app encrypts before sending

The SalamaTalk Android app encrypts report text on the phone before it is sent. The app is the only client that does this today.

4. The browser form does not

A report filed in a browser is protected in transit by TLS and encrypted at rest the moment it reaches the server. There is no client-side encryption in the browser. We say this plainly because some reporting vendors imply otherwise; if you need proof, test the network request.

5. Who can read a report

• The authorised HR and Executive logins of the organisation that received it, scoped to their own organisation. A branch sees its own tree only.
• SalamaTalk operations staff, where necessary to operate, secure or support the service. Each such access is logged.
• An AI provider, only when an AI reading is requested (a case brief, a plan, ask-the-record, a radar deep read or a translation). Decrypted report text is sent to the provider solely to produce that reading; reporter name and contact are not included. No AI message reaches a reporter without a human approving it.

This is not a zero-knowledge design. The platform holds the keys and can decrypt a report on demand for the purposes above. A design where even SalamaTalk cannot decrypt would also stop search, translation, the AI readings and most support.

6. What is not stored with a report

The report row has no column for an IP address, a hardware identifier, a browser fingerprint or a location. The public form does not require a name, email or phone; if a reporter chooses to enter contact details, they are stored with the report and shown to the organisation. An IP address is used in memory to rate limit abuse and appears in standard hosting access logs for operations, but it is never written to the report row or joined to a report.

One exception, on the Android app: each install keeps a random code on the device so the app can list the reports it filed and receive their updates. That code is written to the report row, but it is not derived from the phone's hardware, it is not shown to the organisation, and a report filed in a browser carries no such code.

7. Evidence files

Photos are re-encoded, which removes EXIF and GPS data. PDF and Office documents have their metadata containers blanked. Audio and video are not metadata-scrubbed — if a clip carries location data, that data travels with the file, so a reporter should not attach a raw clip from a phone camera if that matters. Evidence is stored with our object-storage provider and served only through a proxy under our control; direct storage links are never handed to a browser.

8. Audit trail

Staff actions on a case — views, replies, status changes, assignments, exports — are written to an append-only log in which each entry is chained to the entry before it, so a record cannot be altered or removed without breaking the chain. The chain is checked platform-wide rather than organisation by organisation, so a broken entry is detected rather than hidden.

9. Retention and deletion

Reports are kept for the retention window of the organisation's plan. An organisation's owner can schedule deletion of the whole organisation, with a seven-day grace period and a logged, irreversible purge.

10. Who processes our data

SalamaTalk runs on a small number of named providers, listed here with the region each one operates in. Every one of them acts on our instructions and is bound by a data-processing agreement. We do not add a processor without updating this list, and the date at the top of the page is the date that promise was last checked.

• Supabase — hosted PostgreSQL, AWS EU-West-1.
• Render — application hosting, United States.
• Cloudflare R2 — evidence files.
• Brevo — transactional email, EU.
• Google, Groq and OpenRouter — AI drafting, United States, only when an AI reading is used.
• Safaricom M-Pesa — subscription payments, Kenya.
• Browser push services — Google, Mozilla and Apple, only where a browser has opted in to notifications.

11. Account protection and access control

• Passwords are stored only as one-way hashes produced by a deliberately expensive algorithm, never in plain text. Verifying a password costs enough that a flood of sign-in attempts is refused outright rather than queued, so a login burst cannot slow the site down for everybody else.
• Sign-in, password reset, filing and status checks each have their own sliding-window limit, and repeated failures lock an account out temporarily with a stated retry time.
• Staff and platform logins can enable time-based two-factor (TOTP); a password then only starts the sign-in.
• Sessions are scoped to one organisation. A branch login sees its own branch tree, never the parent's other branches. An officer cannot be assigned a case where the system blocks a conflict of interest.
• Password reset links are single use and expire in ten minutes.
• Every staff view, reply, status change, assignment and export is recorded in the audit chain described above, with the account that did it.

12. Operational controls

• Service credentials are held in the hosting provider's secret store and are never committed to the source repository. Storage access is limited to the objects the application needs; it is not an account-wide key.
• The site does not permit other websites to read it through a visitor's browser.
• Where evidence must be handed to a browser directly, it goes as a signed link for one object that expires shortly after it is issued.
• Server failures are shown as a plain branded page, never as internal error detail, and the operator is alerted when failures rise above a normal level.
• Uploads are checked for size and type before they are accepted.

13. Backups and recoverability

The database is backed up every night as a full copy, kept for fourteen days, with an additional off-site copy. A backup does not carry service credentials, so a stolen backup file is not a second set of our keys. Recovery is rehearsed, not assumed: restores are run against a throwaway database and compared row by row before a change is trusted.

14. Secure development and change control

• Every change is checked automatically before it can be deployed, including a standing audit that each organisation's data stays scoped to that organisation.
• Capacity and security changes are verified on a local copy of the application running against a restored copy of the production database, never against live data, and no test ever files a real report.
• Deployment is atomic and a rollback is a redeploy of the previous version, normally complete within minutes.
• After each deploy we confirm that the running service reports itself as the new version, so "deployed" means live, not queued.

15. What we do not claim

• We are not zero-knowledge, and we do not claim end-to-end encryption in the browser.
• We have not yet completed an independent cryptographic audit or a third-party penetration test. When one is completed, its summary and scope will be published on this page.
• We do not hold SOC 2 or ISO 27001 certification. We do not claim them.
• No system can protect a report from a compromised phone, a keylogger or an employer-controlled network. Anonymity is a design property, not an absolute guarantee.

16. Reporting a vulnerability

Email info@salamatalk.com with enough detail to reproduce the issue. You may also use /.well-known/security.txt, which lists the same contact mechanically.

In scope: salamatalk.com, its API and the SalamaTalk Android app. Out of scope: denial-of-service attempts, spam, physical attacks, social engineering against staff or reporters, and third-party services we do not operate.

What we ask of you: report the first working indication of a weakness and stop there. Do not access, download or disclose a real organisation's reports or a real reporter's data, do not scan or attack other customers, and do not include credentials or live report content in your write-up. Testing against our own demonstration organisation is fine.

What you get from us: an acknowledgement within 24 hours - we staff the desk around the clock - a plain-language answer on whether we consider it a vulnerability, a fix targeted at a severity-appropriate timeline, and credit by name if you want it. Safe harbour: if you followed the rules above, acted in good faith and did not expose anyone's data, we will not pursue or report you for research into our own service.

17. If we have an incident

If we confirm that data on this platform was accessed or disclosed without authorisation, we notify the affected organisation's administrator without undue delay and no later than 72 hours after we confirm it, saying what was involved and what we have done. Where a reporter's own contact detail was part of what leaked, we contact that reporter through the thread on their case. We do not notify by reading the audit chain alone: the notification names what was exposed, not just that something happened.