Data Processing Agreement.

1. Background and scope

This Data Processing Agreement ("DPA") supplements the Master Services Agreement (the "MSA") between The Sweet Note, Inc., a Delaware corporation operating the SweetNote B2B platform ("SweetNote," "we," "us," or "processor"), and a business customer ("Customer," "you," or "controller") that engages SweetNote to process Personal Data relating to Customer's recipients (employees, donors, clients, partners, members, or similar individuals).

This DPA is entered into pursuant to and in accordance with applicable US Data Protection Laws, including the California Consumer Privacy Act and California Privacy Rights Act (CCPA / CPRA), the Illinois Biometric Information Privacy Act (BIPA), the Virginia Consumer Data Protection Act (VCDPA), the Colorado Privacy Act (CPA), the Connecticut Data Privacy Act (CTDPA), the Utah Consumer Privacy Act (UCPA), the Texas Data Privacy and Security Act (TDPSA), the Oregon Consumer Privacy Act (OCPA), the Tennessee Information Protection Act (TIPA), the Montana Consumer Data Privacy Act (MTCDPA), the Delaware Personal Data Privacy Act (DPDPA), the Iowa Consumer Data Protection Act (Iowa CDPA), the New Hampshire Data Privacy Act (NH DPA), the New Jersey Data Privacy Act (NJ DPA), the Minnesota Consumer Data Privacy Act (MN CDPA), the Maryland Online Data Privacy Act (MD ODPA, including its heightened sensitive-data provisions), the Rhode Island Data Transparency and Privacy Protection Act (RI DTPPA), the Kentucky Consumer Data Protection Act (KY CDPA), the Indiana Consumer Data Protection Act (IN CDPA), the Nebraska Data Privacy Act (NDPA), the Florida Digital Bill of Rights (FDBR), and any other US state data-protection law in force at the time of processing. SweetNote serves US-based Customers and US-resident recipients at launch; international expansion is on the post-launch product roadmap, and SweetNote will publish the data-protection and transfer frameworks then required for each recipient jurisdiction if and when international support is enabled.

2. Definitions

• Personal Data means any information relating to an identified or identifiable natural person that Customer (or anyone acting on Customer's behalf) provides to, or routes through, SweetNote, including recipient names, addresses, email addresses, the video creative Customer supplies, recipient-facing greeting text, sentiment selections, cohort tags, and any other per-recipient metadata Customer chooses to submit.
• Data Subject means the individual to whom Personal Data relates (typically Customer's recipients).
• Processing has the meaning given in applicable Data Protection Laws.
• Subprocessor means a third party engaged by SweetNote to process Personal Data on our behalf, the current list is at thesweetnote.com/legal/subprocessors.
• Security Incident means an actual or reasonably suspected breach of SweetNote's security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Personal Data processed by SweetNote. A suspected breach that investigation shows did not involve Personal Data is closed with a written note to Customer.
• Acceptable Use Policy or AUP means the content and conduct standards Customer agrees to in the MSA, governing the videos, text, and recipient lists Customer submits to SweetNote.

3. Roles of the parties

Under this DPA and for the Personal Data processed under the SweetNote service:

• Customer is the Data Controller (or a Business under CCPA / CPRA). Customer determines the purposes and means of processing Personal Data, decides which recipients receive a SweetNote campaign, and supplies the recipient data to SweetNote.
• SweetNote is the Data Processor (or a Service Provider under CCPA / CPRA). SweetNote processes Personal Data only on documented instructions from Customer.

SweetNote does not retain, use, sell, share, or disclose Customer's Personal Data outside the specific business purposes set out in this DPA and the underlying MSA. SweetNote does not combine Customer's Personal Data with Personal Data received from other Customers and does not use it for SweetNote's own commercial purposes, except that aggregated, de-identified data may contribute to (a) the cross-tenant benchmark dataset described in Section 4 of this DPA, and (b) SweetNote's external academic publications (including pre-print working papers on the Social Science Research Network, peer-reviewed journal articles, and methodology-replication datasets submitted to research data repositories such as the Open Science Framework). Both (a) and (b) publish only at the sample-floor thresholds documented in Section 4 (k ≥ 10 other contributing brands per benchmark cell (the comparator is the network excluding Customer, so a cell unlocks at eleven brands in total) and n ≥ 25 recipients per cell for the portal benchmark; the elevated k ≥ 15 contributing brands and n ≥ 50 recipients per cell for external academic publications) and never identify individual brands or recipients. Customers may separately opt in under MSA Section 7 to be acknowledged by name as a contributing dataset in external academic publications; that acknowledgment identifies contribution only and does not expose recipient-level data or change the elevated k ≥ 15 / n ≥ 50 academic-publication floor.

CCPA Service Provider commitments. Where SweetNote acts as a Service Provider under CCPA / CPRA (California Civil Code §1798.140(ag)), SweetNote additionally commits, with respect to the Personal Information it processes on Customer's behalf, to:

• Never sell or share Personal Information. SweetNote will not sell and will not share — as “sell” and “share” are defined at California Civil Code §1798.140(ad) and §1798.140(ah) — any Personal Information it collects pursuant to this DPA. This prohibition is absolute: it applies irrespective of the business purposes specified in this DPA and in the MSA, and no business purpose recited anywhere in either document authorizes a sale or a share. SweetNote receives no consideration of any kind for Personal Information and operates no cross-context behavioral advertising.
• Use Personal Information only for the specified business purposes. SweetNote will not retain, use, or disclose the Personal Information it collects pursuant to this DPA for any purpose other than the specific business purposes set out in Section 4 (Scope and nature of processing), nor for any commercial purpose other than those business purposes, nor outside the direct business relationship between SweetNote and Customer, except where the CCPA / CPRA expressly permits it.
• Comply with applicable CCPA / CPRA obligations. SweetNote will provide the same level of privacy protection as is required of a Business under CCPA / CPRA with respect to the Personal Information disclosed to SweetNote.
• Notify the Business if SweetNote cannot comply. SweetNote will notify Customer in writing without undue delay if SweetNote determines that it can no longer meet its obligations under CCPA / CPRA or this DPA, and SweetNote will cease processing the affected Personal Information except as directed by Customer or required by law.
• Permit reasonable steps to remediate unauthorized use. Customer may, upon notice to SweetNote and at reasonable intervals, take reasonable and appropriate steps to ensure SweetNote uses the Personal Information consistent with Customer's obligations under CCPA / CPRA, including by directing SweetNote to stop and remediate any unauthorized use of Personal Information identified by Customer.
• Submit to Business audits as set out in Section 12 (Audit rights) to verify SweetNote's compliance with these commitments and the rest of this DPA.

Analogous controller-processor commitments under VCDPA, CPA, CTDPA, UCPA, TDPSA, OCPA, TIPA, MTCDPA, DPDPA, Iowa CDPA, NH DPA, NJ DPA, MN CDPA, MD ODPA (including its heightened sensitive-data provisions), RI DTPPA, KY CDPA, IN CDPA, NDPA, and FDBR are honored on the same basis where SweetNote processes a covered consumer's Personal Data on Customer's behalf.

Customer-enabled integrations. When Customer configures an integration (for example, webhook destinations that deliver to Customer's own tools, including a CRM Customer points them at), Customer instructs SweetNote to forward the relevant Personal Data, typically pseudonymous per-recipient activity codes that Customer joins to Customer's own records, to Customer's chosen destinations. Each destination is Customer's own subprocessor (Customer chose it, Customer maintains the relationship, Customer is responsible for any privacy disclosures Customer's relationship with the recipient requires). SweetNote acts solely as a pass-through on Customer's documented instructions when forwarding to a Customer-configured destination.

4. Scope and nature of processing

Subject matter

The SweetNote B2B service: hosting and delivery of Customer-supplied video creative, generation of per-recipient QR codes, recipient-facing reveal pages (or, for a direct-delivery study under Section 4A, delivery of each scan to Customer's own page), engagement event capture per the consent architecture described in the privacy notice §5 (scan, video play, watch-depth, fixed three-tap reaction, CTA-click; reactions are anonymous in SweetNote's own dashboard and the cross-tenant benchmark dataset, and aggregated to the campaign; when Customer enables an integration (webhook destinations or similar), engagement events are forwarded to Customer's chosen destinations keyed by a pseudonymous per-recipient code, which Customer joins to their own records on their side; the reveal page does not accept open-ended text input from recipients), aggregate analytics, and ancillary email notifications.

Duration

For the term of the MSA, plus any period required to complete deletion or return of Personal Data as described in Section 13.

Nature and purpose of processing

(a) Ingesting Customer's recipient list. (b) Storing and serving Customer's uploaded video creative. (c) Generating, activating, and linking QR codes to per-recipient reveal pages or, for a direct-delivery study (Section 4A), to the web page Customer designates. (d) On studies that use a SweetNote-hosted reveal page, hosting the reveal page, playing the video, and capturing recipient engagement (the scan/open and its timing, the video-start event — pressing play — and the time-on-page record — how long the reveal was open, powering the aggregate Dwell metric — under legitimate interest; consent decision; consent-gated watch-depth measurement; and the action-as-consent universal three-tap reaction and outbound CTA-click events). (e) Sending transactional emails about the campaign to Customer’s operators (SweetNote does not email recipients). (f) Providing Customer with reporting, dashboards, and webhook event streams.

4A. Direct delivery to Customer's own page

Where Customer elects, for a study, to have each scan delivered to a web page Customer hosts instead of a SweetNote-hosted reveal page (“direct delivery”), the following applies to that study. The provisions of this DPA and of the privacy notice that describe the reveal page apply only to studies that use one.

• What SweetNote processes. SweetNote records that a QR code was scanned and when, keyed by the pseudonymous per-recipient token, under the same legitimate-interest basis, 90-day capture window and retention as other engagement events (Section 13). For this record SweetNote reads no IP address, reads the User-Agent only to screen out automated traffic and does not store it, and stores nothing on the recipient's device. Before the activation date, before payment, after cancellation, or if SweetNote cannot read the study's settings, a scan goes to the fallback page Customer designates and nothing is recorded; cancelling a direct-delivery study stops recording, but its codes keep reaching that fallback page.
• What reaches Customer's page. SweetNote passes to Customer's page nothing that identifies the recipient: only what Customer itself printed on the code and a label naming the study version the code belongs to, which is the same for every recipient of that version.
• Customer's page is Customer's processing. Customer is the controller of its page and of everything that page collects (including any analytics, cookies, forms or consent mechanism on it) and is responsible for the notices, consents and opt-out handling applicable law requires there. That processing is outside this DPA and is not part of the Services; SweetNote does not receive it. The reveal page's consent ribbon, reaction, watch-depth measurement and “About this outreach” link do not appear on a direct-delivery study, so Customer gives recipients any notice it owes them on the printed piece or on its own page.
• Benchmark and Outcome Attribution. Direct-delivery studies do not contribute to the cross-tenant benchmark. Outcome Attribution on a direct-delivery study is available only through the integration paths that do not use a click reference (DPA Outcome Attribution Schedule); the click-reference path is not available.

Categories of Data Subjects

Customer's employees, donors, clients, customers, partners, event guests, members, or similar individuals whom Customer designates as recipients.

Customer represents and warrants that: (a) no recipient is a minor under any applicable law, meaning no recipient under eighteen (18) years of age in general-consumer contexts, and no recipient under whatever higher threshold any applicable state age-appropriate-design statute imposes. For the avoidance of doubt, SweetNote does not knowingly process personal information of any child under thirteen (13) in any context; the federal Children's Online Privacy Protection Act ("COPPA") imposes additional duties on covered services for that age band, and SweetNote architects its B2B service to remain outside the COPPA-covered-service designation; (b) all recipients are U.S. residents at the time of the campaign, Customer agrees not to submit Personal Data of any non-U.S. resident (including EU, UK, Canadian, or other non-U.S. resident) to SweetNote until SweetNote enables international support and publishes the corresponding transfer mechanisms (see Section 9); and (c) Customer is responsible for ensuring recipient lists exclude minors and non-U.S. residents at the point of upload.

SweetNote does not knowingly process Personal Data of minors and does not knowingly process Personal Data of non-U.S. residents under this DPA. If SweetNote becomes aware that Customer has uploaded data that breaches the warranties in this Section, SweetNote will (i) suspend processing of that recipient's data, (ii) notify Customer in writing, and (iii) Customer indemnifies SweetNote under MSA §10 for any regulatory action arising from the unintended processing.

Categories of Personal Data

• Recipient identification: first name, last name (optional), email address (optional)
• Shipping address: street, apt/suite, city, state, ZIP code — optional in the recipient-list input mode (described below; provided only when Customer wants SweetNote to assemble its print-merge file), and not collected in count-only mode
• Customer-supplied content: per-recipient greeting text, sender attribution, optional inline note, video-creative reference
• Engagement data: the scan/open event and its timing, the video-start event (pressing play), and the time-on-page record (how long the reveal page was in the foreground, and how long it stayed open in total; sent each time the page moves to the background and once more as it closes; suppressed, with the video-start event, on a Global Privacy Control signal) — time first opened, any re-opens, whether play was pressed, and time on page, powering the aggregate Reach, Engagement, Speed, Rescanned, and Dwell metrics under legitimate interest; consent decision + timestamp; watch-depth measurement (how far through the video someone watched, consent-gated); sentiment selection (deliberate three-tap choice, action-as-consent); outbound CTA clicks (action-as-consent)
• Cohort metadata Customer supplies at QR-generation time: e.g., department, donor tier, segment, region, randomized variation
• Technical data: IP address and User-Agent, held only in hosting, database and email-provider logs for security and abuse prevention (the User-Agent is read to screen out automated traffic and is not stored with engagement data), kept for the server-log period in §13; and a random per-page-load session identifier stored with the engagement events on their schedule in §13
• If Customer enables Outcome Attribution on a campaign, additional pseudonymous Conversion Data fields are processed under the terms of the DPA Outcome Attribution Schedule (fields defined there; retention per §13). Conversion Data does not include recipient identifiers and is governed by that Schedule's data-minimization provisions.

Customer-elected input modes

The volume of recipient Personal Data SweetNote processes is determined by which of two input modes Customer selects when configuring each campaign. SweetNote does not print or ship; Customer handles fulfillment. The mode is recorded at QR generation and binds the data flow for that campaign:

• Recipient list (default): Customer uploads a recipient list. No field is required — SweetNote processes only the fields Customer chooses to include. First name (when provided) personalizes the reveal greeting; cohort_* tags drive aggregate analytics; the per-recipient reveal fields fill optional reveal slots; and postal address (when provided) is used solely to assemble the print-merge file SweetNote returns to Customer. Any field Customer does not include is not processed.
• Count-only: Customer uploads only a recipient count. Customer handles all addressing, printing, and shipping using the QR ZIP archive SweetNote returns. No recipient names, addresses, or per-recipient identifying data are processed by SweetNote.

Both modes preserve the aggregate-only output architecture, the n ≥ 25 per-cell suppression floor, and the BIPA exclusion attestation in §14.1. Customer's mode selection per campaign is recorded in the campaign metadata and is auditable on Customer request.

No model or AI training

SweetNote does not use Customer Personal Data, recipient engagement events, or Conversion Data to train, fine-tune, or evaluate machine-learning or artificial-intelligence models, whether SweetNote's own or any third party's. The de-identified, floor-aggregated data licensed under MSA § 6.3 may be used for statistical benchmark computation and the methodology research described there; that license does not extend to ML or AI model training.

Special categories of Personal Data

Customer should not submit special categories of Personal Data (such as data revealing racial or ethnic origin, political opinions, religious beliefs, health data, biometric data, or similar) through free-text fields unless contractually agreed. Customer-supplied videos may include likenesses of Customer's designated representatives. Customer attests in the MSA that videos comply with the AUP and that Customer holds appropriate releases for any individual whose likeness is included.

Regulated data

SweetNote is not a business associate under HIPAA, and the Services are not designed to hold nonpublic personal information under the Gramm-Leach-Bliley Act or education records under FERPA. Customer will not submit protected health information, financial-account data or education records in any field, including the cohort tags and the optional per-recipient message. A Customer that is a hospital foundation, a school, a college or a university confirms that its recipient list was lawfully prepared for this outreach under its own program before upload. If SweetNote later publishes a HIPAA or FERPA addendum, it is offered on the same paper to every Customer.

Cross-tenant benchmark and anti-reverse-identification controls

Aggregated, de-identified engagement data may contribute to (a) the cross-tenant benchmark dataset surfaced in the brand-facing dashboard and (b) SweetNote's external academic publications (including pre-print working papers on the Social Science Research Network, peer-reviewed journal articles, and methodology-replication datasets submitted to research data repositories such as the Open Science Framework). In each case publication occurs only at the sample-floor thresholds documented below (k ≥ 10 other contributing brands (the comparator is the network excluding Customer, so a cell unlocks at eleven brands in total) and n ≥ 25 recipients per benchmark cell, elevated to k ≥ 15 / n ≥ 50 for academic publication) and never identifies individual brands or recipients.

Anti-reverse-identification controls. SweetNote acknowledges that mere k ≥ 10-other-brands / n ≥ 25 cell suppression does not, on its own, prevent a sophisticated third party from inferring which contributing brand contributed which slice of the published dataset by triangulating on study size, methodology mix, timing of contribution, vertical, or other quasi-identifiers visible in published descriptive statistics. SweetNote therefore applies the following additional controls before any cross-tenant benchmark cell, working paper, or OSF-archived analysis dataset is made publicly available:

• (i) Cell-merge transformations. Where an individual benchmark cell would, by reason of its size, timing, or methodology fingerprint, be reasonably inferable to a particular contributing brand even at k ≥ 10-other-brands / n ≥ 25, SweetNote merges that cell into a coarser-grained cell (broader vertical, broader study-size band, broader time window) or suppresses it, until no published cell is reasonably inferable. The decision to merge or suppress is documented in the published methodology section.
• (ii) Suppression at higher floors for academic publication. Academic publications (working papers, peer-reviewed articles, OSF-archived datasets) apply suppression thresholds at k ≥ 15 contributing brands per published cell and n ≥ 50 recipients per published cell, materially higher than the portal benchmark's k ≥ 10-other-brands / n ≥ 25 floor. The higher floor for academic publication reflects the lower frequency of update, the broader public audience, and the indefinite archival persistence of academic outputs.
• (iii) Noise injection for quasi-identifiers. Where descriptive statistics include quasi-identifiers (study-size bands, timing windows, vertical descriptors), SweetNote applies bounded rounding or differential-privacy-style noise injection at scales documented in the published methodology section, sufficient to obscure single-brand attribution while preserving the precision of the aggregate effect estimate.
• (iv) Notification before publication. SweetNote will notify each Customer whose data contributed to a forthcoming academic publication at least thirty (30) days prior to public posting, providing the Customer with (A) the proposed publication, (B) a description of the suppression and transformation controls applied, and (C) an opportunity to raise a good-faith concern about reverse-identifiability. SweetNote will consider any good-faith Customer concern raised during the 30-day notice window and, where the concern is substantiated, will apply additional suppression or modify the publication before posting.
• (v) Right to exclude from a specific publication. Any Customer may, by written notice during the 30-day notice window in clause (iv), request that the Customer's contributing data be excluded from a specific academic publication. SweetNote will honor the request by re-running the analysis without the Customer's contribution and re-applying the k ≥ 15 / n ≥ 50 floor to the resulting cells. The publication's methodology section will note the number of post-notice exclusions received as a transparency measure, without identifying the excluding Customer.
• (vi) Benchmark cell “Collecting” state. Until the k ≥ 10-other-brands / n ≥ 25 floor is met for any portal benchmark cell, the cell renders in the brand-facing dashboard as “Collecting” without exposing the underlying count, the contributing tenant count, or any per-recipient detail. The cell remains in the “Collecting” state for as long as it would otherwise be reverse-identifiable.

The controls in this Section are operational commitments by SweetNote running alongside (not replacing) the sample-floor thresholds above. Customer's right to be informed in advance of publication under clause (iv) and to exclude under clause (v) are contractual rights independent of any Customer opt-in under MSA Section 7.

No-re-identification covenant. Consistent with the de-identification standard in California Civil Code §1798.140(m) and analogous state law, SweetNote covenants that it will not attempt to re-identify any individual recipient or any contributing brand from any de-identified or aggregated dataset; will maintain and use such data only in de-identified, aggregated form; and will contractually obligate any recipient of such data (including academic co-authors and research repositories) to the same commitments. This covenant, together with the aggregation and suppression controls above, is the predicate for SweetNote's position that the cross-tenant benchmark is not a “sale” or “share” of Personal Information under applicable US state privacy law. The Aggregate Insights license that authorizes this processing is granted in MSA Section 6.3.

5. Customer instructions

SweetNote processes Personal Data only on Customer's documented instructions, unless required to do so by applicable law. Customer's instructions for the duration of this DPA are comprised of:

• The terms of this DPA;
• The terms of the underlying MSA and any signed ordering document;
• The campaign configuration selections Customer makes through the SweetNote platform (recipient lists, cohort tags, reveal-page configuration, scheduled send windows);
• Any additional written instructions SweetNote and Customer mutually agree to.

If SweetNote reasonably believes an instruction from Customer violates applicable Data Protection Laws, SweetNote will inform Customer promptly and may suspend the affected processing until Customer revises the instruction.

6. Confidentiality

SweetNote ensures that personnel authorized to process Personal Data are bound by written confidentiality obligations or are under a statutory obligation of confidentiality. Access to Personal Data is restricted to personnel who have a need to know for the performance of their duties; access is logged.

7. Security measures

SweetNote implements and maintains appropriate technical and organizational measures designed to protect Personal Data against accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or access. These measures include, at minimum:

• Encryption in transit (TLS 1.2+) for all data flowing to and from the service.
• Encryption at rest (AES-256 or equivalent) for all Personal Data stored in databases, object stores, and backups.
• Per-tenant data isolation enforced at the database layer. SweetNote uses Postgres Row-Level Security (RLS) as the structural mechanism for tenant separation, applied in two complementary ways. Tenant-scoped tables carry RLS policies that restrict every query to the caller's own tenant, so a query bound to one tenant's session cannot read or write another tenant's data even with otherwise valid credentials. Tables holding recipient data run with RLS enabled and deny all access to application (brand and anonymous) roles entirely; only SweetNote's server-side functions read them, each scoped to a single tenant in code. No application user can read another tenant's data. This is enforcement at the database layer, not policy.
• Signed video playback URLs only. Recipient video creative is served via short-TTL signed playback URLs (typical TTL: 5 minutes) such that no public, scrape-able video URLs exist; expired URLs return HTTP 403.
• Role-based access controls; multi-factor authentication for all administrative access.
• Subprocessor governance, including DPA flow-down and 30-day notice on subprocessor changes.
• Documented incident-response procedures with defined notification windows.
• Annual third-party penetration testing (active after first paid customer studies launch; reports shareable under NDA).
• Documented vulnerability-disclosure policy.

The detailed security posture is published at thesweetnote.com/security.

8. Subprocessors

SweetNote may engage subprocessors to provide portions of the service. The current subprocessor list is published at thesweetnote.com/legal/subprocessors. SweetNote will:

• Provide Customer with at least 30 days' prior written notice of any new subprocessor or change to existing subprocessors. Notice is delivered to the email address on file; Customer may also subscribe to subprocessor-change notifications.
• Enter into written agreements with each subprocessor that include data-protection obligations no less protective than those in this DPA.
• Remain liable to Customer for any subprocessor's breach of the data-protection obligations imposed on that subprocessor under this DPA.

Customer may object to a new subprocessor on reasonable data-protection grounds within the 30-day notice window; SweetNote and Customer will work in good faith to address the objection. If the objection cannot be resolved, Customer may terminate the affected study or any subsequent study and receive a pro-rated refund for the unused portion of pre-paid fees per the refund policy.

9. Data residency and international transfers

9.1 Default US-only posture

SweetNote serves US-based Customers and US-resident recipients at launch. All Personal Data processed under this DPA is stored and processed in the United States (default region: US-East via Supabase managed infrastructure). SweetNote does not transfer Personal Data outside the United States in the ordinary course of providing the Services. If Customer has recipients outside the United States, Customer agrees not to submit such recipient data to SweetNote unless international support has been enabled for Customer in writing by SweetNote.

9.2 International support not yet enabled

SweetNote does not support the processing of non-US-resident Personal Data at launch. If and when SweetNote enables international support for a given recipient jurisdiction, SweetNote will publish and incorporate into this DPA the transfer mechanisms and supporting safeguards then required for that jurisdiction (including any required standard contractual mechanisms, transfer-impact assessment, data-residency election, and onward-transfer safeguards) before any non-US-resident Personal Data is processed. SweetNote will confirm such enablement to Customer in writing, and the then-current mechanisms will govern that processing.

Until SweetNote enables international support for a given jurisdiction, Customer’s submission of non-US-resident Personal Data is a breach of this DPA and triggers the indemnification obligations in MSA Section 10.4.

10. Data subject rights

SweetNote will assist Customer in fulfilling its obligations to respond to Data Subject requests (access, deletion, correction, portability, restriction of processing, objection) by providing Customer with the technical means to identify, retrieve, correct, or delete Personal Data processed under this DPA. SweetNote's standard SLA for providing the technical means in response to a Customer-routed request is 10 business days from Customer's submission of the routed request to SweetNote. Customer's statutory response window to the underlying Data Subject (e.g., the 45-day CCPA response window) runs from Customer's receipt of the original Data Subject request and is independent of SweetNote's 10-business-day processing SLA.

If a Data Subject contacts SweetNote directly with such a request, SweetNote will forward the request to Customer within five (5) business days of receipt and will not respond substantively to the Data Subject unless required by law or authorized by Customer.

Scope of pseudonymization. When SweetNote honors a pseudonymization request, we replace the recipient's identifying token on SweetNote's side and stop further activity tracking for that recipient. Records SweetNote already forwarded to Customer-enabled integrations (e.g., engagement events already written to Customer's own CRM) remain in Customer's systems; the recipient should contact Customer directly to request deletion from those systems.

Integration-destination disclosure. Where SweetNote forwards pseudonymous, token-keyed engagement events to a Customer-enabled integration destination, then so Customer can complete deletion on the integration side, SweetNote will provide Customer, on Customer's written request (and as part of any access or pseudonymization request SweetNote fulfills under this Section 10), the list of destinations that received events for the affected recipient_token, with first-seen and last-seen timestamps per destination, returned within the standard 10-business-day SLA above. The disclosure covers destination identity and counts only; the per-event payloads themselves went to the Customer-controlled destination, are deleted from SweetNote's systems once delivery settles (Section 13), and are not re-disclosed by SweetNote. The list covers delivery records still held under Section 13; a destination Customer has deleted is not included, because its delivery records are deleted with it. Outbound event forwarding is a Customer-enabled integration; this destination log is provisioned together with that integration.

11. Security incident response

SweetNote will notify Customer without undue delay and in any event within 72 hours after becoming aware of a Security Incident affecting Customer's Personal Data, with the detail known at that time and updates as the investigation proceeds. The notification will include:

• The nature of the Security Incident, including categories and approximate number of Data Subjects and Personal Data records affected;
• The likely consequences of the Security Incident;
• Measures SweetNote has taken or proposes to take to address the Security Incident, including mitigation steps;
• Contact information for the SweetNote point-of-contact for follow-up.

SweetNote will cooperate with Customer in good faith to investigate the incident and, where required, to provide notifications to regulators or affected Data Subjects. SweetNote will not notify a regulator or a Data Subject about a Security Incident affecting Customer's Personal Data on Customer's behalf without Customer's prior written approval, unless the law requires SweetNote itself to give that notice; in that case SweetNote tells Customer first where the law allows.

12. Audit rights

Customer (or an independent third-party auditor Customer engages) may audit SweetNote's compliance with this DPA at Customer's expense. Most audit requests are satisfied by SweetNote providing:

• The most recent SOC 2 Type 1 attestation (on the post-launch roadmap once the audit-evidence window from early customer studies builds; Type 2 within 12 months of Type 1 completion) or equivalent third-party audit report;
• Responses to Customer's reasonable written information-security questionnaires (SIG, CAIQ, custom);
• Access to SweetNote's information-security documentation (policies, procedures, incident-response plan) under NDA.

If the information above is insufficient to demonstrate compliance, Customer may conduct an on-site inspection on 30 days' prior written notice, no more than once per calendar year (unless a Security Incident or regulatory requirement justifies additional inspections), during normal business hours, and subject to reasonable confidentiality and security obligations. Cost-shifting: if the audit identifies a material non-compliance with this DPA that is attributable to SweetNote, SweetNote will reimburse Customer's reasonable, documented audit costs and will remediate the identified non-compliance within thirty (30) days of the audit findings (or such longer period as the Parties reasonably agree based on the nature of the remediation).

12.1 Data Protection Impact Assessment

SweetNote maintains and completes a Data Protection Impact Assessment (DPIA, or equivalent risk assessment under applicable U.S. state law) for any material new processing activity that involves a likely high risk to the rights and freedoms of recipients, including any feature involving systematic or large-scale automated evaluation. A DPIA-equivalent risk assessment has been completed for the Outcome Attribution Schedule processing and is available to Customer under NDA on request to legal@thesweetnote.com. Where applicable U.S. state law treats a processing activity as assessment-triggering, SweetNote will complete the corresponding assessment before initiating that processing and will make it available to Customer to support Customer’s own controller-side obligations.

13. Return and deletion of Personal Data

On termination or expiration of the MSA, or on Customer's written request, SweetNote will (at Customer's option) either return all Personal Data processed on Customer's behalf to Customer in a commonly used format, or securely delete all such Personal Data from SweetNote's systems and instruct subprocessors to do the same. Default if Customer does not elect within 30 days of termination: Personal Data is deleted on the retention schedule below. That schedule runs on its own clock whether or not the MSA is still in force, so nothing is kept longer because the relationship ended, and nothing is deleted sooner than the schedule states. What remains after the schedule has run is only what it names as outliving the Personal Data: consent records and audit logs for their stated periods, de-identified aggregates, anything a legal hold requires, and any artifact Customer itself exported. SweetNote confirms completion in writing on request.

Default retention (if Customer does not instruct otherwise). SweetNote retains data on the following schedule:

• Per-recipient Personal Data (names, any addresses Customer supplied, and the identifying linkage that makes engagement events linkable to an individual): automatically deleted 30 days after the engagement window closes. Engagement events are themselves 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 linkage that could connect those events to an identified individual. The same pseudonymous processing posture applies as under the DPA Outcome Attribution Schedule.
• Per-recipient Personal Data on a campaign that was issued QR codes but never went live (for example, an invoice that was never paid, or a video that never became available): automatically deleted 60 days after the campaign's scheduled activation date, and never sooner than 30 days after the first deletion notice. SweetNote sends deletion notices to Customer's workspace owner 30, 14 and 1 days before deletion, and deletion takes effect on or after the date stated in the notice. The print files that include recipient names are deleted with the data, within one day. The campaign's QR codes are not deleted and remain valid: if Customer takes the campaign live later, its reveal pages open without the recipient's name. Taking the campaign live before the stated date keeps the data, which then follows the schedule in the preceding item. Choosing a new activation date moves the deletion to 60 days after the new date, with new notices. A legal hold suspends this deletion; when the hold is released, a new 30-day notice period starts.
• Per-recipient Personal Data on a cancelled or refunded study: automatically deleted 30 days after the cancellation or refund. The study's QR codes are retired at cancellation and no longer resolve to a recipient. A legal hold suspends this deletion.
• Per-recipient delivery timestamps (when a card was delivered, and where that date came from, if Customer or its mail provider supplies them): deleted on the same schedule as the Per-recipient Personal Data above, 30 days after the engagement window closes. Before that, the settled study report records only the aggregate delivery-timing figures (never a per-recipient date), which are retained with the report.
• Aggregate and pseudonymous engagement events without recipient identifiers: retained 24 months rolling to support period-over-period program comparisons and the cross-tenant benchmark dataset described in Section 4. Engagement events are captured during the campaign's engagement-tracking window — the pseudonymous, token-keyed capture window that opens on activation and runs to a hard bound of 90 days post-activation. That capture window comprises the 30-day engagement window on which SweetNote's reporting is based, plus an observation tail through day 90 that is banked only in pseudonymous, token-keyed form and is never surfaced as a per-recipient record. Once the identifying linkage above is deleted (30 days after the engagement window closes, approximately 60 days post-activation), these events are de-identified and retained only in this pseudonymous form for the 24-month period stated above.
• Settled study report (the aggregate report frozen when a study's engagement window closes: counts and floored rates, with no recipient identifiers): kept with no fixed end date and available in the portal while Customer's workspace is open; it is not subject to the 24-month window in the preceding item. Live dashboard filtering and new cohort re-cuts draw on the aggregate engagement data in that item and are available for the 24-month Dashboard-access tail defined in MSA Section 1.1. Customer may ask SweetNote to delete a settled report at any time after the study closes. Deletion removes the report and any Outcome Attribution results frozen with it, is permanent, and is suspended by a legal hold; it does not shorten the retention of the aggregate engagement data in the preceding item. Any artifact Customer has exported or downloaded is Customer's to keep.
• Customer-supplied video creative: retained 5 years from upload to support recipient revisits. Customer may ask in writing, before a study activates, for a shorter window for that study's video; SweetNote records the shorter window on the study, and the video goes off serving and is deleted at that date instead.
• Consent records (consent timestamp + consent-text version active at the time of consent): retained 5 years from date of consent for audit purposes.
• Audit logs (integration events, role changes, account actions, DSAR fulfillment records): retained for at least 7 years for compliance, dispute resolution, and procurement-audit purposes.
• Server logs (technical metadata, IP, User-Agent, request paths, categorized as Personal Data per Section 4 but retained separately for security purposes): retained up to 45 days for security, abuse-prevention, and incident-response purposes (hosting and database logs 7 days or less; transactional email delivery logs, held by our email provider, 45 days).
• Token Map (Outcome Attribution): 120-day hard ceiling per the DPA Outcome Attribution Schedule §8 (applies only when Customer enables Outcome Attribution on a campaign). On such a campaign, the cohort tags Customer supplied are kept with the Token Map until its 120-day ceiling, then deleted.
• Outcome Attribution test receipts (applies only when Customer enables Outcome Attribution): a record of each test conversion, each request made with a test key, and each refused live conversion, with the reason, shown in the portal so Customer can check its wiring. Receipts contain no amount, no recipient token and no Personal Data, and are deleted 30 days after they are received. A legal hold suspends this deletion.
• Recipient-level export (opt-in): introduces no new retention window. When Customer enables the recipient-level export, the pseudonymous, recipient-level data file is generatable only while it draws on the per-recipient Personal Data above — through the same 30-day-post-close horizon — after which the data is purged and the export can no longer be assembled. Governed by the DPA Recipient-Level Export Schedule §8.
• Engagement events forwarded to a Customer-enabled integration destination (outbound webhooks; pseudonymous, keyed to the recipient token): the contents of each event are deleted as soon as every destination has received it or delivery has failed five times. An event that still cannot be delivered 30 days after it was queued (for example, while a destination is paused) is dropped, and its contents are deleted within one day after that. SweetNote keeps a delivery record without the event contents (destination, status, attempts, response code, timestamps and, for per-recipient events, the pseudonymous recipient token) so it can provide the destination list described in Section 10; these records are deleted 24 months after they were created. Deleting a destination also deletes its delivery records. A legal hold suspends the 24-month deletion; it does not stop event contents from being deleted.

The windows above are the same for every Customer. The one per-study election is the shorter video window described above; SweetNote does not run a different retention schedule for one Customer than for another. Legal-hold exceptions: SweetNote may retain Personal Data for longer where required by applicable law (e.g., tax records, dispute retention, compelled legal process); the basis will be documented in writing on request.

13.1 Draft-state recipient data (pre-payment)

The SweetNote portal allows Customer to configure a campaign, including uploading a recipient CSV, before the campaign is paid for and launched. Personal Data uploaded into a campaign in draft state (a campaign that has been configured but not yet paid for and launched) is held under the same security measures described in Section 7, and is governed by the following additional commitments:

• Encryption at rest. Recipient names, addresses, email addresses, and any other Personal Data uploaded during draft-state configuration are encrypted at the field level using SweetNote's standard AES-256 encryption envelope. Engineering-side observability tools and database snapshots do not expose draft-state Personal Data in plaintext.
• No QR generation, no reveal page, no recipient activation. No QR code is generated, no reveal page is provisioned, and no recipient can scan or be scanned, until Customer records commercial commitment for the corresponding campaign and SweetNote completes the activation-date-gated resolution described in the MSA. Draft-state recipient data exists solely to render Customer's campaign-configuration view in the portal; it is not used for any service delivery, not exposed to any subprocessor beyond storage infrastructure, and not made addressable through any external interface.
• No analytics processing. Draft-state Personal Data is not processed for engagement analytics, benchmarking, or any other analytical purpose, analytics processing begins only after the campaign records commercial commitment, QR generation completes, and recipients begin engaging with activated reveal pages.
• Customer-initiated deletion. Customer may delete a draft campaign (and all associated recipient Personal Data) at any time from the SweetNote portal. Deletion is propagated to backups within the rotation window of the backing infrastructure (currently daily backups with a 7-day retention window via Supabase Pro). SweetNote will provide written confirmation of deletion on request.
• Automatic abandonment cleanup. Recipient Personal Data uploaded to a draft campaign that is never committed to a paid study is automatically deleted 90 days after it is uploaded. Customer is notified by email 30 days, 14 days, and 1 day before automatic deletion fires, with an option to extend the retention window (no fee); an extension may be exercised more than once but never carries recipient Personal Data past 180 days from upload, which is the outer limit under this Agreement. The draft campaign record itself — without recipient Personal Data — is archived after 180 days of inactivity. Aggregate campaign-configuration metadata (methodology selection, sample-size target, draft name) may be retained beyond these windows in pseudonymized form for product-improvement purposes; recipient PII is not.
• No use as benchmark seed data. Draft-state Personal Data is never used to populate cross-tenant benchmarks or any aggregate dataset described in Section 4. The benchmark dataset draws exclusively from paid, launched, and consented campaign data.

What this means in plain language for Customer's legal team. The draft state exists so Customer's team can fully configure and review a campaign, including the recipient list, before deciding to commit to and launch it. The data-handling commitments above ensure that recipient PII held during this window is protected to the same standard as a live campaign, never used for purposes beyond rendering Customer's draft, and deletable by Customer at any time. The architectural rule is: account = configuration; QR generation = recipients = commercial commitment + activation date. Draft state is part of configuration; nothing recipient-facing happens until commercial commitment is recorded and the activation date arrives.

14. Biometric and content-moderation exclusions

14.1 Biometric Information Privacy Act (BIPA) exclusion attestation

For Customer's avoidance of doubt with respect to the Illinois Biometric Information Privacy Act, 740 ILCS 14 (BIPA), and analogous state biometric privacy statutes:

• SweetNote does not collect, capture, purchase, receive through trade, or otherwise obtain biometric identifiers or biometric information (as those terms are defined in BIPA) from Customer's recipients.
• SweetNote does not apply face geometry, voice template, retina or iris scan, fingerprint, or hand-scan analysis to any Personal Data processed under this Agreement.
• Recipient sentiment is captured exclusively as a deliberate three-tap selection ("Sweet / So sweet / The sweetest"), a self-reported preference, not a biometric measurement.
• Because no biometric processing occurs in the SweetNote pipeline, the service is delivered to recipients in all 50 U.S. states, including Illinois.

14.2 No automated content moderation of Customer-supplied video

SweetNote does not run automated content moderation, biometric analysis, content-classification, or similar automated review on Customer-supplied videos. Specifically:

• Customer-supplied videos are not run through automated biometric analysis or content-moderation services that retain biometric data. Customer attests in the MSA that Customer-supplied content complies with the AUP and that Customer holds appropriate consent and releases from any individual whose likeness is included in the video.
• Subprocessor configuration. SweetNote has configured its video subprocessor (Mux) so that no automated biometric analysis runs on Customer-supplied videos: specifically, automated face detection/recognition and voice-biometric (speaker-identification) features are disabled. SweetNote does enable Mux's automated speech-to-text captioning (auto-generated subtitles) for accessibility (WCAG conformance); this produces a text transcript of spoken words and does not derive, store, or match any biometric identifier. Any future change that would enable a biometric-analysis feature, or that would otherwise alter the configuration described in this Section, is subject to the change-of-terms process in Section 16 (30-day notice; Customer's written acceptance required to take effect).
• Configuration verification. SweetNote performs an internal configuration audit of the Mux account at least once per calendar quarter to confirm no biometric-analysis or automated-content-moderation features are enabled. The current configuration state is attestable to Customer on request to legal@thesweetnote.com; an attestation describing the Mux configuration as of the request date will be returned within ten (10) business days. SweetNote will additionally notify Customer if a Mux product change introduces a feature that would require explicit opt-out to maintain this exclusion, and will exercise that opt-out as part of the standard subprocessor change-notification process in Section 8.

SweetNote will provide a counter-signed copy of this attestation to Customer's legal team on request, alongside the executed DPA, for inclusion in Customer's vendor records.

15. Limitation of liability

Each party's liability under this DPA is subject to the limitations and exclusions set out in MSA Section 9. For clarity, claims arising from a Security Incident, data breach, or other violation of this DPA are subject to the Data-Protection Cap in MSA §9.2(a) (the greater of 2× the General Cap or $500,000), not the General Cap. Direct damages arising from a SweetNote breach of this DPA, including breach-response costs, regulatory fines properly assessed against Customer, notification costs, and credit-monitoring services for affected recipients, are direct damages and are not excluded by the MSA consequential-damages waiver. Nothing in this DPA excludes or limits either party's liability for (a) breach of confidentiality obligations, except that a claim arising from a Security Incident, data breach or other violation of this DPA is governed by the Data-Protection Cap as MSA §9.3(a) provides, even where it is also characterized as a breach of confidentiality, (b) gross negligence, fraud, or willful misconduct, or (c) liabilities that cannot be excluded under applicable law.

16. Term, survival, and changes

This DPA enters into force when both parties have executed the MSA and remains in force for so long as SweetNote processes Personal Data on Customer's behalf. Sections 4 (the cross-tenant benchmark and anti-reverse-identification controls, including the no-re-identification covenant, for as long as SweetNote retains or publishes any aggregated data derived from Customer's use), 6 (Confidentiality), 8 (Subprocessors), 10 (Data subject rights, for as long as SweetNote retains Personal Data subject to the retention schedule in Section 13), 11 (Security incident response), 13 (Return and deletion), 14 (Biometric and content-moderation exclusions, including §14.1 BIPA and §14.2 no automated content moderation), and 15 (Limitation of liability) survive termination.

SweetNote may update this DPA where required to comply with applicable law or to reflect material service changes; substantive changes are communicated to Customer with at least 30 days' notice and require Customer's written acceptance to take effect. For updates required by changes in applicable law, Customer's acceptance will not be unreasonably withheld.

17. Governing law and jurisdiction

This DPA is governed by the law of the jurisdiction specified in the underlying MSA. Disputes are resolved in the forum specified in the MSA. Where the MSA does not specify, this DPA is governed by the laws of the State of Delaware, with exclusive venue in the state and federal courts located in Wilmington, Delaware (subject to the equitable-relief and confidentiality carveouts in the underlying MSA).

18. Contacts

SweetNote / The Sweet Note, Inc.
Data Protection contact: privacy@thesweetnote.com or legal@thesweetnote.com
Security incident contact: security@thesweetnote.com
DSAR routing: privacy@thesweetnote.com or legal@thesweetnote.com (both addresses reach the same intake queue)

19. Execution

This DPA is executed by both parties alongside the MSA. Acceptance is binding immediately upon Customer's in-portal acceptance at checkout (clickwrap, fully enforceable under E-SIGN/UETA). SweetNote's counter-signature is applied automatically by the platform typically within minutes of Customer's acceptance, and the counter-signed PDF is stored in the Customer's portal at Settings → Contracts and emailed to the contact on the Customer's account for the audit file. The DPA is offered as published, same paper for every brand, and is not redlined; structural fairness across customers is treated as a product commitment. Questions are answered inline rather than negotiated.

Pre-launch note. SweetNote is operating in early-customer cohort through the platform's first paid studies. Some control attestations referenced in Section 7 (e.g., SOC 2 Type 1) reach formal completion on the post-launch roadmap once the audit-evidence window from early customer studies builds. Estimated targets and updates are published on /security; the DPA controls themselves are operating-day-one. If SOC 2 Type 1 or Type 2 is a hard renewal prerequisite for your team, email us before you commit so the timing path can be agreed in writing rather than at renewal.