Data Processing Agreement

Version 1.0 · 18.09.2026

This is the template of the data processing agreement we conclude with a customer under art. 28 GDPR. We publish it so that a customer’s data protection officer can read it before any sales conversation. We sign it individually with every customer who asks; writing to the address in section 14 is enough. Until it is signed this document binds neither side. The Polish version governs.

1. Parties and subject matter

The processor is Pluscode Sp. z o.o. (PLUSCODE SPÓŁKA Z OGRANICZONĄ ODPOWIEDZIALNOŚCIĄ), registered office: ul. Kosowska 12/3, 60-464 Poznań, Polska, entered in the register of entrepreneurs of the Polish National Court Register kept by Sąd Rejonowy Poznań - Nowe Miasto i Wilda w Poznaniu, VIII Wydział Gospodarczy Krajowego Rejestru Sądowego (District Court Poznań - Nowe Miasto i Wilda in Poznań, 8th Commercial Division), under KRS number 0000811470, NIP (VAT) 7812002984, REGON 384741150, share capital 5 000,00 PLN.

The controller is the customer named in the main agreement or in the order.

This agreement sets out how we process personal data on behalf of the controller in connection with the Quanty service, including the AI Secretary module. Annex A describes the scope.

In data protection matters this agreement prevails over the terms of service.

2. Roles

The controller determines the purposes and means of processing. We process personal data only on its documented instructions.

Under Regulation 2024/1689 (the AI Act) we are the provider of the AI system and the controller is its deployer. Deployer duties, including informing callers and making sure its own staff are competent, stay with the controller.

We are not a controller of the personal data contained in customer content. If we ever started to determine the purposes of processing that data, we would become a controller within the meaning of art. 28(10) GDPR; we undertake not to do so.

3. Controller instructions (art. 28(3)(a))

We process personal data only on the documented instructions of the controller, including as regards transfers to third countries, unless required to do so by Union or Member State law. In that case we inform the controller before processing, unless the law forbids it.

Documented instructions are: this agreement, the main agreement and the terms of service, the configuration set by the controller in the application (including the assistant’s instructions, the model chosen, retention periods, form fields and mappings), support tickets, and written instructions sent to the contact address.

If we consider an instruction to infringe the GDPR or other data protection law, we tell the controller immediately and may hold execution until the matter is resolved.

4. Confidentiality and authorisations (art. 28(3)(b))

Only people who hold a written authorisation from us and have committed to confidentiality are given access to personal data. We keep a register of authorised people and make it available on request.

Where processing covers data under professional secrecy, our staff and contractors keep that secrecy also after the patient’s death, in line with art. 24(6) of the Polish Patient Rights Act, and after their employment or cooperation ends.

The controller may require that access to its data needs an additional authorisation issued by the controller. The roles on our side that can gain access are listed in Annex C.

5. Security of processing (art. 28(3)(c))

We apply the technical and organisational measures described in Annex C, appropriate to the risk to the rights and freedoms of data subjects (art. 32 GDPR).

We process data in a way that does not disrupt the provision of health services or the continuity of the controller’s operations (art. 24(5) of the Patient Rights Act). If we have to restrict access to the service, we give notice and offer a fallback.

We may change the security measures as long as the level of protection is not lowered. Material changes are reported to the controller.

6. Sub-processors (art. 28(3)(d))

The controller gives general authorisation for the sub-processors listed in Annex B and at /subprocessors.

We give at least 30 days’ notice before adding or replacing a sub-processor. Where our provider gives us a shorter period, we pass the notice on within 7 days of receiving it.

The controller may object within 30 days on reasoned data protection grounds. We then look for a solution; if none is found, the controller may terminate the agreement as to the affected feature without extra charge and with a pro rata refund for the unused period.

We impose the same data protection obligations on sub-processors as this agreement imposes on us. We remain fully liable to the controller for their acts and omissions (art. 28(4) GDPR).

7. Assisting with data subject rights (art. 28(3)(e))

We give the controller features that let it find, correct, export and delete a person’s data itself, including searching AI Secretary requests by phone number.

If a data subject brings a request directly to us, we do not answer it on the merits; we pass it to the controller within 2 business days and tell the person who the controller is.

At the controller’s request we help carry out a request where the available features are not enough.

We notify the controller of a personal data breach without undue delay and no later than 48 hours after becoming aware of it, so that the controller can meet its own 72-hour deadline. The notice contains the information listed in art. 33(3) GDPR as far as it is known to us, and we complete it in stages.

Internally we aim to notify within 24 hours. The 48-hour figure is the contractual limit because part of the information depends on our providers, who notify us without undue delay after confirming a breach.

For a data protection impact assessment (art. 35) and prior consultation (art. 36) we provide a description of the system, the data flow, an inventory of fields and their sensitivity, retention periods, the list of sub-processors and Regions, and a description of the safeguards.

We keep a record of categories of processing carried out on behalf of the controller (art. 30(2) GDPR) and provide the relevant extract on request.

9. End of processing (art. 28(3)(g))

At the end of the service, at the controller’s choice, we delete the data or return it and delete existing copies, unless the law requires storage.

Export as CSV and XLSX and download of files are available throughout the term and for 30 days afterwards, at no extra charge.

After that period we delete the data from production systems, and from backups as they are overwritten, within no more than 90 days. We also instruct sub-processors to delete; their timelines are in Annex B.

If the controller ceases its activity, at its request we hand over the data in a format fit for further processing, in line with art. 24(7) of the Patient Rights Act. We issue a deletion confirmation on request.

10. Information and audits (art. 28(3)(h))

We make available the information needed to demonstrate compliance with art. 28 GDPR, including the description of safeguards, the list of sub-processors, a completed due diligence questionnaire, and our providers’ reports and certificates to the extent we are allowed to share them.

The controller may carry out one audit per calendar year, on at least 30 days’ notice, during working hours, in a way that does not disrupt our operations and that preserves confidentiality and the security of other customers’ data. The audit may be carried out by an independent auditor who is not our competitor, after signing a confidentiality agreement.

A further audit is possible after a personal data breach affecting the controller, or where a supervisory authority requires it.

The controller bears the cost of the audit, unless the audit reveals a material breach on our side.

11. Limits we do not cross

We do not use customer content for our own purposes, including product development, sales statistics or model training. The exception is anonymised technical data about how the system runs, which does not allow anyone to be identified.

We do not create a voiceprint or any other biometric profile of callers and we do not use speaker recognition.

We take no decisions producing legal effects for data subjects. A request is always handled by a person on the controller’s side.

By default we do not collect PESEL numbers or other identity numbers in AI features or in the AI Secretary.

The AI Secretary is not used for urgency assessment, eligibility decisions or advice. That is a boundary of the controller’s instruction which we do not execute.

12. Liability

Each party is liable to the other for damage caused by breach of this agreement, on general principles and having regard to art. 82 GDPR.

The liability limits in the terms of service apply accordingly, save that they do not limit liability towards data subjects or administrative liability.

We are liable to the controller for sub-processors as for our own acts, regardless of the liability limits in our agreements with them.

13. Term and governing law

This agreement runs for the term of the main agreement and for as long as we process data on behalf of the controller.

Polish law applies. Disputes are resolved by the court competent for the defendant’s registered office.

The Polish version is the binding one.

14. How to sign it

Write to dawid@pluscode.io with the name of your organization, its registration data, address, the contact for your data protection officer if you have one, and which Quanty features you use.

We send back a completed document for electronic signature. We sign with each customer separately; this is not a one-click acceptance.

If your organization has its own template, we will review it. The points that usually need a conversation are notice periods, the scope of audits and the list of sub-processors.

Until it is signed this document is information only and creates no obligations.

Annex A. Subject matter, duration, nature and purpose

Subject matter: personal data contained in customer content, including call data handled by the AI Secretary.

Duration: the term of the main agreement and the retention periods described in section 9.

Nature of processing: collection, recording, storage, organisation, retrieval, consultation, use in AI features, disclosure to the controller’s staff, and erasure.

Purpose: providing the Quanty service in line with the configuration set by the controller, including taking phone requests and writing them into the controller’s tables.

Categories of data subjects: the controller’s staff and contractors, its customers and counterparties, people who call a number answered by the AI Secretary, and people whose data those callers give, for example a patient reported by a family member.

Categories of ordinary data: name, phone number, email address, postal address, company data, the content of a request and of correspondence, the call transcript, the AI-written call summary, call metadata, and audio recording where the controller switches it on.

Special categories (art. 9 GDPR): health data implied by the description of the matter, for example a speciality or visit type, and only if we have cleared the controller to process such data in the AI Secretary. At the date of this template no organization is cleared.

Excluded data: PESEL numbers, identity document numbers, health insurance card numbers, full payment card and bank account numbers. The controller undertakes not to enter them.

Annex B. Sub-processors

The current, dated list is published at /subprocessors. The summary below is as at the date of this document.

Amazon Web Services EMEA SARL (Luxembourg), data centres in the eu-central-1 Region (Frankfurt, Germany): hosting for the application and database, file storage, outgoing and incoming mail (Amazon SES), sign-in (Amazon Cognito) and AI models (Amazon Bedrock). Data stored in the EU; model requests may be routed outside the EEA under the Standard Contractual Clauses incorporated in the AWS data processing addendum. Deletion after the end: up to 90 days.

Stripe Payments Europe, Limited (Ireland) with Stripe, Inc. (USA): payments. Stripe receives no customer content and no call data.

Exa Labs, Inc. (USA): web search started by a user. The query text is transferred. We are verifying the provider’s transfer documentation; until that is finished the feature should not be used on special category data.

Eleven Labs, Inc. (USA) with its affiliates, including Eleven Labs Poland sp. z o.o.: running the conversation in the AI Secretary. Storage in the USA, processing in the USA, the EU or Singapore. Basis: EU-US Data Privacy Framework and the Standard Contractual Clauses. The transcript is deleted after 30 days by default.

Language model providers engaged by Eleven Labs: Google Cloud (Gemini and Claude models) and OpenAI (GPT models, including the backup model). The call text is transferred. Transfer basis: EU-US Data Privacy Framework or the Standard Contractual Clauses, through Eleven Labs.

Twilio Ireland Limited (Ireland) with Twilio Inc. (USA): the phone number and call connection, only where Quanty provides the number. Twilio also processes some call data as a separate controller, for abuse prevention. If the controller uses its own operator, that operator is not our sub-processor.

Eleven Labs engages its own further providers for infrastructure, moderation and support, listed at compliance.elevenlabs.io/subprocessors.

Google Ireland Limited and Microsoft Ireland Operations Limited are not our sub-processors. Data reaches them only where the controller connects its own mailbox or spreadsheet and builds an automation; it then acts under its own agreement with those providers.

Notice period for changes: 30 days, or 7 days from receiving our provider’s notice where that provider gives us a shorter period. Objection and its effects are described in section 6.

Annex C. Technical and organisational measures

Location: application and database in Amazon Web Services, eu-central-1 Region (Frankfurt). Server access only through AWS Systems Manager Session Manager, with no open SSH.

Encryption: traffic encrypted with TLS. Database data, object storage files and backups encrypted at rest. Integration tokens and mailbox passwords stored encrypted and never shown again after entry.

Customer separation: every organization has its own data space. Separation is enforced by the application layer on every query; the organization identifier comes from the session, not from request parameters.

Access control: named accounts, roles and permissions at workspace, project and table level. Sign-in through Amazon Cognito. A second factor in the form of a one-time code (TOTP), required for admin accounts and for sensitive operations.

Pluscode staff access: time limited, 7 days by default and 30 days at most, visible to the customer in the organization panel and revocable by the customer at any time. For organizations processing health data we additionally require a written request from the customer, a stated reason and an end date.

Logging: platform admin actions are written to a separate record. Sign-in events and permission changes are logged. Logs are kept for up to 12 months.

Message integrity: incoming and outgoing webhooks are signed, and the signature is verified before a message is processed.

Deletion: deleting an account moves the data to an archived state for 180 days, after which it is permanently deleted. Call data can be deleted item by item from the application.

Staff: contracts with a confidentiality clause, written processing authorisations, a register of authorised people, and training on data protection and on the use of AI.

Development and testing: changes go through code review and a set of automated tests run before deployment. Production and test environments are separate.

What we do not have: we hold no ISO 27001 or SOC 2 certificate and no certification under art. 42 GDPR. Our infrastructure providers hold certificates; those are not ours.