Security

Clear controls. Honest boundaries.

These statements are limited to capabilities visible in the current application and database migration files.

Access control

The staged database migrations define organization and clinic isolation, role permissions, patient assignment checks, protected psychotherapy access, and Row Level Security with anonymous table access denied. These protections depend on applying the numbered migrations and successfully completing isolated-project tests.

Authentication

Ayada uses Supabase Auth with email and password and optional Google sign-in. Password handling is delegated to Supabase Auth. Authenticator-app MFA is available, and privileged or sensitive database operations require the configured assurance level. Do not share account credentials.

Encryption in transit and at rest

The production website and configured Supabase endpoint use HTTPS, providing encryption in transit for those connections. The repository does not independently verify provider encryption-at-rest settings, and Ayada does not claim end-to-end encryption. New clinical offline storage is disabled because managed device-key encryption is not implemented.

Activity and audit logging

The application and staged migrations write selected events for record access and changes, roles, assignments, payments, reminders, exports, lifecycle actions, and subscription administration. Audit payloads are designed to avoid unnecessary psychotherapy content. The repository does not establish an immutable log, a legally approved retention period, continuous security monitoring, or external alerting.

Data storage and hosting

Authentication, database, and file-storage requests are configured for Supabase. The repository does not establish a formal data-residency commitment. The installable web app caches static interface files, while clinical records and new changes require an online connection. Older unsynchronized recovery items may remain temporarily until resolved.

Backups and recovery

Ayada has a documented database-and-Storage recovery runbook and a read-only restored-project verifier. Supabase database backups do not contain the actual Storage file bytes, so independent object backup is required. No successful isolated restoration is recorded yet; backup schedule, retention, RPO, and RTO remain unverified production controls.

Data retention and deletion

No universal retention duration is assumed. The staged governance controls record retention decisions, legal holds, and reviewed lifecycle requests without automatic deletion. Self-service account deletion is not enabled, and operational deletion timing remains subject to authorized and legal review.

Incident reporting

If you suspect unauthorized access, preserve relevant non-clinical details, change compromised credentials, enable MFA where available, and contact Ayada. Do not send patient records, passwords, or authentication codes in an initial report.

Subprocessors and external services

Services visible in the implementation are Supabase for authentication, database, and file storage; Google Fonts; and Google when optional authentication is selected. The repository does not contain a contractual subprocessor register, data-processing terms, or a complete infrastructure inventory.

Contacting Ayada about security

Use the Contact page or email support@ayada.online. Do not include clinical information in the first message.