DPA – contractual framework and product information

A binding agreement is required before processing on behalf of a controller

Article 28 GDPR requires a contract or other legal act binding qasb to the controller and specifying the subject matter, duration, nature, purpose, data types, data subjects, and rights and obligations. A DPA becomes part of the contract only if it is expressly incorporated, with an unambiguous version reference, into an offer, order form or enterprise agreement and validly accepted by both parties.

Before qasb processes personal data on behalf of a controller, the applicable subprocessor list, data regions, third-country transfer mechanisms, erasure and backup periods, and the agreed technical and organizational measures must be documented and assigned to the agreement as annexes. If this information or a valid agreement is missing, qasb must not carry out the relevant processing on behalf of the controller.

A version intended for signature or electronic acceptance can be requested via support@qasb.ai. That version must be reviewed by qualified legal counsel or a data protection professional before use.

Contracting parties and roles

Processor under the agreed DPA: Anel Alicic, trading as qasb, Neue Mainzer Straße 84, 60311 Frankfurt am Main, Germany, email: support@qasb.ai.

Customer: the legal or natural person unambiguously identified in the accepted offer, order form or enterprise agreement.

The customer is the controller insofar as it determines the purposes and means of processing. qasb is a processor only insofar as it processes customer content solely on documented instructions. qasb may act as an independent controller for its own purposes, such as contract administration, billing, product security, prevention of misuse, defense of legal claims and statutory retention. The roles must be documented separately for each data flow.

Subject matter, duration and documented instructions

The subject matter may be the technical provision of expressly commissioned qasb functions, in particular workspace, chat, evidence review using already qualified qasb sources, task-based analysis, file processing, artifacts, storage, export and support. The main agreement or an annex must conclusively identify which functions, regions and data types are actually covered.

Processing generally lasts as long as the main agreement and ends after the return or erasure of data processed on behalf of the customer, unless there is a statutory retention obligation. Specific periods for active systems, queues, logs and backups must be recorded in the accepted contractual annex.

Only the accepted main agreement, the product configuration specified in it, and additional documented instructions from authorized contacts count as instructions. If qasb considers an instruction to violate data protection law, qasb will inform the customer and suspend execution pending clarification, unless a mandatory legal rule prevents this.

Employee data and excluded purposes

The standard purpose of qasb's organizational processing, including the role overview, covers only roles, tasks, skills and aggregated organizational structures. It does not cover personal applicant or employee profiles, ranking, performance or behavioural monitoring, promotion or dismissal recommendations, or the allocation of tasks to individuals based on individual characteristics.

Names, personnel numbers, CVs, and performance, health or disciplinary data must not be transmitted for these excluded purposes. An extension would not merely be an instruction within the existing service scope, but a material change of purpose. It requires a new prior assessment of legal basis, data protection impact, employee participation, security and the AI Act, as well as express contractual agreement and appropriate technical design.

Further limits are set out in the privacy policy, under AI transparency and in the acceptable use policy.

Minimum obligations of the processor

The binding agreement must require qasb in particular to:

• process personal data only on documented instructions, including instructions concerning third-country transfers;
• bind authorized persons to confidentiality and restrict access by role;
• implement demonstrably appropriate technical and organizational measures under Article 32 GDPR and review them regularly;
• assist the customer with data subject rights, security, personal data breaches, data protection impact assessments and any required prior consultation;
• return or erase data at the customer's choice after the processing assignment ends, unless there is a statutory retention obligation;
• provide necessary evidence and permit appropriate audits.

Customer obligations

The customer remains responsible for lawfulness, transparency, data quality, legal bases, data subject rights, erasure periods and the permissibility of its instructions. It must designate contacts and persons authorized to issue instructions, configure roles and access on a need-to-know basis, and transmit only data necessary for the agreed purpose.

Special categories of personal data, criminal offense data, professional secrets, or personal employee and applicant data are not covered by the contract merely because a technical upload field exists. They may be processed only if the data type and purpose are expressly specified in the contract, intended for the subscribed service and safeguarded by a documented risk assessment.

Potential services and contractual classification

Article 28(2) GDPR requires prior specific or general written authorization for subprocessors. The following table identifies services that may be used depending on the subscribed service. The providers actually used are determined solely by the customer-specific DPA and its applicable subprocessor information. This table alone is not a sufficient basis for general authorization.

A binding agreement must include a current agreed list, a change and objection procedure, and the imposition of equivalent data protection obligations on each subprocessor. Stripe may be an independent controller for its own payment and compliance purposes; the specific role must be determined based on the Stripe service selected.

Within the processing framework described here, Perplexity receives no account, file, workspace or billing data, no data from the role overview and not the wording of chat content or cases. qasb may use the Perplexity search API to find public original sources for research or case monitoring. In doing so, Perplexity receives search queries made up of fixed search terms and, where applicable, a public subject such as an occupation title, which qasb derives from a question or from the titles of the sources behind selected claims of a case. Search queries formulated by the customer itself are not sent to Perplexity. A separate service for obtaining public sources may search only public, non-personal sources. Results may be incorporated into customer results only after a separate review of the source, rights, attribution and substantive validity. Extending this data flow would be a material change and requires a new legal, privacy, security and contractual review in advance.

Third-country transfers

Processing outside the EU or EEA may take place only if the conditions in Articles 44 et seq. GDPR are met. For each data flow, the recipient, country, onward transfers and mechanism actually used must be documented. Possible mechanisms include, in particular, an applicable adequacy decision or EU standard contractual clauses with the necessary supplementary measures.

The mere possibility of using standard contractual clauses or the EU-US Data Privacy Framework does not establish a lawful transfer. Certification, contractual module, annexes and transfer impact assessment must fit the specific recipient and data flow.

Data subject rights, incidents and audits

qasb must generally forward requests concerning data processed on behalf of the customer to that customer and assist it with the functions and information available. Confirmed personal data breaches concerning such data must be reported without undue delay with the available information on their nature, extent, consequences and remedial measures.

Evidence may initially be provided through current security and privacy documentation. If that is insufficient, the agreement must allow appropriate audits by the customer or an independent auditor without compromising security, confidentiality or other customers' rights. Rules on costs, deadlines and confidentiality must not exclude mandatory rights under Article 28 GDPR.

Return, erasure and backups

After the processing assignment ends, qasb must return data processed on the customer's behalf in an agreed commonly used format or erase them, according to the customer's documented choice, unless there is a statutory retention obligation. Data in backups must remain blocked until regular, evidenced overwriting and must not be restored for normal product purposes.

Active data, queues, temporary extracts, logs, provider copies and backups each require verifiable erasure periods. A blanket statement about the 'regular backup cycle' is insufficient without documented rotation and recovery rules.

Annex 1 – processing description to be completed

The binding agreement must include at least the specifically subscribed functions, processing purposes and operations, term, data categories, categories of data subjects, frequency, storage locations, erasure periods and instruction channels.

The general product scope may include identity and contact data, account and permission data, technical usage and security data, communication content, occupational and organizational information, document and file content, and results generated from them. Which of these categories are actually permitted must be determined for each customer.

Applicant or employee profiles for individual assessment, special categories of data and criminal offense data are not part of the standard scope.

Annex 2 – technical and organizational measures

Depending on the risk, the binding contractual annex must specifically describe the following categories in particular:

• individual accounts, secure authentication and controlled privileged access,
• tenant and permission separation, including server-side authorization and Row Level Security,
• encryption in transit and evidenced encryption of stored data,
• logging of security-relevant and administrative operations with limited retention periods,
• rate limits, input validation, upload controls and separate public and privileged endpoints,
• backup, recovery, availability and erasure procedures with regular testing,
• incident management, vulnerability handling and contractually governed notification,
• data minimization, restrictive disclosure and reassessment when models, providers or purposes change.

Only the measures contractually documented for the respective service are warranted. Their configuration and effectiveness must be appropriately evidenced and auditable. This general product information is not an unrestricted certification of technical and organizational measures.