Data Processing Agreement

Last updated and published: 24 September 2026

1. Parties, status and main document

This data processing agreement ("DPA") constitutes an appendix to the Unabyss terms of use, an order, subscription agreement, enterprise agreement or another main agreement concluded between the customer and OneType P.S.A. (the "Main Agreement").

The processor is OneType Prosta Spolka Akcyjna with its registered office in Warsaw, Aleja Jana Pawła II 68/19, 00-170 Warsaw, KRS: 0001224271, NIP: 7011299839 (the "Processor", "OneType"). The controller is the customer using Unabyss who determines the purposes and means of processing data imported, uploaded, synchronised, stored, analysed or shared in Unabyss as Context Data (the "Controller").

If OneType processes certain data for its own purposes, in particular account, billing, marketing, security, own claims or service management data, it acts as a separate controller. Such scope is not covered by this DPA unless expressly stated otherwise.

2. Definitions

Term	Meaning
Controller Data	All personal data processed by the Processor on behalf of the Controller within Unabyss, in particular Context Data and data related to integrations, prompts, outputs, embeddings, MCP, chatbots and files.
Context Data	Data, content, files, documents, notes, messages, metadata, prompt/output, indexes, embeddings, configurations and other information imported, uploaded or created by the Controller or its users.
GDPR	Regulation (EU) 2016/679 and, where the Controller is established in the United Kingdom, the UK GDPR and the Data Protection Act 2018; references to Articles of the GDPR include the corresponding provisions of the UK GDPR.
High-Risk Data	Special-category data under Article 9 GDPR, medical data, data relating to convictions and offences, children's data, professional secrets, financial data, authentication data, secrets, API keys, card data, trade secrets and other data whose breach may cause high risk to persons or organisations.
LLM / AI providers	Providers of AI models or services used for classification, generation, extraction, summarisation, transcription, semantic search, embeddings, RAG or other AI features.
MCP	Model Context Protocol or a similar technical mechanism enabling contextual data to be shared from Unabyss to external tools, agents or AI models.
Subprocessor	Another processor to whom the Processor entrusts the processing of Controller Data in order to provide or secure Unabyss.

3. Subject matter and duration of processing

The subject matter of processing is the processing of Controller Data for the purpose of providing, maintaining, securing, developing and supporting Unabyss, including handling integrations, data import, synchronisation, upload, storage, segmentation, semantic search, creation of embeddings, RAG, LLM processing, chatbots, MCP, API, research pipeline, diagnostics, support, security and data deletion.

The processing continues for the term of the Main Agreement and for the period necessary to return, export, delete, anonymise or restrict data after its termination, taking into account backup retention, legal obligations and legitimate defence of claims.

4. Nature and purpose of processing

Element	Description
Nature of operations	collection, retrieval, import, recording, organisation, structuring, storage, adaptation, modification, retrieval, consultation, use, disclosure by transmission, sharing, combination, matching, restriction, erasure and destruction of data.
Purpose	provision of Unabyss and the context layer, integrations, AI/LLM, embeddings, RAG, MCP, chatbots, research pipeline, support, security and data management features in accordance with the Main Agreement.
Place of processing	EEA and countries where approved subprocessors operate, applying transfer mechanisms required by the GDPR.
Categories of persons	Controller's users, employees, collaborators, contractors, customers, leads, candidates, meeting participants, persons in calendars, documents, CRM, repositories, messengers, chatbot public users and other persons whose data is included in the Controller's sources.
Categories of data	all data included in the Controller's sources, files and configurations, including identification, contact and professional data, correspondence, notes, files, calendars, CRM, repositories, transcripts, prompt/output, embeddings, technical data and incidentally sensitive data.

5. Documented instructions of the Controller

The Processor processes Controller Data only on documented instructions from the Controller, unless processing is required by Union or Member State law. The Controller's instructions include, in particular, the Main Agreement, this DPA, service configuration, workspace settings, connection of an integration, selection of scopes, file upload, start of synchronisation, prompt, chatbot conversation, sharing via MCP, AI model selection, retention settings, export or deletion of data.

The Processor informs the Controller if, in its opinion, an instruction infringes the GDPR or other data protection laws. The Processor may suspend performance of an instruction or feature if necessary to prevent a breach of law, security incident, unauthorised transfer or high risk to individuals.

6. Controller's obligations

The Controller is responsible for the lawfulness, fairness, transparency, minimisation and adequacy of data uploaded or synchronised with Unabyss.
The Controller ensures a legal basis for processing under Article 6 GDPR and, for special-category data, additionally the relevant exception under Article 9 GDPR; for data relating to convictions and offences, it ensures compliance with Article 10 GDPR.
The Controller fulfils information obligations towards persons whose data is included in sources, files, communications, transcripts, CRM, repositories, calendars and other data imported into Unabyss.
The Controller should not import data whose processing in Unabyss is prohibited, inconsistent with an agreement, source terms, professional secrecy or internal policies of the organisation.
The Controller is responsible for integration configuration, scope selection, limitation of folders/channels/repositories, retention settings, user permissions and the decision to share data through MCP or public chatbots.
The Controller should conduct a DPIA where the nature of data, scale, integrations, AI, MCP, chatbots or high-risk data may result in a high risk to the rights and freedoms of individuals.
The Controller may itself act as a processor for a third party with respect to some of the data it uploads or synchronises with Unabyss (e.g. the Controller is itself a SaaS business, and its connected sources contain data belonging to its own customers). This is a real, expected scenario, not a hypothetical. This does not change the Processor/Controller structure of this DPA — from Unabyss's perspective, the Controller named in this DPA remains the Controller regardless of what it does with the data on its own side — but it means the Controller's own information obligations and legal-basis analysis in this section may need to account for a further downstream party.

7. Processor's obligations

process Controller Data only in accordance with the DPA, the Main Agreement and documented instructions of the Controller;
ensure that persons authorised to process data have committed themselves to confidentiality or are subject to an appropriate statutory duty of confidentiality;
apply technical and organisational measures adequate to the risk, in particular the measures described in the TOMs appendix;
use only subprocessors in accordance with the rules set out in the DPA;
assist the Controller, to the extent possible and taking into account the nature of processing, in exercising data subject rights, handling breaches, DPIAs and consultations with the supervisory authority;
maintain a record of categories of processing activities where required;
not use Controller Data to train its own models or models of external providers unless the Controller expressly instructs otherwise and an appropriate legal basis, contractual basis and technical configuration exist;
after the end of the services, delete or return Controller Data in accordance with the DPA and the Main Agreement, subject to legal obligations, backups and restriction of data for claims;
make available to the Controller information necessary to demonstrate compliance with Article 28 GDPR, while maintaining the security and confidentiality of other customers.

8. High-Risk Data

Unabyss may technically process High-Risk Data if the Controller places it in connected sources or files. The mere technical possibility of processing does not mean that Unabyss is intended for intentional processing of such data in the ordinary self-service model.

Intentional processing of High-Risk Data, in particular medical data, health data, children's data, criminal data, professional secrets or data requiring special protection, requires at least the following conditions to be met:

The Controller has an appropriate legal basis and has fulfilled information obligations.
The Controller has assessed the risk and, where required, conducted a DPIA.
The parties have entered into a DPA or enterprise agreement covering such data scope.
Adequate restrictions on access, retention, support access, LLM, MCP, public sharing and logging have been enabled.
AI, hosting and monitoring providers have been approved for such data scope or processing of such data in the relevant feature has been disabled.
The Controller does not send passwords, secrets, API keys, payment card data or full medical documentation unless necessary and expressly agreed.

The Processor may implement limits, blocks, redaction, functional restrictions, additional verification or refuse to process High-Risk Data if it considers that sufficient legal or security guarantees are lacking.

9. Integrations, OAuth, API and access scopes

The Controller decides which integrations are connected and which data scopes are synchronised. The Processor should apply the principle of scope minimisation, enable disconnection of integrations and store OAuth tokens and API keys securely. Tokens, secrets and keys should not be logged or disclosed in prompts, outputs, support tickets or monitoring tools.

Disconnecting an integration blocks further import or synchronisation, but does not necessarily automatically delete data already imported unless the Controller chooses data deletion or this follows from the Main Agreement, DPA or retention settings.

10. LLMs, AI, embeddings, RAG and no-training

The Processor may transfer selected fragments of Controller Data to approved AI/LLM providers only to the extent necessary to perform Unabyss features. Processing should be carried out with prompt minimisation, limited logging, retention control, configuration preventing training on customer data and appropriate transfer mechanisms.

The Processor will not use Controller Data to train, fine-tune or improve general models of the Processor or AI providers unless the Controller expressly and separately instructs such processing and legal, technical and contractual requirements are met. Controller Data may not be used in private AI accounts, public chatbots of the Processor's personnel or unapproved browser extensions.

Embeddings, indexes and cache created from Controller Data are treated as data linked to source data and should be deleted, reconstructed or disabled after deletion of the source data, in accordance with technical capabilities and the retention policy.

11. Google API Limited Use

To the extent Unabyss accesses data from Google services such as Gmail, Google Drive, Google Docs, Google Sheets, Google Slides or Google Calendar, the Processor will use such data only to deliver or improve user-facing features, ensure security, comply with legal obligations or in accordance with the Controller's explicit instruction.

The Processor will not sell Google API data, use it for advertising purposes or use it to train general models unless the relevant Google policies, the agreement and the Controller's explicit instruction allow such use. The Processor will seek to limit scopes to the extent necessary for the features selected by the user.

12. MCP, export and public chatbots

Data sharing through MCP, API, public link, webhook, chatbot or another external tool takes place on the instructions of the Controller or its users. The Controller is responsible for assessing whether such sharing is compliant with law, agreements, confidentiality obligations and the rights of data subjects.

The Processor should provide, to the extent technically possible, user-control mechanisms such as selection of the data scope shared, warning before export, audit log, access revocation option and restrictions for High-Risk Data. After data is transferred to an external tool, further processing may be subject to that tool's terms.

13. Security and TOMs

The Processor applies technical and organisational measures adequate to the risk, taking into account the state of the art, implementation costs, nature, scope, context and purposes of processing and the risk to the rights and freedoms of individuals. Minimum measures are described in Appendix 3.

access control, RBAC, least privilege principle and MFA for administrative accounts;
encryption in transit and appropriate safeguards for data at rest;
management of secrets, API keys and OAuth tokens;
separation of production, development and test environments;
limitation of personal data logging and payload masking;
secure SDLC, code review, dependency scanning and vulnerability management;
monitoring, alerting, backups, restore tests and incident procedures;
authorisations, personnel confidentiality, access reviews and offboarding;
subprocessor due diligence and periodic transfer review.

14. Confidentiality and personnel

The Processor ensures that persons authorised to process Controller Data have access only to the extent necessary to perform their tasks, are bound by confidentiality and act in accordance with security documentation. Support or technical team access to production data should be limited, justified, logged and used only when the issue cannot be resolved on synthetic or anonymised data.

15. Subprocessors

The Controller grants the Processor general written authorisation to use the Subprocessors identified in the current register. The Processor will inform the Controller at least 14 days in advance of any intended addition or replacement of a Subprocessor processing Controller Data, unless an urgent change is objectively necessary for security, Service continuity or legal compliance; in such case, the information will be provided without undue delay together with the reasons.

The Processor maintains a separate, up-to-date Subprocessor, Data Source and Target Tool Register. For subprocessors, the register includes at least the name, function, data scope, location or processing region, applicable transfer mechanism and status of key safeguards. The register is made available to the Controller on request or at a location indicated by the Processor. Updating the register does not require an amendment to the DPA, provided that the general authorisation, notification and objection procedure set out below is followed.

The Processor ensures that each Subprocessor is bound by a contract or other legal act imposing substantially the same data protection obligations as those set out in this DPA in respect of the processing entrusted to it, in particular the obligation to implement appropriate technical and organisational measures. The Processor remains fully liable to the Controller for the performance of the Subprocessor's obligations to the extent required by Article 28(4) GDPR.

The Controller may object to a new subprocessor on reasonable grounds. The objection should indicate a specific legal or security risk. If the objection prevents provision of the service, the parties will agree a technical workaround, disable the affected feature or terminate use of that part of the service.

16. Transfers outside the EEA or the United Kingdom

Controller Data may be transferred outside the EEA — or, where the Controller is established in the United Kingdom, outside the United Kingdom — only after ensuring a mechanism compliant with Chapter V GDPR or, where the UK GDPR applies, its UK equivalent: the United Kingdom's adequacy regulations, the International Data Transfer Agreement, or the UK Addendum to the EU standard contractual clauses. Where the Controller is established in the United Kingdom, the Processor's own access to Controller Data from within the EEA is covered by the United Kingdom's adequacy regulations for the EEA. Current transfer routes, providers, regions and supplementary measures are documented in the Subprocessor, Data Source and Target Tool Register and in the current TIA. Where a transfer relies on SCCs, the Processor also documents an assessment of their effectiveness in the circumstances of the specific third country and the supplementary measures adopted. An adequacy decision, including the EU-US Data Privacy Framework, may be relied upon only for a recipient and transfer actually covered by its scope.

Where standard contractual clauses are required for a given transfer, the relevant entities enter into or effectively incorporate the appropriate SCC module together with the required options and annexes describing the transfer and security measures. This DPA does not replace missing elements of the SCCs. In case of conflict between properly entered-into SCCs and this DPA, the SCCs prevail to the extent required by law.

17. Personal data breaches

The Processor informs the Controller of a personal data breach affecting Controller Data without undue delay after becoming aware of the breach, and no later than within 24 hours of determining that the breach concerns or may concern Controller Data. The absence of complete information does not delay the initial notification; further information may be provided in phases without undue delay. The information should include, to the extent known to the Processor, the circumstances, categories of data and persons, likely consequences, remedial measures taken or proposed and a contact point.

The Processor supports the Controller in assessing the obligation to notify the breach to the supervisory authority or data subjects. A breach notification by the Processor does not constitute admission of liability or full legal qualification of the event.

18. Assistance with data subject rights, DPIA and consultations

The Processor assists the Controller, to the extent possible and taking into account the nature of processing, in exercising data subject rights, including the rights of access, rectification, erasure, restriction, portability and objection. If a person submits a request directly to the Processor in respect of Controller Data, the Processor will forward the request to the Controller or act in accordance with its instruction unless the law requires otherwise.

The Processor assists the Controller in conducting a DPIA and any prior consultations with the supervisory authority, within the scope of information available to the Processor, in particular concerning Unabyss features, TOMs, subprocessors, transfers, retention, LLM, MCP and breaches.

19. Audit and demonstration of compliance

The Controller may, at reasonable intervals and in any case where there are reasonable grounds to suspect non-compliance, request an audit of processing compliance. Where the Controller requests more than one audit within a given 12-month period, the request must be accompanied by the Controller's written justification setting out the specific grounds relied upon, and not merely a bare assertion of suspected non-compliance. As a rule, an audit requires at least 30 days' prior written notice, unless a shorter period is justified by a breach, security incident, supervisory-authority request or another urgent need to verify compliance. The audit should be conducted in a manner that does not disrupt the services, while maintaining confidentiality, security and the rights of other customers. The Processor may in the first instance provide documentation, security questionnaires, reports, certificates, test results or other evidence where sufficient to demonstrate compliance; this does not exclude an audit or inspection where required to give effect to Article 28(3)(h) GDPR.

An onsite audit requires separate organisational and security arrangements. The Controller does not obtain access to other customers' data, source code, the Processor's trade secrets or information whose disclosure could reduce the security of the service.

20. Return, export and deletion of data

After the end of the services, the Processor, at the Controller's choice, deletes or returns to the Controller all Controller Data and deletes existing copies, unless Union or Member State law requires further storage of the data. The method and format of return may take account of the technical capabilities of the Service, but this does not limit the obligation to delete data and copies where the Controller has chosen deletion. Backups are subject to the technical retention cycle set out below and, until deletion, are not used for ongoing processing except for disaster recovery. Production data should be deleted without undue delay, recommended within 30 days from an effective request or service termination, subject to restriction of data required by law or claims.

Deletion should include, to the extent technically possible, source data, files, indexes, embeddings, cache, prompts, outputs, chatbot configurations, public users data related to the customer and OAuth tokens. Data from backups is deleted in the ordinary backup retention cycle, recommended up to 90 days, unless the parties have agreed a shorter period for High-Risk Data.

For products built on an append-only ledger, receipt or audit-trail model, satisfying "technically possible" under this section requires the Processor to maintain a dedicated deletion mechanism capable of removing or irreversibly redacting all Controller Data held in ledger entries, audit logs, watch and signal records, proposals, release history and any other organisation-scoped derived records — not only the current, user-facing pages or claims. This mechanism must exist and be tested before such a product processes real Controller Data in production, must complete within the timeframe set out in this section, and must itself generate a dated record confirming completion. The mechanism need not be self-service; execution by authorised Processor personnel through a defined, logged procedure satisfies this section, provided the procedure is documented, has an owner and a committed turnaround time, and is not ad hoc.

Security and audit logs controlled by the Processor are, as a rule, retained for 12 months. The account lifecycle event log may be retained indefinitely only after irreversible anonymisation, in particular after removal of the IP address, user agent, free text and additional metadata; if the remaining account identifier still reasonably allows the event to be linked to an individual, the 12-month rule applies. The foregoing does not change the agreed production-data deletion deadlines or backup cycle.

21. No general monitoring of content

The Processor is not obliged to actively monitor the legality of all data uploaded by the Controller or its users. The Processor may, however, apply security measures, limits, blocks, redaction, automatic flagging or functional restrictions where necessary for security, legal compliance, protection of persons or protection of the service.

22. Liability and relationship with the Main Agreement

The parties' liability for breach of the DPA is specified in the Main Agreement unless mandatory law provides otherwise. The DPA does not limit the parties' liability towards data subjects or supervisory authorities to the extent such liability arises under the GDPR.

23. Precedence of documents

In case of conflict between the DPA and the Main Agreement in the area of personal data processing, the DPA prevails. In case of conflict between the DPA and standard contractual clauses, the standard contractual clauses prevail to the extent required by transfer law.

Appendix 1 - Detailed description of processing

Element	Description
Subject matter	processing of Controller Data within Unabyss.
Purpose	provision, maintenance, security and development of Unabyss features.
Duration	term of the Main Agreement and retention, deletion or legal-obligation period.
Operations	import, synchronisation, storage, analysis, indexing, embeddings, LLM, MCP, chatbot, export, deletion.
Scale	depends on the Controller's configuration; may cover a very broad scope of data and persons.

Appendix 2 - Data categories by sources and integrations

Source / integration	Example data
Gmail / Google Workspace	messages, contacts and metadata only within approved scopes
Google Drive / Docs / Sheets / Slides	files, documents and metadata
Google Calendar	events, participants and metadata
Slack	messages, channels, files and metadata
GitHub / GitLab / Jira / Trello / Linear / Asana	code, issues, PRs, tasks, comments and project data
HubSpot / Pipedrive / Google Ads	contacts, leads, transactions, campaigns and events
Notion / OneNote	notes, attachments and metadata
TLDV / Fireflies / Granola / Fathom	transcripts, participants and summaries
DocuSign / Cloudflare Browser Rendering / public research	signed documents and signatory data, or public websites and research results—depending on the feature
User files and AI import	any content uploaded by the user, including potentially High-Risk Data.

Appendix 3 - Technical and organisational measures (TOMs)

Area	Minimum measures
Access management	RBAC, least privilege, admin MFA, quarterly reviews, named accounts, offboarding.
Encryption and secrets	TLS, storage encryption where available, secret manager, no logging of tokens and keys, secret rotation.
Environments and SDLC	prod/dev/test separation, code review, dependency scan, vulnerability monitoring, rollback plan.
Logging and monitoring	admin audit log, payload limitation, data masking, log retention, alerting.
LLM and AI	approved providers, no-training, prompt minimisation, no private accounts, limited retention.
MCP and sharing	granular permissions, confirmation screen, audit log, revoke access, High-Risk Data restrictions.
Backup and continuity	backups, restore tests, retention cycle, backup deletion procedures.
Personnel	authorisations, confidentiality, training, limited support access, production access register.
Vendors	due diligence, DPA, transfer mechanism, no-training, review at least annually.

Appendix 4 - Subprocessors and transfers

Category	Examples / requirements
Hosting / infrastructure	DPA, regions, encryption, backup, SLA, security documentation.
LLM / AI	DPA, no-training, limited retention, an appropriate transfer mechanism (SCCs or an adequacy decision/DPF only where applicable), deletion capability, vendor assessment.
Error monitoring	payload minimisation, no full prompts, DPA, retention.
Payments	payment provider role and data scope; card tokenisation by the provider.
Email / communication	DPA, retention, content limitation.
Platform integrations	OAuth scopes, API terms, vendor DPA, terms restrictions.

Appendix 5 - Additional rules for High-Risk Data

Control	Requirement
Legal basis gate	Controller confirms legal basis and Articles 9/10 GDPR where applicable.
DPIA gate	Controller conducts a DPIA where required; Processor provides technical information.
LLM restriction	no sending to LLM without approved provider, no-training and limited retention.
MCP restriction	confirmation screen, granular permissions, audit log and default block of public sharing.
Support restriction	access only with justification, logged, time-limited, synthetic data preferred.
Retention restriction	shorter retention, deletion of source data, embeddings, cache and backups according to arrangements.
Security review	configuration review before production import of High-Risk Data.

Appendix 6 - Retention, export and deletion

Category	Deletion / export
Production data	within 30 days from request or termination unless another deadline follows from the agreement or law.
Embeddings / indexes	deletion or reconstruction after deletion of source data.
Cache	deletion in the shortest technically feasible cycle.
Backup	deletion in the backup cycle, recommended up to 90 days; shorter for High-Risk Data if agreed and technically possible.
OAuth tokens	revocation after integration disconnection or account deletion.
Security logs	retention 12 months; longer only for a specific incident, dispute, legal obligation or legal hold.
Ledger, audit trail and other append-only derived records (for any Unabyss feature using this data model)	Deletion or irreversible redaction across all organisation-scoped records — ledger/claim history, audit log, watches, signals, proposals, release history, patrol runs, consumption logs — not only current pages or claims; within the same 30-day timeframe as production data; executed via a defined, tested and logged deletion procedure with a named owner, not ad hoc action. This capability must exist prior to production go-live for any product using an append-only or immutable-history data model.