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 Kasp 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 Kasp 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 organisational measures must be documented and assigned to the agreement as annexes. If this information or a valid agreement is missing, Kasp must not carry out the relevant processing on behalf of the controller.

A version intended for signature or electronic acceptance can be requested via kontakt@kasp.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 KASP, Brigitte-Frauendorfstr. 6, 60486 Frankfurt am Main, Germany, email: kontakt@kasp.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. Kasp is a processor only insofar as it processes customer content solely on documented instructions. Kasp may act as an independent controller for its own purposes, such as contract administration, billing, product security, prevention of misuse, defence 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 Kasp functions, in particular workspace, chat, evidence review using already qualified Kasp 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 authorised contacts count as instructions. If Kasp considers an instruction to violate data protection law, Kasp 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 Kasp's organisational processing, including Orbit, covers only roles, tasks, skills and aggregated organisational 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 Kasp in particular to:

• process personal data only on documented instructions, including instructions concerning third-country transfers;
• bind authorised persons to confidentiality and restrict access by role;
• implement demonstrably appropriate technical and organisational 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 authorised 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 offence 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 authorisation 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 authorisation.

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.

Perplexity is not a recipient of customer, account, chat, file, workspace, Orbit or billing data within the processing framework described here. Where Kasp uses a separate service to obtain public sources, that service may search only public, non-personal sources. Its 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

Kasp 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, Kasp 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 organisational 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 offence data are not part of the standard scope.

Annex 2 – technical and organisational 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 authorisation 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 minimisation, 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 organisational measures.