Security

Version 1.5 · Effective 2026-09-29

1. Security controls

This is the engineering reality of how we protect your data, written without marketing.

1.1 Encryption

• At rest, application layer: OAuth tokens and stored AI prompts and responses are encrypted in our database using authenticated AES-128 (Fernet specification: AES-128 in CBC mode with HMAC-SHA256 for integrity). Encryption keys are held in AWS Secrets Manager and delivered to our running services through IAM-scoped access.
• Health data: not in our database at all. Sleep and activity records are read and processed on your phone, and the reading the app builds is kept in your device's secure storage (iOS Keychain or Android Keystore-backed storage), tied to that device: not synced through iCloud Keychain and not restorable on another device (on Android the app's data is excluded from backups). No network request carries it and no server endpoint accepts it.
• At rest, infrastructure layer: AWS-managed disk-level AES-256 encryption is enabled on all production database volumes. A single-layer compromise (e.g. a backup leak) does not expose plaintext.
• In transit: All API traffic uses TLS 1.2 or higher with HSTS enforced. Our services connect to the database and the cache over TLS inside our virtual private cloud, and to the message queue (Amazon SQS) over TLS using IAM-authenticated requests.

1.2 Access control

• Our running services (the API, the worker and the scheduler) share a single IAM role scoped to the resources the services need. The role our deployment pipeline uses has broad administrative rights, because it creates and changes the infrastructure; it can be assumed only from our main code branch.
• We are a very small team. Access to production is limited to the two founders. There is no standing path for a person to query the production database: it accepts connections only from our application services inside the private network. Cloud API activity is recorded by AWS CloudTrail.
• The database uses a password held in AWS Secrets Manager. It is not rotated automatically today.
• Multi-factor authentication is used on the accounts that reach the AWS console and the codebase.

1.3 Authentication and session management

• JWT access tokens expire after 30 minutes.
• Refresh tokens are rotated on every use. Re-use of an already-rotated token revokes all of that account's sessions, on the assumption that re-use signals a stolen-token replay attempt. The one exception is a 60-second window after rotation, which exists so that a request repeated over a poor connection does not sign a user out. Revoking sessions stops new tokens from being issued; an access token that was already issued stays valid until it expires, at most 30 minutes later.
• All authentication events (login, sign-in-link request, token refresh, token revocation) are logged.

1.4 Logging and monitoring

• Changes to your health consent record (turning the source on or off) are logged with timestamp and operation type and kept for 7 years as evidence of the rights you exercised, like every other consent event. No health data passes through our systems, so there are no reads or writes of it to log. Routine audit entries in our database are retained for 90 days and authentication entries for 30 days, then deleted by a daily retention job. Server, load-balancer, firewall and database logs are retained for 30 days (see Privacy §4 for the full retention table).
• Crashes and errors in the mobile app are sent to our error-tracking provider (Sentry, EU region), scrubbed of personally identifying fields, and reviewed.
• Refresh-token re-use and failed sign-ins are logged. Service alarms (error rates, latency, queue failures, email delivery, spend) notify us. We do not currently run location-based or behavioural anomaly detection on sessions.

1.5 Backups and disaster recovery

• Daily encrypted database backups, retained for 7 days, then overwritten. If the database is ever decommissioned, our infrastructure takes a final snapshot that does not expire on its own; we delete it manually.
• We do not selectively restore individual rows from backup. Backups exist to recover the database after a disaster.
• When you delete your account or disconnect a data source, the deletion runs across our live systems immediately; backup copies are overwritten in the next 7-day rotation.

1.6 Network and infrastructure

• Production runs on AWS in eu-west-1 (Ireland). The database and cache are inside a private VPC with no public ingress. The message queue is Amazon SQS, reachable only with our services' IAM credentials.
• Public ingress passes through a web application firewall with managed rule sets and rate limits, and is DDoS-protected by AWS Shield Standard.
• Container images are scanned for known CVEs when they are pushed to our registry, and we review the findings. The scan result does not automatically block a deployment today.

2. Compliance

We are honest about what we have and what we do not have.

2.1 What we have

• GDPR Article 30 records of processing activities: maintained internally; available to a supervisory authority on request.
• GDPR Article 35 Data Protection Impact Assessment (DPIA): completed for the app's on-device processing of special-category data (health records read from Apple Health on iOS or Google Health Connect on Android) and for the AI analysis of connected-source data, reviewed at least annually.
• Data processing terms with our sub-processors. We hold signed data processing addenda with OpenAI and Sentry. For our other sub-processors, each provider's standard data processing terms, including Standard Contractual Clauses for any cross-border transfer (Article 46(2)(c) GDPR), apply to our accounts; where a separately signed addendum is available we are completing it, and we will not describe one as signed until it is.
• Data-protection contact: responsibility sits with our management; reach us at privacy@eltria.de. See the Privacy Policy contact section, which also explains our position on appointing a Data Protection Officer.
• Internal incident-response runbook with the GDPR Article 33 72-hour clock as the headline target.

2.2 What we do not have

• ISO 27001, ISO 27017, ISO 27701. We are not certified to any ISO information-security standard. Certifications are valuable signals but they are not a precondition for safe operation; we do not believe pursuing one before launch is the best use of pre-launch engineering time. We will reconsider as we scale.
• SOC 2. Not certified. Same reasoning.
• HITRUST or HIPAA attestation. Not pursued. We are not a HIPAA covered entity or business associate; we process consumer health data under the consumer-facing privacy regimes (MHMDA, Nevada CHDPA, GDPR) rather than under HIPAA.
• Bug bounty program. We do not currently run a paid bug bounty program. We invite responsible disclosure (see §3 below) and may launch a bounty post-launch.

We will update this section if any of the above changes. We commit not to claim certifications we do not hold.

3. Reporting a vulnerability

If you have found a vulnerability in the Service, we want to hear from you. Please email security@eltria.de with:

• A description of the vulnerability and how to reproduce it
• The version of the Service (mobile app version or API endpoint) where you observed it
• Any relevant screenshots, logs, or proof-of-concept code

3.1 Responsible disclosure

We ask that you:

• Give us a reasonable opportunity to investigate and remediate before any public disclosure (typically 90 days, longer if needed for a complex fix)
• Do not access, modify, or download data belonging to other users
• Do not perform denial-of-service testing or run automated scanners against production infrastructure
• Do not exploit a vulnerability beyond what is necessary to demonstrate it

In return, we commit to:

• Acknowledge your report within 5 business days
• Keep you informed of our progress
• Credit you publicly (with your permission) when we publish the fix
• Not take legal action against good-faith security research that follows the rules above

3.2 Out of scope

The following are generally not in scope for our security reports:

• Findings from automated scanners with no demonstrated exploitability
• Missing security headers without a concrete attack scenario
• Self-XSS or social-engineering attacks against our employees
• Issues in third-party services we use (please report those to the third party directly)

4. Breach notification

If we discover a personal data breach, our obligations are described in our Privacy Policy §6: we notify the supervisory authority within 72 hours of becoming aware of the breach, as required by GDPR Article 33, and we notify affected users without undue delay where the breach is likely to result in a high risk to their rights and freedoms (Article 34). Where a US state breach-notification statute applies (e.g. Cal. Civ. Code § 1798.82, RCW 19.255), we follow that statute's timing in addition to the GDPR commitment.

5. Contact