Information Security Policy

Christian Wilson LLC · Effective July 18, 2026 · Reviewed annually

This policy documents how Christian Wilson LLC ("the Company"), operator of the Monte iOS application, protects user data and the systems that process it. The Company is a single-operator organization; the controls below reflect that structure honestly rather than describing processes that don't exist.

1. Scope & asset inventory

• Production infrastructure: fully managed platform services — Supabase (database, authentication, serverless functions; hosted on AWS), Plaid (bank connectivity), Twilio (SMS), RevenueCat and Apple (subscriptions), Anthropic (AI processing), GitHub Pages (static website). The Company operates no server instances, containers, or network equipment of its own.
• Corporate endpoints: one macOS development machine, operated solely by the Company's principal. There are no employees, contractors, or additional devices.
• This complete inventory is re-reviewed whenever a service is added or removed.

2. Data handling

• Bank credentials are never transmitted to or stored on Company systems; they are entered directly with Plaid. The Company stores Plaid access tokens server-side only.
• User financial data is stored in Supabase, encrypted at rest and in transit (TLS), with row-level security scoping every record to its owning user.
• Documents users share in chat are processed transiently to extract values; the files themselves are not persisted.
• Users can export their data and permanently delete their account (and all associated data) from within the app.
• The Company does not sell user data and does not share it with third parties for marketing.

3. Access control

• Production access is limited to the Company's principal via per-service accounts; there are no shared credentials.
• Multi-factor authentication is enabled on all critical accounts: cloud infrastructure, source control, banking connectivity, messaging, payments, domain registrar, and the Apple developer account.
• API secrets and service keys live in the platform's encrypted secret store — never in source code, the repository, or client applications. Server-only keys (database service role, AI provider, messaging) are readable only by server-side functions.
• Webhook endpoints authenticate their callers (signature verification or shared-secret headers); unauthenticated requests are rejected.

4. Endpoint security

• The development machine runs current macOS with automatic security updates, full-disk encryption (FileVault), Gatekeeper and XProtect malware protections, screen lock, and remote-locate/wipe (Find My).
• As a single-operator company, the principal's device is the corporate device; the controls above apply to it in full.

5. Vulnerability management

• Production infrastructure patching and network security are managed by the platform providers (Supabase/AWS), whose own programs include continuous scanning and compliance certifications.
• Application dependencies are kept current through routine development updates; the operating system and toolchain apply security updates automatically.
• Server-side code enforces authentication and per-user scoping on every request; changes are version-controlled with full history.

6. Change management

• All application and server-side code is version-controlled (Git) with full history; every production change is a tracked commit that can be rolled back.
• Releases follow a defined path: server-side functions and database migrations deploy only through the platform's CLI tooling; iOS releases are built, signed, and distributed exclusively through Apple's App Store pipeline, which adds Apple's own review gate.
• Changes are manually verified end-to-end against the live system before release. As a single-operator company there is no second-person code review; version control, platform gates, and post-deploy verification serve as the compensating controls.

7. Logging & monitoring

• Every server-side request is logged by the platform (function invocations with status codes, database logs, authentication events), retained by the provider.
• Third-party processors provide their own audit surfaces reviewed by the principal: Plaid API and item logs, Twilio messaging logs, RevenueCat event history.
• Webhook failures and bank-connection errors surface actively (error events from providers trigger user-facing re-link prompts). Formal real-time security alerting is not currently deployed; provider dashboards are reviewed routinely and the incident response process below governs anything discovered.

8. Incident response

• Any suspected exposure of user data triggers: immediate credential/secret rotation, revocation of affected Plaid items, assessment of scope via provider logs, and notification of affected users without undue delay.
• Security contact: zachwilson106@gmail.com. Reports are acknowledged within 2 business days.

9. Review

This policy is reviewed at least annually, and whenever the architecture or vendor set changes materially.