Data Processing Agreement

1. Scope, roles & incorporation

This DPA governs Lucubra’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 Lucubra is Customer’s subprocessor and Customer warrants its instructions are authorized by the controller), and Lucubra 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.

2. Definitions

“Customer Personal Data” means personal data within Customer Data that Lucubra 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.

3. Processing on documented instructions

Lucubra 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 Lucubra, 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.

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.

Lucubra 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 in the future, 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 restricted attribute store), and special-category data only through the restricted attribute store under an explicit, runtime End-User consent to the health purpose — and instruct only Processing this DPA and the Agreement permit;
• ensure the accuracy and lawfulness of Customer Personal Data as submitted, and configure retention, consent purposes, and access for its team appropriately.

5. Confidentiality of personnel

Persons Lucubra 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

Lucubra 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 Lucubra 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 Customer’s account contact 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 prepaid, unused fees for it.

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

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.

8. Data-subject requests

If a data subject sends a request about Customer Personal Data directly to Lucubra, 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 ten business days, with backup copies of deleted data aging out of the backup cycle within 35 days (Section 12). A verified export instruction follows the same ten-business-day window; for an export of exceptional scope we may extend once, by a further ten business days, with notice before the first window ends. Instructions are executed by our operators on written request (hello@pharen.ai); there is no self-service deletion or export endpoint today. One shape to know about: records created before an End User is identified — in particular tester-enrollment records — are keyed to the device identifier or label supplied at enrollment, so a deletion instruction must include that identifier to reach them.

9. Personal data breach

Lucubra will notify Customer without undue delay after becoming aware of a Personal Data Breach affecting Customer Personal Data — we aim to notify within 72 hours of becoming aware — 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, Lucubra 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 are written to make most of a DPIA answerable from the published record.

11. Information & audits

On reasonable request (and no more than once per calendar year unless a supervisory authority requires otherwise or a Personal Data Breach has occurred), Lucubra 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 Lucubra. 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 do not currently hold third-party certifications (such as SOC 2 or ISO 27001) and do not claim any; what we provide instead is a truthful, detailed account of the measures in Annex 2.

12. Return & deletion

During the Agreement and for 30 days after termination, we will produce Customer Data to Customer in a machine-readable form on written request, within ten business days of the request — export is operator-assisted today; there is no self-service export endpoint. The 30-day 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: deletion completes within 30 days across live systems, with backup copies aging out of the backup cycle within 35 days — deviating only where law requires retention, in which case the data stays protected under this DPA and is deleted when the requirement ends. We certify completed deletion in writing on completion.

13. International transfers

Lucubra Processes Customer Personal Data in the United States (Annex 1). 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 Lucubra 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 either party able to end it as the Addendum provides. 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. Lucubra is not certified under the EU–U.S. Data Privacy Framework today; 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, Lucubra 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. Lucubra 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.

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 the exclusions and the aggregate cap in Section 17 of the Terms; this DPA does not enlarge or duplicate that cap. This DPA takes effect with the Agreement and remains in force as long as Lucubra Processes Customer Personal Data.

Annex 1 — Details of processing

A. Parties. Data exporter: Customer (contact details per its account). Data importer: Lucubra LLC, 522 W Riverside Ave, Ste N, Spokane, WA 99201-0581, USA, hello@pharen.ai.

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. These are the platform’s real, current measures — engineering properties first, promises second.

• 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 (the SDKs additionally drop a short list of obvious identifying keys from track() properties as a convenience); identity traits live in 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.
• Tenant isolation. Every record holding Customer Personal Data carries a tenant, app, and environment scope. Tenant and environment are stamped server-side from the authenticating credential — the client cannot supply or spoof them — and data access without a tenant scope fails closed. Cross-tenant 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-tenant 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 (sign-in through a developer identity provider against an explicit allowlist) and role-scoped. Ingest credentials are write-only, per-environment, revocable, and rotatable. Production access is limited to a small, enumerable set of named operators — Lucubra is deliberately a small operation, and its access surface matches.
• Transmission & storage protection. Build artifacts upload directly to object storage over presigned, scope-limited URLs; storage is prefixed per tenant, 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 35-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 tenant scoping — are encoded as machine-checkable validators enforced in continuous integration, alongside schema-migration guards and a publication-boundary check on everything that ships publicly.
• 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. Network-address capture 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. Ambient capture (anything recording a person who is not actively composing a report) is opt-in only.
• Retention & erasure. Retention is classification-driven; diagnostic payloads are bounded at 30 days; deletion propagates across live stores, derived data, object storage prefixes, and backups on rotation. Each deletion ends with a verification query confirming zero remaining rows for the subject, kept with the request record — a documented operator procedure, not yet an automated pipeline.
• Governance & accountability. A written privacy model and tenancy model govern the platform’s design; secrets live in managed stores with a rotation register and scheduled checks; subprocessors are bound by written contracts with equivalent protections.
• Certifications. None held today, 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.