Security

• In transit: TLS 1.2 or higher for all client-server, server-to-sub-processor, and inter-service communication. HSTS is enabled on customer-facing endpoints.
• At rest: managed AES-256 encryption provided by our database and storage providers (Supabase / AWS).
• Application-layer encryption: user-provided SMTP credentials are encrypted with AES-256-GCM authenticated encryption before being written to the database; the encryption key is held in our secrets store and never lives in the database. Machine-to-machine credentials issued to customers (e.g. MCP tokens) are stored only as SHA-256 hashes; the cleartext is shown exactly once at issuance and is not recoverable thereafter.

• Authentication uses Supabase Auth with email-and-password or OAuth (Google, Microsoft) and bcrypt password hashing performed by the auth provider.
• Row-level security policies enforce per-user and per-workspace access at the database layer; the application layer reinforces these checks. Service-role database keys are restricted to backend functions executing on our compute platform.
• Production system access is restricted to the engineers operating the service. Access is provisioned via single-sign-on with multi-factor authentication and reviewed quarterly.
• Logical separation of customer data is enforced through user_id and workspace_id foreign keys with database-level constraints; we do not operate a single shared tenant.

• Input validation at all system boundaries using strongly typed schemas (Zod v4).
• Output sanitisation for HTML rendering (React) and for log output.
• Rate limiting on authentication, signup, machine-to-machine credentials, and AI-bearing endpoints.
• Authenticated webhook endpoints verify Stripe and Resend signatures.
• Dependencies are kept current via automated updates and a pull-request review process; SCA scanning is performed on each pull request.

• Application errors and security-relevant events are recorded in our error-monitoring provider (Sentry) with PII-redacting filters applied before events leave Spendrein servers.
• Database and storage access is logged by the database provider.
• A workspace-level activity log records member changes, invitations, ownership transfers, and workspace state changes; this log is exposed to Workspace Owners and Admins at /settings/workspace/activity.
• An incident response process is documented. We notify affected customers of any Personal Data Breach within 72 hours of becoming aware, as set out in Section 8 of our DPA.

• Application is hosted on a managed compute platform (Vercel) with automatic failover and multiple availability zones.
• Database backups are taken daily with thirty (30) day retention.
• Disaster recovery procedures are tested at least annually.

• AI calls send the minimum data necessary to perform the task (e.g. transaction descriptions for classification; extracted contract text for field extraction). Raw bank statement files are never sent to an AI provider.
• Calls are routed through the AI gateway; the underlying providers (Anthropic, OpenAI) are configured for zero data retention and do not use submissions for model training, as confirmed by their published data-use policies and account configuration.
• Output schemas are validated and recommendations are non-binding. No automated decision-making with legal or similarly significant effects on a data subject is performed within the meaning of GDPR Article 22.

• Raw bank statement files uploaded for an audit are deleted from primary storage within minutes of successful parsing. An automated daily sweep purges any orphaned files within seven (7) days at the latest.
• Parsed transactions, subscriptions, contracts, and audits are retained for the duration of the customer’s account and deleted within thirty (30) days of account or record deletion. Backups are purged on the rolling thirty (30) day backup-retention schedule.
• Workspacesmoved to the “soft-deleted” lifecycle state are hard-deleted thirty (30) days later, unless the Owner restores them in the interim.

• Each sub-processor is reviewed against our data-protection criteria before engagement and on material changes thereafter. The current list is at /legal/subprocessors.
• Data Processing Agreements (or equivalent terms) are in place with each sub-processor. We give Workspace Owners at least thirty (30) days’ notice before adding or replacing a sub-processor.

If you believe you’ve found a security vulnerability in Spendrein, please email security@spendrein.comwith a description and (where applicable) reproduction steps. We aim to acknowledge reports within one business day. Please do not disclose the issue publicly until we’ve had a reasonable opportunity to investigate and address it.