Security
at Covmont
How financial data is protected.
Covmont is financial-data infrastructure. Bank data passes through it, is structured by it, and is stored in it — so the controls below are the product, not a layer on top of it. This page states what is in place today, in enough detail to be checked.
Last reviewed August 2026
Data we
handle
What Covmont holds, and why.
Covmont holds two categories of data: business profile information submitted directly, and transaction history retrieved from a connected bank account. Both are required to produce the structured financial context the platform exists to provide.
That data is stored in a managed Postgres database. Every row carries the user and account that own it, and Row-Level Security is enforced at the database layer — so a query scoped to one tenant cannot reach another’s data even if the application layer were wrong.
Retention windows, deletion requests, and the legal basis for processing are covered in the Privacy Policy and the Data Retention page.
Bank
access
Read-only, and never credential-bearing.
Bank connections are established through Plaid. Authentication happens inside Plaid’s flow, against the institution directly. Covmont receives a read-only token scoped to the Transactions product — sufficient to retrieve transaction history, and insufficient to move money, initiate a transfer, or alter an account.
Plaid operates its own security and compliance program and is listed as a subprocessor. Covmont does not inherit Plaid’s certifications; where Plaid’s posture is the relevant control, it is Plaid’s to attest. Their security documentation is public.
Control
register
The controls in place today, with enough specificity to be evaluated or carried into a security questionnaire. Entries describe implemented behaviour, not intent.
Data protection
- Encryption in transitTLS for all browser and service-to-service traffic. HTTP Strict Transport Security is set with a two-year max-age and includeSubDomains.All surfaces
- Encryption at restDisk-level encryption on the managed Postgres instance, provided and operated by Supabase.Stored data
- Tenant isolationRow-Level Security is enabled on every table. Each row is scoped to the user and account that own it and is enforced at the database, independent of application code.Database
- Retention and deletionRetention windows, archival paths, and deletion routines are documented and reviewed whenever a new data class is introduced.Data lifecycle
Bank data access
- Access scopeBank connections request the Plaid Transactions product only. The resulting token is read-only: it can retrieve transaction history and cannot move money, initiate transfers, or change account settings.Bank connections
- Credential handlingBank authentication happens inside Plaid. Covmont never receives, stores, or transmits bank usernames, passwords, or MFA codes.Bank connections
- Vendor posturePlaid is the system of record for the connection and runs its own security and compliance program. Covmont does not inherit Plaid’s certifications and treats Plaid as a subprocessor.Vendors
Identity and access
- Password policyA 12-character minimum, screened server-side against known-breached password corpora before an account can be created or a password changed.All accounts
- Multi-factor authenticationTOTP authenticator enrollment with single-use recovery codes, stored hashed. Available to broker accounts, expanding across the product.Broker accounts
- Identity resolutionAccount identity is resolved server-side from the session on every request. Account and user identifiers supplied by a client are never trusted.API
- Secret managementService credentials remain server-side. Privileged database operations require service-role keys that are never exposed to the browser.Application
Application and network
- Security headersContent-Security-Policy with a per-request nonce, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy, and a restrictive Permissions-Policy.All responses
- Rate limitingSliding-window limits at the edge, scoped per route group — tighter on authentication and bank-token exchange than on general API traffic.API
- Input validationAPI request bodies, query parameters, and headers are parsed against explicit schemas with size limits before any handler logic runs.API
- Audit eventsSecurity-relevant events — authentication factor changes, privileged administrative actions, configuration validation — are recorded as structured audit events.Platform
Operations
- Access control policyDocumented least-privilege policy with access reviewed on a quarterly cycle and the review recorded.Organization
- Patch managementDocumented patching policy with a maintained end-of-life register for runtime and dependency versions.Organization
- Incident responseDocumented response process covering detection, containment, notification, and post-incident review.Organization
- Vendor reviewA small, published set of subprocessors, each reviewed when added or changed.Vendors
Compliance
posture
Where formal audits stand.
Covmont is not SOC 2 certified, and holds no ISO, PCI, or HIPAA certification. A SOC 2 Type II audit is planned as the company scales. Stating that plainly is more useful to an evaluator than implying coverage that does not exist.
In the meantime, the controls that audit assesses are the ones in the register above: documented access control, encryption, tenant isolation, vendor review, patch management, and incident response. The subprocessor list is published and current at /subprocessors.
For a security questionnaire, vendor review, or diligence request, write to security@covmont.com.
Responsible
disclosure
Reporting a vulnerability.
Report suspected security issues to security@covmont.com with a description and steps to reproduce. Receipt is acknowledged, the issue is investigated, and the reporter is followed up with directly.
Please allow a reasonable window for remediation before public disclosure. There is no paid bounty program at this stage; researchers who want to be credited will be.
security@covmont.com