Security
How we protect your books
Setttle holds bank connections, financial records, and the credentials that reach them. This page describes the controls that are actually in the product today, and where our formal program still has work to do.
Where we are
A small team, and honest about it
Setttle is built and run by a small team. We do not hold SOC 2 or ISO 27001, and we will not display a badge we have not earned. Our written information-security policy is being finalized before launch.
What we can do is show you the controls that are implemented now, and tell you plainly what is still in progress.
In the product
Controls that are implemented today
- Bank credentials
- Plaid access tokens are encrypted with authenticated AES-256-GCM before storage. The key is supplied at the server boundary, and plaintext tokens are never returned to the browser or written to logs.
- Company isolation
- Row-level security and entity membership checks keep each company's books separate. A connection, token, or report never spans two companies.
- Transport and webhooks
- All external calls use HTTPS/TLS. Incoming bank webhooks are accepted only after signature, body-digest, and freshness verification.
- Authentication and access
- Individual accounts, entity-scoped authorization, and a service-role-only boundary for provider credentials. Production and provider consoles require unique credentials and multi-factor authentication.
- Audit history
- Financial changes record an actor — person, collaborator, system, or agent — with a timestamp and source. Posted entries cannot be deleted individually, and corrections preserve the original.
- Payments
- Card data is handled by Stripe, not by Setttle. We retain processing, fee, refund, dispute, and payout facts for reconciliation, and we never store full card numbers.
How we operate
The practices around the product
- Least privilege
- Access is granted per person according to need and removed when work ends. Production access is reviewed rather than assumed.
- Secrets management
- Deployment secrets live in the deployment secret store, not in source control. Credentials are rotated after suspected exposure or a change in access.
- Change review
- Changes to code, schema, infrastructure, and integrations are reviewed before release, with formatting, linting, type checking, and tests for security-relevant changes.
- Dependencies
- Dependencies are monitored for advisories. Critical issues are triaged promptly, and a fix or a compensating control is recorded.
- Backup and recovery
- Critical data is backed up, and restore procedures are documented and tested on a schedule appropriate to the service.
- Vendors
- Providers that touch restricted data are reviewed for security, privacy, availability, retention, and breach-notification terms before production use.
Incident response
What happens when something goes wrong
A suspected incident is identified, contained without destroying evidence, fixed, and documented. Exposed credentials are rotated, normal operation is restored, and the fix is validated.
- Critical
- Contain immediately and begin remediation within one business day.
- High
- Begin remediation within seven calendar days.
- Lower severity
- Prioritized in the normal maintenance queue.
- Notifications
- We coordinate notifications required by law, contract, or provider terms.
These are internal operating goals, not a contractual promise to you, and not a substitute for any notification obligation we owe.
Reporting
Tell us about a vulnerability
Include what you found, how to reproduce it, and any impact you can demonstrate. We welcome good-faith research, will confirm receipt, and will keep you posted as we work through it.
Get your books settled
Questions about security are welcome before you sign up.
7-day Max trial · no credit card required