Security Policy

Last updated: June 24, 2026

At Latch, the security of our customers' financial data is foundational to the product. This page describes the controls, practices, and commitments that protect the data flowing through our platform. It is written to be useful to security teams evaluating Latch as a vendor as well as to customers who want a clear picture of how their information is handled.

If you have questions about anything below, or need to report a vulnerability, contact us at support@golatch.com.

1. Infrastructure & Hosting

Latch runs on established cloud providers, each chosen for a specific layer of the stack. All infrastructure is access-controlled and managed through authenticated administrative consoles.

  • Application frontend: Netlify
  • AI and inference services: Fly.io
  • Database and application backend (PocketBase): DigitalOcean

Customer data is hosted in the United States. Access to each provider's administrative console is restricted to authorized Latch personnel. We do not host customer data in environments outside the providers listed above.

2. Encryption

Customer data is encrypted both in transit and at rest.

  • In transit: All traffic between customers, integrated services, and Latch's infrastructure is encrypted using TLS 1.2 or higher.
  • At rest: Data stored in Latch's database is encrypted using AES-256.
  • OAuth tokens and integration credentials: Encrypted with AES-256-GCM before being written to storage, so that credentials are never persisted in plaintext.

3. Access Controls

Latch enforces strict, identity-based access to all systems that touch customer data.

  • Role-based access control (RBAC) governs what each authenticated user can see and do inside the application.
  • Individual authenticated logins are required for every administrative action. Shared credentials are not used anywhere in the platform.
  • Administrative access to production systems is limited to authorized Latch personnel (currently the founder and CTO).
  • No third-party contractors or vendors have access to customer data.
  • Need-to-know basis: Access to customer data is granted only to personnel whose role requires it.
  • Logical isolation: Each customer account's data is logically isolated, so that one customer's data is not visible to another.

4. Integration Security

Latch connects to customer financial systems (accounting, banking, payroll, expense, CRM) to read the data required to generate reports and intelligence. These connections are designed to minimize blast radius.

  • Read-only by default: All financial integrations are read-only. Latch does not move money, post journal entries, or write data back to your accounting, banking, or payment systems.
  • OAuth 2.0 with authorization-code flow: Customer-authorized connections use the standard OAuth 2.0 authorization-code flow. Latch never sees or stores customer passwords for connected systems.
  • Webhook signature validation: Inbound webhooks from integrated providers are validated using HMAC-SHA256 signatures, so that only authentic events from authorized providers are processed.
  • Idempotency checks: Event processing is idempotent, preventing duplicate writes or duplicate downstream actions if a provider re-delivers an event.

5. Data Retention & Deletion

Customer data is retained only as long as it is needed to provide the service.

  • Active accounts: Historical transaction and integration data is retained while the customer's Latch account remains active, so that reports, trends, and intelligence remain usable.
  • Disconnected integrations: When a customer disconnects an integration, the associated OAuth tokens are revoked and the stored credentials are cleared from our database.
  • Closed accounts: When a customer closes their Latch account, associated data is removed from production systems within 90 days. Financial records may be retained longer where required by applicable law.
  • Backups: All backups are encrypted at rest.

Customers may request export or deletion of their data by contacting support@golatch.com.

6. Incident Response

Latch maintains a documented incident response process for suspected or confirmed security events.

  • Containment: On any suspected breach involving integration credentials, the affected OAuth tokens are immediately revoked to cut off further access.
  • Investigation: The incident response process includes assessment of scope, root cause, and impact.
  • Customer notification: Affected customers will be notified within 72 hours of confirmation of a breach involving their data, in accordance with applicable law and industry standards.
  • Sub-processor breaches: If a confirmed breach involves a sub-processor (Netlify, Fly.io, DigitalOcean), Latch will coordinate with the sub-processor on investigation and remediation and will notify affected customers as outlined above.
  • Postmortem: Confirmed incidents are reviewed internally, with remediations tracked to completion.

7. Compliance & Standards

Latch applies industry-standard security practices across infrastructure, application, and operations.

  • SOC 2: Our SOC 2 Type I program is targeting attestation in Q4 2026. We are happy to share current control documentation with prospective enterprise customers under NDA.
  • Industry standards: We follow widely adopted practices for application security, secrets management, and cloud configuration.

We will not overstate our compliance posture. If a certification is in progress, we will say so; if it is complete, we will publish the report or summary.

8. Customer Data Use

Latch is a customer-facing financial intelligence product, not a data broker.

  • Single purpose: Customer data is used solely to deliver financial intelligence, reports, alerts, and AI-assisted analysis to the customer whose data it is.
  • No third-party sharing: Customer data is never sold, shared, or otherwise exposed to any third party.
  • No affiliate or marketing sharing: Customer data is not shared with affiliates or marketing partners. We do not use customer financial data to train shared or external models.
  • Sub-processors: The only sub-processors involved in handling customer data are the infrastructure providers listed in Section 1, used strictly to operate the service.

9. Reporting a Vulnerability

If you believe you have discovered a security vulnerability in Latch, please report it to support@golatch.com.

When reporting, please include:

  • A description of the issue and its potential impact.
  • Steps to reproduce, if available.
  • Any relevant URLs, request/response samples, or proof-of-concept material.

We commit to:

  • Acknowledging receipt within 2 business days.
  • Providing an initial assessment within 10 business days.
  • Resolving validated issues within a reasonable timeframe based on severity.
  • Coordinating public disclosure timing with the researcher.

We ask that researchers refrain from accessing or modifying customer data, degrading service for other users, or publicly disclosing an issue before we have had a reasonable opportunity to respond.

10. Contact

For any questions about this Security Policy, or about Latch's security practices in general:

Email: support@golatch.com

Latch will update this policy as our practices and certifications evolve. Material changes will be reflected by an updated "Last updated" date at the top of this page.