Version v1.0, effective 2026-08-31. The official language of the Terms is English; any translation is provided for convenience only.
KOMASHI — MODULE D(2) · ANNEX 3 (AUTHORIZED SUB-PROCESSORS)
Parent agreement. This Annex forms part of the Komashi Data Processing Agreement (Module D(2)) and is maintained separately from Annexes 1–2 (module-d2-annexes.md) so the sub-processor list can be re-issued on its own cadence. Capitalized terms not defined here have the meanings given in the DPA, Module 0, or the GDPR.
Annex 3 version: v1.0 Annex 3 effective date: 2026-08-31 Also published at: https://komashi.com/legal/subprocessors
Maintenance / amendment. This Annex is maintained under the general authorization in DPA §4.1. Komashi informs Controllers of intended additions or replacements at least 14 days in advance via the list page, email, or the Platform (DPA §4.2), giving the opportunity to object on reasonable data-protection grounds. Each change carries a new version number and effective date, and superseded versions are retained and available on request under Section 4.5 of Module 0.
SCC linkage. This Annex 3 populates SCC Annex III (list of sub-processors). The EU Standard Contractual Clauses under DPA §5.2a are operative, not contingent: Section B contains sub-processors established in or owned from the United States, so Chapter V transfers occur and the SCCs are the mechanism relied on. Adding any further non-EU/EEA sub-processor requires the transfer impact assessment under §5.2a(b) and the §4.2 notice/objection process before the addition takes effect.
Annex 3 — Authorized Sub-processors
General authorization under DPA Section 4.1. Current list maintained at https://komashi.com/legal/subprocessors.
A. Infrastructure
There is no sub-processor in the infrastructure layer at all. Komashi runs the Platform's application, database, storage and log indexing on equipment it owns, at its own premises in the EU/EEA. It rents no compute, hosting, database, or log-analytics service from any provider, and the equipment is not housed in a third-party data centre, so no facility operator has physical access to the machines either. Outbound transactional email is sent from Komashi's own mail servers, so no delivery provider receives recipient names or addresses.
The practical consequences for the Controller are:
(a) no third party holds any account over the Platform's database, logs, or mail — logical or physical;
(b) the logging layer, usually the least-controlled place personal data ends up, does not leave Komashi's own systems; and
(c) the security assurance for this layer is entirely Komashi's own. There is no facility operator's certification to inherit and no hosting provider's audit report to point at, which is why Annex 2 carries the physical-security commitments directly and why DPA Section 3.9(a) is drafted around a documented response rather than a certification. This cuts both ways, and the Controller should read it that way: the CLOUD Act and third-party-access exposure that a rented facility would carry does not arise, but nor is there an external auditor standing behind the physical controls. Annex 2 therefore states those controls directly — including the one that is not in place, so that the position can be assessed rather than assumed.
The sub-processors in Section B are therefore application-level services only — invoicing, AI, sign-in and analytics, and payment-side verification. None of them holds Controller Data at rest on Komashi's behalf as a matter of infrastructure.
B. Sub-processors
The "Controller Data" column states what actually leaves Komashi's own systems. Nothing beyond the categories listed reaches the recipient.
| # | Sub-processor (legal name) | Service | Controller Data received | Processing location | Owner / parent jurisdiction | Transfer mechanism |
|---|---|---|---|---|---|---|
| 1 | Billingo Technologies Zrt. (Hungary) | Issuance and delivery of invoices through the Platform | Billing name, address, tax identifier, email address, invoice line items and the other data required to issue the invoice | Hungary | EU | None — EU/EEA-located |
| 2 | KBOSS.hu Kft. ("Számlázz.hu", Hungary) | Issuance and delivery of invoices through the Platform | Billing name, address, tax identifier, email address, invoice line items and the other data required to issue the invoice | Hungary | EU | None — EU/EEA-located |
| 3 | OpenRouter, Inc. (United States) | Routing of requests to AI models where an AI feature is enabled. OpenRouter is a router: the model provider it routes to also receives the request, as OpenRouter's own sub-processor (Section D(d)) | Service names and descriptions, support questions and the content of support tickets, and other free text submitted to an AI feature — which can and does contain End User personal data | United States, and the country of the model provider routed to | United States | SCCs (Section D) |
| 4 | Google Ireland Limited / Google LLC | (i) Google Sign-In where a user chooses it; (ii) web analytics operated on Komashi's own account | (i) Name, email address, Google account identifier; (ii) IP address, device and browser data, usage and event data | Ireland; United States | United States | SCCs (Section D) |
| 5 | Stripe Payments Europe, Limited / Stripe, Inc. — only to the extent Stripe acts as processor | Provider onboarding and verification carried out on Komashi's instruction. For the payment transaction itself Stripe is an independent controller — see Section C | Name, email address, billing data and the personal data required for Provider verification / KYC | Ireland; United States | United States | SCCs (Section D) |
This list is complete. It contains no hosting, data-centre, or email-delivery entry because those functions are performed by Komashi on its own equipment (Section A) — an unusually short list for a platform of this kind, and a deliberate one.
C. Parties that are not sub-processors, and why
Listing these is deliberate: a Controller's counsel will look for them, and each is excluded for a stated reason rather than by omission.
| Party | Why it is not a sub-processor of Controller Data |
|---|---|
| Barion Payment Zrt. · Mollie B.V. · Stripe (payment leg) | Each acts as an independent controller for the payment data it processes, determining its own purposes and means under its own licence and regulatory obligations (Privacy Policy Section 5.1(c)). They are not engaged by Komashi to process Controller Data on its instructions, are not subject to the Section 4.2 objection right, and Komashi receives no End User funds, card numbers, or payment credentials (Provider Terms Section 4.1a). Stripe additionally appears in Section B for the separate onboarding and verification processing it carries out on Komashi's instruction — the two roles are distinct and are not interchangeable |
| Web analytics a Provider configures on its own account | Where the Provider switches on Google Analytics or Microsoft Clarity for its own presence, on its own account and under its own legal basis and consent collection (Provider Terms Section 6.7), that processing is the Provider's, not Komashi's. This is separate from the analytics Komashi operates on its own account, which is in Section B, row 4(ii) |
| Exchange-rate data source | Provides reference rates only. No personal data is transmitted to it (Module F Section 4.2) |
D. Third-country transfers
Rows 3, 4 and 5 of Section B are established in or owned from the United States, and the categories of Controller Data stated in those rows are therefore transferred to a third country within the meaning of Chapter V GDPR. Those transfers are made under the EU Standard Contractual Clauses, on the terms set out in DPA Section 5.2a, and are covered by the transfer impact assessment required by DPA Section 5.2a(b).
(a) Why the SCCs and not an adequacy decision. Some of these recipients are, or may become, certified under the EU–US Data Privacy Framework. Komashi nevertheless relies on the SCCs as the primary mechanism for every US transfer. The reason is resilience rather than caution: an adequacy decision can be annulled or suspended, and a package that depended on one would lose its transfer basis overnight. Where a recipient is DPF-certified, that certification operates as an additional safeguard, not as the basis relied on.
(b) Data minimisation as a supplementary measure. The "Controller Data received" column in Section B is not descriptive — it is a limit. Only the categories stated there leave the EU/EEA, and this is the principal supplementary measure recorded in the transfer impact assessment.
(c) Adding a sub-processor. Adding any sub-processor outside the EU/EEA, or any EU/EEA sub-processor under non-EU/EEA ownership, requires the transfer impact assessment in DPA Section 5.2a(b) and the notice-and-objection process in DPA Section 4.2 to be completed before the addition takes effect.
(d) Onward transfer in the AI routing chain. Row 3 is a routing service, not a model operator: the request is passed to a downstream model provider, which receives the same text as OpenRouter's own sub-processor. Two consequences follow and are treated as binding on Komashi. First, the set of models a feature may route to is part of the sub-processor position, not a free configuration choice — enabling a model whose provider sits in a further third country, or which does not accept the no-training commitment, is a change to this Annex and requires the Section 4.2 process. Second, the "no use for the recipient's own purposes, including model training" commitment in DPA Section 5.2a(c) must hold down the whole chain, not only at the router; Komashi configures the routing so that upstream providers which reserve training rights are not used for Controller Data.
(e) No UAE transfer. No Controller Data is transferred to, stored in, or accessible from the United Arab Emirates, notwithstanding Komashi's registration there (DPA Section 5.2).