Trust

Security at GiveTone

The best way to protect donor data is to never hold it in the first place. That's the foundation GiveTone is built on — and the rest of our security program follows from that choice.

Architecture

Zero-knowledge on donor data

GiveTone is designed so that donor names, donor email addresses, donor mailing addresses, phone numbers, and giving history never reach our servers. Not encrypted on our servers. Not temporarily cached. Not routed through our AI pipeline. Not in our logs. They are simply not part of the data we handle.

This is not a policy we enforce with procedures — it's an architecture we enforce with code. No database table, no API route, and no frontend form accepts donor-level data as input.

How the mail merge works

  1. You describe your campaign (the occasion, the tone, the stories you want to tell). We send that description to Claude, along with your brand kit. Donor data is not involved because we don't have any.
  2. Claude returns a letter template containing placeholder tokens —{{first_name}},{{preferred_salutation}},{{org_name}}, and so on.
  3. You export that template from GiveTone as a Word document, HTML file, or CSV ready for Mailchimp, Constant Contact, Salesforce NPSP, or one of the other platforms we support.
  4. Substitution happens in your platform, on your computer, with your donor list. GiveTone never sees the final, personalized letters.

The result: if GiveTone were breached tomorrow, an attacker would find brand kits, letter templates, and campaign descriptions — but no donor list, no email addresses to phish, and no giving history to sell.

What we do protect

The data we do hold — your account, your brand kit, your generated templates — is protected with standard industry practice:

  • Encryption in transit: all traffic to and from GiveTone uses TLS 1.2 or higher.
  • Encryption at rest: data stored in our database and object storage is encrypted at rest.
  • Tenant isolation:we use row-level security policies in our database so that your organization's records can only be read by authenticated users in your organization. This is verified by an automated cross-tenant smoke test that runs against every schema change.
  • Authentication: passwords are hashed using industry-standard algorithms. We support email-based sign-in today, with support for passkeys and SSO planned.
  • Access controls: access to production systems is limited to a small number of engineers, with logged sessions and short-lived credentials.
  • Audit logging: significant actions (sign-ins, permission changes, billing events) are logged for our own review and to support investigations.

Our infrastructure

  • Hosting: Vercel (application), Supabase (database and authentication). Both are SOC 2 Type II audited.
  • AI:Anthropic (Claude). We send your brand kit and campaign inputs for inference; we do not send donor data because we don't have any.
  • Payments: Stripe. Handles card data directly; we never see full card numbers.

Responsible disclosure

If you believe you've found a security vulnerability in GiveTone, please email [email protected] with the details. Please:

  • Give us a reasonable window to investigate and fix before disclosing publicly
  • Avoid accessing data that doesn't belong to you
  • Avoid attacks that could degrade service for other customers

We'll acknowledge receipt within two business days and keep you updated on our progress. We don't yet run a formal bug bounty, but we're genuinely grateful for responsible reports and happy to publicly credit researchers who help us.

Where we're going

GiveTone is early. We're not SOC 2 certified yet, and we don't promise things we can't deliver. As we grow, we'll formalize the controls we already practice — with third-party audits and a public trust center. For nonprofits that need more than the above today, email [email protected] and we'll share what we can.