— Security & Trust

How we protect what you give us.

Last updated: 2026-08-17

We're honest about where we are. Mallin is pre-SOC 2, late-stage design partner. The architecture is built for enterprise security; the formal attestations are being sequenced. This page describes what's true today and what's in progress, with no aspirational claims dressed up as current state.

Architecture in one paragraph

Mallin is a multi-tenant SaaS application. Each customer is a separate tenant; every customer record carries a tenant identifier and every read and write is scoped to it. The product is hosted on Vercel (US-East), backed by Supabase (Postgres, US-East), authenticated through Clerk, and delivers AI inference via Anthropic's Claude API. CRM integrations (HubSpot live; Salesforce, Pipedrive planned) are OAuth-based and write through to your CRM as the system of record — Mallin does not maintain a parallel data plane (see AI Governance for the doctrine).

Encryption

  • In transit: TLS 1.3 on all customer-facing endpoints. HTTP requests are redirected to HTTPS. HSTS enforced.
  • At rest: AES-256 via our infrastructure providers (Supabase, Vercel). All customer data, backups, and audit logs encrypted.
  • Secrets: API keys, OAuth tokens, and other secrets stored in Vercel's encrypted environment variable store. Never committed to source control. Rotated on personnel changes.

Authentication & access control

  • Customer authentication: handled by Clerk (SOC 2 Type 2). Email + password by default; MFA available (TOTP, recovery codes).
  • Multi-tenant isolation: every database query filters by tenant_id. Enforcement is in the application layer today; database-level enforcement is on the security roadmap (see below).
  • Mallin team access: production database access is limited to engineering staff (currently the founder) via service-role credentials stored in a password manager. Administrative writes, exports and deletions are recorded in an audit log; read-access logging is not yet implemented.
  • Least privilege: service-role credentials are held server-side only. Frontend code never sees them, and they are never exposed to the browser.

Multi-tenant isolation

Every table that stores customer data carries a tenant_id column, and application code filters by tenant on every read and write. That is the boundary that is enforced today.

Planned — Three further layers are on our security roadmap and have not yet been built: a shared data-access layer that would make the tenant filter structurally impossible to omit, an automated cross-tenant test suite that attempts unauthorised reads across every customer-data surface, and database-level Row-Level Security, which would enforce the boundary independently of application code. We would rather name these as planned than describe controls we have not finished. We will publish results on this page as each one lands.

Audit logging

We log security-relevant events: CRM writes (who wrote what to where, when), AI calls (prompt + response metadata, not full content), data exports, deletions, and account modifications. Authentication events are recorded by Clerk, our identity provider. Audit logs are retained for the life of the account.

Planned — Read access by Mallin staff is not recorded in the audit log today. That instrumentation, and a customer-facing query API, are on the security roadmap and have not yet been built.

Backups & disaster recovery

  • Database backups: managed by Supabase under our current plan. We can confirm the exact backup window and point-in-time recovery coverage in writing on request.
  • Recovery objectives: we target a full database restore within 4 hours. We have not yet run a documented restore drill, so we describe this as a target rather than a tested commitment.
  • Code/configuration: source code and deployment configuration in GitHub; Vercel maintains immutable deployment history for rollback.

Incident response

We maintain an incident response playbook covering: detection, triage, containment, customer notification, post-incident review.

Notification commitment: if we become aware of a security incident affecting your data, we will notify you within 72 hours with the facts we have at that time, and we will continue to update you as the investigation progresses.

Report a suspected vulnerability: brendan@mallin.io with "Security" in the subject. We acknowledge within 24 hours.

Data deletion

Customer-initiated data deletion: email brendan@mallin.io from an account-owner email address. We acknowledge within 24 hours and complete deletion within 30 days, including backups.

On account closure: all customer data is purged from active systems within 30 days and from backups within an additional 30 days, per the Privacy Policy retention schedule.

Compliance posture

FrameworkStatusNotes
SOC 2 Type 1PlannedFormal engagement scoped for after first paid customer. Architecture is SOC 2-aligned today; the attestation lags.
GDPRAlignedDPA available on request. Subject-rights workflow operational. Standard Contractual Clauses for EU→US transfers where applicable.
CCPA / CPRAAlignedSubject-rights workflow operational. We do not sell personal information.
HIPAANot in scopeMallin is not currently designed for protected health information. Do not upload PHI.
PCI DSSNot in scopeMallin does not collect or process payment card data.

Vendor security questionnaires

If your security team needs a SIG, CAIQ, or custom questionnaire filled out, or if you need us to sign a DPA or NDA before exchange, email brendan@mallin.io with the request. We turn these around within 48 hours during design-partner phase.

What we will not do

  • Sell or rent your data.
  • Use your deal content to train shared AI models.
  • Share your data with other Mallin customers.
  • Provide your data to law enforcement without legal process; if compelled by valid process, we will notify you unless prohibited.
  • Maintain a parallel data plane that diverges from your CRM (see AI Governance and Terms).