Information Security Policy

This page is maintained by the CozyBudget team to describe our information security policy and the operational procedures we follow to identify, mitigate, and monitor information security risks. It is an app-owned policy statement, not an independent certification or audit report. A partner-facing summary of our attestations is available on the Compliance Center.

1. Purpose and scope

This policy applies to the CozyBudget web application, its supporting infrastructure, and the data our users entrust to us. Its purpose is to protect the confidentiality, integrity, and availability of user information; define responsibilities; and establish a repeatable approach to managing security risk.

2. Risk management approach

We identify, mitigate, and monitor risk through the following cycle:

• Identify: We review our architecture, data flows, vendor integrations, and user-facing features for security and privacy risks. This includes access-control reviews, dependency scanning, and periodic review of connected services such as Plaid.
• Mitigate: We apply controls such as row-level access controls, server-side token storage, HTTPS encryption, strong authentication, least-privilege service accounts, and automated security scanning.
• Monitor: We monitor for vulnerabilities in dependencies, review access patterns, and respond to user-reported security concerns.

3. Roles and responsibilities

• App owner: Maintains this policy, approves risk treatment decisions, and ensures security is considered in feature design.
• Development and operations: Implements secure coding practices, manages secrets, configures access controls, and responds to incidents.
• Users: Are responsible for keeping their account credentials confidential, using strong passwords, and promptly reporting suspected unauthorized access.

4. Access control and authentication

• User accounts are protected by email/password or OAuth authentication through our auth provider.
• Multi-factor authentication (MFA) is required for connecting bank accounts through Plaid and for accessing sensitive financial areas such as Connected Banks, household and business financial data, the Subscription Manager, bills, and security settings. MFA options include TOTP authenticator apps, email verification, and optional email OTP.
• Database access is enforced through row-level security (RLS) so each user can only access data they own or that has been explicitly shared with them.
• Administrative and service access is limited to the minimum necessary permissions.
• Access reviews: We review user and administrative access at least quarterly and whenever someone changes role or leaves the project. Access to production systems and third-party services is tied to named accounts and revoked promptly when no longer needed.

5. Data protection

• All data in transit is encrypted with TLS (HTTPS). Data at rest is encrypted by our cloud database and storage providers.
• Bank access tokens from Plaid are stored server-side only and are never exposed to the browser or client application code.
• Uploaded files are stored in private buckets scoped to the user's account and accessed through signed URLs.
• Sensitive financial data is not used for advertising or sold to third parties.

6. Data retention and deletion

We retain user data only for as long as necessary to provide the service or as required by applicable law.

• Financial records, bank connections, and uploaded documents are kept while the user's account remains active and the relevant feature is in use.
• When a bank connection is disconnected, the associated Plaid access token and synced transaction/balance records are deleted.
• Users can delete individual records (transactions, budgets, goals, bills, etc.) through the app at any time.
• Account closure requests result in deletion of user data within a reasonable period, subject to legal retention obligations.
• This retention and deletion approach is reviewed periodically as part of our security and privacy program.

7. Vendor and third-party management

We rely on a small set of subprocessors:

• Supabase — database, authentication, and file storage.
• Plaid — optional bank account connections.
• Google Gemini — optional AI features invoked at the user's request.
• Cloudflare — hosting and edge runtime.

We select vendors with published security practices, use the least privilege integration options available, and review access regularly.

8. Security monitoring and vulnerability management

• We run automated dependency and security scans against the project codebase and lockfile.
• Findings are triaged and remediated according to severity. Critical and high-severity issues are addressed as a priority; medium findings are scheduled within 30 days; low findings are scheduled within 90 days where applicable.
• We keep dependencies up to date and remove unused or unsupported packages where feasible.
• We monitor end-of-life (EOL) announcements for dependencies and runtime components and update or replace them before EOL dates where possible.

9. Secure tokens and certificates

• All public traffic is served over HTTPS using valid TLS certificates.
• Authentication tokens are issued by our managed auth provider, scoped to the user, and never hardcoded or exposed in client bundles.
• Service credentials and API keys are stored as encrypted secrets and accessed only by server-side code. They are rotated when a team member leaves or when a credential is suspected to be compromised.

10. Zero trust access architecture

• Every request to backend data is authenticated and authorized at the application and database layers.
• We enforce least privilege: users see only their own data (or explicitly shared household data), and service accounts have only the permissions required for their function.
• MFA is required for high-risk actions such as connecting a bank account, viewing business finances, or changing security settings.
• Secrets and tokens are not trusted based on network location alone; they are verified on every use.

11. Automated de-provisioning and access modification

• When a team member's employment or role ends, their access to production systems, third-party services, and source control is revoked or adjusted promptly.
• Our auth provider supports immediate session revocation, which we use to terminate active sessions when needed.
• Users can sign out all devices from the Account Security page, and account deletion removes all associated data.

12. Incident response

• Suspected security incidents are investigated promptly by the app owner and development team.
• Affected users will be notified if their data is involved, in accordance with applicable laws and our privacy obligations.
• Root causes are documented and remediated to reduce the likelihood of recurrence.

13. Business continuity

• The app is hosted on a managed edge platform with automatic failover and geographic distribution.
• Database backups are handled by our managed database provider.
• We test critical user flows regularly and maintain the ability to deploy fixes quickly.

14. Policy review

This policy is reviewed at least annually and whenever a material change occurs to our technology, vendors, or risk profile. The current version is shown at the top of this page.

15. Reporting security issues

If you discover a security issue or have questions about this policy, please contact us through the in-app support option in Settings.