Data Processing Agreement

1. Scope, roles & incorporation

This DPA governs Pharen’s Processing of Customer Personal Data under the Agreement. Customer is the controller of Customer Personal Data (or, where Customer acts for its own controllers, a processor — in which case Pharen is Customer’s subprocessor and Customer warrants its instructions are authorized by the controller), and Pharen is Customer’s processor. This DPA is incorporated into and forms part of the Agreement; for the matters it addresses it prevails over the Terms, and where the Standard Contractual Clauses apply, they prevail over everything.

Data held on devices. The SDKs keep data on End Users’ devices, inside Customer’s Apps, until the Service accepts it — for longer while the Service is not accepting it, such as during a limit hold (Terms Section 11.4) or a suspension. That storage runs within the per-device limits the Documentation states and any limits Customer sets, under the plan, Additional Volume, and settings Customer selects. Where the Service offers them, Customer can end a limit hold by raising its Additional Volume (Terms Section 11.6), and can have what devices hold refused rather than sent by giving a Discard (Terms Section 11.5); the SDKs delete held data on a withdrawal of consent as the Documentation describes. Data held on a device is not in Pharen’s possession or control and is not Customer Personal Data Processed by Pharen until the Service accepts it, and Pharen cannot reach it to act on a request about one person. The Service can tell the SDKs in an App’s installs to stop, which deletes what they hold on those devices, as the Documentation describes. Pharen does so only on Customer’s documented instructions under Section 3 — the Agreement, including its end, the end of a plan or a trial that no plan follows (Terms Section 11.2), and an SDK version’s end of life or, for debug builds, its end of support, as the Documentation states; and a credential revoked at Customer’s request, once any period in which it can be restored has passed — or as a security measure under Section 6, for a defect in the SDKs or in a release of an App that affects privacy, security, or the App’s stability, or for a credential that is compromised. Data deleted this way is deleted on Customer’s instruction or as that security measure, not discarded by Pharen for its own purposes.

2. Definitions

“Customer Personal Data” means personal data within Customer Data that Pharen Processes on Customer’s behalf. “Data Protection Laws” means the privacy and data-protection laws applicable to a party’s Processing under the Agreement, including the GDPR (EU 2016/679), the UK GDPR, the Swiss FADP, and U.S. state privacy laws such as the CCPA/CPRA. “SCCs” means the European Commission’s Standard Contractual Clauses for international transfers (Decision 2021/914). “Personal Data Breach”, “Processing”, “data subject”, and similar terms have the meanings Data Protection Laws give them. Other capitalized terms come from the Terms. In this DPA, “Pharen” (“we”) means Pharen, a trade name of Lucubra LLC, the entity identified as data importer in Annex 1, and “Customer” means the Customer under the Terms — so a countersigned copy of this DPA identifies its parties on its own.

3. Processing on documented instructions

Pharen Processes Customer Personal Data only on Customer’s documented instructions: the Agreement, Customer’s configuration of the Service (including the consent purposes Customer enables and the data Customer’s Apps submit), and any further written instructions the parties agree to — plus what applicable law requires of Pharen, in which case we inform Customer of the legal requirement before Processing unless the law prohibits it. We will inform Customer if, in our opinion, an instruction infringes Data Protection Laws; we are not obligated to execute an instruction we reasonably believe unlawful. A Discard Customer gives through the Service (Terms Section 11.5) is a documented instruction: we record who gave it, when, and how much the Service later refused under it, and the data it covers is refused and not stored.

Government and law-enforcement requests. If an authority demands Customer Personal Data from us, we will redirect the authority to Customer where possible, notify Customer promptly unless legally prohibited from doing so, challenge demands we reasonably consider overbroad or unlawful, and disclose only the minimum the law compels.

Pharen does not sell Customer Personal Data, does not use it for advertising, and does not use it to train machine-learning or AI models. If Customer enables an AI-assisted capability, its Processing stays inside this DPA: inputs are pseudonymized and minimized, direct identifiers and special-category data are excluded from any model prompt, and any AI provider must be bound to no-training and zero-retention terms before it may be engaged (and appears in the register per Section 7).

4. Customer obligations

Customer will:

• have a lawful basis for the Processing it instructs, and provide End Users the legally required notices — the Service’s consent mechanics implement Customer’s policy; they do not substitute for it;
• comply with the AUP’s prohibited-data rules — in particular: no direct identifiers on the event stream (identity traits go through the Service’s identity store, a restricted attribute store separate from events), and special-category data only through the Service’s separate special-category store, and only where the Service offers one, under an explicit, runtime End-User consent to the health purpose, and, where it offers none, no special-category data at all — and instruct only Processing this DPA and the Agreement permit;
• ensure the accuracy and lawfulness of Customer Personal Data as submitted, and configure consent purposes, access for its team, and the retention settings the Service offers appropriately;
• cover in its disclosures to End Users that the SDKs store data on their devices before sending it, including for longer periods while the Service is not accepting it (Section 1).

5. Confidentiality of personnel

Persons Pharen authorizes to Process Customer Personal Data are bound to confidentiality by contract or statutory obligation, and access is limited to what their role requires (Annex 2).

6. Security

Pharen implements and maintains the technical and organizational measures in Annex 2, appropriate to the risk of the Processing. We may improve these measures over time; we will not materially degrade them during the Agreement.

7. Subprocessors

Customer generally authorizes Pharen to engage the subprocessors listed in the Subprocessor Register (Annex 3). Before a new subprocessor Processes Customer Personal Data, we will update the register and notify the contact of Customer’s organization at least 30 days in advance. Customer may object in writing within that notice period on reasonable data-protection grounds; we will then work with Customer in good faith on a resolution (an alternative measure, or a configuration that avoids the subprocessor), and if none is found before the notice period ends, Customer may terminate the affected portion of the Service with a pro-rata refund of any fees prepaid for it for the period after termination or, where that portion is the whole of the Service, terminate the Agreement with a refund of any fees prepaid for the period after termination.

Each subprocessor is bound by a written contract imposing data- protection obligations at least as protective as this DPA’s for the Processing it performs on Pharen’s behalf, and Pharen remains fully responsible to Customer for each subprocessor’s performance.

Ordinary provider metadata. Render and Cloudflare receive connection metadata for requests they handle. This means the minimum network address, routing, timing, protocol, status and service-performance information reasonably necessary to host, deliver, secure, troubleshoot, maintain and optimize the contracted infrastructure service, prevent abuse, or meet applicable legal obligations. For these limited lawful operations, a provider may process that metadata in a separate legally determined role under its applicable terms. The Privacy Notice and register describe those roles; not every such operation is processing on Pharen’s behalf.

This recognition does not authorize sale or rental, advertising, or model training using Customer Data or End-User personal data, including identifiable connection metadata. It does not authorize unrelated profiling, personal-health inference, or independent development using identifiable End-User data beyond those limited infrastructure operations. Event, trait, feedback, attachment and other Customer Data contents, and personal-health values or revealing URL components, are not ordinary metadata under this paragraph. Applicable notice, consent, transfer, rights and retention duties remain; an IP address may be personal data. A provider’s role label does not decide its role or permission under Data Protection Laws, and its terms do not enlarge Pharen’s permissions.

Pharen’s Processing on Customer’s behalf and each provider’s Processing on our behalf remain subject to this DPA’s instructions, confidentiality, subprocessor and Section 14 restrictions. The separate-role description does not remove Customer Personal Data from this DPA, waive a restriction on sharing, or authorize consumer-health Processing outside applicable law. If an actual flow is incompatible with those protections, Pharen will not start it, or will stop and remediate it under Section 14. This paragraph is not a representation that a provider has agreed to broader restrictions than its applicable terms impose.

Emergency replacement. Where replacing or adding a subprocessor is urgently necessary to address a security risk or to keep the Service available — a hosting or storage provider failing is the paradigm — we may engage a replacement that provides materially equivalent protections before the notice period elapses, updating the register and notifying Customer without undue delay afterward. Customer’s objection right then runs from that notice, with the same remedies. This procedure does not override the SCCs or mandatory law: any applicable prior authorization, advance notice and opportunity to object must be satisfied before the replacement Processes the affected Customer Personal Data.

8. Data-subject requests

If a data subject sends a request about Customer Personal Data directly to Pharen, we will forward it to Customer promptly and not respond substantively except to direct the person to Customer. Taking into account the nature of the Processing, we will assist Customer in fulfilling data-subject requests — access, export, rectification, erasure, restriction. We execute a verified deletion instruction from Customer without undue delay, and in any event within 20 business days, with backup copies of deleted data aging out of the backup cycle within 180 days (Section 12), subject to any shorter deadline the law requires. For consumer health data, archived and backup copies are deleted no later than six months after authentication of the request, not six months after our later execution of it. A verified export instruction follows the same 20-business-day window; for an export of exceptional scope we may extend once, by a further 20 business days, with notice before the first window ends. An instruction that serves one data subject’s request, given to us promptly, is executed without undue delay and in time for Customer to meet the deadline the law sets for that request, and is not subject to that extension. Instructions are executed on written request ([email protected]); the Service offers no self-service deletion or export endpoint. A deletion instruction that is to reach tester-enrollment records must include any device identifier or label supplied at enrollment. Pharen cannot reach data still held on an End User’s device to act on a request about that person (Section 1); the SDKs’ own controls, which the Documentation describes, are how Customer acts on it.

9. Personal data breach

Pharen will notify Customer without undue delay after becoming aware of a Personal Data Breach affecting Customer Personal Data, with the information Article 33(3) GDPR contemplates so far as known: the nature of the breach, categories and approximate numbers of data subjects and records, likely consequences, and measures taken or proposed. We will update Customer as material information develops, cooperate reasonably with Customer’s own notification obligations, and take reasonable steps to contain and remediate. Notification is not an admission of fault.

10. DPIAs & consultations

Taking into account the nature of the Processing and the information available to us, Pharen will provide reasonable assistance with data protection impact assessments and prior consultations with supervisory authorities, to the extent they concern Processing under this DPA. Annex 2, the architecture page, and the SDK privacy guide describe the Processing for that purpose.

11. Information & audits

On reasonable request (and no more than once per calendar year unless Data Protection Laws or a supervisory authority require otherwise or a Personal Data Breach has occurred), Pharen will demonstrate compliance with this DPA by providing: current security documentation, completed responses to a reasonable security questionnaire, and a remote review session with the people who operate the platform, scheduled on at least 30 days’ notice. Customer may conduct that review through an independent third-party auditor bound to confidentiality and not a competitor of Pharen. An on-site audit is available where Data Protection Laws or a supervisory authority require one for Customer, or where a remote review has proven demonstrably insufficient; it must be scheduled on reasonable notice, scoped to Customer Personal Data, subject to confidentiality, and at Customer’s cost. We hold no third-party certifications (such as SOC 2 or ISO 27001) and claim none; Annex 2 states the measures.

12. Return & deletion

During the Agreement and for 30 days after termination, or the longer export window the Terms’ Section 18 provides, we will produce Customer Data to Customer in a machine-readable form on written request, within 20 business days of the request — we deliver the export on written request; the Service offers no self-service export endpoint. The export window exists for Customer’s benefit, not ours: Customer may instruct deletion earlier at any time (Section 8), and an executed deletion ends the window for the deleted data. At the end of the window, at Customer’s choice, we return any remaining Customer Data or delete it. In either case, we delete the copies we retain: deletion completes within 90 days across live systems, with backup copies aging out of the backup cycle within 180 days, both measured from the end of the applicable export window. Returning data does not restart or extend either deadline. Section 8’s earlier-deletion instructions and shorter statutory deadlines still apply — deviating only where law requires retention, in which case the data stays protected under this DPA and is deleted when the requirement ends. On Customer’s request, we certify completed deletion in writing.

13. International transfers

Pharen Processes Customer Personal Data in the United States (Annex 1), except as the Subprocessor Register states: requests cross Cloudflare’s global edge network in transit; notifications an App’s owner configures the Service to deliver cross Apple’s and Google’s delivery networks in transit; and correspondence held by our email provider, Google Workspace — Customer’s instructions and support requests, and security reports, which can carry End Users’ identifiers — may be stored in Google’s data centers in other countries, under Google’s data processing terms for Workspace, which state the safeguards for those transfers. For transfers from the EEA, the SCCs are incorporated into this DPA by reference: Module Two (controller → processor) where Customer is a controller, Module Three (processor → processor) where Customer is a processor — with Customer as data exporter and Pharen as data importer, and completed as follows: Clause 7 (docking) is not used; for Clause 9(a), Option 2 (general authorization) applies with the 30-day notice in Section 7; the optional language in Clause 11 is not used; for Clause 17, Option 1 applies and the governing law is Ireland’s; for Clause 18, the courts of Ireland; Annex 1 and Annex 2 of this DPA serve as Annexes I and II of the SCCs, and Annex 3 as the Clause 9 subprocessor list.

For transfers from the United Kingdom, the UK International Data Transfer Addendum to the SCCs (version B1.0, in force 21 March 2022) applies, entering into force with this DPA, with its tables completed by the information in this DPA and both the exporter and the importer able to end it under its Table 4. For transfers from Switzerland, the SCCs apply adapted as the Swiss FADP requires: references to the GDPR are read as the FADP, the competent authority is the Swiss FDPIC, and Swiss law governs where the transfer is exclusively subject to it. Pharen is not certified under the EU–U.S. Data Privacy Framework; the SCCs are the operative mechanism, and if they are invalidated or superseded the parties will cooperate in good faith on a lawful replacement.

14. U.S. state privacy laws

Where the CCPA/CPRA or a similar U.S. state privacy law applies, Pharen acts as Customer’s service provider / processor: we Process Customer Personal Data only for the business purpose of providing, securing, and supporting the Service under the Agreement; we do not sell or share it; we do not retain, use, or disclose it outside the direct business relationship or combine it with personal data from other sources except as those laws permit for a service provider; and our subprocessors are bound to the same restrictions for the Processing they perform on our behalf. Pharen certifies that it understands these restrictions and will comply with them, will notify Customer if it determines it can no longer do so, and — upon reasonable notice — Customer may take the steps those laws authorize to stop and remediate unauthorized use of personal data. Where Washington’s My Health My Data Act or a similar consumer-health-data law applies to Customer Personal Data, irrespective of a field name, consent label, or storage location, Pharen Processes it only under this binding contract and Customer’s documented instructions, subject to Section 3, and only within the actions those instructions and applicable law permit. Pharen assists Customer by appropriate technical and organizational measures, insofar as possible, in fulfilling Customer’s obligations under that law, and does not use that data for any other purpose. This paragraph does not authorize submission of data the AUP prohibits.

15. Liability & precedence

Each party’s liability arising out of or related to this DPA (including any incorporated SCCs, except where they mandate otherwise) is subject to Section 17 of the Terms — its exclusions, its aggregate cap, and the exceptions it states to both; this DPA does not enlarge or duplicate that cap. This DPA takes effect with the Agreement and remains in force as long as Pharen Processes Customer Personal Data.

Annex 1 — Details of processing

A. Parties (Annex I.A of the SCCs). Data exporter: Customer — the entity named, with its jurisdiction, in Customer’s acceptance record; address: as recorded at acceptance or, where none was recorded, as Customer supplies when it requests a countersigned copy or notifies to [email protected], which then forms part of this Annex; contact person: the signer named in the acceptance record, by name and title, at the notices email recorded there, or any replacement Customer notifies under the Terms; activities: operating its Apps and the Service integration; role: controller (Module Two) or, where Customer acts for its own customers, processor (Module Three); data protection officer and representative: as Customer notifies, if any. Data importer: Lucubra LLC, doing business as Pharen, principal office 1315 NW Mall St Ste 1, Issaquah, WA 98027, USA; mailing address 522 W Riverside Ave, Ste N, Spokane, WA 99201-0581, USA; contact person: the data-protection contact, [email protected] — the individual holding that role is identified by name and position in each countersigned copy of this DPA; activities: providing the Service — crash and error reporting, build distribution, product analytics, and engagement — on Customer’s instructions; role: processor (Module Two) or sub-processor (Module Three). Pharen has not designated a data protection officer or a representative in the EU or UK. Signature and date: Customer’s acceptance of the Agreement, recorded with the document versions, the statement accepted, and the timestamp, signs for both parties; a countersigned copy is available on request (Section 1).

B. Description of processing.

C. Competent supervisory authority (where the SCCs apply): determined per Clause 13 — the authority of the EEA member state in which the data exporter is established or, where Annex I.C of the SCCs so requires, of its representative or the data subjects concerned. The specific authority is identified per Customer at onboarding and recorded with the acceptance record.

Annex 2 — Technical & organizational measures

Organized per the SCCs’ Annex II headings.

• Pseudonymization & encryption. The event stream is pseudonymous by design: End Users are keyed by install and customer identifiers; the Service classifies fields at ingestion and rejects events carrying fields it classifies as identifying; identity traits live in the identity store, a separate, restricted attribute store referenced by identifier; the SDKs emit link-open events carrying only the domain a link arrived on, never its path or query string. Data in transit is encrypted with TLS; data at rest is encrypted by the managed hosting and storage providers.
• Organization isolation. Every record holding Customer Personal Data carries an organization, app, and environment scope. Organization and environment are stamped server-side from the authenticating credential — the client cannot supply or spoof them — and data access without an organization scope fails closed. Cross-organization access is a hard failure recorded as a security event. For the most sensitive stores — including restricted identity attributes and user-submitted content — isolation is additionally enforced by the database itself (row-level security), a floor beneath the application layer. The one deliberate exception to per-organization storage is the shared public listing data the Terms’ Store Data clause describes — publicly sourced, never personal — held once with per-customer access through interest records.
• Access control. Operator and customer access to the control plane is person-bound, limited to the members an organization has admitted, and role-scoped. Ingest credentials are write-only, per-environment, revocable, and rotatable. Production access is limited to named operators.
• Transmission & storage protection. Build artifacts upload directly to object storage over presigned, scope-limited URLs; storage is prefixed per organization, app, and environment; symbol files and diagnostic payloads live in private buckets; install links are served from unguessable, unlisted paths.
• Logging & monitoring. Administrative and security-relevant actions are attributed to the acting identity in service logs. Application logs are engineered to exclude personal data — a redaction layer in the logging path plus per-module tests in continuous integration, so a regression fails the build rather than shipping.
• Availability & recovery. Managed database with the provider’s automated backups — backup copies of deleted data age out of the backup cycle inside the 180-day outer bound Section 12 commits to; overloaded ingestion returns explicit retry signals rather than silently dropping data.
• Testing & assessment. The governance rules — consent enforcement, identifying-field classification at ingest, mandatory organization scoping — are encoded as machine-checkable validators enforced in continuous integration.
• Minimization & consent gating. Collection is consent-gated at the point of collection: every event carries the consent context, and an event whose purpose is not granted is dropped at the boundary — before storage. The Service’s capture of network addresses is off by default and stays off until a Customer deliberately enables it; where enabled for anonymous link hits, the address can be stored truncated or hashed rather than in full. (Every request’s address still reaches the hosting and delivery providers in transit; the register Section 7 points to names them.) Ambient capture (anything recording a person who is not actively composing a report) is opt-in only.
• Retention & erasure. Retention follows the windows the Documentation states for each kind of data; diagnostic payloads are bounded at 30 days; deletion propagates across live stores, derived data, object storage, and backups on rotation, and each deletion is verified and recorded.
• Governance & accountability. A written privacy model and tenancy model govern the platform’s design; secrets live in managed stores and are rotated; subprocessors are bound by written contracts with equivalent protections for the processing they perform on our behalf.
• Certifications. None held, and none claimed. Security documentation and questionnaire responses are available under Section 11.

Annex 3 — Subprocessors

The current subprocessor list, the 30-day advance-notice commitment, and the way to subscribe to changes are published at pharen.ai/legal/subprocessors, which is the operative register for Clause 9 purposes.