Security
Version 2026-10-31
The technical and organizational measures ISSA uses to protect data, and how we respond to an incident.
1. Approach
We protect data with measures proportional to its risk, with special care for health data. This page describes what is implemented today.
2. Encryption
- In transit: every connection uses HTTPS (TLS).
- Clinical data: sensitive fields and files (photos, signatures, documents) are encrypted with AES-256-GCM and a key derived for each organization.
- Secrets: API keys, integration tokens and businesses’ own Anthropic keys are stored encrypted.
- Passwords: we only store their Argon2id hash. Open API keys are stored as hashes.
3. Isolation between organizations
Every query on an organization’s data goes through a client scoped to that organization and the database enforces row-level security, so one organization cannot read another’s data.
4. Access and authentication
- Second authentication factor (TOTP codes) available for every account.
- Least-privilege roles: owner, admin, agent and health professional; only clinical roles see records.
- Sessions in protected cookies (httpOnly, Secure, SameSite) that you can end at any time.
- Sign-in attempt limits and a bot check on the demo.
5. ISSA staff
ISSA staff access to customer data is exceptional, only for support you ask for or for security, under a duty of confidentiality, and it is logged.
6. Logs and audit
We log each organization’s relevant actions. Every view, print and export of a clinical record goes into a log that admins can see. Technical logs never hold passwords, tokens, secrets or the full text of messages.
7. Backups
Every day we back up the database and the files, encrypted with AES-256; clinical files, already encrypted, are encrypted again. They are kept for 14 days and tested with restores.
8. Development and operations
We review code and test it automatically before releasing it, keep dependencies up to date and never keep secrets in the repository or in images. Servers are at Hostinger (United States), behind Cloudflare’s network and attack protection.
9. Incident response
When an incident happens we contain it, assess its scope and fix the cause. If we confirm a breach affecting a customer’s personal data, we notify them without undue delay and within 48 hours at the latest, so they can meet their own deadlines: informing data subjects immediately in Mexico, notifying the ANPD within 3 business days in Brazil and the supervisory authority within 72 hours in the European Union and the United Kingdom. Where we are the controller, we make those notifications ourselves.
10. Your part
Security is shared: use unique passwords, turn on the second factor, remove access for people who leave your team, protect the phones linked to your channels and keep your API keys somewhere safe.
11. Reporting a vulnerability
If you find a vulnerability, write to [email protected] with the details and give us reasonable time to fix it before disclosing it. Do not access other people’s data or disrupt the service while investigating.