TALLWRIGHT - DATA PROCESSING AGREEMENT Version dpa-1.0. In force from 2026-09-12. Replaces: nothing. This is the first version. The SHA-256 of this file, with CRLF normalised to LF, is published at https://tallwright.com/legal beside this version. 0. The parties, this document, its form 0.1 The parties are you - the customer named in the account or in the signed application, as controller or, where clause 1.5 applies, as a processor - and us: Kyoomee GmbH Grazer Strasse 1/3, 8120 Peggau, Austria Firmenbuch FN 682788a, Landesgericht fuer Zivilrechtssachen Graz UID ATU83518524, hello@tallwright.com "We", "us" and "Kyoomee" mean that company, and it is the processor. hello@tallwright.com is also the contact for data protection. We have appointed no data protection officer, because Art 37(1) GDPR does not require one; if that changes we name them here. 0.2 This agreement is attached to and governed by the Tallwright Terms of Service, version terms-1.0 (https://tallwright.com/legal/terms-1.0.txt). Service, Edition names, Record, Payload, Archive, Exhibit, Operator, Owner, Admin and every other capitalised term mean what they mean there; data protection terms mean what Article 4 GDPR says. 0.3 This version is dpa-1.0 (https://tallwright.com/legal/dpa-1.0.txt) and has no predecessor. The page at https://tallwright.com/legal lists all four documents, each at its own URL, with the SHA-256 of each computed from the served bytes, never typed. This file's digest is pinned in the application's module, in the witness policy template and in the notary runbook, each derived from these bytes; the witness pins in its own configuration on its own machine, which is the point of it. 0.4 It is a contract in writing in electronic form for Art 28(9) GDPR, accepted as terms-1.0 clause 2 describes: the apply screen links this file and the Terms, shows both digests and offers acceptance only through one control naming both, before anything is signed or sent, and the account-creation screen links them too. Where you enrolled as an Operator, this version's name and digest sit inside the bytes your own key signed, which is the acceptance, and the bytes you signed are kept in the account's application row. No store of ours holds a separate acceptance record for a self-service account; when the product writes one it will hold the version, the digest, the time and the user agent. We process no personal data of yours before this version is in force for you. 0.5 Annexes A, B, C and D form part of it. A and D are below. Annex B is the technical and organisational measures document and Annex C the sub-processor list, each published at https://tallwright.com/legal. This agreement governs which version of each is in force: the most recent one notified under clause 6.3 for B or clause 7.3 for C and published there. Today they are toms-1.0 and sub-processors-1.0. 0.6 Annexes B and C are incorporated by name and URL, never by digest, because a new version here is a new digest pinned on two machines at once and an application naming a version we do not pin is refused. Neither annex substitutes its own successor, and nothing either publishes varies this agreement. 0.7 Four terms here are unusual, and we point them out. The witness's register entry for your admission, and any refusal, are permanent, never amended, and a conclusive refusal is published (14.5). We refuse to dispose of an Archive carrying a retention label (14.3). We keep no register of legal holds: you declare them in each request (10.5). Silence for fourteen days after a sub-processor notice authorises that change (7.4). 1. What we are, per Edition 1.1 Cloud. We are controller of the account relationship: seats, sign-in, the audit log of what was done to a seat, the billing contact. We are processor of the Archive metadata: the Record envelope, the operator identifier, the retention label, the hold flag. None of your Record content is on our disk: every Archive the product provisions holds hashes only, custody is fixed at creation, a line carrying a payload, a base64 payload or a subject identifier is refused by name rather than dropped, and it cannot be otherwise. Two Archives on the fleet host do hold content, and both are ours - Kyoomee's own records, and an isolation probe - read off the host on 2026-09-12. 1.2 Managed. We are processor of operational metadata only: an operator and a box identifier, the clock the reporting machine wrote into the document, its schema version, a tenant label, a severity, the number of records, the number anchored, the age of the oldest unanchored head, and codes from a closed set. Per box the receiver keeps first-seen, last-heard, last-spoke, last-knocked and last-refused times, document and refusal counts, and current and highest Archive count. No field could carry the text of a finding, and the reporter on your machine cannot open an Archive. 1.3 Witness. It receives no Record content by construction: three lines, a signature over those bytes, hash-only consistency material. It learns the origin string you chose, which can carry personal data, the tree size, the time a request arrives and the network address it arrives from. For the origin string and enrolment data we are processor. For the arrival time we are controller: our basis is the legitimate interest in running the register and answering who presented which log and when (Art 6(1)(f) GDPR), and it lasts as long as the register entry. It records the address nowhere: its handler writes no request log. 1.4 Self-Hosted. Nothing of ours runs inside your estate and we process no personal data of your data subjects. If you anchor to our witness, clause 1.3 applies to that traffic; if you hold an account, clause 1.1's first sentence applies to it. 1.5 Where you are yourself a processor, we are your sub-processor. We follow your controller's instructions as you pass them to us, and yours must not conflict with them. You confirm your mandate covers engaging us and the Annex C sub-processors, and you forward to your controller every notice we owe you under clauses 4, 8.4 and 12. 2. Subject matter, duration, nature, purpose 2.1 Annex A sets these out per Edition, in the detail Art 28(3) requires. 2.2 The duration is the term of terms-1.0, extended by the triggers in clause 14 and any retention in A.9. 3. Your instructions, and the decision that is yours 3.1 We process your personal data only on your documented instructions. 3.2 Four channels count as a documented instruction. The signed application or the account, including the Edition and its settings. The product's settings, command arguments and API parameters, documented because you hold the record of what you sent; on our side a seat action is kept in the account audit log and a search or a query in the Archive's access log, and nothing else is. A written instruction to hello@tallwright.com from an Owner or Admin. A signed order form. 3.3 What enters a Payload is your decision, and nothing of ours stands between that decision and the seal. There is no personal-data detection, and the only redaction is this. Keys on our credential list are replaced with a redaction marker and the path is noted on the Record, and the transport adapter replaces the keys on our reasoning list too; both ship with the recorder as defaults, your operator may pass a wider or a narrower set, and no denylist is complete. In the tier-1 adapter, messages are projected onto an allowlist of fields and content-block types, so anything outside it is absent, and the record names what was dropped without carrying its value. Everything else is sealed as sent. 3.4 You declare what a subject identifier is: opaque, pseudonymous, direct or undeclared. We keep and print it and do not verify it. One check runs, only where you declared "opaque": a visible e-mail address, an international telephone number or an IBAN is refused. 3.5 We process for the purposes in Annex A.1 and no others. Your Records, Payloads, metadata and telemetry are not used to train, benchmark, evaluate or improve any product, model or service. We open a Payload only on your written instruction for a support purpose you describe. 3.6 The one departure is processing required of us by Union or Member State law, and we tell you first unless that law forbids it. Where the law requires it, or a court or an authority orders it, we may make an identified record inaccessible; we tell you what we did and why, and every proof over that record stays intact. 3.7 You must not put special-category data, or personal data about criminal convictions and offences, into a Payload without a separate written agreement recording the restrictions and safeguards that then apply. 3.8 What is yours. You supply the personal data and its lawful basis, you tell data subjects what you must, you instruct us through 3.2 and keep your own copy, you declare what a subject identifier is (3.4) and what is under hold (10.5), and clause 13 is how you satisfy yourself that our measures fit. 4. An instruction we believe is unlawful 4.1 If in our opinion an instruction infringes the GDPR or other Union or Member State data protection law, we tell you immediately and say why. 4.2 We suspend that instruction until you confirm, amend or withdraw it in writing. Only that instruction: no suspension here stops a recording, an anchor or an export. 4.3 If you confirm it afterwards, we may terminate this agreement and the affected Service on written notice, and your export rights under clause 14 survive. 5. Confidentiality 5.1 Access is limited to those who need it for a task by who holds a host credential, and by nothing else; Annex B states what is not enforced. What binds every person we authorise today is the statutory duty in clause 5.2, which needs no signature; Annex B records that a separate written undertaking is not in place. We sign one, covering all personal data processed for you and surviving the engagement, before we authorise any further person. 5.2 Under Section 6 DSG we and our staff must keep entrusted data secret; staff may transmit data only on an express order; and the duty outlives the employment. 5.3 Under Section 6 Abs 5 DSG a right of yours to refuse testimony may not be got around by coming to us instead. Clause 8.4 governs a demand made to us. 6. Security 6.1 Annex B describes the measures per host type and per Edition and says for each whether it is in force, partial or absent; the tests and files behind each come with the pack in 13.1. 6.2 A measure not listed in Annex B, as it stands or as changed under 6.3, is not in place; what it states as missing is part of this agreement as much as what is present. 6.3 We review the measures at least yearly and whenever the processing or the risk changes materially. We do not lower the protection of a measure without your agreement in writing. Where a provider's change, a security need or the law forces a lowering, we tell Owners and Admins thirty days in advance, naming the measure, the old and the new state and the reason; you may object within fourteen days on data protection grounds, and if we cannot keep the level you may terminate the affected Service without penalty and with a pro-rata refund. A notified change is part of Annex B from the date it takes effect. 6.4 No organization other than ours has audited or tested the Service's security. 7. Sub-processors 7.1 You give us a general written authorisation, limited to the sub-processors in Annex C as it stands and to a change notified under 7.3. 7.2 Annex C names each sub-processor individually: who it is, what it does for us, what data reaches it, where it processes. 7.3 Before we add or replace a sub-processor we give Owners and Admins at least thirty days' written notice, stating the name, the role, what data would reach it, where it would process, and the basis under Annex D. Publishing the change is not the notice. 7.4 You may object within fourteen days, in writing, on data protection grounds. We then keep your personal data away from that sub-processor; if we cannot, you may terminate the affected Service without penalty and with a pro-rata refund. Silence for fourteen days authorises that change and nothing else. 7.5 Each sub-processor processes under its own published data protection terms, which we have not read against this agreement. We undertake to put a written contract in place with each, imposing in substance the obligations here, including the duty to contribute to an inspection under clause 13. We stay fully responsible for a sub-processor's performance whatever its own terms say, and we tell you without undue delay when one fails such an obligation in a way that affects your data. 7.6 On request you get a copy of a sub-processor agreement and its amendments, redacted only as far as business secrets need. 7.7 If we cease to exist in law or become insolvent, you may require us to instruct each sub-processor to return or delete your personal data, and we give you what you need to deal with that provider directly. We undertake to agree such a term with each one; Annex D records that this is not yet performed. 8. Transfers outside the EU and the EEA 8.1 We do not transfer your personal data to a third country or an international organisation except on your documented instruction or where Union or Member State law requires it of us. 8.2 Annex D states per sub-processor where it processes and on what evidence. We measured the three hosts and the backup repository ourselves and read the backoffice database in its provider's console. For outbound mail the EU processing rests on the provider's own statement and we pin no region; for the payment provider the contracting entity and the place of processing are not verified by us. For those two a transfer to a third country may be occurring for which this agreement names no safeguard: treat them as unresolved in your own Chapter V record, and clause 7.4 gives you the objection right. We name no transfer mechanism we have not seen in place, and where another page of ours does, this agreement prevails. 8.3 This agreement does not by itself make any transfer lawful and does not satisfy Chapter V GDPR. 8.4 If an authority outside the EU demands data we hold for you, or access to it: we tell you before we answer unless the law binding on us forbids it, and then as soon as it permits; we assess whether the demand is lawful and binding on us and challenge it on reasonable grounds; we disclose the minimum it permits; we record that assessment for you; and where you are yourself a processor you forward this to your controller. 8.5 Under Article 32 of Regulation (EU) 2023/2854 we do not transfer data held in the EU, and do not give access to it, where that would conflict with Union or Member State law. 9. Helping you answer a data subject 9.1 A request that reaches us directly goes to you without undue delay and we do not answer it, unless you authorise us in writing. 9.2 We assist without undue delay and early enough to leave you inside your own Chapter III time limit. That limit is not extended: you decide whether a request is admissible and answer it. 9.3 What we can do. For access and portability: the records of an Archive, a court export for one Record, a one-use Exhibit link, the usage basis. For an Archive holding content, the erasure in clause 10. For Archive metadata, what it holds for a subject identifier you give us. Where 1.1 makes us controller, we answer ourselves. 9.4 What we cannot do. In a provisioned Archive we hold no Payload, no key and no subject identifier, and where you hold the Payloads there is nothing here to search. In an Archive holding content we hold the per-subject keys, so we could open a Payload; we do not, and clause 3.5 is the undertaking. We have no index that would find a person, and the key store holds the identifier exactly as you sent it; you supply it, and without it there is nothing to act on. 9.5 A sealed Record cannot be corrected, because any later change to it is detectable; a correction is a new Record superseding the earlier one, which stays. 9.6 On your instruction we stop new recording into an Archive, close it, remove or replace a retention label by hand, and revoke a credential we hold for you. 10. Erasure, legal hold, backups 10.1 An Archive holding content is one you operate, because the product provisions none: this clause is what the software does in your hands, and what we undertake if we ever hold one. An erasure destroys the subject's key and the salts of their records in the live Archive, in one act or not at all; after it the ciphertext cannot be read. Every proof stays valid, so an Exhibit for another Record still verifies. 10.2 The erasure record names content addresses and never the subject, so the act names the subject nowhere new. 10.3 The act is not irreversible: a restore of the key directory from a backup brings the key and the salts back, and the Archive's self-check reports it. We restore only on your instruction or to recover from a failure, and we re-apply after a restore any erasure you have already requested. 10.4 The fleet host backs up every Archive on it; the receiver host backs up only the Managed roster - per box, the hash of its key and the silence interval - and never a receipt and never a telemetry document. Both are encrypted on the host before they leave, not searched and not edited. The destination is a storage service of Hetzner Online GmbH in Germany, reached over SFTP; that repository is not append-only, and no restore has been rehearsed. Nothing of ours prunes snapshots, so a snapshot of your data has no maximum age: treat our backup retention as unbounded in your own records. The witness host has no backup script at all, and the backoffice store has only its provider's point-in-time history (A.9). 10.5 An erasure or a disposal is refused while any record it would touch is under a hold you declare in that request. We keep no register of holds: the obligation behind a hold is yours to know. Each request states the records under hold, one that does not say is refused rather than assumed clear, and a conflict is raised to a person. 10.6 In an Archive holding hashes only there is nothing to erase: no subject identifier, no key, no salt. Such a request is answered in your own estate, from the Payloads you hold. 11. Helping you with Articles 32 to 36 11.1 We assist with your own security, breach-notification, impact-assessment and prior-consultation duties, so far as the processing and what is available to us allow: Annex B and the tests behind it, the pack in 13.1, the data flows for your Edition, and clause 12. 11.2 An impact assessment stays yours: we do not run it and nothing here moves the duty. 12. A personal data breach 12.1 We notify you of a personal data breach affecting personal data we process for you without undue delay after becoming aware, and in any event within 48 hours. Becoming aware means a person of ours reading an alarm: Annex B says the chain ends at a journal line and a mailbox, with no paging and no on-call rotation, so an alarm raised out of hours may not be read until the next working day. The 48 hours runs from that reading, and nothing of ours records it: we note it by hand in the incident note we send you. That figure is our commitment, not a period the law fixes for a processor. 12.2 We do not first assess whether the breach is likely to result in a risk. That is yours. 12.3 The notice states the nature of the breach, including where possible the categories and approximate number of data subjects and of records concerned; a contact point; the likely consequences; and the measures taken or proposed. 12.4 We do not notify a supervisory authority or a data subject on your behalf unless you authorise us in writing for that incident; if we do, we give you a copy. 12.5 A separate duty of ours, not about your data. We are a trust service provider established in Austria and we are not qualified: that status has not been granted to us. Under Article 19a eIDAS we must notify the supervisory body - the Telekom-Control-Kommission, under Section 12(1) SVG - within 24 hours of becoming aware of any breach or disruption with a significant impact on the trust service or on the personal data maintained in it; where that Article applies we must also tell the people affected, other competent authorities, and the public where the disruption is of public interest. 13. Information and inspection 13.1 On request, once in any twelve months and after an incident affecting you, we give you at no charge, under the confidentiality in 13.2: a completed security questionnaire; Annex B; the tests that hold each statement in it and their latest results, redacted only as far as another customer's data or a business secret needs, with the reason; Annexes C and D; the data flows for your Edition; the backup repository's address and topology; and the part of our Article 30(2) record that concerns you, or what 15.1 puts in its place. 13.2 You, or an auditor you mandate, may inspect remotely or on site, once in any twelve months, on thirty days' written notice, in business hours and under confidentiality; more often after a material failure or where a supervisory authority requires it. For a hosted Edition it may cover the hosts carrying your Archives: our own access, configuration and records in full, and physical access to the datacentre so far as the infrastructure provider permits, and otherwise remote inspection of the host and that provider's assurances. The decision and the method are yours, and you may contest both and the results. 13.3 An inspection is at your cost unless it finds a material failure to meet this agreement or Annex B, when it is at ours. No fee may make these rights impractical, and there is none for the pack or the assistance in clauses 9, 11 and 12. 13.4 You may require remedial measures for a shortcoming found; we agree a plan and a date in writing and report completion. We obtain the same rights from a sub-processor where its terms allow. 13.5 A supervisory authority is not restricted by this agreement in any way: no notice period, no cost, no frequency cap, no escort, no confidentiality condition. We give it inspection results on request. 14. The end of the processing 14.1 When the Service ends an Owner or Admin chooses in writing between deletion and return of the personal data we process for you. Return means the records of each Archive and its Exhibits by the paths in clause 9.3, the Archive metadata, and the account's seats, invitations and audit events as files, within fourteen days and at no charge. 14.2 On closure, recording stops and Records and Exhibits stay exportable for thirty days, by the paths in clause 9.3 and at no charge, or for any longer period a mandatory provision requires, in particular Article 25 of Regulation (EU) 2023/2854 where it applies to your Edition. If you ask for nothing, we dispose of nothing. 14.3 Deletion means disposal of a book - every Archive of your account and their Payloads at once - as a supervised act by a person outside the provisioning door, and nothing in the product schedules it. It is refused while any of those Archives is open, within thirty days of closure, while any carries a retention label, or under a hold you have declared, and it needs the account's closed state supplied to it. An Owner or Admin removes or replaces a label by written instruction under clause 3.2; we do it by hand, nothing in the product records the change, and we do not assess the obligation behind your decision as controller. We confirm a disposal in writing, naming the Archives, the act and the date. 14.4 What we keep. Invoicing data for seven years, because Section 132 BAO requires it. The account audit log, the only record of who changed a seat, which answers a later dispute or an authority - our legitimate interest under Art 6(1)(f) GDPR, against the one e-mail address a row holds. A row is removed only by a deliberate administrative act, never by the application, and we state no period, because nothing in the product enforces one. 14.5 What we do not delete: the witness's register entry for your admission, and any refusal. We do not edit them, a refusal is answered only by a later dated statement, and such an entry names your organisation, your operator identifier and your keys, and no data subject. Where a refusal is conclusive we publish it, telling you first, and we publish no origin string we know to name a natural person. An entry sits on the witness host, organisationally separated from the hosts carrying Archives, and the witness pushes its register to the backoffice, which holds a copy it can neither edit nor invent but could withhold. Annex B says the witness host has no backup, so permanence is a rule we keep, not a guarantee against losing the machine. 14.6 Until deletion or return is complete, every clause here keeps applying. 15. Records, liability, precedence, change 15.1 We will keep the record of processing activities Article 30(2) GDPR requires and give you the part that concerns you; until it is written, Annexes A and D stand in its place and are yours on request. 15.2 Each of us answers for its own compliance. Liability between us is governed by terms-1.0 clause 20, and nothing here limits a data subject's rights or Article 82 GDPR. 15.3 For personal data this agreement prevails over terms-1.0; a signed order form prevails over both. Austrian law governs and terms-1.0 clause 27 fixes the venue. English is authoritative; where a deal is in German, the incorporation notice and the accept label are given in German too. 15.4 We do not change this agreement by publishing a change. A new version is a new file at its own URL naming this version's digest, notified to Owners and Admins in advance, and the version inside the bytes you accepted governs until you accept another. The Terms and this agreement change together, for the reason in 0.6. On a change of either, or of the price list, you may end this agreement and the affected Service by writing to hello@tallwright.com: it takes effect on receipt, needs no reason and no notice period, stops the next charge, and terms-1.0 clause 14.2 does not apply to it. Either of us may terminate for material breach on thirty days' written notice, unremedied. ANNEX A - DESCRIPTION OF THE PROCESSING A.1 Purposes. To operate the Edition you bought: to keep the account, its seats and sign-in; to meter usage and invoice it; to provision and operate Archives; to receive Records and seal them; to present heads to the witness and keep the cosignature; to produce Exhibits and exports; to report a fault; and to keep the admissions register. No others. A.2 Nature. Collection, recording, organisation, storage, encryption, hashing, transmission of hashes and signatures, retrieval for export, destruction of keys and salts on an erasure, disposal of an Archive. A.3 Categories of data subjects. Your personnel and contractors to whom you give a seat, and people you invite to one. The person who holds the payment relationship with us. Individuals identifiable from an origin string you composed. Your own end users or others whose personal data your integration puts into a Payload or a field you control, which arises only where you hold the Payloads or operate an Archive holding content, which the product does not provision (10.1). A.4 Categories of personal data. Account relationship: e-mail address and chosen name; a seat's role and scope label; an invited address and who invited it; per session, how the person signed in, the user agent string, and times of issue, expiry, last use and revocation; per passkey, its identifier, public key and times; per audit event, the actor, their e-mail address as it then was, the subject of the act and what changed; per account, the name and the payment-provider customer identifier. Nothing of ours collects the invoicing entity, a VAT identification number or a register number; you give them in writing to hello@tallwright.com, and the payment provider collects a VAT number in its portal. No IP address or location is stored; a caller's address is only an in-memory rate-limit key. Archive metadata: record identifier, previous record hash, payload hash, time, agent system identifier and version, operator identifier, event type, action type, actor authority, retention label, hold flag, gap manifest. A Record carries no content, and personal data appears here only in a field you control. Payload, in an Archive that holds content: whatever your integration sends, as clause 3.3 describes, with a mandatory subject identifier; in the tier-1 adapter, the model context close to verbatim, including tool arguments and results. Managed telemetry: the fields in clause 1.2 and nothing else. Witness: the three things in clause 1.3, plus enrolment data - operator identifier, organisation name, public keys, delegate, applicant domain, basis, and the accepted version names and digests. The admissions copy in the backoffice: your signed application document as published and signed, and the witness's register entry and head exactly as the witness wrote them, carrying that enrolment data and all three parts of your signature. Mail we send: recipient address, subject, and a plain-text body that can carry a one-use sign-in or invitation link, an account name, an operator identifier, a register entry number and the sentence an Exhibit bears. A.5 Special categories. None is asserted and none is intended; clause 3.7 governs. Nothing in the product detects such data. A.6 Frequency. Continuous for recording. Anchoring is scheduled fifteen minutes after the previous run for that Archive started, spread by up to two minutes, so a run never overlaps its predecessor and the interval is not a service level; while anchoring is unavailable, no bound on how long a Record stays unanchored holds. On each event for account actions; daily for metering, monthly for invoicing; on request for exports, erasures and disposals. A.7 Duration. As clause 2.2 states. A.8 Locations. The witness host and the fleet host are Hetzner vServers on separate machines in the same datacentre in Falkenstein, Germany (fsn1-dc8); the Managed receiver is a Hetzner vServer in Helsinki, Finland (hel1-dc2). All three read from the provider's metadata service on 2026-09-12. The backoffice database is in Amazon Web Services eu-central-1, Frankfurt; its server code executes in Frankfurt (fra1), pinned there and read off a live response on 2026-09-12; that store also holds the admissions copy in A.4. The off-host backup repository is in Germany. Archives we host are in the EU and do not leave it; on Self-Hosted and Managed the Archive is on your machine and its place is yours. A.9 Retention. Exact figures appear only where code enforces them. Enforced: a session 8 hours; a sign-in link 10 minutes, single-use; an invitation 7 days; a provisioning claim 5 minutes; the Managed receiver keeps one receipt per box and only the newest accepted document; the backoffice database has six hours of provider-side history. Records and Payloads: while the Archive is open, then clauses 14.2 and 14.3. A subject's key and salts: destroyed on an erasure you request, under clause 10. Users, memberships, invitations, audit events, usage days, billing periods and the admissions copy in A.4: not deleted by any code path (14.4). Removing a member sets a removal time and revokes their sessions. Invoicing data: seven years, Section 132 BAO. The witness's register entry and any refusal: permanent, under clause 14.5. Backup snapshots, of the fleet host's Archives and the receiver's roster alike: as clause 10.4 states, with no maximum age. ANNEX B - TECHNICAL AND ORGANISATIONAL MEASURES The technical and organisational measures document, today toms-1.0 at https://tallwright.com/legal/toms-1.0.txt, incorporated by name and URL under clause 0.6. Clause 6.2 applies to what it says is missing as much as to what is in place. ANNEX C - SUB-PROCESSORS The sub-processor list, today sub-processors-1.0 at https://tallwright.com/legal/sub-processors-1.0.txt, incorporated by name and URL under clause 0.6. It also names the infrastructure third parties that are not processors of personal data. Sign-in is a one-use emailed link or a passkey; any external identity provider we connect appears in that list. ANNEX D - BASIS PER SUB-PROCESSOR Per sub-processor: what it does, where it processes, the evidence, and whether we have verified its legal entity and its parent's domicile. This annex is the authoritative list, and where a page of ours names fewer of them or asserts an unverified entity, this annex prevails. We have not read these providers' own data protection agreements against this agreement, so under clause 8.2 no transfer mechanism is asserted here, and clause 7.7 is not yet performed. D.1 Hetzner Online GmbH, Germany. The witness host and the fleet host in Falkenstein, Germany; the Managed receiver in Helsinki, Finland; and the off-host backup repository, a Storage Box reached over SFTP - where the fleet host puts a copy of every Archive on it and the receiver host a copy of the Managed roster, each encrypted before it leaves. EU entity, EU processing, measured by us on 2026-09-12. The repository's address and topology are not published here; you get them under 13.1. D.2 Vercel. The hosting platform for the backoffice. Server-side execution is pinned to Frankfurt, Germany (fra1) by our own configuration, read off a live response on 2026-09-12. Legal entity and parent domicile: not verified by us. D.3 Neon. The backoffice database, in Amazon Web Services eu-central-1, Frankfurt, read in that provider's console on 2026-09-11, with six hours of point-in-time history and no copy outside it. Legal entity and parent domicile: not verified by us. D.4 Resend. Outbound product mail; what reaches it is in Annex A.4. Processing in the EU on that provider's own statement - we pin no region. Legal entity and parent domicile: not verified by us. D.5 Stripe. Payment processing and invoicing. It receives an account name or operator identifier, the e-mail address of one money reader, and two metadata fields. A card, a billing address and a VAT identification number are typed on that provider's own pages and never reach us. Contracting entity and place of processing: as that provider states them, not verified by us. D.6 World4You, Austria. Inbound mail and DNS for tallwright.com, including the mailbox for hello@tallwright.com, so it receives resolver queries and the content of that mail. Processing in Austria. Legal entity and parent domicile: not verified by us.