Data Processing Agreement (DPA) pursuant to Art. 28 GDPR
Discontinue · AI operations platform for hotels
Last updated: 12 September 2026 · Version 3.12 (production version)
This Data Processing Agreement (“DPA”) is a binding annex to the usage/activation agreement and to the General Terms and Conditions. It replaces the earlier combined pilot version (DPA + NDA + pilot service description). Annexes: Annex 1 – Sub-Processor List, Annex 2 – Technical and Organisational Measures (TOMs). Transfer Impact Assessments (TIAs) for third-country transfers are not contract annexes; they are maintained as accountability documents and made available to the Controller on request (Section 8(4)). Which third-country transfers exist and on what basis they take place is set out in Annex 1.
Contracting Parties
| Party | Details |
|---|---|
| Controller | The customer (hotel operator), hereinafter the “Controller” |
| Processor | discontinue.dev MAS GmbH, Bruno-Marek-Allee 5, 1020 Vienna, Austria, represented by its management, hereinafter the “Processor” |
| Data protection contact | [email protected] |
Section 1 Subject Matter and Duration of Processing
(1) The Processor operates an AI-supported operations platform for hotels that builds on the source systems connected by the customer (e.g. a property management system). The Controller uses the platform to independently configure and operate reports and agents on its data from the connected systems. Access to the customer-connected source system and other integrations takes place exclusively on the basis of the connection established by the Controller itself (OAuth authorisation); the Controller may revoke this connection at any time.
(2) The processing takes place for the duration of the usage agreement. Following its termination, the personal data will be deleted or returned in accordance with Section 10.
Section 2 Nature and Purpose of Processing
(1) The processing comprises:
- Retrieving hotel data via the interface of the connected system (reservations, master data, folios, invoices, reports, maintenance) in read-only mode
- Storing and analysing this data to produce reports and operational dashboards
- Processing by AI models for the structuring, summarisation and formulation of reports and notices; AI processing takes place in the builder (creating and editing reports and agents), during agent runs, in chat and during validations (paragraph 3)
- Automated delivery of reports and notifications via the channels specified by the Controller (email, customer-connected chat/messaging services, file download)
- Execution of agents (monitoring, alerting, preparation of actions) as configured by the Controller
- Preparation and execution of write operations against the connected systems (e.g. notes, folio adjustments, reservation updates, maintenance tickets); by default following individual approval by an authorised, individually identified employee of the Controller via the approval queue. A waiver of individual approval is only possible by the Controller’s explicit per-agent opt-in; without opt-in, no write operation is autonomous
(2) Processing for other purposes – in particular for marketing, for training AI models or for benchmarking between hotels – does not take place. This also applies to run traces: the Processor processes them exclusively to perform the assignment, to demonstrate compliance to the Controller and for the security of processing pursuant to Art. 32 GDPR, and not to improve the Platform, the models used or any other purposes of the Processor outside the respective tenant.
(3) Data flow and use of AI. AI processing takes place in the builder, during agent runs, in chat and during validations. A scheduled report run executes the plan defined in the builder deterministically; no AI processing and no transfer to the AI provider takes place in that step.
| Function | AI processing | Transfer to the AI provider | Logging |
|---|---|---|---|
| Builder (creating/editing reports and agents) | yes | yes | AI run trace |
| Scheduled report run and delivery | no (deterministic execution of the plan defined in the builder) | no | deterministic run record |
| Agent run | yes | yes | AI run trace |
| Chat | yes | yes | AI run trace |
| Validation / agent self-check | yes | yes | AI run trace |
(4) Cross-run reuse for agents. An AI run trace is created for every agent run. For agents, the results of previous runs are drawn on again in subsequent runs — via the run trace and, where the applicable processing route uses an agent environment managed by the AI provider, via the session history kept there for each agent — in order to validate and improve execution; in doing so, this content is again processed with AI support and, to that extent, transferred to or processed at the AI provider of the applicable processing route. The reuse is an essential functional characteristic of the agent function and is not separable from it; it serves to validate, to self-correct after failed runs and to continuously maintain the Controller's respective agent. The Controller determines it by creating and activating an agent; reports are available to it without this processing, since their scheduled runs trigger neither AI processing nor reuse.
Reuse takes place exclusively within the same tenant and the same agent; no cross-tenant analysis takes place. As regards retention: the Processor's own run traces are retained for 90 days; the session history and any task resources in an agent environment managed by the AI provider exist for the operating life of the agent (Section 6(1)). The Controller may deactivate or delete an agent at any time. Where the Controller deactivates an agent, no further runs and therefore no further reuse take place; the run traces already in existence are deleted upon expiry of their retention period, while the session history at the AI provider remains in place until the agent is deleted. Where the Controller deletes the agent, that agent's run traces as well as the associated session history and task resources at the AI provider are deleted; backup copies are overwritten upon expiry of the backup cycle (at most twelve months).
Section 3 Categories of Personal Data
| Category | Data fields |
|---|---|
| Guest master data | Salutation, first and last name |
| Guest contact data | Email address, to the extent stored in the source system |
| Reservation data | Check-in/check-out, room/unit number, booking status, booking number |
| Stay data | Length of stay, rate, revenue data, special requests/notes |
| Folio/invoice data | Folio line items, refunds, city tax reports, invoices (recipient, address, line items, amounts) |
| Approval and execution data | Time, approving person (name/identifier of the platform user), decision and outcome of write operations approved or executed autonomously under opt-in |
| Recipient data of deliveries | Recipient address or channel identifier, content delivered, time and delivery status |
| AI run traces and deterministic run records (including the processed content) | The inputs, outputs, tool calls, delivery and status information and technical metadata required for execution, traceability, error analysis and security – including the content processed in the process from the categories listed above |
| Session histories and task resources in the agent environment managed by the AI provider (processing route via the AI provider only) | The session history (event history of the agent runs) kept for each agent as well as any task resources (e.g. working files, memory stores) – including the content processed in the process from the categories listed above (Section 6(1)) |
Account, usage and billing data of the platform users are not subject to this DPA; in this respect, Discontinue is an independent controller (cf. Privacy Policy Part B). Excluded from this clarification is approval and execution data: it arises in the execution of the assignment and is, to that extent, processed as customer data, including where it names the approving platform user.
Special categories of personal data (Art. 9 GDPR) are not an intended subject of the processing. Free-text fields (e.g. special requests/notes) may, however, incidentally contain such information in individual cases. The controller ensures an appropriate legal basis (Art. 9(2) GDPR) for such content, keeps it to a minimum and works towards ensuring that special categories are not included in free-text fields unless they are required for the purpose; Discontinue processes incidentally contained information exclusively like all other customer data and does not separately analyse it.
Section 4 Categories of Data Subjects
- Hotel guests and bookers
- Hotel employees (in their role as platform users)
- other natural persons designated by the Controller as recipients of deliveries (the selection of recipients and the purpose of the delivery rest with the Controller)
Section 5 Obligations of the Processor
- The Processor processes personal data exclusively on the documented instructions of the Controller. The documented instruction arises from this Agreement and from the Controller’s use of the platform (configuration of reports, agents, triggers and delivery channels). If the Processor considers an instruction to be unlawful, it informs the Controller. Where the Processor is required to carry out a processing operation by Union or Member State law, it informs the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.
- The Processor ensures that the persons authorised to process the data are committed to confidentiality or are subject to an appropriate statutory duty of confidentiality.
- The Processor implements the technical and organisational measures set out in Section 7 and in Annex 2.
- The Processor uses the sub-processors named in Annex 1 (Sub-Processor List). Changes are notified to the Controller at least 14 days before they take effect; the Controller may object on reasoned grounds within this period.
- The Processor supports the Controller in fulfilling its obligations pursuant to Art. 32–36 GDPR (security of processing, data protection impact assessment, notification obligations).
- The Processor informs the Controller without undue delay after becoming aware of a breach of the protection of personal data (Art. 33(2) GDPR). Where not all required particulars are available at that time, an initial notification is given first; further information is supplied without unreasonable delay. The documented process arises from the Data Breach Process document.
- The Processor supports the Controller in responding to requests from data subjects (Art. 12 et seq. GDPR) to the extent necessary.
- Technical execution within the assignment. Within the framework configured by the Controller (reports, agents, released tools and scopes, triggers, delivery channels and recipients), the Processor selects the technical execution independently — in particular the field selection and data minimisation applied per request — which operate exclusively in a reducing manner within the data categories and scopes released by the Controller —, the model routing between the recipients approved under Section 8 and the internal orchestration. These decisions are non-essential means within the meaning of Art. 28 GDPR; they may not extend the purpose, scope or set of recipients determined by the Controller. Which tools and operations are available to an agent is determined by the Controller (GTC Section 4(4)). Instructions outside the platform configuration are issued by the Controller in text form to [email protected].
Section 6 No-Training Guarantee and Limited Retention Period for AI Models
(1) To provide the AI functions, the Processor uses one or more AI providers. Which these are is set out in Annex 1 (Sub-Processor List); that annex governs in this respect. An AI provider is used only after it has undertaken — contractually or through documented provider commitments (published provider documentation or product-side configuration forming part of the documented instructions) — the no-training guarantee and a limited retention period, or the ability for the Processor to delete the stored content at any time, or equivalent safeguards and — where processing takes place in a third country — a valid transfer basis pursuant to Art. 44 et seq. GDPR is in place (Section 8(3)); the procedure is governed by Section 8(2). Every AI provider used has guaranteed — contractually or through documented provider commitments (published provider documentation or product-side configuration forming part of the documented instructions) — that
- data processed via the API is not used to train the models (no-training guarantee),
- transmitted content is stored only for a limited period and is automatically deleted thereafter (limited retention period) or can be deleted by the Processor at any time (deletability).
The retention period is as follows in detail: for the stateless AI functions (builder, chat, validations), storage at the AI provider is generally limited to a maximum of 30 days (solely for abuse detection), followed by automatic deletion. The terms of individual AI providers provide for exceptions to this — for instance longer retention of content flagged by their automated abuse-detection systems. Where a processing route uses an agent environment managed by the AI provider, the session history (event history) and any task resources of each agent are additionally stored there; according to the provider's documentation they are exempt from the standard retention period, exist for the operating life of the agent and are deleted by the Processor when the Controller deletes the agent, at the latest in accordance with Section 10. The periods and exceptions applicable to each provider, and whether a special agreement on deviating retention periods (zero data retention) exists, are set out in Annex 1; Annex 1 governs in this respect. Statutory retention obligations and retention for dispute resolution remain unaffected. The retention of flagged content serves to detect and prevent abusive use of the AI provider’s services and thus the security of processing (Art. 32 GDPR) and the defence of legal claims. It takes place within the processing on behalf; the AI provider does not thereby become an independent controller. The Processor cannot determine the duration of this retention and draws the Controller’s attention to this; where the Controller considers the retention to be incompatible with its obligations, it may terminate extraordinarily under Section 8(2).
(2) Upon any change of, or addition of a further, AI model provider, the no-training guarantee and the limitation of the retention period or deletability — contractual or under documented provider commitments — are reviewed and documented before the provider is taken into production use. The new provider is also added to the Sub-Processor List and announced to the Controller in accordance with Section 5 No. 4.
(3) The change, addition or replacement of AI models, AI providers or the underlying agentic/orchestration framework — including switching to self-/locally hosted models or other API providers — is an ordinary operational measure covered by the general authorisation under Section 8, provided the data-protection level (no-training, limited retention or equivalent safeguards and — where processing takes place in a third country — a valid transfer basis under Art. 44 et seq. GDPR pursuant to Section 8(3)) is maintained. The controller’s right to object on legitimate data-protection grounds remains unaffected; commercial consequences are governed solely by the Subscription Agreement and the GTC.
Section 7 Technical and Organisational Measures (TOMs)
The Processor implements appropriate technical and organisational measures pursuant to Art. 32 GDPR. The complete catalogue of measures is Annex 2 (TOMs). Core measures:
| Measure | Implementation |
|---|---|
| Encryption at rest | AES-256-GCM for sensitive data (OAuth tokens, API credentials); encrypted storage media |
| Encryption in transit | TLS 1.2+/1.3 for all connections (platform, interface of the connected system, AI API, sub-processor APIs) with verification of server certificates |
| Access control (platform users) | Role-based access control (RBAC) at workspace/tenant level |
| Multi-tenant isolation | Tenant-ID-based data separation in all queries and at the API level; no cross-tenant access and no cross-tenant data flow to the AI provider |
| Data minimisation in AI processing | Multi-layered, cumulative protection system: scope minimisation (only the scopes released in the source system), granular and configurable tools with a per-agent allowlist and tool/scope minimisation per task and tenant/integration scoping – instead of classic pseudonymisation |
| Backup | Daily backups, OCI Object Storage, Frankfurt (DE) |
| Data residency | Hosting of the platform and database: Oracle Cloud Infrastructure, Frankfurt (EU); session histories of an agent environment managed by the AI provider at the respective AI provider in accordance with Annex 1 |
| Password security | Hashing with bcrypt/Argon2; no plaintext storage |
| Audit trail of the runs | AI runs (builder, agent run, chat, validation): complete AI run trace (trigger, system prompt snapshot, tool calls with parameters/result, model used, consumption in euros, deliveries, errors). Scheduled report runs without AI involvement: deterministic run record (trigger, status and times, rendered result, data coverage, deliveries, errors) — without a system prompt and without a model reference, because no model is involved. Both as the Processor's own record in the tracing environment operated by discontinue.dev itself; independently of this, on the processing route via the AI provider the AI provider keeps the session history for each agent in its managed agent environment (Annex 1, Section 6(1)). Authorised users of the Controller can review the run history of agent runs in the Platform |
| Human-in-the-loop approval | Write operations against the connected systems by default pass through proposal → approval queue → approval by an authorised user → execution (complete logging); only with explicit per-agent opt-in without individual approval – without opt-in, no write operation is autonomous |
| Prompt injection protection | System instructions and external customer content are technically separated; content from connected systems is treated as untrusted input. Appropriate measures limit the risk that such content alters system instructions or triggers unauthorised tool calls |
| Incident response | Documented process: detection → assessment → notification → remediation → lessons learned |
Note on pseudonymisation: In operational use, the Processor deliberately refrains from fully pseudonymising the guest data transmitted to the AI model, because operational hotel workflows (e.g. “today’s VIP arrivals”) lose their function if the guest name is replaced by an anonymous identifier. Data minimisation is achieved through the multi-layered protection system described above as well as through the no-training guarantee and limited retention period or deletability assured in Section 6.
Details of the backup concept, restoration and testing intervals are set out in Annex 2 (TOMs).
Section 8 Sub-Processors
(1) The Controller grants a general authorisation for the use of sub-processors. The complete list is Annex 1 (Sub-Processor List).
(1a) Conditionally engaged sub-processors (AI processing routes). Annex 1 may designate sub-processors as conditionally engaged: such a sub-processor is engaged only where the Controller selects the relevant AI processing route (agent stack; GTC Section 2 and Section 4(10)) for the use in question. The selection constitutes a documented instruction within the meaning of Section 5 no. 1; its exercise or change by the Controller itself does not constitute a change within the meaning of paragraph 2. The AI processing routes designated in Annex 1 are alternatives; in no individual AI run are the sub-processors of both routes engaged at the same time. A change of model or model version within a provider designated in Annex 1 does not constitute a change within the meaning of paragraph 2, provided that no additional legal entity thereby receives personal data.
(2) The Processor informs the Controller of any change (addition, replacement, removal) at least 14 days in advance by email. The Controller may object for important data protection reasons within this period; the objection must be made in text form and substantiated with specific reasons within that period. The notice under sentence 1 contains the information required for that assessment. An important data protection reason exists where the change, having regard to the specific processing, the categories of data concerned, the places of processing, the transfer basis, the technical and organisational measures or the further sub-processing chain, gives rise to concrete doubts as to compliance with the General Data Protection Regulation; whether the level of protection is maintained is assessed on the facts of the individual case. An important data protection reason does not exist in the case of a mere preference for a different provider, general reservations unrelated to the specific processing, or purely commercial considerations. No right of objection arises where the change does not result in an additional legal entity processing personal data; this is the case in particular where a model is changed within a provider already listed, where the Controller selects a model level (GTC Section 4(10)), and where a component is operated within the environment controlled by discontinue.dev at a hosting sub-processor already listed. Upon a valid objection the parties endeavour to find an amicable solution; if none is reached, the Controller may terminate the contract extraordinarily with effect from the date the change takes effect; any unused credit is refunded. The Sub-Processor List names the sub-processors engaged directly by the Processor, with their identity, location, processing purpose and transfer basis. For the further sub-processors engaged in turn by those sub-processors, the Sub-Processor List identifies the authoritative and continuously updated source — the list published by the respective sub-processor or, where no such list is published, the list agreed contractually; the Processor makes the information required for that purpose available to the Controller on request (Art. 28(3)(h) GDPR), and passes on to the Controller, without undue delay, any changes in that chain notified to it, so that the Controller can exercise its right to object under sentence 2. The information on the entire chain is thereby available to the Controller at all times; the form and manner of provision are hereby specified contractually within the meaning of Opinion 22/2024 of the European Data Protection Board.
(3) Where sub-processors are used in third countries (outside the EU/EEA), the Processor ensures, before use, a valid basis pursuant to Art. 44 et seq. GDPR — in particular an adequacy decision under Art. 45 GDPR or appropriate safeguards under Art. 46 GDPR (such as EU Standard Contractual Clauses pursuant to Art. 46(2)(c) GDPR). A Transfer Impact Assessment is carried out to the extent required by the transfer basis chosen and the circumstances of the transfer. Where a transfer relies on an adequacy decision, the Processor verifies and documents before use that the decision covers the specific recipient and the specific transfer, and monitors its continued existence. Where an adequacy decision ceases to apply, is suspended, restricted or declared invalid, the Processor suspends the affected transfer or promptly moves it to another valid basis under Art. 44 et seq. GDPR, and informs the Controller thereof without undue delay. The same applies mutatis mutandis where appropriate safeguards under Art. 46 GDPR cease to be effective.
(4) The specific third-country transfers, the respective recipient, the transfer basis and the existence of a Transfer Impact Assessment are set out in Annex 1. Where a Transfer Impact Assessment is maintained for a transfer, it is made available to the Controller on request ([email protected]).
(5) The Processor imposes on every sub-processor the same data protection obligations as are set out in this Agreement, and remains liable to the Controller for the sub-processor’s compliance with those obligations.
Clarification on product analytics (Google): Insofar as the Processor uses Google Analytics 4 to analyse the use of its own platform, it acts in this respect as an independent controller (not as a processor of the hotel). In doing so, Google processes no guest data or data from the connected systems. Google is therefore not a sub-processor under this DPA; this processing is governed by the Processor’s Privacy Policy.
Section 9 Rights of Data Subjects
(1) The Processor supports the Controller with appropriate technical and organisational means in fulfilling the rights of data subjects pursuant to Art. 15–22 GDPR (access, rectification, erasure, restriction, data portability, objection). The process is described in the Data Subject Rights Process document.
(2) Requests from data subjects received directly by the Processor are forwarded to the Controller without undue delay; no direct response is provided.
(3) In the standard configuration, no automated individual decision within the meaning of Art. 22 GDPR takes place: write operations pass through human approval. Where the customer expressly activates opt-in operation for an agent, it is responsible as controller for assessing whether that agent's outputs constitute a decision with legal or similarly significant effect and for meeting the requirements of Art. 22 GDPR. In that case, the Processor supports it in fulfilling its obligations under Art. 22 GDPR by providing, on request, the configuration of the agent concerned, the relevant inputs and the course of the specific run, and by enabling the opt-in to be deactivated without undue delay.
Section 10 Deletion and Return of Data
(1) Upon termination of the usage agreement, the Processor will
- at the Controller’s request, return all personal data in a common format (via the export functions of the Platform; on request as a structured file pursuant to GTC Section 14a(3)). This also covers the personal content contained in the run records (AI run traces and deterministic run records); the exception under GTC Section 14a(3)(e) concerns exclusively the provider-side components of the traces (Discontinue's system prompts, tool definitions and schemas, internal orchestration and routing logic) and leaves both the obligation under this number and the rights of data subjects under Art. 15 et seq. GDPR unaffected;
- delete all personal data after expiry of the retrieval period pursuant to GTC Section 14a(4), at the latest within 60 days after the end of the contract in the production systems, unless a statutory retention obligation exists; this includes the deletion of the session histories and task resources kept in an agent environment managed by the AI provider via the deletion functions provided for this purpose — sessions and independently kept task resources are each deleted separately, because deleting a session does not automatically cover independent resources; paragraph 3 applies to backup copies;
- confirm the deletion to the Controller in text form upon request.
(2) During the ongoing contract, the following periods apply. Run data is deleted automatically after 90 days; this covers the report artefacts, the rendered results of the runs, the AI run traces including the tool calls and results they contain, the deterministic run records, the delivery logs and the approval decisions of the approval queue. Operating logs of the connectors are deleted after 30 days. The log of granted access authorisations and connections — the record of who granted or withdrew which access and when — is retained for 12 months. Invoice data is subject to the statutory retention obligation (7 years pursuant to Section 132 BAO – Austria).
(3) Deletion covers all existing copies including backup copies. Deletion in the production systems takes place without undue delay; backup copies are overwritten upon expiry of the respective backup cycle, and no later than after twelve months. That period is a deliberate choice: it preserves recoverability even where an erroneous deletion or an attack is detected late. Until the cycle expires, deleted data may persist in the backup copies; they are accessed solely in a restoration scenario. Where a backup copy is restored, deletions and restrictions of processing effected in the meantime are applied again before productive operation resumes. Complete erasure including the backup copies is thus completed at the latest twelve months after the deletion in the production systems; that later point in time is the expressly agreed period for complete erasure within the meaning of Art. 25(2)(h) of Regulation (EU) 2023/2854. The Processor arranges for corresponding deletion at all sub-processors and confirms it in text form upon request. The only data exempt from the deletion obligation is that which must be retained under mandatory Union or Member State law (Art. 28(3)(g) GDPR). Where the Processor is in fact unable to enforce deletion at a sub-processor — at the AI provider where content has been flagged by its abuse detection (Section 6(1)) —, it identifies this in the deletion confirmation and names the data concerned. The Controller is informed of this before the conclusion of the contract (Section 6(1)).
(4) Because AI run traces and deterministic run records may contain the processed content, personal data contained in them continues to exist until the end of the retention period, even if it has already been deleted in the source system. Erasure requests concerning run records are handled in accordance with the data subject rights process.
Section 11 Audit and Inspection Rights
The Controller has the right to verify compliance with this Agreement pursuant to Art. 28(3)(h) GDPR. Verification is carried out primarily by:
- requesting and reviewing current certifications, audit reports, the TOMs and written information;
- only where the foregoing evidence is insufficient: an on-site inspection at most once per calendar year (and on a case-by-case basis after a demonstrated incident), with reasonable prior notice of at least 30 days, during normal business hours, without disproportionate disruption to operations and while safeguarding confidentiality and the rights of other tenants;
- engaging an independent third party bound to confidentiality that is not a competitor of the Processor.
The Controller bears the reasonable costs incurred by the Processor as a result of on-site inspections.
Upon substantiated request, the Processor shall also disclose to the Controller, or to a third party engaged by the Controller and bound to confidentiality, the architectural information required to assess the processing — in particular the version of the system prompt used, the model used, the field selection applied per request and the extent of trace reuse for the agent concerned. Trade secrets of the Processor are protected in accordance with Section 15a of the GTC; they do not justify withholding the information required under Art. 28(3)(h) GDPR.
The restrictions on frequency and prior notice do not apply where a supervisory authority so orders, in the event of a personal data breach, or where concrete, documented facts suggest a material breach of this agreement which cannot adequately be clarified by written evidence. Even in those cases, the inspection is limited to the necessary and proportionate scope and is carried out with such prior notice as the circumstances allow. The Controller bears the costs of its auditors and its own additional expense; where a material breach by the Processor is established, the Processor bears the costs reasonably caused by the special audit. Inspections by a supervisory authority remain unrestricted.
Section 12 Liability
Liability is governed by the provisions of the GDPR (in particular Art. 82) as well as by the usage agreement and the General Terms and Conditions between the parties.
Section 13 Term and Termination
This Agreement is linked to the usage agreement and ends automatically upon its termination. Separate termination of this Agreement is not possible as long as the usage agreement remains in force.
Section 14 Final Provisions
(1) Austrian law applies. The place of jurisdiction is the registered office of the Processor in Vienna. Mandatory provisions of Union law (in particular the GDPR) remain unaffected.
(2) Amendments and supplements must be made in text form (including electronic form).
(3) In the event of conflicts between this DPA and other agreements, the provisions of this DPA take precedence in data protection matters.
(4) Should individual provisions be invalid, the remainder of the Agreement remains effective.
Acceptance
This DPA is accepted by the Controller electronically in the ordering process (GTC Section 5(2)); the form required by Art. 28(9) GDPR (in writing, including in electronic form) is thereby satisfied. The time of acceptance and the version accepted are logged (Annex 2, no. 6). For Enterprise/custom contracts, this DPA may additionally be countersigned in text form.
Annexes: Annex 1 – Sub-Processor List · Annex 2 – Technical and Organisational Measures (TOMs)
discontinue.dev MAS GmbH · [email protected] · Last updated: 12 September 2026