Data Processing Agreement

This Data Processing Agreement ("DPA") is part of the Terms of Service between the customer ("Controller": an org, or a coach for their students' recordings, section 1.6) and Löhr & Sørensen GmbH i.G., Am Krähenberg 5, 22587 Hamburg, Germany, in formation and not yet entered in the commercial register ("Debrief", "Processor"). An org admin accepts it for the org on the org's admin page; a coach accepts it when applying to coach on Debrief (both in electronic form, Art. 28(9) GDPR). It follows Article 28 of the GDPR.

1. Scope and roles

1.1 The Controller decides which recordings its users upload or process with Debrief, whether voice comms are transcribed, who in the org sees what and how long it is kept. For this Customer Data (Annex 1) the customer is the controller and Debrief is the processor.

1.2 Debrief is an independent controller for the data it needs to run its own service: users' accounts and sign-in, sessions, the security log, support, billing and legal records, as described in the Privacy Policy. This DPA does not cover that data.

1.3 Members' PCs. Recordings can be processed by the Debrief client on the PCs of the Controller's own users, including PCs that their owners share with the org's swarm. Those users act for the Controller, not for Debrief; they are not Debrief's subprocessors. The Controller is responsible for its users following the Terms' rules for shared PCs (keeping copies confidential and deleting them on request).

1.4 Debrief's cloud servers. Where the Controller allows cloud processing (on its admin page), recordings are processed on virtual servers that Debrief runs in Microsoft Azure (Annex 2, section I). This is processing by Debrief under this DPA.

1.5 The Coach. When the Controller turns the Coach on, Debrief makes the data the Coach needs (Privacy Policy, section 7) available to the PC of the Controller's admin that the Controller chose, which sends it to Anthropic with that admin's own Claude account. That transfer, and Anthropic's processing under the terms of that account, is the Controller's own processing, not Debrief's: Anthropic is not Debrief's subprocessor. Debrief stores the report the PC returns as Customer Data. The Controller decides which Claude account and settings it uses (Privacy Policy, section 7, on model training). If Debrief itself drafts reports or reviews on its own servers with Anthropic's API, Anthropic is Debrief's subprocessor for that (Annex 3).

1.6 Coaches. Where the customer is a coach, the Controller is the coach and Customer Data includes the recordings the coach's students upload through the coach's upload links, the reports made from them, the students' details the coach enters (name, optional email address), the students' confirmations, and the coach's notes, pinned moments, agenda, reviews and share links. The coach is responsible for its relationship with each student: having a legal basis, informing the student (Debrief shows the student a short notice on the upload page naming the coach as controller and Debrief as processor, which the coach may not contradict), and not coaching students under the minimum age of the Terms. AI-drafted reviews made on the coach's own PC with the coach's own Claude account are the coach's own processing, as in section 1.5. Debrief forwards a student's requests about their data to the coach (section 7.1). A share link the coach makes is the coach's instruction to show that one report and the approved review to whoever holds the link.

1.7 Voice recognition. Where the Controller has voice comms transcripts on, its members can each agree to voice recognition (Privacy Policy, section 6). Debrief then keeps a voiceprint of each consenting member and uses it, on the Controller's own processing PCs only, to put that member's name on their lines in the Controller's transcripts. The voiceprint rests on the member's explicit consent given to Debrief; the names it puts on lines are Customer Data.

2. Instructions

2.1 Debrief processes Customer Data only on the Controller's documented instructions, including for transfers to third countries, unless EU law or the law of an EU member state to which Debrief is subject (in particular German law) requires otherwise (Debrief then tells the Controller first, unless the law forbids it).

2.2 The Controller's instructions are: this DPA, the Terms, and the Controller's use and settings of Debrief (for example uploading, sharing, making a recording private, turning transcripts on or off, setting their retention, allowing cloud processing, keeping recordings' videos in the source archive, deleting, turning the Coach on, or giving support access), as described in Annex 4.

2.3 Debrief tells the Controller if it believes an instruction breaks the GDPR or other data protection law.

2.4 (Planned, with custom rules.) The Controller authorises Debrief to compute aggregated statistics about detection rules from the Controller's verdicts (for example how often a rule's flags were marked right or wrong). Debrief uses only these statistics, which contain no personal data, to improve Debrief's rules for all customers.

2.5 Training data. The Controller allows Debrief to use samples of the Controller's recordings in the labelling tasks the Controller runs ("Help train Debrief"), the labels its members give, the reasons given when a flag is marked wrong, and the samples of closed tasks kept in the Controller's training archive, to measure and improve Debrief's readers, detectors and rules (Privacy Policy, section 11). For this use Debrief is a controller in its own right. Debrief limits it to Debrief and the Controller, never pools the samples with other customers' data, never publishes them, deletes them together with their source data (recording, voice line, transcript, account, the Controller's org) and at the latest 24 months after a sample was added, after which only labels without personal data remain.

2.6 Apart from sections 2.4 and 2.5, Debrief does not use Customer Data for its own purposes.

3. Confidentiality

Debrief ensures that everyone it authorises to process Customer Data is bound by confidentiality. The platform admin does not see an org's recordings except through a support access (Annex 2, section D).

4. Security

Debrief implements the technical and organisational measures in Annex 2, appropriate to the risk (GDPR Art. 32). Debrief may improve them over time, but not lower the overall level of protection.

5. Subprocessors

5.1 The Controller gives Debrief general authorisation to use subprocessors. The current ones are in Annex 3 and at /legal/subprocessors.

5.2 Debrief tells the Controller's admins at least 30 days before it adds or replaces a subprocessor (on the site and by notification). The Controller may object on reasonable data protection grounds within that time. If the parties cannot agree, the Controller may end the affected part of the service and get a refund of prepaid fees for the time after the end.

5.3 Debrief imposes data protection obligations on each subprocessor that are at least as protective as this DPA, and remains responsible to the Controller for its subprocessors.

6. Transfers

Customer Data is stored in the EU (Microsoft Azure, Sweden Central). A transfer outside the EU/EEA happens only as described in Annex 3, and only with a transfer mechanism under GDPR Chapter V: an adequacy decision (for example the EU-US Data Privacy Framework for a certified recipient) or the EU Standard Contractual Clauses.

7. Helping the Controller

7.1 Data subjects' rights. Debrief gives the Controller and its users self-service tools (Annex 4: download my data, delete my account, delete recordings, delete voice lines and transcripts, correct profile data). If a data subject contacts Debrief about Customer Data, Debrief forwards the request to the Controller's admins without undue delay and does not answer it on its own, except to point to the self-service tools. Debrief helps with other requests at the Controller's reasonable request.

7.2 Security, breaches, DPIAs. Debrief helps the Controller with its obligations under GDPR Articles 32 to 36, taking into account the information available to Debrief. This includes information for the Controller's data protection impact assessment, for example on voice comms transcripts.

8. Personal data breaches

Debrief notifies the Controller's admins without undue delay, and where possible within 48 hours, after becoming aware of a personal data breach affecting Customer Data. The notice describes, as far as known then: what happened, the categories and approximate number of data subjects and records, the likely consequences, and the measures taken or proposed. Debrief adds information as it becomes available and takes reasonable steps to contain the breach.

9. End of the agreement: return and deletion

9.1 During the subscription and for 30 days after it ends, the Controller's users can download their data (Annex 4).

9.2 Debrief deletes the Customer Data 60 days after the end, unless EU or German law requires Debrief to keep it. Deleted data leaves Debrief's backups within 37 days (Annex 2, section F). Copies on members' PCs are the Controller's (section 1.3).

10. Audits and information

Debrief makes available the information needed to show compliance with Article 28, including this DPA, its annexes and, on request, written answers to reasonable security questionnaires. The Controller (or an independent auditor bound by confidentiality) may audit Debrief once a year, or after a personal data breach, with at least 30 days' notice, at the Controller's cost, in a way that does not disrupt the service or expose other customers' data. Debrief may meet the request with existing reports or certifications of its subprocessors where these cover it.

11. Liability and term

The liability rules of the Terms apply to this DPA, to the extent the GDPR allows. This DPA applies as long as Debrief processes Customer Data for the Controller. If this DPA and the Terms conflict on data protection, this DPA wins.

12. Law

This DPA is governed by German law. Disputes follow the Terms (section 21).

Annex 1: Details of the processing

Annex 2: Technical and organisational measures

A. Hosting and encryption

• Hosted in Microsoft Azure, region Sweden Central (EU): Azure Container Apps (the site and a separate host for report pages), Azure Database for PostgreSQL (Flexible Server), Azure Blob Storage (locally redundant, in the same region), Azure Key Vault, Log Analytics.
• Encryption in transit: HTTPS only (HSTS on the site); TLS 1.2 or later to storage; the database requires TLS.
• Encryption at rest: Azure's storage service encryption and database encryption with Microsoft-managed keys.

B. Access control (users)

• Sign-in only through OAuth / OpenID Connect providers (authorisation code flow with PKCE and state); no passwords are stored by Debrief. People join through an allow-list or a single-use, expiring invite.
• Sessions: a 256-bit random token in an HttpOnly, Secure, SameSite cookie; only its SHA-256 hash is stored; ends after 14 days without use or 30 days at most; rotated hourly; "sign out everywhere".
• Roles: each user sees only the orgs they belong to; within an org, org admins and members; a recording can be private to its owner and the org's admins.
• Protection against cross-site requests (exact Origin check and a custom header on every change), a strict Content Security Policy, and report pages on a separate, sandboxed origin.
• Rate limits on sign-in, pairing, access requests and data exports.

C. Access control (systems)

• Least-privilege database roles: the site's role reads and writes data but cannot change the schema; the report host can only read the few tables it needs; only the migration job uses the admin login.
• Secrets in Azure Key Vault; each managed identity can read only its own secrets. The site reaches storage with managed identities (Entra ID; storage account keys are turned off) and blobs are never publicly accessible.
• Files are served through signed links that expire: report pages 12 hours, video 3 hours, uploads 15 minutes, a user's data export 7 days.
• The client on a member's PC uses a per-PC token, stored only as a hash, that its owner or an admin can revoke at once. A PC joins only after its owner approves a pairing code.

D. Support access

• The platform admin has no access to an org's recordings. To help an org they start a support access with a reason; it is read-only, covers only shared (not private) recordings, lasts 24 hours by default and 72 hours at most, notifies the org's admins at once (with the reason), can be ended by them at any time and is recorded in the security log.
• To look at a problem a member reports, the platform admin can view the site as that member: read-only, with a reason, for at most 30 minutes at a time; they see only what that member sees (never more than the member's own access). The member is notified at once with the reason, every start and end is recorded in the security log, and the member's data export lists it.

E. Logging and monitoring

• A security log of sign-ins, refused sign-ins, admin actions, support access, exports and deletions (who, what, when).
• Application logs in Azure Log Analytics, kept 30 days; Debrief does not store IP addresses in its database.

F. Availability, backups and deletion

• Point-in-time restore of the database for 7 days; a nightly export of the database kept 30 days; deleted files recoverable for 7 days (soft delete). All in the same region.
• Deleting an account, a recording, voice lines or a transcript removes it from the database and from every stored file in one operation; file deletions are queued and retried until done. Deleted data leaves all backups within 37 days.
• Unprocessed uploads are deleted after 30 days; the 720p playback copy after 90 days; a video in the source archive (only while the Controller turns it on) 12 months after it was stored.

G. Data minimisation

• Voice comms are transcribed only when the Controller turns it on, and only after the uploader's confirmation; transcription runs on the processing computer and no audio is sent to a speech or AI service.
• Voice embeddings stay on the processing computer and are never uploaded; voiceprints exist only for members who consented, are used only by the Controller's own processing PCs and are never shown in a browser, an export or a log.
• Deleting a voice line also removes what was computed from it (callout figures, the Coach's quotes) from every stored copy.
• No analytics, advertising or tracking tools.

H. Organisation

• Everyone at Debrief with access to production is bound by confidentiality and uses a personal account, protected by multi-factor authentication, for Azure and GitHub.
• Deployments are automated (tests run before every deploy; no long-lived deployment secrets).
• Incidents are handled and notified as in section 8.
• These measures are reviewed at least once a year and after any significant change or incident.

I. Cloud processing servers

• Started by Debrief in the same Azure region only for waiting jobs of orgs that allow cloud processing; no public IP address, all incoming connections refused; each server has its own one-time pairing secret and an identity that can only read that secret and delete its own server.
• A server downloads a recording over HTTPS through a signed, expiring link, deletes its copies after the job, and deletes itself (with its disk; an ephemeral disk where the server size allows it) when idle.
• The uploaded source is deleted after processing (kept at most 7 days when its voice comms still have to be transcribed on a PC).

Annex 3: Subprocessors

The current list, with purposes and locations, is at /legal/subprocessors and is part of this DPA.

Annex 4: Standard instructions (the Controller's settings)

• Upload, process, share, make private, move, delete a recording: by its owner, and for the org's recordings by the org's admins.
• Voice comms transcripts: on or off per org, retention per org (as long as the recording, or 30 / 90 / 365 days), delete one line, a speaker's lines, a transcript or all transcripts of the org.
• Members and access: invites, roles, removing members, support access (ended by the org's admins).
• Swarm: each member decides whether their PC shares with the org.
• Cloud processing: never, only when none of the org's PCs is free, or always (the org's admins); per recording "Move to the cloud" / "Back to our PCs".
• Source archive: on or off per org (the org's admins; off for a new org, not available to coaches): while on, the PC that processed a recording uploads its video (with its sound) to Debrief's storage in the same region, kept 12 months after it was stored for processing the recording again; turning it off deletes every archived video of the org; deleting a recording or an account deletes its archived video.
• Self-service rights tools: download my data, delete my account, correct profile data.
• Voice recognition: available while transcripts are on; each member decides for themselves (consent and withdrawal on their Profile).
• Training: labelling tasks (prepare, close and archive), which members help ("Help train Debrief" is each member's choice).
• Coaching (coaches): upload links (expiry, single or multiple use, revoke), deleting a student's recording, notes, pins, agenda, drafting and approving reviews, share links (expiry, revoke).
• Coach: on or off, the PC that runs it, the players it coaches and its settings (the org's admins); the team's decisions on its proposals (members). Debrief then makes the data in the Privacy Policy, section 7, available to that PC (section 1.5).