Security Review Process

1. Purpose

This document defines how Legacy-Loop Tech LLC (“Legacy-Loop”) conducts security reviews to protect user data, platform integrity, and third-party data received through APIs including Meta Platform Data and Google OAuth data.

The Security Review Process applies to all Legacy-Loop systems including:

• Application code (Next.js, TypeScript, Prisma)
• Authentication systems (Google OAuth, Facebook Login, email/password, magic link, JWT session tokens)
• Database (Turso encrypted at rest)
• Sub-processor relationships (Vercel, Turso, Cloudinary, Stripe)
• API integrations (Meta Platform, Google OAuth, Stripe, Cloudinary)

2. Security Principles

Legacy-Loop operates under the following security principles:

• Least privilege — Each system component and user role receives the minimum access necessary
• Defense in depth — Multiple layers of security controls (HTTPS, encryption at rest, authentication, authorization, audit logging)
• Secure by default — Default configurations favor security over convenience
• Audit before trust — Code, configurations, and dependencies are reviewed before deployment
• No data resale — User data is never sold, rented, or licensed to third parties
• User control — Users can access, export, and delete their data at any time

3. Review Cadence

3.1 — Continuous Reviews (Per Release)

Performed before every production deployment:

• Code review by Founder/CEO and any engaged senior developers
• Automated dependency vulnerability scan (npm audit, pnpm audit)
• Static analysis via TypeScript strict mode (tsc --noEmit must pass)
• Secret scanning to verify no API keys, tokens, or credentials are committed
• Manual smoke test of authentication flows
• Verification that no new third-party data flows have been introduced without review

3.2 — Quarterly Reviews

Performed at the start of each calendar quarter:

• Full review of this document and the Incident Response Plan
• Sub-processor list verification — confirm Vercel, Turso, Cloudinary, Stripe still match Privacy Policy disclosure
• Sub-processor security posture check (review their published security pages and any security incidents disclosed)
• Access review — verify only authorized individuals have access to production environments, vault credentials, and Meta/Google developer accounts
• Credential rotation review — assess whether any long-lived credentials should be rotated
• Backup and recovery test — verify production data backup and restoration process
• Privacy Policy, Terms of Service, and Data Deletion page review for accuracy

3.3 — Annual Reviews

Performed at least once every 12 months:

• Full security audit of authentication flows (Google OAuth, Facebook Login, email/password, magic link, JWT)
• Full data flow audit (what data enters the system, how it is stored, where it is sent, when it is deleted)
• Review of all environment variables and secrets stored in Vercel and Mac Keychain
• Review of all webhooks, callbacks, and redirect URIs for current accuracy
• Penetration test consideration (engage third-party firm if user count or data sensitivity warrants)
• Updated threat model documenting current risks and mitigations

3.4 — Event-Triggered Reviews

Performed whenever any of the following occur:

• Security incident (per Incident Response Plan)
• Onboarding a new sub-processor or third-party integration
• Material change to authentication, payment, or data storage architecture
• Material change to applicable privacy or security law
• Reported vulnerability from a researcher or user

4. Review Checklist (Used Each Cycle)

4.1 — Code & Application Security

• All routes that handle user data require authentication
• All user input is validated and sanitized
• Database queries use parameterized statements (Prisma ORM enforces this)
• Session tokens use cryptographically secure signing
• OAuth flows include CSRF state validation
• Error messages do not leak sensitive information

4.2 — Data Protection

• All connections to and from the application use HTTPS (TLS 1.2 or higher)
• Turso database encryption at rest is enabled
• User passwords are hashed using bcrypt or equivalent
• API keys, OAuth secrets, and JWT signing keys are stored only in: Vercel encrypted environment variables (production/preview/development); local .env.local files (gitignored, never committed); Mac Keychain (developer machines)
• No secrets appear in code, git history, logs, screenshots, or chat transcripts

4.3 — Access Control

• Only authorized individuals have access to the production Vercel project
• Only authorized individuals have access to the Meta Developer dashboard
• Only authorized individuals have access to the Turso production database
• Two-factor authentication is enabled on all accounts where supported (GitHub, Vercel, Meta, Google, Stripe)
• Vault credentials (1Password or equivalent) are used for credential storage

4.4 — Third-Party Data Handling

• Sub-processor list in Privacy Policy is current and accurate
• Each sub-processor's Data Processing Agreement (DPA) or Terms of Service has been reviewed
• No user data is shared with parties not disclosed in the Privacy Policy
• Meta Platform Data (Facebook Login email + public_profile) is used only as disclosed in the App Review submission
• Google OAuth profile data is used only for account identification and personalization
• Stripe payment data is processed by Stripe and never stored in Legacy-Loop databases except as required tokens

4.5 — Logging & Monitoring

• Vercel request logs are enabled
• Authentication events (login, logout, password reset, account deletion) are logged
• Failed authentication attempts are logged for anomaly detection
• Logs do not contain raw passwords, full credit card numbers, or other sensitive PII in plaintext
• Log retention is documented and limited to what is operationally necessary

4.6 — Backup & Recovery

• Turso database has point-in-time recovery enabled per the Turso plan
• Application code is backed up via GitHub (LegacyLoop/LegacyLoop-MVP and LegacyLoop/LandingSite)
• Critical configuration is documented in private internal documents

4.7 — Compliance & Disclosure

• Privacy Policy at legacy-loop.com/privacy is current and accurate
• Terms of Service at legacy-loop.com/terms is current and accurate
• Data Deletion page at legacy-loop.com/data-deletion is current and functional
• In-app account deletion at app.legacy-loop.com/settings is functional
• All required regulatory disclosures (GDPR, CCPA) are honored

5. Review Documentation

Each review cycle produces a written record stored internally:

• Date of review
• Reviewer name
• Checklist items completed
• Findings identified
• Remediation actions taken or planned
• Date of next scheduled review

Records are retained for a minimum of 24 months.

6. Roles & Responsibilities

Legacy-Loop is a single-member LLC. The Founder & CEO holds primary responsibility for security review execution. External vendors and contracted senior developers may be engaged to assist with specialized reviews (e.g., penetration testing, cryptographic review).

7. Independence and Scale Acknowledgment

Legacy-Loop Tech LLC is a single-member LLC operating at early-stage scale. The Security Review Process is designed to be commensurate with this scale while still providing meaningful protection of user data.

As Legacy-Loop grows, this process will scale accordingly. Specifically:

• At 1,000 active users: Engage a third-party security firm for an annual penetration test
• At 10,000 active users: Pursue SOC 2 Type I attestation
• At 50,000 active users: Pursue SOC 2 Type II attestation
• Upon any material data processing change: Re-evaluate the cadence and depth of this review

8. Plan Maintenance

This Security Review Process is reviewed and updated:

• Quarterly by the Founder & CEO
• After any security incident requiring Incident Response Plan activation
• When material changes occur to the platform, sub-processors, or applicable law
• At minimum, annually

Most recent review: May 16, 2026. Next scheduled review: August 16, 2026.

9. Acknowledgment

By operating Legacy-Loop Tech LLC, the Founder & CEO accepts responsibility for the maintenance and execution of this Security Review Process.

Last updated: May 16, 2026 | Return to Security & Trust