Architecture-enforced isolation. No cross-tenant data path. No biometrics. By design.

All recipient-facing surfaces and operator-facing dashboards run over HTTPS with TLS 1.2+ only. Older protocols and ciphers are explicitly disabled at the edge.

Recipient engagement events at rest are encrypted with AES-256 using cloud-provider managed keys. At launch, personally-identifiable inputs uploaded during draft-state configuration (recipient names, addresses, and email) are additionally encrypted at the field level with SweetNote's standard AES-256 envelope, so that database snapshots and engineering-side observability tools never expose draft-state PII in plaintext. See DPA § 13.1.

The platform runs on managed cloud infrastructure: Supabase for database, authentication, file storage, and edge functions; Netlify for static hosting, edge functions, edge CDN, and SSL termination. Both operate in US-East regions. Recipient engagement events are processed and stored in the United States; international expansion (UK, EU, Canada) is on the post-launch roadmap.

Data residency commitments specific to your engagement live in your DPA. The contractual posture at launch is US-only; EU / UK / Canada residency is on the post-launch roadmap. Non-US recipient data should not be submitted under the current DPA scope, see DPA § 4.

Production access is gated by least-privilege role-based access control, with all engineering access requiring multi-factor authentication. At launch, per-tenant data isolation is enforced at the database layer via Supabase Row Level Security (RLS), tenant data is not exposed across tenant boundaries even to an authenticated user, because the policy itself is evaluated by Postgres on every query.

Customer-side authentication at launch uses Supabase Auth, email magic-link sign-in (default), plus OAuth via Google and Microsoft; multi-factor authentication is on the roadmap. SAML / OIDC SSO will be included for every customer, with no enterprise gate and no contract addendum, and is commonly required by university, healthcare, and financial-services buyers — it rolls out post-launch. Email support@thesweetnote.com if SSO is a procurement requirement now and we'll wire it for your tenant ahead of the general rollout.

SOC 2 Type 1 audit is on the post-launch roadmap: a Type 1 tests how the controls are designed at a point in time, and it waits on engaging an independent auditor, not on an evidence window. Operating evidence is logged from launch, and Type 2 (which tests that evidence over a period) follows within 12 months of Type 1 completion.

Operating from day one: the controls SOC 2 codifies (access management, change management, encryption, incident response, vendor governance) are documented in the DPA and reviewable before contract signing. If SOC 2 Type 2 is a hard renewal prerequisite for your team, email us before you commit, we'd rather agree on the timing path in writing than after a contract.

Annual third-party penetration testing is on the standard ops calendar, beginning the quarter after early customer studies launch. Reports will be shareable under NDA once testing completes.

Pre-launch, the codebase is built against the OWASP Top 10 (injection, auth, XSS, CSRF) as a baseline development standard, and third-party dependencies are monitored for known vulnerabilities. This is our own internal review, not a third-party assessment; the independent penetration test above is what validates it. Specific practices and dependency-monitoring detail available on request.

SweetNote's subprocessor list is maintained as a public, versioned document at /legal/subprocessors.

Each subprocessor is engaged under data-processing terms consistent with the commitments we make to you. Adding a new subprocessor triggers a notice to existing customers with a 30-day window to object before activation.

• Supabase: managed Postgres, authentication, file storage, edge functions
• Netlify: static hosting, edge functions, edge CDN, SSL termination
• Mux: video encoding and adaptive delivery for the reveal page (no automated biometric analysis: face and voice-biometric identification disabled per BIPA exclusion — SweetNote requests only generated_subtitles from Mux, nothing else; automated speech-to-text captioning is enabled for accessibility and, per Mux’s own documentation and processing terms, produces a text transcript and derives no biometric identifier)
• Postmark (an ActiveCampaign company), transactional email (subprocessor-change notices, DSAR acks, opt-in campaign emails)
• Stripe: payment processing (brand checkout); also a source of conversion events for brands on Stripe that enable outcome attribution (the brand's own handler relays the processor's webhook event; no recipient PII crosses; SweetNote receives only the four declared fields (join key, value, currency, and timestamp), discarding the per-recipient value after incrementing the cell aggregate)
• Sentry (error monitoring): a beforeSend scrubbing hook redacts email addresses and access tokens, strips URL query strings, and never transmits request headers, cookies, or bodies; the recipient-facing reveal page does not load Sentry at all
• Better Uptime: public status page (status.thesweetnote.com) and uptime monitoring for the 99.0% Monthly Uptime SLA; monitors public endpoints only; no tenant data or recipient PII

SweetNote's incident response process is documented in the DPA and includes:

• Detection via continuous logging, automated alerting, and customer-reported channels
• Notification to affected customers without undue delay and in any event within 72 hours of becoming aware of a Security Incident affecting their Personal Data, per DPA §11
• Remediation with root-cause analysis and post-incident report shared with affected customers
• Disclosure publicly via the status page (status.thesweetnote.com) for incidents that affect platform availability

The incident-response runbook is in place at launch and set on a quarterly review cadence; affected-customer notification templates are written in advance so we can move fast if something goes wrong.

Suspected security issues should be sent to security@thesweetnote.com. Reports are acknowledged within one business day; we do not pursue legal action against good-faith researchers operating under the principles of disclose.io.

Public bug bounty program launches alongside SOC 2 Type 1.

The defaults documented in Section 13 of the DPA are: per-recipient Personal Data — the names, any addresses Customer supplied, and the identifying linkage that could tie an engagement event to a named individual — is automatically deleted 30 days after the engagement window closes. Engagement events themselves are processed in pseudonymous, token-keyed form (keyed to an opaque per-recipient token, never to a name); deleting the names and addresses on this schedule removes the only linkage that could connect those events to an identified person. From that point the events exist solely as de-identified data, retained in aggregate 24 months rolling to support period-over-period program comparisons and the cross-tenant benchmark dataset. Customer may negotiate an even shorter retention window in the MSA — the same option, wording, and scope for any customer who elects it.

Customer-initiated deletion (DSAR / right-to-be-forgotten) is processed within 10 business days of receipt, and propagated to all subprocessors that received the affected data. Audit log of every deletion is retained.

Exception: the outcome-attribution cell map. The pseudonymous token→(cohort, variation) cell map used for outcome attribution is purge-exempt from PII deletion. It holds no name, address, or engagement events — only the cohort and variation assignment — and is retained for 120 days post-activation (the platform-locked 90-day attribution window plus a 30-day closeout buffer), then deleted. This lets a conversion that occurs days or weeks after the CTA click still be attributed to the correct cohort cell. Conversions reported past day 90 post-activation are rejected outright — that is the data-minimization boundary. The map contains no PII and does not interact with the per-recipient deletion path.