Databehandleravtale

1. Parties and purpose

This Data Processing Agreement ("DPA") is between the customer who accepts the psylab Terms of Service (the "Controller") and Build AS, Ensjøveien 21L, 0655 Oslo, Norway, org. no. 930 335 584 (the "Processor").

It governs the Processor's processing of personal data on the Controller's behalf in the course of providing psylab (the "Service"). It forms part of the Terms of Service and is incorporated in them by reference. It satisfies Article 28(3) GDPR and the Norwegian Personal Data Act, and section 4a binds the Processor to Normen. Where a clinic or programme is the Controller, its clinicians are Users under the Terms and the clinic remains responsible for them; where a clinician contracts alone, that clinician is the Controller.

Appendix A describes the processing, Appendix B the security measures, Appendix C the sub-processors, and Appendix D the Normen requirements and how each is met. In case of conflict, this DPA prevails over the Terms for anything about personal data.

2. Roles

The Controller determines the purposes and means of processing session data: whether to record, what to transcribe, what to keep, and what to share. The Processor processes that data only on the Controller's documented instructions. The Service's functions, as described in Appendix A and the Terms, constitute the Controller's standing instructions; a Controller gives further instructions by using the Service's controls (keep, share, delete) or in writing.

For data about the account holder (name, email, sign-in, billing, service logs), Build AS is an independent controller under its Privacy Policy, and this DPA does not apply.

3. Controller's obligations

The Controller:

• determines and secures the legal basis for processing session data, including the Article 9(2) GDPR condition: typically the client's explicit consent (Art. 9(2)(a)) where sessions are used for supervision or training, or Art. 9(2)(h) where they document care. This includes the applicable Art. 6 basis and any authorisation its duty of confidentiality requires. The Controller confirms this by accepting this DPA, and that it acts as a health professional under a duty of confidentiality, or on behalf of such professionals;
• obtains and documents whatever consent, notice or authorisation its law, regulator and professional ethics require before a session is recorded, and confirms it has done so by recording;
• is responsible for the accuracy and lawfulness of what it enters, and for not entering directly identifying details of clients where the Service does not ask for them;
• responds to data subjects, including its clients, and to supervisory authorities, with the Processor's assistance under section 6;
• ensures its Users comply with the Terms and this DPA;
• does not instruct the Processor to process data in a way that infringes the GDPR.

4. Processor's obligations

The Processor:

• processes personal data only on the Controller's documented instructions, including with regard to transfers, unless EU or Norwegian law requires otherwise, in which case it informs the Controller before processing unless the law prohibits it;
• informs the Controller immediately if, in its opinion, an instruction infringes the GDPR;
• ensures that every person authorised to process personal data is bound by a contractual or statutory duty of confidentiality, and that access is limited to what is strictly necessary;
• holds a signed confidentiality declaration from every employee and contractor, and makes the declarations available to the Controller for inspection;
• logs every read of session content, and provides the Controller an extract of that log for its data on request;
• implements the technical and organisational measures in Appendix B, and maintains a level of security appropriate to the risk under Article 32 GDPR;
• engages sub-processors only under section 7;
• assists the Controller under section 6;
• deletes or returns personal data under section 9;
• makes available the information needed to demonstrate compliance and allows audits under section 8;
• never processes session data for its own purposes, never uses it to train or improve AI models, and never sells or discloses it for advertising.

4a. Normen

(1) The Processor shall comply with statutory requirements and with the requirements of the Code of Conduct for Information Security and Data Protection in the Healthcare and Care Services Sector ("Normen"), as in force from time to time, that are relevant to this engagement; Appendix D lists them and how each is met.

(2) The Processor is independently responsible for information security and for the data subjects' privacy (GDPR Arts. 28, 29, 32; Patient Records Act § 22), and maintains a management system covering risk assessment, security audit and incident handling.

(3) Sub-processors are bound to the same obligations, including relevant Normen requirements; those agreements are made available to the Controller on request.

(4) When Normen changes, the Processor assesses the required measures within 90 days and notifies the Controller in writing.

(5) Breach of Normen or this section is a breach of contract. The Controller may require remedy within a reasonable period, normally 30 days; on material breach, or failure to remedy, the Controller may terminate with immediate effect, with a pro-rata refund of prepaid fees, in addition to damages under §11.

Norsk tekst.

(1) Databehandler forplikter seg til å oppfylle lovbestemte krav og de krav i den til enhver tid gjeldende Norm for informasjonssikkerhet og personvern i helse- og omsorgssektoren («Normen») som er relevante for avtaleforholdet; vedlegg D angir kravene og hvordan de ivaretas.

(2) Databehandler har et selvstendig ansvar for informasjonssikkerheten og de registrertes personvern (personvernforordningen art. 28, 29 og 32, pasientjournalloven § 22), og har et styringssystem med risikovurdering, sikkerhetsrevisjon og avviksbehandling.

(3) Underleverandører pålegges de samme plikter, herunder relevante krav i Normen; avtalene gjøres tilgjengelige for behandlingsansvarlig på forespørsel.

(4) Ved endringer i Normen vurderer databehandler innen 90 dager hvilke tiltak som kreves, og varsler skriftlig.

(5) Brudd på Normen eller denne bestemmelsen er mislighold. Behandlingsansvarlig kan kreve retting innen rimelig frist, normalt 30 dager; ved vesentlig mislighold, eller manglende retting, kan avtalen heves med umiddelbar virkning med forholdsmessig tilbakebetaling av forhåndsbetalt vederlag, i tillegg til erstatning etter § 11.

5. Personal-data breach

This section covers every security incident (avvik) affecting the Controller's data or the Service's security, including a breach of this DPA or of Normen.

The Processor notifies the Controller without undue delay, and within 24 hours of the Processor establishing with reasonable certainty that the Controller's data is affected. The Processor gives an early warning as soon as such an incident is suspected.

The notice carries the information in Article 33(3) GDPR as far as it is known, supplemented as it becomes available. The Processor sends notices to the email address on the Controller's account. The Controller reports incidents and suspected incidents to the Processor at security@psylab.ai. The Processor assists the Controller with its notification to the supervisory authority within 72 hours and, where required, to data subjects. The Processor documents every incident, its effects and the remedial action taken, and tells the Controller the corrective measures.

6. Assistance

Taking account of the nature of the processing, the Processor assists the Controller:

• in responding to data-subject requests (access, rectification, erasure, restriction, portability, objection), by the Service's built-in controls where they suffice and otherwise within ten working days of a request;
• in meeting Articles 32 to 36 GDPR: security, breach notification, data protection impact assessments and prior consultation, by providing the information in this DPA and its appendices and answering reasonable questions.

Assistance beyond the Service's built-in controls and this documentation may be charged at the Processor's reasonable rates, agreed in advance.

7. Sub-processors

The Controller gives general authorisation to the sub-processors in Appendix C. The Processor imposes on each sub-processor, by written contract, data-protection obligations equivalent to those in this DPA, including the relevant Normen requirements under section 4a, and remains fully liable to the Controller for the sub-processor's performance. The Processor makes those contracts available to the Controller on request.

The Processor gives the Controller 30 days' written notice by email before adding or replacing a sub-processor, or changing one's location or purpose. The Controller may object on reasonable data-protection grounds within that period; if the parties cannot resolve the objection, the Controller may terminate the affected Service without penalty and receive a pro-rata refund of prepaid fees. Non-material changes (a sub-processor's renamed entity, a new region inside the EU for the same purpose) are documented in Appendix C without prior notice.

8. Audits

The Processor makes available all information necessary to demonstrate compliance with Article 28 GDPR and section 4a: this DPA and its appendices, its sub-processor contracts' data-protection terms, its current security documentation, and any third-party assessment (penetration test, certification) once completed, available on request. The Controller, or an independent auditor bound by confidentiality and mandated by it, may audit the Processor's compliance at most once a year, on 30 days' written notice, during business hours, in a way that minimises disruption and does not give access to other customers' data. The Controller bears its own audit costs; the Processor bears its own for one audit a year and may charge reasonable costs for further audits, unless an audit reveals material non-compliance.

The Processor allows inspections by the supervisory authorities competent for the Controller, and assists the Controller with them.

Once a year, the Processor sends the Controller a security report covering availability, failed sign-ins, security incidents and configuration changes.

9. Deletion and return

Session data is deleted on the lifetimes in Appendix A regardless of termination.

Before deletion, on the Controller's request, the Processor returns the Controller's transcripts, notes and documents, and the access log for the Controller's data, in a readable format within 30 days. A clinic's templates are returned in a machine-readable form on request.

On termination of the Service, the Processor deletes all remaining personal data processed on the Controller's behalf within 30 days, at its sub-processors too, unless EU or Norwegian law requires retention. Where the law requires retention, the Processor keeps only what the law requires, for as long as it requires, and confirms this in writing.

Within 30 days of termination, without being asked, the Processor sends the Controller a signed declaration that all of the Controller's data is deleted, at sub-processors too, and that no copies are kept. The declaration names the backup tail: encrypted copies age out of the database backups and point-in-time recovery within 7 days, of the virtual-machine disk snapshots within 14 days, and of the noncurrent Cloud Storage object versions within 30 days.

The duty of confidentiality in section 4 survives termination.

10. International transfers

All session data is processed and stored within the EU/EEA. It is accessed only from within the EU/EEA, administrative and support access included.

Each sub-processor processes the data in these locations:

• Google Cloud: compute, the database and the keys in region europe-north2 (Stockholm, Sweden); Cloud Storage and its encryption key in the EU multi-region; voice conversion in region europe-west1 (Belgium).
• Google Vertex AI: Gemini text and voice models in the EU multi-region (eu); the pseudonymisation scan in region europe-north1 (Finland).
• Soniox: the EU region.
• Google Identity Platform: the United States, for sign-in data only, which is Build AS's own controller data under section 2.
• Sentry: Frankfurt, Germany, for error reports; organisation metadata in the United States.
• Resend: EU sending; delivery logs in the United States.
• Google Workspace: Google's global infrastructure, for the email addresses of invited Users.

Three Gemini models that Google serves in no EU location (gemini-3-pro, gemini-3.1-pro and gemini-3-flash) are pinned to Google's global endpoint, and no production default uses them.

The Processor does not transfer session data to a third country. Where a sub-processor for account or operational data is established outside the EU/EEA, the Processor relies on an EU adequacy decision, including the EU-US Data Privacy Framework, or on the EU Standard Contractual Clauses (Commission Decision 2021/914) with a transfer impact assessment and supplementary measures, and never for session data.

11. Liability and term

Each party is liable to the other under Article 82 GDPR and the Terms. The Processor's liability under this DPA is subject to the limitation in the Terms, except for its liability to data subjects under Article 82 and any liability that cannot be limited by law.

This DPA lasts as long as the Processor processes personal data for the Controller, and sections 4, 9 and 11 survive.

12. Governing law and Controllers outside the EU/EEA

Norwegian law; the courts of Oslo, as in the Terms. Where the Controller is established in another EU/EEA state, the mandatory data-protection law of that state applies to the processing.

The Service is offered only to Controllers established in the EU/EEA. Before the Service is offered to a Controller outside the EU/EEA, the parties add to this DPA the transfer instrument that the GDPR and the Controller's own law require.

---

Appendix A: Details of the processing

A.1 Subject matter and purpose. Providing a professional workbench for psychotherapists: making a session available to the therapist as it happened, reading it against a treatment model and the common factors of effective therapy, drafting a session note from what was said, and letting the therapist share a session with a supervisor of their choosing. The Service is a tool for the therapist's professional development, supervision and documentation. It is not a medical device, not a patient record, and makes no decision about a client.

A.2 Nature of the processing. The therapist records or uploads session audio. The audio is transcribed; the transcript is pseudonymised turn by turn (names, places, dates and identifying details replaced) before storage; the recording is deleted; a note, a reading and answers to the therapist's questions are produced from the pseudonymised transcript by AI models on an inference-only basis; the therapist reviews and may share, keep or delete; everything expires on the lifetimes below. If the therapist keeps audio for a supervisor, the client's voice is converted to a synthetic one on the Processor's own infrastructure and the original is deleted.

A.3 Categories of personal data. Session content: what was said in a therapy hour, including health data and other special categories under Article 9 GDPR (mental health, and whatever the client discloses about sexuality, ethnicity, religion, family, or offences). The Service asks for no directly identifying client data (no name, date of birth, personal identity number, address or contact detail) and replaces incidental identifiers in the transcript, but the content remains personal data of the client. Therapist data in the session: the therapist's own words, notes, annotations and questions. Third parties mentioned in a session.

A.4 Categories of data subjects. Clients of the therapist; the therapist; third parties mentioned in a session (family members, colleagues, other clinicians); where shared, the supervisor as author of their comments.

A.5 Duration.

A.6 Special instructions. Pseudonymisation is not optional and cannot be disabled by instruction. No session data is used to train or evaluate models. No session data is processed outside the EU/EEA.

Appendix B: Technical and organisational security measures

Access control. Sign-in through Google Cloud Identity Platform. A TOTP second factor is required for every user since 14 October 2026. The application sits behind Google Identity-Aware Proxy. Every access is scoped to the signed-in user: a therapist sees their own sessions, a supervisor only what was shared with them and only while the share lasts, a clinic administrator only templates and membership. Administrative access is limited to a small number of named engineers, by named account, least privilege, and logged; no shared credentials.

Encryption. TLS 1.2 or higher on every network connection that carries the Controller's data. AES-256 at rest across databases, object storage and backups. Raw recordings and transcripts are kept in dedicated storage under customer-managed encryption keys in Google Cloud KMS, in force in production since 27 September 2026. Session text in the database is envelope-encrypted, so the database layer never holds plaintext session text.

Data separation. Raw recordings in a bucket of their own, separate from the product database. Each session is processed in isolation. Customers share one deployment and are separated logically: every read and write is scoped to the signed-in user and enforced server-side, and no query can cross that scope. Access to session data comes only from the owner's account or from a share the owner grants; a clinic administrator cannot read case folders. A clinic or training programme may have its own tenant (a dedicated deployment with its own database and keys) under its order form.

Pseudonymisation. Automated turn-by-turn scan-and-replace of identifiers before storage, not configurable. Voice conversion for any kept audio.

Retention enforcement. Lifetimes in Appendix A are enforced by automated sweeps: hourly for unfiled sessions and daily for case folders. Expired data is unreadable from the moment it expires, pending purge. Deletions by the Controller are immediate and irreversible.

Logging and monitoring. Structured logs with a fixed redaction list applied in every runtime; no session content in logs. Error monitoring with personal data off and session replay fully masked. Reads of session content by staff are logged (section 4). Audit logs are kept 730 days. Security alerts on infrastructure and key use.

Backups. Encrypted; the database keeps seven daily backups and seven days of transaction logs, disk snapshots are kept 14 days and storage object versions up to 30 days, so a deletion propagates out of every backup within 30 days.

Location. Compute, the database and the keys in Google Cloud region europe-north2 (Stockholm, Sweden). Cloud Storage and its encryption key in the EU multi-region. AI inference on Vertex AI in the EU multi-region and in EU regions, as section 10 sets out.

AI inference. The AI models process the Controller's data on an inference-only basis. A transcript may be held in a transient context cache for at most 30 minutes while it is read.

Procedures. Static application security testing and secret scanning on every change; container image and dependency scanning; dependency updates. Incidents are handled under a written incident procedure, version 1.0 of 14 October 2026, with the notification times in section 5. Staff are bound by confidentiality under signed declarations. Access is reviewed on role change or departure. No external certification is held. An external penetration test is booked; its summary is available to the Controller on request once it is completed.

Resilience. Managed, replicated cloud infrastructure. Backups are tested by restore drill, last performed on the development environment on 23 September 2026.

Appendix C: Sub-processors

Voice conversion runs on the Processor's own Google Cloud workloads and involves no further sub-processor. Last updated: 14 October 2026.

Appendix D: Normen requirement matrix

The requirements are the Normen 7.0 demands in psylab's compliance register. The requirement and status columns are generated from the register, and the appendix is regenerated whenever the register changes. Status "resolved" means psylab has confirmed the requirement met or not applicable. Status "open" means it is not yet confirmed; the third column states what is in place and what is in preparation. Generated 14 October 2026.