Information Security & Data Protection Policy

1. Purpose & scope

This policy defines how LIFE Direct identifies, mitigates, and monitors information-security risk across the application at lifedirectapp.com, its backend systems, and the vendor services it relies on. It applies to everyone with administrative access to production systems (currently the Founder) and to all consumer data the Service processes.

2. Governance

• Accountable owner. The Founder & Security Lead is responsible for this policy, for vendor security posture, and for remediation of identified risks. Security contact: inquire@wineinc.net.
• Review cadence. This policy and the practices below are reviewed quarterly, and additionally whenever a material feature (especially one touching financial data) ships.
• Release reviews. Significant releases undergo an adversarial security review (automated multi-pass code audit covering authentication, access scoping, injection, and data exposure) before deployment. Confirmed critical findings block release until fixed.

3. Access control

• Least privilege. Production access (hosting console, deploy credentials, payment and bank-data vendor dashboards) is limited to the Founder. There are no shared accounts.
• Multi-factor authentication is required on all infrastructure and vendor consoles that store or process consumer financial data (hosting, payments, bank-data, identity providers).
• Application access. Every user record is scoped by account. API endpoints authenticate via HttpOnly, SameSite session cookies; bank-data endpoints additionally verify per-user ownership of linked accounts. Passwords are stored only as salted PBKDF2 hashes. Login attempts, signups, and sensitive endpoints are rate-limited per client.
• Secrets (API keys, encryption keys) live in the host's secret store or server-side environment files, are never committed to code, never sent to the browser, and the web server refuses to serve configuration, database, or source files.
• Access reviews. Vendor-console access, API keys, and deploy credentials are reviewed as part of the quarterly review; unused or superseded credentials are revoked.
• Non-human authentication. All service-to-service access (payments, bank data, identity, AI, hosting) authenticates with scoped OAuth/bearer tokens over TLS; no shared passwords between systems.

4. Data protection

• In transit: all traffic is HTTPS (TLS 1.2+), enforced by redirect. All vendor API calls (Stripe, Plaid, Google, Anthropic, ElevenLabs) use TLS.
• At rest: production data lives on encrypted block storage. Vault documents carry an additional layer of application-level authenticated encryption with per-user data-encryption keys wrapped by a master key held in the secret store.
• Bank credentials never touch our systems. Bank linking is performed inside Stripe Financial Connections / Plaid Link; the Company receives only scoped access tokens and account identifiers, which are stored per-user. Transaction data is fetched on demand for display and analysis and is not persisted in our database.
• Minimal collection. The Service collects only what its features require, and does not sell personal data.

5. Secure development & vulnerability management

• Minimal dependency surface. The backend is dependency-free (language standard library only), eliminating most third-party supply-chain exposure. The few client-side libraries are pinned and loaded from their official origins.
• Patching. Workstations run automatic OS security updates. Production containers are rebuilt from a current minimal base image on every deploy, picking up upstream security patches.
• Testing. Changes are verified in test/sandbox modes (test-mode payments, sandbox bank data) before production. Periodic adversarial security audits cover the full codebase; findings are triaged by severity.
• Remediation targets: critical (data-exposure) findings within 48 hours; high within 7 days; others in the normal release cycle.
• End-of-life software. Production runtimes are kept on supported (non-end-of-life) versions — the container base image is refreshed on every deploy, and the quarterly review verifies that no end-of-life software remains in production.

6. Data retention & deletion

• User self-service: users can export a complete copy of their data (Settings → Export my data) and permanently delete their account without contacting support.
• This retention schedule is reviewed on the same quarterly cadence as the rest of this policy.

7. Consumer consent

Users create accounts deliberately and are shown Terms & Privacy at signup; connecting a bank is an explicit, separate user action performed through the vendor's own consent flow; family location sharing is off by default and requires the family member's approval. Children's accounts are restricted and parent-linked.

8. Incident response

On indication of a security incident: contain (revoke affected credentials/sessions, take affected systems offline if needed) → assess scope and affected users → notify affected users and vendors without undue delay, and within any timeline required by applicable law → remediate and review (root-cause fix, then a written post-incident review feeding back into this policy).

9. Subprocessors