Where each commitment stands
Every commitment shows whether it runs today.
Encryption
Live- TLS 1.2+ on every page and dashboard; older protocols off at the edge.
- AES-256 at rest with provider-managed keys.
- Names and addresses uploaded during setup are also encrypted field by field (DPA § 13.1).
Hosting and residency
Live- Supabase (database, sign-in, storage, server functions) and Netlify (hosting, CDN), US-East.
- US recipient data only under the current DPA (§ 4). UK, EU and Canada are on the roadmap.
Data isolation
Live- Postgres row-level security keeps each brand’s data in its own workspace.
- Server functions work out the brand themselves and never accept one from the caller.
- Holds even if another brand’s login is compromised. See the diagram.
Access control
Live- Least-privilege production access; multi-factor authentication on all engineering access.
- Customer sign-in by email link, Google or Microsoft. Customer MFA is on the roadmap.
- SSO (SAML / OIDC) for every customer, no enterprise gate, is on the roadmap. Need it now? Email support@thesweetnote.com.
SOC 2
Planned- Type 1 once an independent auditor is engaged; Type 2 within 12 months of it.
- Operating evidence logged from launch. Controls documented in the DPA, reviewable before you sign.
- If Type 2 is a hard requirement, email us before you commit and we agree the timing in writing.
Penetration testing
Planned- Annual third-party test, starting the quarter after early customer studies launch. Report shared under NDA.
- Today: built against the OWASP Top 10, dependencies monitored. That is our own review, not an independent one.
Incident response
Live- Notice without undue delay, and within 72 hours of becoming aware of a Security Incident affecting your Personal Data (DPA § 11).
- Root-cause analysis and a written post-incident report. Availability incidents posted at status.thesweetnote.com.
- Runbook and notice templates in place, reviewed quarterly.
Vulnerability disclosure
Live- Report to security@thesweetnote.com; acknowledged within one business day.
- Safe harbor for good-faith research under disclose.io principles.
- A public bug bounty launches alongside SOC 2 Type 1.
Data minimization
We record only what the study needs.
We record
- That a code was scanned, and when, keyed by a pseudonymous token, never a name.
- On the hosted video page: opens, plays, reactions and the call-to-action click, counted for everyone. Watch depth only with the recipient’s opt-in.
- Three coarse labels from the first scan: device type, OS family, US state or country. Reported in aggregate at the study’s close, small groups folded or withheld.
- Names and addresses only if you upload them, deleted on the schedule below.
- Per-recipient rows reach you only through the recipient-level export, or as study facts written to your own CRM records when you turn on CRM sync. You choose either in setup.
We never collect
- Biometrics: no camera, microphone, face or voice.
- Device fingerprints, cross-site or behavioral tracking.
- The IP address or user agent alongside a scan.
- Free text from recipients.
- Card or account details. Outcome attribution receives an amount, currency and time, and discards the individual amount.
- Anything stored on the device when the code opens your own site.
A Global Privacy Control signal stops what SweetNote derives and measures for itself: the scan labels, device codes, pressed-play, time-on-page, reaction, click and watch-depth records, and any cross-context sharing (SweetNote does none). Only the server-side open and a record that the signal was honored are kept; the open, like every recorded scan, remains the sending organization’s own study data.
Isolation
Your results stay yours.
Each brand works in its own workspace. No other brand ever sees your data, and the benchmark only ever uses pooled aggregates, never your rows or your brand name.
Brand A
Scans of Brand A’s codes
Brand A’s workspacerow-level security
Brand A’s dashboardBrand A’s team only
When active: pooled aggregates only
Brand B
Scans of Brand B’s codes
Brand B’s workspacerow-level security
Brand B’s dashboardBrand B’s team only
When active: pooled aggregates only
Cross-brand benchmark · not yet active
When it activates: aggregate cells only, read through a restricted database role. A cell stays empty until at least 10 other brands and 25 recipients contribute to it (your own brand never counts toward your comparison), and no cell names a brand. Details in the FAQ.
- Rates and counts. Counts always show. A rate, percentage or interval is withheld when its base is under 25 recipients, on every surface and in the database read path for sliced results.
- SweetNote staff. The operator console reads aggregates only; even the owner cannot see per-recipient data. Deletion requests are the one logged path to personal data.
Your own site · direct delivery
When the code opens your own site
- RecordedThe scan and its time, keyed by a pseudonymous token, plus the three coarse labels from the first scan. Then the person goes on to your page.
- On the deviceNothing stored: no cookie, no local storage.
- User agent and IPThe user agent screens out automated traffic and gives the device and OS labels; region comes from the host’s coarse location. Neither is stored with the scan. Hosting and database logs keep standard technical metadata briefly (DPA § 13).
- Global Privacy ControlNo label is kept and no booking reference is added to the redirect. The scan itself is still recorded and remains part of your study’s results: the signal stops what SweetNote derives for itself, not your own first-party record.
- Passed to your pageOnly what you printed on the code and a study-version label, the same for everyone in that version. Never a per-person value, with one opt-in exception: where offered, on a study with Outcome Attribution on and its Schedule accepted, the redirect carries an encrypted booking reference, new on every scan and meaningless outside SweetNote, in the URL fragment (so your server and logs never receive it; on a cal.com booking page it goes in the query, where cal.com reads it), and never when the browser sends Global Privacy Control.
Referrer-Policy: no-referrer, so your page never learns the code from the referrer. - WindowScans recorded for 90 days from activation; the readout settles on the first 30.
- Not recordedBefore activation or payment, before the pieces are marked mailed, while paused, after cancellation, after 90 days. The scan goes to your default page.
- If settings can’t be readYour default page or a plain try-again page, never a SweetNote error. Nothing recorded.
- Your pageWhat it collects is your own processing (DPA § 4A).
Retention
Each kind of data has its own deletion date.
- Day 0 to 90Scans and page events captured, keyed by a pseudonymous token. Nothing is recorded after day 90; the readout settles on the first 30 days.
- About day 60Names and addresses deleted, 30 days after the engagement window closes, with the scan labels and delivery dates. That removes the only link between an event and a person (DPA § 13).
- Day 120Outcome cell map deleted (Outcome attribution studies only). A token-to-cell map with no name or address that lets a later conversion land in the right group; conversions after day 90 are rejected.
- 24 monthsDe-identified events and aggregate counts deleted, on a rolling basis. Your settled study report stays while your workspace is open, and is deleted on request.
- Same for everyone. One schedule for every customer. The one per-study election is a shorter video window (default 5 years), asked for in writing before the study activates.
- Deletion requests. Processed within 10 business days, passed on to every subprocessor that received the data, and audit-logged.
Subprocessors
These providers process data for us, under our terms.
Versioned list at /legal/subprocessors. Each is engaged under data-processing terms consistent with ours to you. A new subprocessor triggers notice, with 30 days to object before it activates.
- SupabaseManaged Postgres, authentication, file storage, server functions.
- NetlifyStatic hosting, edge functions, CDN, SSL termination.
- MuxVideo encoding and delivery for the hosted video page. Face and voice-biometric identification disabled. SweetNote requests only
generated_subtitles: automated captions for accessibility, which per Mux’s documentation and terms produce a text transcript and no biometric identifier. - Postmark(an ActiveCampaign company) Transactional email to brand users only: sign-in links, team invites, study status and payment notices, subprocessor-change notices, deletion-request acknowledgements. SweetNote never emails recipients.
- StripeBrand checkout. Also a conversion source when a brand turns on Outcome attribution: SweetNote receives only join key, value, currency and timestamp, and discards the per-recipient value after updating the cell.
- SentryError monitoring. Redacts email addresses and access tokens, strips URL query strings, never sends headers, cookies or bodies. Not loaded on the recipient page.
- Better UptimeStatus page (
status.thesweetnote.com) and uptime monitoring for the 99.0% Monthly Uptime SLA. Public endpoints only.
Outcome attribution
Using Outcome attribution?
The suggested recipient-facing disclosure, the cookie row for the click-token path and how conversions are handled are on the Outcome attribution integration page.
Questionnaires
Your security questionnaire may already be answered.
Start with our pre-answered security questionnaire: answers in the usual SIG Lite and CAIQ domains, each with its source, and a CSV you can paste into your own form. Still need yours filled? Send it (SIG, CAIQ or your own) through the contact form; a complete answer set comes back within five business days. Architecture diagrams, key-management procedures and subprocessor DPAs are available under NDA.