Data Processing Addendum (DPA)

DRAFT — pending operator legal sign-off. Short-form DPA reflecting the platform's actual processing (audited 2026-07-24). The operator is an Australian business: this DPA is anchored in the Privacy Act 1988 (Cth)/APPs and written GDPR-aware. Requires counsel review. EEA/UK customers are out of scope for the current release (ratified 2026-07-30), so the SCC module referenced in §9 remains incorporated-by-reference only; it must be made execution-ready before any EEA/UK customer is onboarded.

This DPA forms part of the Terms of Service between [OPERATOR LEGAL ENTITY NAME] ("Processor", "we") and the customer ("Controller", "you") and applies to personal data of your email recipients that we process on your behalf ("Recipient Data").

1. Roles and scope

You are the controller of Recipient Data (you decide whom to email and on what consent basis); we are your processor. This DPA does not cover (a) your own account data, for which we are an independent controller under our Privacy Policy, or (b) the limited platform-protection processing in §8, for which we are an independent controller. "Controller" and "processor" are used in their GDPR sense as widely understood labels; Australian law does not draw this distinction, and each party must in any event handle personal information in accordance with the Privacy Act 1988 (Cth) and the APPs to the extent they apply to it.

2. Details of processing

• Subject matter / nature: hosting and managing contact lists; building campaign audiences; rendering and transmitting email; processing delivery results, bounces, and complaints; recording opens, clicks, and unsubscribes; maintaining suppression lists.
• Duration: the term of the agreement, plus the retention periods in §7.
• Data subjects: your contacts/recipients.
• Categories of data: email address; optional name fields; any custom fields you choose to upload; delivery and engagement events including IP address and user-agent of opens/clicks; bounce/complaint reports; unsubscribe and preference records.

• Special categories: none intended; you must not upload special-category or children's data. Custom fields are free-form — this prohibition is your obligation.

3. Instructions

We process Recipient Data only on your documented instructions: the Terms, the AUP, this DPA, and your configuration actions in the product (imports, list edits, campaign sends, deletions). The following are standing documented instructions built into the service, which you accept by using it:

1. automatic insertion of unsubscribe mechanisms and immediate enforcement of opt-outs;
2. open- and click-tracking with bot/Apple-MPP classification as described in the Privacy Policy;
3. suppression enforcement at audience build and again pre-send;
4. the retention carve-outs in §7.

We will inform you if we believe an instruction violates applicable data-protection law.

4. Confidentiality and personnel

Access to Recipient Data is limited to personnel who need it to operate the service and who are bound by confidentiality. Administrative access to customer accounts is audit-logged.

5. Security (Annex-level summary of actual measures)

TLS in transit on public endpoints and outbound SMTP where the receiving server supports it (required by default); per-tenant isolation enforced in the data-access layer; HMAC- signed, non-enumerable tracking/unsubscribe tokens; application-layer encryption (AES-256-GCM) of relay credentials; hashed passwords; secrets stored outside the application with restricted permissions; append-only event and audit logs; automated abuse guardrails; continuous off-site database backups (WAL archiving + nightly backups), AES-256-encrypted before upload, with a weekly automated restore drill.

6. Sub-processors

You authorize the following sub-processors for Recipient Data:

Stripe processes customer billing data only, not Recipient Data, and is listed in the Privacy Policy rather than here. Outbound email is sent from our self-hosted mail server — no third-party ESP touches Recipient Data. We will give 30 days' notice of new sub-processors; you may object on reasonable data-protection grounds, and if we cannot resolve the objection you may terminate the affected service.

7. Deletion, return, and retention carve-outs

• During the term: the product provides per-contact erasure. Erasure deletes the contact record, list memberships, import-error rows containing the address, and any not-yet-sent queue entries.

• Carve-outs (standing instruction / legal-obligation retention): we retain (a) the bare suppressed email address so opt-outs keep working (including after erasure or termination); (b) consent attestations; and (c) minimal send-proof records for messages already dispatched (recipient address, consent basis, dispatch state) as evidence of anti-spam-law compliance — under the Spam Act 2003 (Cth) the sender bears the burden of proving consent, and equivalent record-keeping expectations apply under CASL for mail into Canada and CAN-SPAM for mail into the US; where the GDPR applies, Art. 17(3)(b)/(e) supports this retention. Structured bounce/complaint records are retained as deliverability and compliance evidence; raw bounce/complaint report payloads are deleted after 90 days.

• On termination: upon request within 30 days we will return Recipient Data in a structured, commonly used format, then delete it, except the carve-outs above and routine backups (which age out per backup rotation).

8. Independent-controller carve-out (platform protection)

To protect all customers' deliverability, addresses that hard-bounce or that complain repeatedly (3+ complaints across the platform) are added to a platform-wide suppression list used across tenants. For this narrow purpose (bare email address + reason), we act as an independent controller with legitimate interest in preventing abuse of shared infrastructure.

9. International transfers

We are an Australian entity. Recipient Data is hosted in Canada (OVH, Beauharnois, Québec), with encrypted off-site backups in Cloudflare R2 [CONFIRM R2 bucket region/jurisdiction] — so Recipient Data you disclose to us is stored outside Australia. We take the reasonable steps APP 8 contemplates for this: the commitments in this DPA and our sub-processor contracts apply to the data wherever it is stored, backups are encrypted before leaving our server, and we remain accountable for our sub-processors' handling. If you are an Australian APP entity, this DPA is intended to provide the contractual protections on which your own APP 8 analysis can rely.

For EEA/UK-origin data — not in scope for the current release — the EU Standard Contractual Clauses (Module 2, controller→processor) and the UK Addendum are incorporated by reference, with you as data exporter and us as data importer and this DPA's annexes supplying the required descriptions; they will be made execution-ready before any EEA/UK customer is onboarded.

10. Assistance, breaches, audits

• We will assist you, as reasonably necessary and at your reasonable expense, with data subject requests concerning Recipient Data (routing recipient requests we receive at [email protected] to you), with DPIAs, and with regulator consultations.

• We will notify you without undue delay after becoming aware of a personal-data breach affecting Recipient Data, with the information reasonably available to us, and will provide reasonable assistance with any notification obligations you have (e.g. the Notifiable Data Breaches scheme under Part IIIC of the Privacy Act 1988 (Cth), or breach laws applicable to you).

• Once per 12 months, on reasonable notice, we will make available information reasonably necessary to demonstrate compliance with this DPA, and permit audits limited to that purpose (remote/documentary first; no access to other customers' data or to shared infrastructure that would compromise it).

11. Liability and order of precedence

Liability under this DPA is subject to the limitations in the Terms of Service. In conflict, this DPA prevails over the Terms for data-protection matters; executed SCCs prevail over this DPA where they apply.