Information Security Policy

1. Purpose and Objectives

This Information Security Policy ("ISP") establishes the foundation for Formation's information security program. It defines our commitment to protecting the confidentiality, integrity, and availability of all information assets, including consumer financial data accessed through third-party aggregation providers.

1.1 Objectives

• Confidentiality: Ensure that consumer financial data, credentials, and personally identifiable information (PII) are accessible only to authorized parties and systems.
• Integrity: Protect information from unauthorized modification, ensuring accuracy and completeness of financial data throughout its lifecycle.
• Availability: Maintain reliable access to the Formation platform and its data for authenticated users while ensuring system resilience.
• Compliance: Meet or exceed applicable legal, regulatory, and contractual requirements, including obligations to our data aggregation partner (Plaid) and data privacy laws.
• Risk Management: Identify, assess, and mitigate information security risks through proactive controls and continuous monitoring.

2. Scope

This policy applies to:

• All information assets: Consumer financial data, authentication credentials, API keys, access tokens, encryption keys, application source code, infrastructure configurations, and business records.
• All systems: The Formation web application, backend APIs (Netlify Functions), Supabase database and Edge Functions, third-party integrations (Plaid, Stripe, Resend, Twilio, Anthropic, Perplexity, OpenAI, ElevenLabs, Array, RentCast, Google), and development environments.
• All personnel: The founder, any contractors, employees, or third parties who access Formation's systems or data.
• All environments: Production, preview (deploy previews and branch deploys, isolated to a non-production Supabase project), development, and sandbox environments.

4. Access Control

4.1 Principle of Least Privilege

Access to systems, data, and infrastructure is granted on a need-to-know basis using the principle of least privilege. No user or system is granted more access than necessary to perform its function.

4.2 Authentication Requirements

• Consumer authentication: Email/password with Supabase Auth (passwords hashed using bcrypt with appropriate work factors), plus Sign in with Google and Sign in with Apple via OAuth. Multi-factor authentication is required for all users via authenticator app (TOTP) or SMS one-time codes (Twilio Verify, through the Supabase MFA phone factor); a user without a verified second factor is forced to enrol before reaching any data. Enforcement is applied both client-side (an enrolment gate) and server-side (the API rejects any request whose session has not reached AAL2). Self-serve MFA recovery is provided through an emailed magic link.
• Administrative access: All infrastructure dashboards (Supabase, Netlify, Plaid, Stripe, Twilio, GitHub) require MFA-enabled accounts.
• API authentication: API keys and access tokens are stored as environment variables, never in source code. Secrets are rotated on a regular schedule or immediately upon suspected compromise.

4.3 Role-Based Access Control (RBAC)

• The client never queries the database directly. All data access is mediated by server-side functions (Netlify Functions, Supabase Edge Functions) that verify the caller's JWT and scope every query to the authenticated user_id in application code, so a user can only read or write their own financial data.
• Service role keys are restricted to those server-side functions and are never exposed to the client.
• Supabase Row-Level Security (RLS) policies are maintained as defense-in-depth around the user_id = auth.uid() boundary; because the application path uses the service role, the server-side scoping above is the primary enforcement layer.
• Stripe webhook endpoints validate signatures to prevent unauthorized access.

4.4 Access Reviews

Access to all systems is reviewed quarterly. Unused accounts, stale API keys, and unnecessary permissions are revoked promptly, and each review is recorded with its date and reviewer. When a contributor leaves or changes role, their access to every system (GitHub, Supabase, Netlify, Plaid, Stripe, Twilio, and any shared credentials) is revoked or adjusted as part of a documented offboarding checklist, and shared secrets they could have accessed are rotated. While Formation operates without dedicated personnel, these steps are performed manually by the Information Security Owner; they will be automated and integrated with an HR/identity provider as the team grows.

5. Data Protection

5.1 Encryption in Transit

• All client-server communication uses TLS 1.2 or higher, enforced by HSTS headers with max-age=31536000; includeSubDomains; preload.
• API calls to third-party providers (Plaid, Stripe, Resend, Anthropic, Twilio) use TLS-encrypted connections exclusively.
• WebSocket connections to Supabase use WSS (TLS-encrypted WebSockets).

5.2 Encryption at Rest

• All consumer financial data stored in Supabase (PostgreSQL) is encrypted at rest using AES-256 encryption.
• Database backups are encrypted using the same standard.
• Plaid access tokens are stored encrypted in the database and are never logged or exposed in API responses.
• Stripe customer IDs and subscription data are stored with database-level encryption.

5.3 Data Classification

Classification	Examples	Handling Requirements
Critical	Plaid access tokens, Stripe API keys, Supabase service role key, Resend API key, Anthropic/OpenAI/ElevenLabs API keys, Array, RentCast, and Perplexity API keys, Twilio auth token	Stored only in environment variables; never in code or logs; rotated regularly; access limited to production systems
Confidential	Consumer financial data (account balances, transactions, holdings), user email addresses and phone numbers, authentication credentials, Stripe customer IDs	Encrypted at rest and in transit; access controlled by RLS; retained per data retention policy; deleted upon user request
Internal	Application source code, infrastructure configuration, internal documentation, edge function code	Access limited to authorized personnel; stored in private repositories; protected by MFA
Public	Privacy policy, security policy, marketing content, landing page	No access restrictions; reviewed for accuracy before publication

6. Infrastructure and Network Security

6.1 Hosting Security

• Netlify: Production application hosted on Netlify's globally distributed CDN with automatic TLS certificate management, DDoS protection, and edge caching. Server-side API logic runs in Netlify Functions (serverless).
• Supabase: Database hosted on Supabase's managed PostgreSQL infrastructure with automated backups, point-in-time recovery, and network isolation. Edge Functions handle server-side processing such as email notifications.

6.2 Security Headers

The following HTTP security headers are enforced on all responses:

• Content-Security-Policy (CSP): Restricts script, style, and connection sources to approved domains only.
• Strict-Transport-Security (HSTS): Forces HTTPS with preload and subdomain coverage.
• X-Frame-Options: Set to DENY to prevent clickjacking.
• X-Content-Type-Options: Set to nosniff to prevent MIME-type sniffing.
• Referrer-Policy: Set to strict-origin-when-cross-origin.
• Permissions-Policy: Restricts access to sensitive browser APIs (camera, geolocation, payment); microphone is enabled only for the in-app AURA voice feature.

6.3 Third-Party Integrations

Provider	Purpose	Security Measures
Plaid	Financial data aggregation	OAuth token exchange; tokens stored encrypted; webhook signature verification; sandbox/production environment separation
Supabase	Database, authentication, and Edge Functions	Row-level security; service role key restricted to server-side; JWT-based session management; automated backups
Stripe	Subscription billing & payment processing	PCI DSS compliant; webhook signature verification; API key stored in environment variables; no raw card data handled by Formation
Resend	Transactional email delivery	API key stored in environment variables; HTTPS-only communication; email content does not include sensitive financial data
Twilio	SMS two-factor authentication (Verify)	Credentials stored in environment variables; HTTPS-only communication; integrated through the Supabase MFA phone factor; phone numbers handled per Twilio's data terms
Anthropic	AURA & document/statement parsing	API key in environment variables; receives your financial context and uploaded documents to answer or parse (your real data, not anonymized); Anthropic does not train on it; uploaded files are not retained after parsing
OpenAI	Real-time voice assistant & text-to-speech	API key in environment variables; receives voice audio and financial context only when you use voice; ephemeral session tokens; not used for training
ElevenLabs	Text-to-speech (voice reply fallback)	API key in environment variables; receives only AURA's reply text to synthesize speech
Array	Consumer credit-score connection	API credentials in environment variables; receives user email/ID to mint a token; returns score + factors; webhook signature verification
RentCast + address lookup	Real-estate valuations & property records	API key in environment variables; receives only property addresses you add; no account or identity data
Perplexity	Live market quotes, dividends, splits & ticker news (web search)	API key in environment variables; receives ticker symbols only; no consumer data
Google	Ad-conversion tag & web fonts (marketing pages)	Loads on public marketing pages only; receives browsing data (IP, user agent, page) for advertising measurement; no access to financial data; disclosed in the Privacy Policy
Netlify	Hosting and serverless functions	Environment variables for secrets; automatic TLS; deploy previews isolated from production

7. Application Security

7.1 Secure Development Practices

• Source code is stored in a private Git repository with access restricted to authorized personnel.
• Dependencies are regularly audited using npm audit and updated to patch known vulnerabilities.
• Secrets and API keys are never committed to source code; .env files are excluded via .gitignore.
• Input validation and output encoding are applied to prevent injection attacks (XSS, SQL injection).
• Parameterized queries are used for all database operations.
• Stripe webhook payloads are verified using signature validation before processing.

7.2 Deployment Security

• Production deployments are performed through Netlify's CI/CD pipeline with build verification.
• Supabase Edge Functions are deployed with access control and JWT verification.
• Environment variables are managed through Netlify's and Supabase's secure environment variable stores, not in code.
• Deploy previews and branch deploys run against an isolated non-production Supabase project (formation-preview), scoped via per-context environment variables, and use sandbox aggregator/payment credentials — they never read or write production data.

8. Vulnerability Management

8.1 Scanning and Patching

• Dependency vulnerabilities are scanned continuously: Dependabot opens pull requests for vulnerable and outdated packages, and every pull request and merge to main runs npm audit in CI, which blocks merge on any high-severity or critical advisory in a production dependency.
• End-of-life (EOL) runtimes and dependencies are monitored: the build runtime (Node.js) is pinned to a supported LTS release in .nvmrc and netlify.toml, and Dependabot flags packages that fall out of support so they can be upgraded or replaced.
• Critical and high-severity vulnerabilities are patched within 7 days of discovery.
• Medium-severity vulnerabilities are patched within 30 days.
• Low-severity vulnerabilities are tracked and addressed in the next scheduled maintenance window.

8.2 Endpoint Security

• Development machines use full-disk encryption (FileVault on macOS).
• Operating systems and applications are kept up to date with the latest security patches.
• Firewall and antivirus protections are enabled on all development machines.

9.2 Incident Response Procedure

1. Detection & Identification: Monitor system logs, Supabase audit logs, Netlify function logs, and Stripe webhook logs for anomalies. Investigate alerts promptly.
2. Containment: Isolate affected systems. Revoke compromised credentials immediately. Disable affected API keys and rotate secrets across all providers.
3. Eradication: Identify root cause. Apply patches or configuration changes. Remove any unauthorized access.
4. Recovery: Restore systems from known-good state. Verify data integrity. Re-enable services after verification.
5. Notification: Notify affected users within 72 hours of confirmed breach. Notify Plaid and Stripe per contractual obligations. Report to relevant regulatory authorities as required by law.
6. Post-Incident Review: Document lessons learned. Update security controls. Revise this policy if necessary.

10. Data Retention and Disposal

Formation maintains a separate Data Retention and Disposal Policy that governs:

• Retention periods for each data category (financial data, credentials, preferences, billing records)
• Secure disposal methods (cryptographic erasure, database deletion, token revocation)
• User rights to request data deletion
• Compliance with applicable data privacy laws

11. Privacy

Formation maintains a Privacy Policy that is displayed to end-users within the application. Key privacy commitments include:

• Explicit consent is obtained before collecting, processing, or storing consumer data.
• Data is used only for the purposes described in the privacy policy.
• Consumer data is never sold to third parties.
• Users can request access to, correction of, or deletion of their data at any time.
• Third-party data sharing is limited to service providers necessary for application functionality (Plaid, Supabase, Stripe, Resend, Twilio, Anthropic, Perplexity, OpenAI, ElevenLabs, Array, RentCast, Google, and Netlify).

12. Business Continuity

• Database backups: Supabase provides automated daily backups with point-in-time recovery capability.
• Infrastructure redundancy: Netlify's CDN provides global distribution with automatic failover.
• Source code: All application code is version-controlled in Git with remote repository backup.
• Edge Functions: Supabase Edge Functions are deployed globally and can be redeployed from source within minutes.
• Disaster recovery: In the event of a complete infrastructure failure, the application can be redeployed from source code within 1 hour. Database can be restored from the most recent backup.

13. Security Awareness and Training

• All personnel with access to Formation systems must understand and comply with this policy.
• Security best practices are documented and reviewed during onboarding of any new team members or contractors.
• The Information Security Owner stays current on security threats, vulnerabilities, and best practices through industry resources (OWASP, NIST, CISA advisories).

14. Compliance and Audit

• This policy is aligned with security requirements from Plaid and Stripe partner agreements.
• Security controls are assessed semi-annually through internal review.
• Supabase, Netlify, and Stripe maintain their own compliance certifications (SOC 2, PCI DSS, etc.) which Formation relies upon for infrastructure-level controls.
• Any findings from security assessments or partner reviews are tracked and remediated according to the severity timeline in Section 9.

15. Policy Review and Updates

This policy is reviewed and updated:

• Semi-annually: Scheduled review every 6 months (next review: January 7, 2027).
• After any security incident: Policy is reviewed and updated to address gaps identified during incident response.
• After significant changes: Any material change to infrastructure, data handling, or third-party providers triggers a policy review.
• After partner feedback: Remediation requirements from Plaid, Stripe, or other partners are incorporated promptly.