Information Security Policy

This policy defines the security controls applied to Project Millionaire's data, infrastructure, and operations. Scope includes all production systems, source repositories, deployment infrastructure, third-party platforms holding application data, and operator practices.

The application is single-user, owner-operated. The operator is the sole administrator, developer, and end-user.

The operator is solely responsible for security design, implementation, monitoring, key rotation, dependency updates, access reviews, and incident response. There are no other personnel with access to production data or infrastructure.

• Sensitive: Plaid access tokens, API tokens, encryption keys. Stored encrypted at rest or in environment-scoped secrets only.
• Confidential: account balances, holdings, snapshot history. Encrypted in transit; access restricted to the operator.
• Reference: securities catalog (ticker, name, type). No user identifiers; shared data.

• Multi-factor authentication required on every administrative platform: GitHub, Render, Vercel, Neon, Plaid Dashboard
• Single-operator access model; no shared accounts
• Application-layer bearer token authentication on /api endpoints
• CORS origin allowlist restricting browser-side callers
• Database access restricted to the backend service via TLS-only connection string; no direct or public exposure

• At rest: Plaid access tokens encrypted with Fernet (AES-128-CBC + HMAC-SHA256) before persistence. Postgres on Neon adds full-disk encryption with managed key rotation.
• In transit: TLS 1.2 or higher on every hop — HTTPS to Plaid, TLS-required with SCRAM channel binding to Neon Postgres, TLS-terminated edges on Render and Vercel.

• All public endpoints behind TLS edge (Render, Vercel, Neon)
• No SSH or RDP exposure: backend runs on managed PaaS (Render); frontend on Vercel; database on Neon
• No public database exposure; access only via TLS connection string with SCRAM channel binding
• Webhook endpoint accepts only JWT-signed payloads from Plaid

• GitHub Dependabot alerts enabled on both repositories
• Dependency versions pinned (requirements.txt is the output of pip freeze)
• Managed runtime patching by Render, Vercel, and Neon (auto-applied)
• Personal development device kept on current vendor security updates within 7 days of release

• Application request and error logs collected by Render
• Platform-level audit logs by GitHub, Render, Vercel, and Neon
• In-app reachability indicator (BackendStatus) surfaces real-time API status to the operator
• Render and Vercel deliver deploy and outage notifications via email

The operator is the sole responder. Documented playbooks for common compromise scenarios:

• API token compromise: rotate APP_API_TOKEN on Render and NEXT_PUBLIC_API_TOKEN on Vercel; force redeploy of frontend bundle; revoke previous tokens
• Plaid access token compromise: invoke DELETE /api/plaid/items; rotate APP_ENCRYPTION_KEY; re-link affected institutions
• Administrative credential compromise: rotate password, revoke active sessions, rotate MFA seed if affected, re-issue API keys downstream
• Database breach: take application offline, pivot to a fresh Neon project, restore from point-in-time recovery, rotate all secrets, audit access logs

• Source control on GitHub with MFA-required commits
• Self-review on every change; AI-assisted code review on security-sensitive paths
• CI/CD: Render auto-deploys backend on push to main; Vercel auto-deploys frontend
• Database migrations applied automatically as a Render pre-deploy step (alembic upgrade head)
• No direct database access from CI; no secrets in build logs

• Neon automated backups with point-in-time recovery (7-day window)
• Source code recoverable from GitHub
• Configuration secrets recoverable only by re-issuance from origin platforms (Render, Vercel, Plaid Dashboard); not backed up centrally to avoid creating a secrets-aggregation risk

Application data is processed by the following third-party platforms, each holding industry-standard certifications:

• Plaid — data source; SOC 2 Type II
• Neon — managed Postgres; SOC 2 Type II
• Render — backend hosting; SOC 2 Type II
• Vercel — frontend hosting; SOC 2 Type II
• GitHub — source control; SOC 1 Type II, SOC 2 Type II

No other third party processes application data. No analytics, advertising, or tracking SDKs are integrated.

This policy is reviewed:

• Annually
• On any material change to the application's data model or Plaid product set
• On any change in user scope (e.g., admitting third-party users)
• Following any security incident
• On replacement of any third-party platform listed in section 13

Material updates are versioned, dated, and committed to the application's source repository.

Cajetan Rodrigues
cajetanrodrigues88@gmail.com