Security Policy

Carlo Finance (“Carlo”) handles sensitive consumer financial data. We take that responsibility seriously. This Security Policy describes the controls we have in place to protect your data, and where we are honest about what is currently implemented versus what is planned as we grow.

We are a pre-launch company with a small team. Some of the practices described here are proportional to our current size and will scale as we do. Where a control is planned but not yet implemented, we say so explicitly.

01

Organizational security

Carlo is currently a two-person founding team. Security responsibility sits with the CTO, who oversees all technical architecture, access controls, and incident response.

• Currently implemented: Security decisions are reviewed by both co-founders. All infrastructure changes require code review.
• Planned: As the team grows, we will designate a formal security lead and implement a security review process for all new hires and contractors.

02

Access control

• Least privilege— access to production systems and data is limited to the minimum required for each role.
• Unique accounts— every team member uses individual accounts. No shared credentials.
• Multi-factor authentication (MFA)— MFA is required on all systems that access production data, including source control (GitHub), hosting (Vercel), financial data services (Plaid), and email.
• Role-based access control (RBAC)— currently enforced through GitHub organization roles and Vercel team permissions. Database-level RBAC will be implemented with our production database deployment.
• Access reviews— with a two-person team, access is reviewed continuously. Formal quarterly access reviews will begin when the team exceeds five people.

03

Infrastructure security

• Hosting platform— Carlo is deployed on Vercel, which provides enterprise-grade infrastructure including SOC 2 Type II compliance, DDoS protection, and automatic TLS certificate management.
• TLS 1.2+— all data in transit between users and our application is encrypted via TLS 1.2 or higher. We do not support older, deprecated protocols.
• Network isolation— our database (planned: PostgreSQL) will be deployed in an isolated network with no direct public internet access. Connections will be restricted to our application’s compute environment.
• Edge network— Vercel’s global edge network provides automatic geographic distribution and DDoS mitigation.
• No SSH access— our serverless architecture means there are no long-running servers to compromise via SSH. Compute runs in ephemeral, isolated environments.

04

Data protection

• Encryption at rest— all stored data will be encrypted using AES-256 or equivalent, managed by our database provider’s encryption-at-rest capabilities.
• Encryption in transit— TLS 1.2+ for all connections: user-to-application, application-to-database, and application-to-third-party APIs.
• Key management— encryption keys are managed by our infrastructure providers (Vercel, database provider) using their key management systems. We do not manage raw encryption keys directly. API keys and secrets are stored in Vercel’s encrypted environment variable system, never in source code.
• Data classification— we treat all user-provided financial data and Plaid-sourced data as sensitive. Access, logging, and retention policies reflect this classification.

05

Application security

• Secure development practices— all code changes go through pull request review before merging to production. The main branch is protected; direct pushes are not allowed.
• Dependency scanning — we run dependency auditing as part of our development workflow and monitor for known vulnerabilities in our dependency tree. GitHub Dependabot alerts are enabled.
• Framework security— Carlo is built on Next.js and React, which provide built-in protections against common web vulnerabilities including XSS (automatic output escaping) and CSRF.
• Input validation— user inputs are validated on both client and server. Database queries use parameterized statements to prevent SQL injection.
• Planned: Static analysis— we plan to integrate automated security scanning (SAST) into our CI/CD pipeline as the codebase grows.

06

Plaid integration security

Plaid is our sole conduit for accessing user financial data from institutions. Here is how that integration is secured:

• OAuth-based connections— users authenticate directly with their financial institution through Plaid Link. Carlo never sees or handles bank login credentials.
• Token management— Plaid provides access tokens that let us retrieve data from connected accounts. These tokens are stored encrypted and are scoped to the specific data permissions the user granted.
• No credential storage— we store only Plaid access tokens, never bank usernames or passwords. Tokens can be revoked by the user at any time.
• Minimal data retrieval— we request only the Plaid products (account info, balances, transactions) needed for Carlo’s financial simulations. We do not request identity verification, asset reports, or other Plaid products we do not need.
• Plaid’s security— Plaid maintains SOC 2 Type II compliance, encrypts all data in transit and at rest, and undergoes regular third-party security audits. See Plaid’s security page for details.

07

Incident response

If a security incident occurs, we follow this process:

• Detection— monitoring of application logs, error rates, and anomalous access patterns. Vercel provides built-in monitoring and alerting for infrastructure events.
• Response— the CTO is the primary incident responder. Upon detection, the priority is containment (revoking compromised credentials, isolating affected systems) followed by investigation and remediation.
• Notification— in the event of a data breach affecting user data, we will notify affected users within 72 hours of confirming the breach. We will also notify relevant regulatory authorities as required by applicable law.
• Post-incident review— every security incident results in a written post-mortem and action items to prevent recurrence.

08

Vulnerability management

• Currently implemented: Dependency scanning via GitHub Dependabot. Critical vulnerabilities in dependencies are patched within 48 hours of disclosure; high-severity within one week.
• Currently implemented:Vercel’s platform handles OS-level patching and runtime security updates automatically.
• Planned for Q3 2026: Third-party penetration testing before public launch, with annual retesting thereafter.
• Planned for Q4 2026: Formal bug bounty or vulnerability disclosure program.

09

Employee and contractor security

• Currently implemented: Both co-founders use MFA on all accounts, encrypted devices with full-disk encryption, and unique per-service credentials managed through a password manager.
• Currently implemented: Source code access is restricted to the founding team via GitHub organization controls.
• Planned: Background checks for all employees and contractors with access to production data or user financial information, to be implemented as the team grows.
• Planned: Formal security awareness training program for all team members, conducted at onboarding and annually thereafter.

10

Physical security

Carlo is a fully cloud-hosted service. We do not operate physical data centers or on-premise servers. Physical security of our infrastructure is managed by our hosting providers:

• Vercel uses AWS infrastructure, which maintains SOC 2, ISO 27001, and other physical security certifications for its data centers.
• Our database provider (planned: managed PostgreSQL) will be selected from providers with equivalent physical security certifications.

Team members’ devices are protected with full-disk encryption and screen lock policies.

11

Compliance

• CCPA— we are aware of and designed to comply with the California Consumer Privacy Act. Our Privacy Policy details the rights available to California residents.
• Plaid compliance— our Plaid integration follows Plaid’s data security requirements, including proper token handling, data minimization, and end-user consent flows.
• Planned: SOC 2 Type II— we intend to pursue SOC 2 Type II certification as we approach and pass public launch. The controls described in this document are designed with SOC 2 trust service criteria in mind.

12

Implementation status

In the interest of transparency, here is a summary of what is operational today and what is planned:

Currently implemented

• TLS 1.2+ on all connections
• MFA on all team accounts
• Encrypted environment variables (Vercel)
• Code review on all changes
• Protected main branch
• Dependency vulnerability scanning (Dependabot)
• Full-disk encryption on team devices
• Password manager for all credentials
• OAuth-based Plaid integration (no credential storage)
• Vercel platform security (DDoS protection, edge network, SOC 2)

Planned

• Production database with encryption at rest and network isolation
• Database-level RBAC
• Automated SAST in CI/CD
• Third-party penetration testing (Q3 2026)
• Formal vulnerability disclosure program (Q4 2026)
• Background checks for new team members
• Security awareness training program
• Formal quarterly access reviews
• SOC 2 Type II certification

13

Contact

Questions about this Security Policy or our security practices: