Our security

All data transfers are TLS-encrypted (at least TLS 1.2, preferably TLS 1.3) between browser, application, database and transcription engine. HSTS is active on all public endpoints; HTTP requests are redirected to HTTPS and cipher suites are configured according to the Mozilla "Modern" profile.

Data is encrypted at rest: backups are secured with AES-256 and database volumes are fully disk-encrypted. Passwords are stored exclusively with bcrypt (cost ≥ 10). API keys are stored hashed and shown in plaintext only once, at creation.

Administrative access to production systems runs exclusively over SSH with asymmetric key authentication – password login is disabled. All staff accounts on platform and cloud consoles are protected by TOTP-based two-factor authentication.

• Role-based access control (RBAC) following the least-privilege principle
• Quarterly review of all access permissions
• Full audit log of all administrative access (who, when, what, from where)
• In normal operation, Aliru staff have no read access to transcription content
• On the customer side: optional TOTP 2FA, backup codes, a separate audit log per account

Each workspace (internally a "Directory") is logically separated from all others via a UUID. Every database query checks the Directory context of the current request – cross-tenant read access is technically impossible, because the application layer never allows an unchecked query against the database. Backups, audit logs and caches follow the same separation.

• Daily automated backups; rolling 14-day retention
• Backups encrypted (AES-256) and held on separate hardware in a second data centre
• Documented restore tests every six months
• RTO (Recovery Time Objective): 4 hours in the event of total failure
• RPO (Recovery Point Objective): a maximum of 24 hours of data loss
• Status page at deepscript.com/status with minute-level probing and a 90-day incident history

We operate a documented incident-response process with a clear escalation chain: detection → containment → analysis → remediation → customer notification → post-mortem.

• Notification of data breaches to customers within 24 hours of becoming aware
• Content of the notification: nature of the breach, categories and approximate number of affected records, measures taken, point of contact
• Reporting to the authority under art. 33 GDPR (72-hour deadline) is the controller's responsibility – we support with all necessary information
• A post-mortem for every incident with root-cause analysis and measures to prevent recurrence

Each year we engage an independent external security provider to run a penetration test against the web application and the public REST API. Findings are prioritised by risk weighting; critical findings are resolved within 14 days. We make an executive summary available to business customers on request under NDA.

Internally, we carry out a quarterly TOM effectiveness review – the current version is documented in Annex 1 of the data processing agreement.

• Mandatory code review for all changes to production code
• Dependency scanning on every build (pnpm audit) – no known critical CVEs in production
• Automated CI with type checking, unit tests and E2E tests before every deployment
• Strict separation of development, staging and production environments – no real data in non-production systems
• Secrets in production configurations via encrypted environment variables; no secrets in the code repository

Our speech-to-text engine falls under the "limited risk" category of the EU AI Regulation (Regulation (EU) 2024/1689). There is no biometric identification, no social scoring and no automated decision with legal effect. Details are set out in the AI compliance statement (Annex 4 to the DPA).

• All staff bound to confidentiality under art. 28(3)(b) GDPR
• Mandatory annual training on data protection and information security
• Onboarding training for every new staff member with access to production systems
• Off-boarding process with immediate revocation of all access at the end of employment