Data Processing Agreement

pursuant to Art. 28 GDPR — version 2.0, effective 29 September 2026

This is a convenience translation and is not binding. The German version of this Agreement is the sole authoritative text and is available at https://app.metisora.com/legal/dpa. In the event of any discrepancy, the German wording governs.

between

the Customer identified in the metisora General Terms and Conditions — the "Controller" —

and

metisora — Julian Miksch
Schlott 24, 86558 Hohenwart, Germany
E-mail: info@metisora.com

— the "Processor" —

This Agreement supplements the metisora General Terms and Conditions (the "Main Agreement") and is concluded in electronic form pursuant to Art. 28(9) GDPR by the Controller's acceptance of the Main Agreement. It takes precedence over the Main Agreement in all matters of data protection.

1. Subject matter, scope and duration

1.1 The Processor processes personal data on behalf of the Controller in order to provide the metisora service as described in the Main Agreement. Annex 1 specifies the subject matter, nature and purpose of the processing, the categories of data subjects and the types of personal data, in accordance with Art. 28(3) GDPR.

1.2 The processing takes place exclusively within the European Union or the European Economic Area, with the exception of the transfers set out in § 7 and Annex 3.

1.3 This Agreement runs for as long as the Processor processes personal data for the Controller under the Main Agreement, and the obligations in §§ 4, 5, 9 and 10 survive its termination for as long as the Processor holds any such data.

2. Rights and obligations of the Controller

2.1 The Controller is responsible for assessing the lawfulness of the processing, for the existence of a legal basis, and for safeguarding the rights of data subjects. Within the contractual relationship, the Controller is the controller within the meaning of Art. 4 no. 7 GDPR.

2.2 The Controller is responsible in particular for:

a. selecting which Salesforce objects and fields are extracted, and for limiting that selection to what is necessary (Art. 5(1)(c) GDPR); b. informing data subjects under Art. 13 and 14 GDPR, including its own employees whose names appear in the analysed data; c. where applicable, obtaining the co-determination of a works council under § 87(1) no. 6 BetrVG before introducing the service, and concluding any required works agreement; d. carrying out a data protection impact assessment where Art. 35 GDPR requires one — which the Controller should assume is likely where the analysis covers employees; e. deciding whether the storage of AI prompt content is switched on or off (§ 3.5).

2.3 The Controller issues instructions in text form or through the configuration functions of the service. Instructions given verbally are to be confirmed in text form without undue delay. The Controller names the following as authorised to issue instructions: the Controller's administrator as designated in the service, and any further person the Controller names in text form.

2.4 The Controller may at any time request information about the processing, and may demand the correction, restriction, deletion or return of the data.

3. Obligations of the Processor

3.1 Processing on instructions only. The Processor processes personal data only on the documented instructions of the Controller, including as regards transfers to a third country, unless required to do so by Union or Member State law to which it is subject; in that case the Processor informs the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest (Art. 28(3)(a) GDPR).

3.2 The Main Agreement, this Agreement and the configuration the Controller makes in the service together constitute the Controller's complete documented instruction. The provision of the contractual service as described is an instruction.

3.3 Notification of unlawful instructions. The Processor informs the Controller without undue delay if, in its opinion, an instruction infringes the GDPR or other data protection provisions of the Union or a Member State (Art. 28(3), 2nd subparagraph GDPR). The Processor may suspend performance of the instruction until it is confirmed or amended.

3.4 No processing for own purposes. The Processor does not process the personal data for any purpose of its own. In particular, the Processor does not use the data to train, fine-tune or improve any machine-learning model, whether its own or a third party's, and has contracted with its AI sub-processor on the same basis. The Processor may create irreversibly anonymised aggregate statistics that permit no identification of the Controller, any data subject or any individual record; such statistics are no longer personal data.

3.5 AI prompt records. By default the Processor stores the prompt content sent to the AI sub-processor and the response received, tenant-scoped, for 30 days, for the sole purpose of diagnosing faults. The Controller may switch this off at any time in the service's settings, whereupon the content is not written at all. The switch operates prospectively; records already written are deleted on expiry of the 30-day window or on request.

3.6 Confidentiality. The Processor ensures that every person authorised to process the personal data has committed to confidentiality or is under an appropriate statutory obligation of confidentiality, and is instructed in the applicable data protection requirements (Art. 28(3)(b), Art. 29, Art. 32(4) GDPR). That commitment survives the end of their engagement.

3.7 Security of processing. The Processor implements the technical and organisational measures set out in Annex 2 (Art. 28(3)(c), Art. 32 GDPR). The measures are subject to technical progress; the Processor may modify them provided the agreed level of protection is not reduced. Material changes are documented and notified to the Controller on request.

3.8 Data protection officer / contact. The Processor's contact point for data protection is info@metisora.com. The Processor is not required to appoint a data protection officer under Art. 37 GDPR or § 38 BDSG and has not appointed one; the assessment is documented and available to the Controller on request.

3.9 Record of processing activities. The Processor maintains a record of the processing activities carried out on behalf of the Controller (Art. 30(2) GDPR) and makes the relevant extract available to the Controller on request.

3.10 No place of processing outside the agreed locations. Processing takes place at the locations stated in Annex 3. Any change requires prior notification under § 6.

4. Assistance to the Controller

4.1 Data subject rights. Taking into account the nature of the processing, the Processor assists the Controller by appropriate technical and organisational measures, in so far as possible, in fulfilling the Controller's obligation to respond to requests for exercising the data subject's rights under Chapter III GDPR (Art. 28(3)(e) GDPR).

4.2 If a data subject contacts the Processor directly with a request concerning personal data processed on the Controller's behalf, the Processor does not respond to it on the merits. It forwards the request to the Controller without undue delay and informs the data subject that it has done so.

4.3 Assistance with Art. 32 to 36 GDPR. The Processor assists the Controller, taking into account the nature of the processing and the information available to it, in ensuring compliance with the obligations on security of processing, personal data breach notification, data protection impact assessment and prior consultation (Art. 28(3)(f) GDPR). For a data protection impact assessment concerning employee data, the Processor provides Annex 1 and Annex 2 of this Agreement and answers the Controller's specific technical questions.

4.4 Remuneration. Assistance under §§ 4.1 and 4.3 is provided free of charge where it concerns the ordinary operation of the service or a matter for which the Processor is responsible. Where assistance requires disproportionate effort and is not attributable to the Processor, the Processor may charge its reasonable expenditure at €150 per hour, having notified the Controller of that in advance.

5. Personal data breaches

5.1 The Processor notifies the Controller without undue delay, and in any event within 24 hours of becoming aware, of any personal data breach affecting personal data processed on the Controller's behalf (Art. 33(2) GDPR).

5.2 The notification describes, as far as known: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Information not available at the time is provided in phases without further undue delay.

5.3 The Processor documents every breach, takes appropriate remedial and mitigating measures without delay, and supports the Controller in its notifications to the supervisory authority (Art. 33 GDPR) and to data subjects (Art. 34 GDPR).

5.4 The Processor does not notify a supervisory authority or data subjects on its own initiative in respect of data processed on the Controller's behalf, unless legally obliged to do so.

5.5 The Processor's breach contact point is info@metisora.com. The Controller's is the Controller's administrator as designated in the service.

6. Sub-processors

6.1 General written authorisation. The Controller grants the Processor general written authorisation to engage sub-processors within the meaning of Art. 28(4) GDPR. The sub-processors engaged at the time of conclusion of this Agreement are listed in Annex 3 and are hereby approved.

6.2 Notification and objection. The Processor informs the Controller in text form of any intended addition or replacement of a sub-processor at least 14 days in advance.

Where the change originates with a sub-processor already engaged — that sub-processor adding or replacing one of its own — the Processor is dependent on the notice it receives itself, which is currently as short as ten days. In that case the Processor informs the Controller without undue delay after becoming aware, and the objection period runs from that notification rather than from the effective date.

The Controller may object within the applicable period on reasonable data protection grounds, stating them. If the Controller objects, the parties will seek a solution in good faith. If no solution is found within a further 30 days, the Controller may terminate the Main Agreement for cause with effect from the date the change takes effect, without a termination fee; fees paid for the period after that date are refunded pro rata.

6.3 Equivalent obligations. The Processor imposes on each sub-processor, by contract, data protection obligations offering the same level of protection as this Agreement, in particular sufficient guarantees of appropriate technical and organisational measures (Art. 28(4) GDPR). Where the sub-processor fails to fulfil its data protection obligations, the Processor remains fully liable to the Controller for its performance.

6.4 Not sub-processing. Ancillary services that do not involve processing personal data on the Controller's behalf — telecommunications, postal services, maintenance of hardware, cleaning, external auditing — are not sub-processing within the meaning of this section. The Processor is nonetheless obliged to make appropriate arrangements to ensure the protection of the personal data in such cases.

6.5 Salesforce is not a sub-processor. The Controller's own Salesforce organisation is the source system. The Processor accesses it on the Controller's authorisation; the Controller's relationship with Salesforce is its own.

7. Transfers to third countries

7.1 The transfers listed in Annex 3 to recipients in a third country take place on the basis of the safeguards stated there — an adequacy decision of the European Commission, or the Standard Contractual Clauses pursuant to Implementing Decision (EU) 2021/914, in the applicable module, supplemented where necessary by additional technical and organisational measures.

7.2 The Processor has carried out an assessment of the legal situation in the recipient country and of the effectiveness of the safeguards (transfer impact assessment), and makes it available to the Controller on request.

7.3 The Processor will not transfer personal data to a further third country without notifying the Controller under § 6.2 and putting an appropriate safeguard in place.

7.4 If a legal basis for a transfer ceases to apply — in particular through the invalidation of an adequacy decision — the Processor will inform the Controller without undue delay and the parties will agree an alternative safeguard or the discontinuation of the transfer without undue delay.

8. Erasure and return

8.1 On termination of the processing, and at the Controller's choice, the Processor deletes or returns all personal data processed on the Controller's behalf and deletes existing copies, unless Union or Member State law requires storage (Art. 28(3)(g) GDPR).

8.2 The Controller must exercise that choice before deletion is triggered. The service allows the Controller's administrator to close the organisation's account, which triggers immediate and irreversible deletion without a prior export. The Processor points this out in the service before the action is confirmed. Where the Controller wishes to receive an export, it must request it before that point; the Processor provides one machine-readable export free of charge.

8.3 Where no earlier instruction is given, the Processor deletes the personal data within 30 days of the end of the Main Agreement.

8.4 Scope of deletion. Deletion covers: all records extracted from the Controller's Salesforce organisation, the extraction runs that produced them and the change history kept from them (Annex 1 § 5); all Scopes with their field mappings, stage configurations, hierarchies, filters, targets, weekly snapshots, initiatives and weekly clean-up lists; all AI call records with any stored prompts and responses; the business profile and AI settings; the Salesforce connection, whose refresh token the Processor revokes at Salesforce; and all user accounts of the Controller's organisation, whose sessions and cached results are removed immediately.

8.5 What the Processor retains, and on what basis:

a. a minimal record of the closure — the organisation's name, its Salesforce organisation ID, the closure date, whether the Controller or the Processor initiated it, and the e-mail address of the person who requested it — as evidence that the deletion took place and was instructed (Art. 5(2), Art. 28(3)(h) GDPR). This is the only personal datum in that record; b. the Processor's internal record of operator actions concerning the account;

b-bis. the record of the Controller's acceptance of the Main Agreement and this Agreement — the accepting person's name and e-mail address, the time of acceptance, and the version and content hash of each document accepted. This is the evidence that this Agreement was concluded and what it provided, which Art. 28(9) and Art. 5(2) GDPR make the Controller's interest as much as the Processor's: a deleted acceptance record leaves neither party able to show that an Art. 28 contract existed. Legal basis: Art. 6(1)(c) with Art. 5(2) GDPR, and Art. 6(1)(f) GDPR; c. copies in infrastructure backups: daily volume backups retained for 6 days, and a point-in-time recovery archive reaching back approximately four weeks. Backups restore the entire database and are never used to restore a single organisation. The Processor's documented procedure requires the deletion to be re-executed for every closed organisation after any restore; d. data already transmitted to the AI sub-processor, which is subject to that sub-processor's own retention and cannot be recalled; e. accounting records required by § 147 AO and § 257 HGB.

8.6 The Processor confirms the deletion to the Controller in text form on request.

9. Evidence and audits

9.1 The Processor makes available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Art. 28 GDPR, and allows for and contributes to audits, including inspections, conducted by the Controller or another auditor mandated by it (Art. 28(3)(h) GDPR).

9.2 In the first instance, the Processor may discharge this obligation by providing: this Agreement with its Annexes; the extract from its record of processing activities; a completed security questionnaire; and, where available, a current attestation or certification by an independent body or an audit report.

9.3 On-site or remote inspection. If that is not sufficient in the particular case, the Controller may carry out an inspection during the Processor's normal business hours, without disrupting operations, having given at least four weeks' notice, once per calendar year and additionally on any occasion giving specific cause — in particular after a personal data breach. The Controller bears its own costs; the Processor may charge its reasonable expenditure for inspections beyond the annual one at €150 per hour.

9.4 The Controller will ensure that inspections are carried out only by persons bound to confidentiality, that the Processor's trade secrets and other customers' data are protected, and that the inspection does not compromise the security of the Processor's systems.

9.5 The Processor is obliged to cooperate with the supervisory authority in the performance of its tasks (Art. 31 GDPR) and informs the Controller without undue delay of any supervisory measure or investigation concerning data processed on its behalf, unless prohibited from doing so.

10. Instructions concerning employee data

10.1 The parties agree that the personal data processed under this Agreement includes data relating to the Controller's employees — in particular the names of sales representatives as owners of opportunities and as members of the sales hierarchy, and, through the change history (Annex 1 § 5), which employee owned an opportunity at which time, and, through the weekly clean-up lists (Annex 1 § 5), to which employee a list of deals was assigned for a given week and to what extent it was completed — and that the analysis produces results that can be attributed to an individual employee.

10.2 The Controller instructs the Processor to process that data for the purpose of analysing and improving the Controller's sales process at an organisational level. The instruction does not extend to the evaluation of individual employee performance, to decisions concerning individual employees, or to the systematic monitoring of individual behaviour.

10.3 The Processor will not use the data for any such purpose and does not offer any function whose stated purpose is the evaluation of individual employees.

10.4 The parties note that Regulation (EU) 2024/1689 (Artificial Intelligence Act) classifies AI systems intended to be used for the evaluation or monitoring of workers' performance and behaviour as high-risk (Annex III no. 4). The purpose limitation in § 10.2 and § 8 of the Main Agreement is intended, among other things, to keep the use of the service outside that classification. A use by the Controller that departs from § 10.2 is a change of intended purpose within the Controller's own responsibility and may make the Controller a provider of a high-risk AI system under Art. 25(1) of that Regulation.

10.5 Weekly clean-up lists. The service's weekly clean-up lists assign deals that need attention in a calendar week to a member of the sales hierarchy and record whether each was dealt with. Their purpose is planning work. Because a list shows, per named employee and week, whether it was completed, the function is nonetheless objectively suitable for monitoring the behaviour or performance of employees within the meaning of § 87(1) no. 6 BetrVG. The Controller decides whether and how it uses this function, with particular regard to § 2.2 c and d; the instruction in § 10.2 applies to it without restriction.

11. Liability and recourse

11.1 Liability between the parties under this Agreement is governed by § 17 of the Main Agreement, subject to the following.

11.2 Liability towards data subjects under Art. 82 GDPR is governed by that provision and is not limited by this Agreement or by the Main Agreement.

11.3 Internal allocation (Art. 82(5) GDPR). Where one party has paid full compensation for damage caused by a processing operation for which both parties are responsible, it may claim back from the other the part of the compensation corresponding to that other party's part of the responsibility. The same applies to administrative fines, to the extent recourse is legally permissible.

11.4 The Processor is liable for damage caused by the processing only where it has not complied with obligations of the GDPR specifically directed to processors, or where it has acted outside or contrary to the Controller's lawful instructions (Art. 82(2) GDPR).

12. Final provisions

12.1 Amendments to this Agreement and its Annexes require text form. Changes to Annex 3 are made in accordance with § 6.2. Changes to Annex 2 are made in accordance with § 3.7.

12.2 Should any provision of this Agreement be invalid, the validity of the remaining provisions is unaffected. The parties will replace it with a valid provision that comes closest to its purpose.

12.3 This Agreement is governed by German law. The place of jurisdiction follows § 21.4 of the Main Agreement.

12.4 In the event of a conflict between this Agreement and the Main Agreement, this Agreement prevails in all matters of data protection.

Annex 1 — Details of the processing (Art. 28(3) GDPR)

1. Subject matter

Provision of the metisora Sales Process Intelligence service: extraction of historical opportunity data from the Controller's Salesforce organisation, computation of sales process metrics and the metisora SPI Score, visualisation of the results, and generation of written findings using a large language model.

2. Nature and purpose of the processing

Collection (extraction from Salesforce via the Salesforce API), storage, recording of changes between successive extractions, organisation, structuring, computation and analysis, planning and tracking of initiatives and weekly clean-up lists by the Controller's users, disclosure by transmission to the sub-processors in Annex 3, retrieval and display to the Controller's authorised users, and erasure.

Purpose: analysis and improvement of the Controller's sales process at an organisational level. Not the evaluation of individual employees (§ 10 of this Agreement).

3. Duration

For the duration of the Main Agreement, plus the retention periods in § 6 below and the deletion periods in § 8 of this Agreement.

4. Categories of data subjects

5. Types of personal data

Special categories of personal data (Art. 9 GDPR) and data relating to criminal convictions (Art. 10 GDPR) are not the subject of this processing. The Controller undertakes not to configure the extraction so as to include them (§ 7.4 of the Main Agreement).

6. Retention within the service

7. Places of processing

European Union / EEA — Netherlands (europe-west4), with the transfers set out in Annex 3.

8. Erasure

As set out in § 8 of this Agreement.

Annex 2 — Technical and organisational measures (Art. 32 GDPR)

Status as at 29 September 2026. Measures marked [planned] are not yet implemented and are listed for transparency; they are not part of the level of protection currently warranted.

1. Pseudonymisation and encryption (Art. 32(1)(a))

• In transit: all traffic between the user's browser and the service is encrypted with TLS (certificates issued and renewed automatically by Let's Encrypt). HTTP Strict Transport Security is set with a two-year max-age and includeSubDomains. Traffic to the Salesforce API and to the AI sub-processor is TLS-encrypted.
• Salesforce OAuth tokens are encrypted at rest with Fernet (AES-128-CBC with HMAC-SHA256), the key being derived from an application secret held only as an environment variable, distinct per environment, and never stored in the code repository.
• Storage at rest is encrypted by the cloud infrastructure provider.
• No credentials of the Controller's users are stored. Authentication is exclusively Salesforce single sign-on; no passwords and no password hashes exist in the system.
• Pseudonymisation of the names of the Controller's sales representatives in the analysis is [planned].

2. Confidentiality (Art. 32(1)(b))

2.1 Physical access control

The service runs exclusively in the data centres of the cloud providers named in Annex 3. Physical security is provided by those providers under their own certified regimes (Railway is SOC 2 Type II and SOC 3 certified; its compliance documentation is at trust.railway.com). The Processor operates no server hardware of its own.

2.2 System access control

• Authentication of the Controller's users exclusively via Salesforce SSO with OAuth 2.0, using the PKCE extension and a signed, single-use state parameter against cross-site request forgery.
• Server-side sessions: the session cookie carries a cryptographically random identifier only; the session content is held in the server-side store and expires after 14 days. The session and sign-in cookies are set HttpOnly, Secure and SameSite=Lax.
• Sign-ins from Salesforce organisations that have not been provisioned are rejected.
• Access to the Processor's internal operator console is possible only over a private, end-to-end encrypted network (WireGuard-based); it has no public address.
• Administrative access to the infrastructure is protected by the provider's authentication with multi-factor authentication enabled.

2.3 Data access control

• Tenant separation is enforced in the database, not only in the application: PostgreSQL row-level security policies restrict every tenant-scoped table, and the application connects under a role that is explicitly not permitted to bypass those policies. The application refuses to start if it detects that it is connected under a bypassing role.
• All database access is routed through a single, reviewed query module in which every tenant-scoped statement carries the tenant identifier; this makes the absence of a tenant filter reviewable rather than a matter of discipline.
• Least-privilege database roles: a request-serving role without bypass rights, a separate operator-console role with column-level grants on organisation metadata only and no access to customer data at all, and an administrative role used solely for migrations.
• Role model within the customer organisation: administrator and member, with administrator-only actions for deleting Scopes, taking over the Salesforce connection and closing the account.
• Elevated access for the Processor's own personnel is governed by a separate flag that the customer-serving role cannot write; it is granted manually in the operator console and recorded there. Personnel holding it can read the stored AI prompts and responses of any organisation, which may contain deal names, account names, the names of deal owners and of hierarchy members, and written loss reasons. A per-access audit log of such reads is [planned].
• The operator console additionally reads the record of this Agreement's acceptance — which document version was accepted, when, and the name and e-mail address of the person who accepted it (§ 8.5 b-bis). That is the evidence the Controller may itself need, and it is the only customer-side personal datum the console's database role can read: it has no access to the analysed Salesforce data at all.

2.4 Separation control

Data of different customers is separated logically by tenant identifier and enforced by row-level security (§ 2.3). Production and staging run as separate environments with separate databases, separate secrets and separate AI API keys.

2.5 Network control

• The application backend has no public internet address. The only public entry point is the web front end, which proxies API requests server-side over the provider's private network.
• Security headers on the application: Strict-Transport-Security, X-Frame-Options: DENY, and a Content Security Policy on the operator console.
• Rate limiting at the API level is [planned].

3. Integrity (Art. 32(1)(b))

• Input control: the service does not write to the Controller's Salesforce organisation; the extraction is read-only.
• All requests and responses are validated against explicit schemas.
• All database access uses parameterised statements (no string-built SQL).
• Change control: every change to the software goes through version control and an automated pipeline running linting, static type checking and the test suite, and is reviewed by the Processor's owner before it is merged. There is no second reviewer. Database migrations are executed out of band under a dedicated administrative role, not by the running application.
• Audit trail: actions by the Processor's operators on a customer account — sign-in, provisioning, role changes, reopening, deletion on request — are written to an append-only record that the application cannot modify or delete.
• Immutability of extractions: each extraction is stored as a separate, labelled run, so that an analysis can be reproduced against the data as it stood.

4. Availability and resilience (Art. 32(1)(b), (c))

• Daily volume backups of the database, retained 6 days, plus continuous point-in-time recovery reaching back approximately four weeks. Backups are taken by the hosting provider from the volume in the processing region stated in § 7; the Processor has asked the provider to confirm the storage region of the backups in writing and will state it here once confirmed.
• Infrastructure in a managed cloud environment with the provider's own redundancy.
• Availability target 99.0 % per calendar month (§ 6 of the Main Agreement).
• A documented procedure requiring the re-execution of the deletion routine for every closed organisation after any restore from backup, so that a restore cannot resurrect deleted data.
• Documented, regularly tested restore drills are [planned].

5. Procedures for regular testing, assessment and evaluation (Art. 32(1)(d))

• A documented security review of the backend has been carried out; the findings are tracked and remediated.
• Automated tests run on every change; the test suite includes tests asserting tenant isolation under enforced row-level security.
• Automated dependency vulnerability scanning is [planned].
• An independent penetration test is [planned].
• This Annex is reviewed at least annually and on any material change to the architecture.

6. Data protection by design and by default (Art. 25)

• Data minimisation at source: the Controller selects which Salesforce objects are extracted and over what period. For opportunities, opportunity line items and accounts, every field the authorising Salesforce user can read is extracted; the Controller limits the fields through that user's field-level security in Salesforce.
• Change history as differences, not copies: superseded extractions are not kept; only what changed between two extractions is recorded, so a record exists once rather than once per week, and erasing it is a single operation.
• Minimisation towards the AI sub-processor: most AI functions receive aggregated figures — and, where a view is narrowed to one member of the sales hierarchy, that member's name and level. The loss-reason themes receive the written loss reasons without any deal, account or owner field. The single function that receives individual records receives a bounded sample, and the prompt instructs the model to use only the values supplied. Figures displayed next to a generated narrative are computed by the Processor, not by the model.
• Prompt storage is a per-organisation switch that, when off, prevents the content from being written at all — not merely from being displayed.
• No prompt or response content is ever written to application logs; logs carry only identifiers, token counts and timings.
• Deletion is complete and automatic, resumed by a scheduled job if interrupted.

7. Organisational measures

• Number of persons with access to personal data processed on behalf of controllers: one — the Processor's owner. No other person holds production access. The Controller should note the corollary: the Processor is a single-person operation, and business continuity arrangements are as set out in the Main Agreement.
• All such persons are bound to confidentiality in writing and instructed in data protection; the obligation survives the end of their engagement.
• Secrets are held exclusively as environment variables in the hosting platform, never in the code repository; each environment has its own distinct values.
• A documented deletion concept exists and is maintained with the product.
• Incident procedure with a defined contact point (info@metisora.com) and a 24-hour notification commitment to controllers (§ 5).

Annex 3 — Sub-processors

Version of 29 September 2026. Changes are notified in accordance with § 6.2 of this Agreement. The current version is always part of this Agreement, published at https://app.metisora.com/legal/dpa.

Anthropic retention — stated precisely

The Processor has not entered into a zero data retention arrangement with Anthropic. Under Anthropic's standard commercial retention policy, inputs and outputs are deleted within 30 days of receipt or generation. Where content is flagged by Anthropic's automated trust-and-safety systems, Anthropic may retain inputs and outputs for up to two years and the resulting classification scores for up to seven years. Anthropic does not use the content to train models.

The Processor will notify the Controller under § 6.2 if this arrangement changes.

Not sub-processors

• Salesforce — the Controller's own source system, accessed on the Controller's authorisation (§ 6.5).
• Qonto (Olinda SAS, France) — the Processor's bank. A payment service provider processes payment data as an independent controller under its own legal obligations, not on the Processor's instructions, and is therefore not a sub-processor. It receives no personal data processed on the Controller's behalf.
• GitHub, Inc. — authenticates the Processor's own operators to the internal console and hosts the source code. It receives no personal data processed on the Controller's behalf.
• Hostinger — DNS only; no personal data.

metisora Data Processing Agreement, version 2.0, 29 September 2026.