Security at Live Every Day

Our approach

The Live Every Day Foundation treats account and health information as sensitive. We use layered administrative and technical controls intended to prevent unauthorized access, limit the impact of a failure, detect inappropriate activity, and recover safely. We review safeguards as the Service and threat landscape change.

No organization can guarantee absolute security. This page describes current control design; it is not a warranty that incidents can never occur and does not reveal confidential implementation details that could weaken user protection.

Encryption

In transit

Production web, mobile, API, and database connections are configured to use encrypted transport. The production database accepts encrypted connections and uses a managed certificate authority. We do not intentionally transmit passwords, session secrets, or health documents over unencrypted public connections in production.

At rest

Production databases, managed backups, logs, and cloud storage use provider-managed encryption at rest. Operational secrets—such as database credentials, authentication secrets, provider keys, and email credentials—are held in a managed secrets service rather than committed to application source code.

Live Every Day is not end-to-end encrypted: the Service must process authorized data on the server to calculate scores, prepare trends, extract labs, and provide sharing features. Server-side access is therefore restricted and auditable.

Authentication and session protection

• Users may authenticate with an email and password or supported Google and Apple sign-in.
• We do not receive Google or Apple account passwords.
• Direct account passwords are stored only in a one-way protected form through the authentication system.
• Production web sessions use secure cookie protections.
• Mobile authentication material is stored using the device platform’s secure storage.
• Sessions and linked provider accounts are invalidated or removed during account deletion.

Users should protect their devices and sign-in accounts, use a unique password for a direct password account, and report suspected access promptly.

Authorization and data isolation

Patient-owned records are associated with an authenticated user identifier. Server-side authorization scopes reads and writes to that identity; hiding a control in the user interface is not treated as authorization. Patient-controlled sharing permissions are checked by the server for circle and care-team features.

Administrative and support capabilities use separate roles and additional policy checks. Sensitive access is designed to fail closed if required audit recording cannot be completed.

Least privilege and cloud boundaries

• Application, migration, audit, deployment, and scheduling workloads use separate service identities with roles scoped to their function.
• The application database uses private networking and does not expose a public IP address in the production design.
• Access to secrets is granted to specific runtime identities rather than broadly to every user or workload.
• Deployment automation uses short-lived federated identity instead of a long-lived cloud service-account key stored in the code repository.
• Access to retained security logs is restricted to designated reviewers and separated from general application access.

Audit logging and monitoring

The application records security-relevant actions such as authentication, data access, data changes, permission decisions, processor disclosures, and account deletion. Audit events use identifiers, action types, outcomes, timestamps, and limited metadata needed for accountability.

Audit records are designed not to contain lab values, questionnaire answers, uploaded document contents, support-message text, passwords, access tokens, or unrestricted health payloads. A restricted retention configuration supports keeping audit evidence for up to six years. Monitoring can alert designated personnel to audit failures, unusual login failures, authorization denials, configuration changes, and infrastructure health problems.

Cloud request logs for the patient-data API are excluded from retention because platform-generated URL, IP, referrer, and user-agent fields can create unnecessary privacy risk. Privacy-safe structured application logs and aggregate service metrics remain available for operations.

Backups and resilience

The production database uses automated encrypted backups and point-in-time recovery. Database storage automatically expands to reduce capacity-related failure risk, and maintenance follows the managed provider’s stable update track. Backup access is restricted and backups are used only for continuity and disaster recovery.

When an account is deleted, residual data may remain in isolated backups until they expire or are overwritten, typically within 30 days. If a backup must be restored, deletion controls are reapplied before normal use. See the Data Deletion page.

Data minimization and safer processing

• Uploaded lab documents are sent for extraction, but the original bytes are not stored in the Live Every Day application database after processing.
• Extracted lab information is treated as untrusted until it passes schema and supported metric checks and is reviewed by the user.
• AI-assisted observation wording receives only a small set of structured facts needed to phrase an already-established pattern—not names, emails, notes, raw documents, or unrestricted history.
• Observation source links support targeted withdrawal after retrospective edits or source deletion. Persisted derived evidence and chart values are redacted when their supporting source is removed.
• Diagnostic logging is filtered to avoid secrets, source documents, raw model prompts containing patient data, and unnecessary health payloads.
• Tests, fixtures, screenshots, and examples use synthetic or de-identified data.

HIPAA-aligned safeguards

Our architecture and operating principles are designed to align with relevant HIPAA Security Rule concepts, including access control, audit controls, integrity, person or entity authentication, transmission security, backup and contingency planning, and minimum-necessary access. HIPAA applicability depends on the organization’s legal role and a particular data flow; HIPAA is a compliance framework, not a general product certification. We also protect health information that falls outside HIPAA.

Report a security issue

Email info@liveeveryday.health with the subject “Security report.” Include the affected URL or feature, steps to reproduce, observed impact, and a safe way to contact you. Do not send passwords, tokens, real patient data, or a live exploit that could harm users.

We prioritize reports involving unauthorized account access or exposed health information and will triage credible reports as soon as practicable. Please allow a reasonable opportunity to investigate and protect users before public disclosure. We do not currently offer a paid bug-bounty program.

Organization details