Security and incident response — summary
Version: 2026-10-31-draft · Date:
DRAFT — must be reviewed by a lawyer before it binds anyone (Law of the Republic of Uzbekistan “On Personal Data”). Text in [square brackets] is a placeholder.
What this is
A description of how we protect the service and handle incidents. It is our policy, not a guarantee that no incident can happen.
Protection
TLS everywhere with HSTS; secrets, tokens and the anonymisation map encrypted at rest (AES-256-GCM); passwords hashed with Argon2id; two-factor sign-in, required for platform administrators; per-company separation with PostgreSQL row-level security; least-privilege database roles; rate limits; uploads size-capped and parsed in an isolated worker; strict browser security headers; pseudonymisation before every AI call; an append-only audit log.
Detection
Security events go to the audit log; errors and unusual activity are monitored; dependencies and the code are scanned for known vulnerabilities and leaked secrets on every change.
Response
When an incident is suspected we contain it, assess what was affected, remove the cause, restore the service and review what to change so it does not happen again.
Notification
If a confirmed incident affects your personal data, we notify you without undue delay, aiming to do so within [BREACH NOTICE HOURS] hours of confirmation, and inform the competent authorities as the law of the Republic of Uzbekistan requires.
Reporting a vulnerability
Write to [SECURITY EMAIL]. Test only against your own account and data, never other customers’; we will not take legal action against good-faith reports that follow these rules.