Data Processing Agreement
This Data Processing Agreement ("DPA") is entered into under Article 28(3) GDPR between Sphere Consulting Group LLC ("Processor"), a Wyoming limited liability company at 30 N Gould St Ste R, Sheridan, WY 82801, United States (EIN 30-1326629), and the customer identified in the account registration ("Controller").
It incorporates the EU Standard Contractual Clauses, Commission Implementing Decision (EU) 2021/914, Module Two, and it takes effect with the Terms of service. No separate signature is needed to be bound by it.
Version 1.0 ยท 29 October 2026. An executed copy, the Security Annex and the Transfer Impact Assessment are available from support@modelworks.dev, and are provided as part of any procurement review.
1. Definitions
Terms used with a capital letter and not defined here have the meanings given in Regulation (EU) 2016/679 ("GDPR").
Services means the inference services operated by the Processor and described in the Documentation at the time a key is issued. As at the date of this agreement the Services are text-to-speech only; this agreement describes no service that is not offered.
Documentation means the API reference published at https://modelworks.dev/docs.html.
Customer Data means any personal data submitted to the Services by or on behalf of the Controller, including text submitted for synthesis.
Sub-processor means any processor engaged by the Processor to carry out processing on behalf of the Controller.
2. Scope and roles
2.1 The Controller is the controller and the Processor is the processor of Customer Data.
2.2 The subject-matter of the processing is the provision of the Services. The duration is the term of the agreement between the parties. The nature and purpose is the conversion of text to audio, as instructed through the Services.
2.3 The Processor processes Customer Data only on documented instructions from the Controller, including with regard to transfers of personal data to a third country, unless required to do otherwise by Union or Member State law, in which case the Processor will inform the Controller before processing unless that law prohibits it.
2.4 The Processor will immediately inform the Controller if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions.
3. What the Processor commits to
3.1 Confidentiality. Persons authorised to process Customer Data are bound by appropriate obligations of confidentiality, whether contractual or statutory.
3.2 Security (Article 32). The Processor implements the technical and organisational measures set out in the Security Annex, including encryption in transit, access control, logging, and backup. The Security Annex forms part of this agreement.
3.3 No retention by default. Customer Data is not retained after a request completes, except for the logging described in clause 3.4. This commitment is the one that distinguishes the Services from commodity alternatives and is the reason a Controller with EU obligations should prefer it.
3.4 Logging. The Processor retains request metadata - timestamp, endpoint, byte counts, status code, the API key used, and, for a visit to the public site, the referring page - for 30 days, for security, abuse prevention and billing. The client address and the User-Agent are deleted before any log line is written. No request or response content is included in these logs.
3.5 Sub-processors.
- The Controller grants general written authorisation for the engagement of Sub-processors.
- The current Sub-processor list is published and maintained at https://modelworks.dev/subprocessors.html and is incorporated into this agreement by reference.
- Changes are announced on that page and by email to the Controller's billing address at least 30 days before they take effect. A Controller who objects to a new Sub-processor may terminate this agreement and the affected Services without penalty, and receives a pro-rata refund of any prepaid and unused allowance.
- The Processor will give the Controller at least 30 days' notice of any intended addition or replacement, so the Controller may object.
- Any Sub-processor is bound by data protection obligations equivalent to those in this agreement. The Processor remains fully liable to the Controller for the performance of a Sub-processor's obligations (Article 28(4)).
3.6 Data subject rights. The Processor assists the Controller, by appropriate technical and organisational measures, in responding to requests to exercise data subject rights. Because Customer Data is not retained, a request can be satisfied by the absence of the data rather than by a retrieval process - which is a simpler and more reliable answer than a deletion workflow.
3.7 Assistance with Articles 32 to 36. The Processor assists the Controller in ensuring compliance with the security of processing, breach notification, data protection impact assessments, and prior consultation, taking into account the nature of the processing and the information available to it.
3.8 Breach notification. The Processor notifies the Controller without undue delay and in any event within 72 hours of becoming aware of a personal data breach (Article 33). Notification includes the nature of the breach, the categories and approximate numbers concerned, the likely consequences, and the measures taken or proposed. The Processor does not notify supervisory authorities or data subjects on the Controller's behalf - that is the Controller's obligation and decision.
3.9 Return or deletion. On termination, and at the Controller's choice, the Processor deletes or returns Customer Data. In practice there is nothing to delete or return, because Customer Data is not retained (clause 3.3). Metadata logs described in clause 3.4 are deleted on the same schedule regardless of termination.
3.10 Audit. The Processor makes available all information necessary to demonstrate compliance with Article 28 and allows for audits, including inspections, conducted by the Controller or an auditor it mandates. The Processor's position is that the published security page, the penetration test report where one exists, and the sub-processor list together satisfy Article 28(3)(h), and that an on-site inspection is available at the Controller's cost, on reasonable notice, no more than once a year, and subject to confidentiality.
4. International transfers
4.1 The Controller authorises the Processor to process Customer Data outside the European Economic Area as necessary to provide the Services.
4.2 Where Customer Data originating in the EEA is transferred to a country without an adequacy decision, the Standard Contractual Clauses in Commission Implementing Decision (EU) 2021/914, Module Two (controller to processor), are incorporated into this agreement by reference and take precedence over any conflicting term.
4.3 India is not subject to an EU adequacy decision. Transfers to the Processor are therefore made under the SCCs, with a Transfer Impact Assessment available to the Controller on request, and kept current as the deployment changes.
4.4 The Processor will inform the Controller of any change to the location of processing that affects this clause.
5. Liability and precedence
5.1 Each party's liability under this agreement is subject to the limitations in the main agreement between them.
5.2 Where this agreement conflicts with the main agreement on a matter of data protection, this agreement prevails.
5.3 This agreement is governed by the law of the jurisdiction named in the main agreement.
Annexes
Annex 1 - Security measures. Set out below. Each row names the security-page claim it implements, so the two documents can be checked against each other - which is what clause 3.2 requires.
Annex 2 - Sub-processors. Published at https://modelworks.dev/subprocessors.html and incorporated by reference, so that adding one does not require re-signing this agreement.
Annex 3 - Transfer Impact Assessment. Referenced in clause 4.3. It records the facts of the transfer and the safeguards relied on, so that a Controller can reach its own conclusion.
Annex 1 - Security measures
The Security Annex. Each row names the measure, the claim on the security page it implements, and its status. The annex claims nothing the security page does not claim, and the security page is the customer-facing statement of the same controls.
| # | Measure | The security-page claim it implements | Status |
|---|---|---|---|
| 1 | Encryption in transit. TLS terminated on our own host (Caddy with an ACME certificate; the .dev TLD is HSTS-preloaded, so the site is HTTPS-only by construction), TLS 1.2 or higher only. Plain HTTP is redirected to HTTPS. | "TLS 1.2 or higher on every API endpoint... Plain HTTP is redirected to HTTPS, and the API itself is only served over TLS." The page's earlier "refused rather than redirected" line was corrected on 28 October - stock Caddy redirects. | Designed, verified at deploy |
| 2 | Encryption at rest. Whatever the host provides; no application-level encryption is claimed. | The security page states that no application-level encryption at rest is claimed. | Not claimed |
| 3 | Access control. One API key per customer, revocable individually; keys held by the gateway and never in plaintext in the engine or logs. | "API keys are per-customer... Keys are stored hashed, never in plaintext." | Designed |
| 4 | Logging and retention. Request metadata only - timestamp, endpoint, byte counts, status code, key used, referring page for the public site - for 30 days; no request or response content, no client address, no User-Agent. Matches clause 3.4. | "Request metadata never contains content." | Designed |
| 5 | Content retention. Text and generated audio discarded when the request completes. Matches clauses 3.3 and 3.9. | "We do not retain your content." | Designed |
| 6 | Isolation. No per-customer process isolation is claimed. A single inference process serving multiple customers is the expected architecture and is stated as such. | The security page states that requests share one inference process and that no per-customer isolation is claimed. | Not claimed |
| 7 | Sub-processors. Compute: Hetzner Online GmbH (EU). DNS only: Cloudflare, whose records are unproxied. The merchant of record handles billing outside the request path and is not a processor (Annex 2). | "The full sub-processor list is published separately and changes are announced 30 days in advance." | Settled 28 October; the Hetzner datacentre is confirmed at creation |
| 8 | Incident response. Notification to the Controller without undue delay and within 72 hours of awareness (clause 3.8); a written breach runbook. | The security page states the runbook is written and has not yet been exercised end to end. | Written; not yet exercised |
| 9 | Personnel. The service is operated by the LLC's sole member; all access is subject to the confidentiality obligation in clause 3.1. | "The operator's own access is limited to what is needed to run the service." | Designed |
| 10 | Penetration testing and certification. None claimed. No SOC 2, no penetration-test report. | The security page says so explicitly under "What we do not have yet". | Absent, stated |
Two things this annex does not do. It does not describe the measures in more technical detail than the security page, because an annex that outruns the page it implements is a claim without a control behind it. And it does not convert a control that is not yet in place into an unqualified commitment: the status column says what is running and what is not.
Annex 3 - Transfer Impact Assessment
The Transfer Impact Assessment. This annex records where data is processed, the legal instruments that apply, and the safeguards relied on. It describes the architecture rather than a template, so a Controller can assess the transfers for itself.
1. What the transfer actually is. The Controller is an EEA customer; the importer is Sphere Consulting Group LLC, a Wyoming limited liability company. The Services run on a rented server in the European Union (Hetzner Online GmbH, Germany or Finland - deploy/VPS spec.md), with DNS at Cloudflare. The content is therefore processed inside the EEA, but the importer is organised in the United States and its sole member administers the system from India. Both are third countries for GDPR purposes, through different channels.
2. The three channels, kept separate because they need separate analysis.
- (a) The importer is a US entity. Customer Data sits under the control of a US company. Whether US legal process can reach data held on EU infrastructure turns on the CLOUD Act and, for the categories it covers, FISA section 702. No DPF certification is claimed, and no participant record surfaced in a search on 28 October 2026 - so the SCCs plus this assessment are the route.
- (b) Remote administration from India. The operator's access to the system - SSH to the host, the gateway's admin API - is exercised from India. Remote access from a third country is itself a transfer on the EDPB's reading (Guidelines 05/2021), even where the data never leaves the EU. The Indian instruments in play are the Digital Personal Data Protection Act 2023 and the interception and blocking powers under the Information Technology Act 2000, and the Processor treats that channel as a transfer requiring its own safeguards.
- (c) The payment path. The merchant of record handles billing data outside this Service entirely: it is not a processor and sees no content. Any transfer of billing data is covered by the merchant of record's own terms, not by this annex.
3. The measure that does most of the work. Customer Data is not retained after a request completes (clause 3.3). A transfer assessment normally measures the exposure of stored data; here there is none, so compelled or intercepted retrieval would have to happen during the request itself. That does not remove the transfer and is not a substitute for the SCCs - but it is the largest single mitigation and should be described as exactly that, not as an exemption.
4. Supplementary measures already in the design.
- EU hosting - no content at rest outside the EEA.
- TLS terminated on our own host, not at the CDN (Annex 1, row 1).
- Four fewer channels than the usual stack: no analytics, no error tracking, no support platform, no LLM provider in the path.
- Per-customer keys held by the gateway and revocable individually.
- Metadata-only logs, 30 days, no content.
5. The gaps this annex does not close, named rather than implied.
- No DPF certification.
- Government requests. The Processor discloses Customer Data to a public authority only where legally compelled, notifies the Controller before disclosure unless prohibited by law, keeps a record of every request, and publishes the number of requests received and complied with in its annual transparency note. This answers SCC Clause 15.
- The operator is one person in a third country, so the access-control measure is process rather than architecture.
6. Conclusion. The design supports a finding of no routine access and nothing retained: content is not stored, and the residual risk is the administration channel from India, which is documented in section 4 and treated as a transfer with its own safeguards. That is adequate for the read-aloud and back-office workloads these Services target. It is not adequate for special-category data, which the Services do not seek and which the Controller must not submit.