# Data Processing Agreement

**Synthestat portal: standard agreement under Article 28 GDPR**

Version 1.0 of 5 October 2026. Published at /legal/dpa. A Czech version is published at /legal/cs/dpa.

This agreement ("DPA") governs the processing of personal data that a business customer of the Synthestat portal uploads or enters into the portal. It is concluded under Article 28(3) of Regulation (EU) 2016/679 (General Data Protection Regulation, "GDPR").

## 1. Parties and roles

1.1 **Controller:** the business customer named in Annex 4 (the "Client"). The Client decides which personal data it uploads to or enters into the portal and for which purposes. It is the controller of that data, or acts as a processor for its own client; in that case the Client warrants that its own controller has authorised this processing and the engagement of the Processor.

1.2 **Processor:** Briar Hamsfest Consulting s.r.o., Wolkerova 607, 473 01 Nový Bor, Czech Republic, IČO 03486770, DIČ CZ03486770, registered in the Commercial Register kept by the Regional Court in Ústí nad Labem, Section C, file 35225, contact info@synthestat.com (the "Processor"). The Processor operates the Synthestat portal.

1.3 **Client Personal Data** means the personal data that the Client or its authorised users upload to or enter into the Client's organisation in the portal, and the personal data derived from it in the portal, as described in Annex 1.

1.4 **Outside this DPA:** the Processor processes the account, sign-in, activity, billing and correspondence data of the Client's users for its own purposes (running accounts, security, billing, legal obligations) as a controller. That processing is described in the privacy notice at /legal/privacy and is not governed by this DPA.

1.5 This DPA forms part of the Client's subscription agreement for the portal and of the terms of use at /legal/terms. Where they conflict on the protection of personal data, this DPA prevails.

## 2. Subject matter, duration, nature and purpose

2.1 **Subject matter:** processing of Client Personal Data to provide the portal to the Client under its subscription.

2.2 **Duration:** from the earlier of signature and the first upload of Client Personal Data until the Client Personal Data has been deleted or returned under clause 11.

2.3 **Nature and purpose:** storage, encryption, pseudonymisation, classification, aggregation, comparison with synthetic results, sending prompts to AI models where the Client uses features that do so, export of reports and aggregates, and deletion; all solely to provide the portal functions the Client uses. Annex 1 gives the details.

2.4 The Processor does not use Client Personal Data for its own purposes, does not sell it, and does not use it to train AI models.

## 3. Obligations of the Client

3.1 The Client is responsible for the lawfulness of the processing it instructs: a legal basis for each upload, the information given to data subjects under Articles 13 and 14 GDPR, and any consents.

3.2 The Client uploads only the personal data its work needs. Where possible it removes names, contact details and other direct identifiers from survey files before upload.

3.3 The Client tells the Processor in writing before it uploads special categories of personal data (Article 9 GDPR) or data on criminal convictions (Article 10 GDPR).

3.4 The Client's administrators decide which features process Client Personal Data, including model choice, EU-only routing, the deletion date of each upload and the use of real human answers in the Replication Lab (Annex 1).

## 4. Documented instructions (Article 28(3)(a))

4.1 The Processor processes Client Personal Data only on the Client's documented instructions, including with regard to transfers to third countries, unless Union or Member State law to which the Processor is subject requires otherwise. In that case the Processor informs the Client of that legal requirement before processing, unless that law prohibits it on important grounds of public interest.

4.2 The Client's instructions are: this DPA; the subscription agreement; and the settings and actions of the Client's authorised users in the portal (for example uploading a file, setting its deletion date, choosing a model, switching EU-only routing on or off, starting a run, exporting a report or deleting a study). Further instructions are given in writing to info@synthestat.com.

4.3 The Processor informs the Client immediately if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions.

## 5. Confidentiality (Article 28(3)(b))

5.1 The Processor ensures that persons authorised to process Client Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. The obligation continues after their engagement ends.

5.2 The Processor gives access to Client Personal Data only to persons who need it to operate, support or secure the portal.

## 6. Security of processing (Article 28(3)(c) and Article 32)

6.1 The Processor implements the technical and organisational measures described in Annex 2.

6.2 The Processor may change the measures as technology and risks develop, provided that the overall level of protection is not reduced. Annex 2 is updated with each material change.

6.3 No approved code of conduct or certification under Articles 40 to 42 GDPR is relied on for this DPA.

## 7. Sub-processors (Article 28(2), (3)(d) and (4))

7.1 The Client gives the Processor general written authorisation to engage the sub-processors listed in Annex 3.

7.2 The Processor informs the Client of any intended addition or replacement of a sub-processor at least 30 days in advance, by email to the Client's contact in Annex 4, and updates Annex 3.

7.3 The Client may object to the change on reasonable data protection grounds by email to info@synthestat.com within that period. The parties then discuss the objection in good faith. If they cannot resolve it, the Client may terminate the affected part of the subscription with effect before the change, and the Processor refunds prepaid fees for the period after termination.

7.4 The Processor imposes on each sub-processor, by contract, data protection obligations that give the same level of protection as this DPA, in particular sufficient guarantees for appropriate technical and organisational measures. The Processor remains fully liable to the Client for the performance of each sub-processor's obligations.

7.5 Model endpoints that the Client configures with its own key or address, and model providers the Client reaches with its own key, are chosen by the Client. They are the Client's own recipients and not sub-processors of the Processor; the Client is responsible for its arrangement with them.

## 8. Assistance with data subject rights (Article 28(3)(e))

8.1 Taking into account the nature of the processing, the Processor assists the Client by appropriate technical and organisational measures, insofar as possible, in responding to requests of data subjects exercising their rights under Chapter III GDPR.

8.2 If a data subject sends such a request directly to the Processor, the Processor forwards it to the Client without undue delay and does not answer it itself unless the Client instructs it to.

8.3 The portal stores respondent records under keyed pseudonyms (Annex 2). Where a request concerns a respondent, the Client provides the respondent identifier used in its own files so that the Processor can locate the records.

## 9. Assistance under Articles 32 to 36; personal data breaches (Article 28(3)(f))

9.1 Taking into account the nature of the processing and the information available to it, the Processor assists the Client in ensuring compliance with Articles 32 to 36 GDPR: security of processing, notification of personal data breaches to the supervisory authority and communication to data subjects, data protection impact assessments and prior consultation.

9.2 The Processor notifies the Client of a personal data breach affecting Client Personal Data without undue delay after becoming aware of it, by email to the Client's contact in Annex 4.

9.3 The notification describes, as far as then known: the nature of the breach, including the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed to address the breach and mitigate its effects; and a contact point. Where the information is not available at once, the Processor provides it in phases without undue further delay.

9.4 The Processor does not notify the supervisory authority or data subjects on the Client's behalf unless the Client instructs it to or the law requires it.

## 10. Transfers outside the EU and EEA

10.1 The portal and its data are hosted in Germany (EU).

10.2 Some sub-processors in Annex 3, including OpenRouter and several AI model providers, are based outside the European Economic Area. Using their models can transfer Client Personal Data contained in prompts to third countries such as the United States.

10.3 Such transfers take place only as part of the Client's instructions (clause 4.2) and rely on the EU-US Data Privacy Framework where the recipient is certified under it, and otherwise on the standard contractual clauses adopted by the European Commission (Chapter V GDPR). The Processor provides on request the safeguard that applies to a particular recipient and a copy of the clauses.

10.4 The Client's administrators can switch on EU-only routing. The portal then sends model requests only through OpenRouter's EU endpoint, without fallback to other routes, and refuses direct providers and the Client's own endpoints.

## 11. Deletion or return at the end of the services (Article 28(3)(g))

11.1 During the subscription, each uploaded file is deleted at the deletion date set for it (by default 90 days after upload), and the Client may delete content earlier through the portal or by instruction to info@synthestat.com.

11.2 When the subscription ends, the Client has 30 days to export its content through the portal's export functions or to ask for a copy of the Client Personal Data held, in the form in which it is stored. After that period the Processor deletes the Client Personal Data, unless Union or Member State law requires storage.

11.3 Copies in database backups are deleted when the backups expire (Annex 1). Until then backups are kept under the measures of Annex 2 and are not used for any other purpose.

11.4 On request, the Processor confirms the deletion in writing.

## 12. Information and audits (Article 28(3)(h))

12.1 The Processor makes available to the Client all information necessary to demonstrate compliance with Article 28 GDPR, in particular this DPA, its annexes and written answers to the Client's reasonable questions.

12.2 The Processor allows for and contributes to audits, including inspections, conducted by the Client or by an auditor mandated by the Client who is bound by confidentiality and is not a competitor of the Processor.

12.3 The Client gives at least 30 days' written notice of an audit. Audits take place at most once in any 12 months, during business hours and without undue disruption of operations, unless a personal data breach affecting Client Personal Data or a request of a supervisory authority justifies an additional audit.

12.4 Each party bears its own costs of an audit.

12.5 An audit does not give access to other customers' data or to information whose disclosure would compromise the security of the portal.

## 13. Liability

13.1 Each party is liable for its own breaches of this DPA and of the GDPR, including under Article 82 GDPR.

13.2 Liability between the parties is otherwise governed by the subscription agreement and applicable law. Nothing in this DPA excludes or limits liability that cannot legally be excluded or limited, including liability for intentional misconduct or gross negligence.

## 14. Term and termination

14.1 This DPA applies for as long as the Processor processes Client Personal Data, and ends when the Client Personal Data has been deleted or returned under clause 11.

14.2 Clauses 5, 11, 12 and 13 survive the end of the DPA to the extent needed.

## 15. Governing law, jurisdiction, language and changes

15.1 This DPA is governed by Czech law, without prejudice to the GDPR and other mandatory provisions. Jurisdiction follows applicable law.

15.2 This DPA is provided in English and in Czech. If the two versions differ, the English version prevails.

15.3 Changes to this DPA require written form, except updates of Annex 2 under clause 6.2 and of Annex 3 under clause 7.2.

15.4 Notices under this DPA are sent by email: to the Processor at info@synthestat.com and to the Client at its contact in Annex 4.

15.5 If a provision of this DPA is invalid, the remaining provisions stay in force, and the parties replace the invalid provision with a valid one closest to its purpose.

---

## Annex 1: Details of the processing

### Categories of data subjects

- Respondents of human surveys and fieldwork whose answers or profiles the Client uploads (for example survey waves exported from a survey host, reference data for the Replication Lab, respondent rosters, panel profile files from a fieldwork provider).
- The Client's authorised users, to the extent the Client manages them in its organisation (invitations, membership, roles, project membership).
- Persons named in content the Client uploads or enters, for example authors of published studies added to a validation package, or persons named in questionnaires and notes.

### Categories of personal data

- **Human survey files** as uploaded (CSV, XLSX or Parquet): the whole file, which can contain respondent identifiers, contact columns, demographic and geographic variables, answers including open text, interview dates and weights. The portal detects identifier, contact and sensitive columns and withholds their values from diagnostics.
- **Normalised respondent records** derived from those files: the respondent identifier replaced by a keyed pseudonym, mapped answer codes, segments, geography, field date and weight.
- **Respondent rosters and population files** uploaded with a questionnaire: row identifier, mapped demographics, interview date and weight.
- **Panel profile files** from a fieldwork provider: age band, sex or gender, region, education and the provider's person reference.
- **Organisation membership data:** name, email address, role and invitations of the Client's users.
- **Bibliographic data** in validation packages: titles, abstracts and author names of published studies.
- **Other workspace content** the Client enters: questionnaires, scenarios, prompts, notes and generated outputs, insofar as they contain personal data.
- **Special categories** (Article 9 GDPR) only where the Client uploads them, for example health, religion, ethnicity or political opinion variables in a survey file (clause 3.3).

### Processing operations

- Upload, encrypted storage and classification of survey files; creation of pseudonymised respondent records.
- Aggregate analysis: quality checks, weighting, comparison of synthetic results with human results (validation, Replication Lab, calibration), with estimates suppressed below the minimum cell size (Annex 2).
- Prompts to AI models: workspace content (questionnaires, scenarios, population descriptions) is sent to the model chosen for a run. Real respondents' answers are sent to a model only when the Client switches on context or informed twins in the Replication Lab, and then only under the safeguards in Annex 2.
- Export of reports and aggregates to the Client's users.
- Deletion at the deletion date, on instruction and at the end of the subscription.

### Duration and retention

The periods published in the privacy notice at /legal/privacy (section 6) apply, in particular:

- uploaded files including human survey data: until the deletion date set for the upload (by default 90 days after upload), and no longer than workspace content;
- workspace content: for the subscription; after it ends the Client has 30 days to export it, then it is deleted;
- rendered prompts stored with survey responses: 30 days, then emptied by a daily clean-up;
- database backups: 30 days, then deleted.

### Location

Hosting in Germany (EU). Transfers outside the EEA only as described in clause 10 and Annex 3.

## Annex 2: Technical and organisational measures

The measures below describe what the portal does as of the date of this version.

### Hosting and encryption in transit

- The portal and its data are hosted at Contabo in Germany (EU).
- The application servers listen only on the local interface behind a reverse proxy that terminates TLS (HTTPS). The web application sends Strict-Transport-Security. In production the session and CSRF cookies are sent only over HTTPS, and the session cookie is not readable by scripts.
- The API refuses to start in production when the deployment self-check reports an error (for example a missing signing key for AI marking).

### Access to the portal

- Accounts are created by invitation only. Invitation tokens are stored only as SHA-256 digests and expire after 14 days.
- Passwords are stored only as salted PBKDF2-SHA256 hashes and must pass password-strength validators. Google sign-in is verified with Google and requires a verified email address.
- Sign-in tokens are 256-bit random values stored only as SHA-256 digests. They expire after 30 days and can be revoked by signing out or revoking all sessions.
- Sign-in attempts are rate-limited per IP address and per account.

### Role-based access and project isolation

- Every organisation member has a role (viewer, operator, analyst, admin, owner). The server checks the role on each request; users outside an organisation receive "not found" for its data.
- Project membership limits which projects a user sees within the organisation.
- Automated tests check that one organisation cannot read another organisation's data.
- Uploading human survey data requires a specific capability that only platform administrators grant to an organisation.
- Platform administrators of the Processor can access all organisations to operate and support the portal; their access to restricted evidence is recorded (see audit logs).

### Restricted storage of human survey data

- Uploaded human survey files, panel profile files from fieldwork providers and the normalised respondent records are encrypted at rest with AES-256-GCM before they are written. Keys are versioned, held outside the code repository and can be rotated.
- Restricted files are stored per organisation in directories readable only by the service account.
- Respondent identifiers are replaced by keyed (HMAC) pseudonyms in the normalised records.
- Every decryption is checked against a stated purpose and capability and recorded in the audit log. Decryption is refused once the upload's deletion date has passed.
- Restricted files are never offered for download through the portal.
- Credentials of fieldwork providers are encrypted with AES-GCM under a separate versioned keyring.
- Questionnaire and population (roster) files uploaded with a survey design are kept in a private directory on the server that the portal does not serve directly. They are not encrypted at rest by the application.

### Aggregate-only outputs

- Outputs computed from human data are aggregates. Estimates and dashboard cells with an effective sample size below 30 are suppressed, and the Replication Lab applies a minimum cell size of 30.
- Exports are reports and aggregate tables; the portal offers no export of respondent-level human data.
- When ESS microdata is used for a validation package, it is processed in a temporary folder that is deleted after the aggregates are computed.

### AI model requests

- Model requests contain the prompt content a run needs. Rendered prompts stored with synthetic survey responses are emptied after 30 days by a daily scheduled clean-up.
- Real respondents' answers reach a model only in Replication Lab context or informed twins, which the Client must switch on and which require the human-data capability. Those requests go only to OpenRouter with the instruction that hosts must not collect the data (data_collection: deny), or to a local model; if no host accepts this, the run fails and the answers are not sent. The answers are not stored with the synthetic responses, and prompt logging is off for those runs.
- EU-only routing (clause 10.4) can be switched on per organisation.
- API keys that an organisation stores for its own model providers, and its credentials for data sources in validation packages, are encrypted with a server-held key and an integrity tag.

### Audit and activity logs

- Security-relevant events (sign-ins, membership and role changes, organisation deletion, decryption of restricted evidence, changes of privileged access) are written to an append-only audit log whose entries are hash-chained; a verification command detects alteration.
- Sign-ins, sign-outs and pages opened by signed-in users are recorded with time, IP address, browser user agent, organisation and role.

### Backups

- Database backups are created through an administrative function restricted to Processor staff, stored on the hosting server with owner-only file permissions, and rotated so that only the newest backups are kept.

### Deletion

- A daily scheduled job deletes the source files and respondent records of human survey uploads whose deletion date has passed, keeping only a record that the deletion took place.
- Deleting a Replication Lab study destroys its uploaded reference file.

### AI marking of outputs

- Exported AI-generated reports and data files carry a machine-readable AI marking signed with the Processor's Ed25519 key over a SHA-256 hash of the content (the files concerned are listed at /legal/ai). Public keys and a verification endpoint are published, so alteration of a marked export can be detected.

### Application security

- The web application sends security headers (frame-ancestors 'none', X-Frame-Options DENY, X-Content-Type-Options nosniff, a Referrer-Policy and a Permissions-Policy). Cross-origin requests are allowed only from configured origins.
- Releases are refused when the installed framework versions differ from the pinned ones. Dependency and secret scans run in continuous integration.

### Organisational measures

- Persons with access to Client Personal Data are bound to confidentiality (clause 5).
- Personal data breaches are handled and notified under clause 9.
- Changes of sub-processors follow clause 7.

## Annex 3: Sub-processors

Authorised sub-processors as of the date of this version. Several are used only when the Client configures or chooses them.

| Sub-processor | Service | Location | Transfer basis |
|---|---|---|---|
| Contabo | Hosting of the portal and its data | Germany (EU) | None needed (EU) |
| OpenRouter | Routes requests to AI models; receives prompts built from workspace content and passes them to the provider of the model chosen for a run | Outside the EEA | EU-US Data Privacy Framework where the recipient is certified under it, otherwise standard contractual clauses |
| Providers of the models chosen for a run, reached through OpenRouter (the default model catalogue includes models from Google, Z.ai, OpenAI, inclusionAI, DeepSeek and Anthropic) | Run the chosen AI model on the prompt | Depends on the provider; can be outside the EEA | EU-US Data Privacy Framework where the recipient is certified under it, otherwise standard contractual clauses |
| Anthropic and Google (Gemini), directly | Run their models when a run uses them through the Processor's key | Can be outside the EEA | EU-US Data Privacy Framework where the recipient is certified under it, otherwise standard contractual clauses |
| TypeSafe | The "Jev" model for closed survey questions, when chosen | Stated on request | If outside the EEA: EU-US Data Privacy Framework where the recipient is certified under it, otherwise standard contractual clauses |
| The Processor's email delivery provider | Sends invitations and service messages to the Client's users | Stated on request | If outside the EEA: EU-US Data Privacy Framework where the recipient is certified under it, otherwise standard contractual clauses |

Notes:

- When EU-only routing is on (clause 10.4), model requests go only through OpenRouter's EU endpoint, and direct providers are refused.
- Model endpoints and keys that the Client configures itself are not sub-processors (clause 7.5).
- Stripe (card payments), Google (Google sign-in), map image providers and Deepgram (Academy voiceover) are named in the privacy notice. They receive no Client Personal Data under this DPA.
- Speech recognition for media contrasts runs on the Processor's own servers.

## Annex 4: Signatures

The parties sign this DPA, version 1.0 of 5 October 2026, including Annexes 1 to 3.

| | Client (controller) | Processor |
|---|---|---|
| Name | ______________________ | Briar Hamsfest Consulting s.r.o. |
| Registered office | ______________________ | Wolkerova 607, 473 01 Nový Bor, Czech Republic |
| Company ID (IČO or equivalent) | ______________________ | 03486770 |
| Register entry | ______________________ | Regional Court in Ústí nad Labem, Section C, file 35225 |
| Contact for notices under this DPA (clauses 7.2, 9.2) | ______________________ | info@synthestat.com |
| Represented by (name, function) | ______________________ | ______________________ |
| Place and date | ______________________ | ______________________ |
| Signature | ______________________ | ______________________ |