Security
How we protect your financial data
LedgerMind handles sensitive financial data for CPA firms and their clients. This page documents exactly what we store, what safeguards are in place, and our roadmap to SOC 2 Type II certification.
Data inventory
What we store and why
We collect the minimum data necessary to deliver financial health scoring. Nothing is sold or shared with third parties.
| Data type | Sensitive fields | Purpose | Protection |
|---|---|---|---|
| Financial metrics | Revenue, expenses, cash, payroll, health score, risk flags | Financial health scoring and trend analysis | Server-only access, scoped by user ID |
| Business identity | Business name, industry | Associate analyses with a business entity | Server-only access, scoped by user ID |
| CPA–client relationships | Client email address, invite tokens | CPA-to-client linking and invite flow | Server-only access, dual-party scoping |
| Contact preferences | Email address, firm name | Alert emails, digest subscriptions | Server-only access, scoped by user ID |
| OAuth credentials | QuickBooks access & refresh tokens | QuickBooks API authorization for data sync | AES-256-GCM encrypted at rest; server-only |
| Audit trail | User ID, action, IP address | Security event logging for compliance | Append-only; no user-facing read access |
Financial metrics
Fields: Revenue, expenses, cash, payroll, health score, risk flags
Purpose: Financial health scoring and trend analysis
Protection: Server-only access, scoped by user ID
Business identity
Fields: Business name, industry
Purpose: Associate analyses with a business entity
Protection: Server-only access, scoped by user ID
CPA–client relationships
Fields: Client email address, invite tokens
Purpose: CPA-to-client linking and invite flow
Protection: Server-only access, dual-party scoping
Contact preferences
Fields: Email address, firm name
Purpose: Alert emails, digest subscriptions
Protection: Server-only access, scoped by user ID
OAuth credentials
Fields: QuickBooks access & refresh tokens
Purpose: QuickBooks API authorization for data sync
Protection: AES-256-GCM encrypted at rest; server-only
Audit trail
Fields: User ID, action, IP address
Purpose: Security event logging for compliance
Protection: Append-only; no user-facing read access
Current safeguards
What's in place today
These controls are implemented and active in production.
Authentication & authorization
- All routes require Clerk authentication before any data access
- Middleware enforces auth as a second layer across the entire app
- Every database query is scoped to the authenticated user ID
- CPA–client data isolation enforced at the query level — clients never see other clients
Data protection
- QuickBooks OAuth tokens encrypted at rest with AES-256-GCM
- Supabase service role key is server-only — never exposed to client code
- All connections use HTTPS/TLS in production
- Row Level Security enabled on all tables as a defense-in-depth layer
Input & API security
- Zod schema validation on every API route input
- CSRF protection for QuickBooks OAuth via signed state cookie
- TypeScript strict mode — no unsafe type coercions
- 0 known npm vulnerabilities (audited continuously)
Audit & observability
- Audit log captures QB connections, syncs, invite flows, PDF exports, and analysis creation
- Logs include user ID, action, resource, and IP address
- No PII in audit metadata — email domains stored, not addresses
- Append-only table — no update or delete access
Known gaps
What we're working on
We document known gaps openly. Each is tracked and has a planned resolution.
No self-service data deletion
Users cannot delete their own data through the UI. Deletion requests are handled manually via support. A self-service deletion flow is on the roadmap.
Audit trail starts at deployment
The audit log captures events from the date it was deployed. There is no historical trail for actions taken before this date.
RLS bypassed by design
Row Level Security policies are defined but bypassed by the server-side service role client. Data isolation is enforced at the application layer instead. This is a known architectural trade-off.
SOC 2 roadmap
Our path to SOC 2 Type II
SOC 2 Type II certification requires a 6–12 month audit period and typically costs $15–30K/year. At the pre-seed stage, we have made a deliberate decision to implement strong technical controls now and pursue formal certification once our first enterprise contracts justify the cost.
Pre-SOC 2 safeguards
- AES-256-GCM encryption for OAuth tokens
- Audit logging for all sensitive operations
- Role-based access controls via Clerk
- Covers typical enterprise pilot questionnaire
SOC 2 Type II
- Triggered by first enterprise contract
- Vendor: Drata or Vanta (automated evidence collection)
- Controls implementation: 3–6 months
- Audit period: 6–12 months for Type II report
Enterprise security
Security questionnaires & reviews
Evaluating LedgerMind for your firm? We're happy to complete security questionnaires, discuss our architecture, or set up a call with a technical founder.
support@getledgermind.com