Security

Version 1.1 · Effective 2026-08-30

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 Apple Health data 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 with IAM-scoped access; no engineer holds a long-lived key locally.
• 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. Internal services (database, message queue, cache) communicate over TLS within our virtual private cloud.

1.2 Access control

• Production infrastructure uses least-privilege IAM roles. Engineer access to production data passes through an audited break-glass workflow that requires an explicit reason, logs the actor identity and the session duration, and is reviewed regularly.
• Direct long-lived database credentials are not distributed to individuals.
• Multi-factor authentication is enforced for all employee accounts to the AWS console, the codebase, and the support tooling.

1.3 Authentication and session management

• JWT access tokens expire after 30 minutes.
• Refresh tokens are rotated on every use; any re-use of an already-rotated token revokes the session immediately, on the assumption that re-use signals a stolen-token replay attempt.
• All authentication events (login, sign-in-link request, token refresh, token revocation) are logged.

1.4 Logging and monitoring

• Reads and writes against consumer health data are logged with timestamp, actor identity, and operation type. These logs are retained for 90 days, then deleted by a daily retention job (see Privacy §4 for the full retention table).
• Errors and suspicious activity are forwarded to our error-tracking provider (Sentry, EU region) and reviewed.
• Authentication anomalies (rapid token refreshes, geographically improbable session re-use) trigger alerts for engineering review.

1.5 Backups and disaster recovery

• Daily encrypted database backups, retained for 7 days, then overwritten.
• 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, message queue, and cache are inside a private VPC with no public ingress.
• Public ingress is rate-limited at the API gateway and DDoS-protected by AWS Shield Standard.
• Container images are scanned for known CVEs on every build. We do not deploy images with known critical vulnerabilities to production.

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 our processing of special-category data (health records read from Apple Health on iOS or Google Health Connect on Android), reviewed at least annually.
• Data Processing Addenda with each sub-processor (OpenAI, AWS, RevenueCat, Sentry, Expo) covering Standard Contractual Clauses for any cross-border transfer (Article 46(2)(c) GDPR).
• 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