Data Processing Addendum

Draft prepared on 2026-10-06 for review by counsel. This is a template, not legal advice, and no attorney has reviewed it. Points needing the owner's decision are marked [DECISION: …]; points needing an attorney's judgment are marked [COUNSEL: …]. Product facts were verified in the repository at commit 85967208 (working tree of 2026-10-06); the Privacy Policy and the Security document describe the products in more detail.

This Data Processing Addendum ("DPA") forms part of the agreement under which Varrock Inc., a Delaware corporation (Delaware file number 10482601) ("Varrock"), provides OasisGUI and OasisNet to the customer identified in Section 9 ("Customer"; together the "Parties"). This DPA is offered to Customers that use the Products in the course of a trade, business or profession; it is not offered to consumers. The underlying agreement is the Business License Agreement, the End User License Agreement or any other written agreement for the Products that references this DPA (the "Agreement"). [DECISION: which agreement this DPA attaches to; the business license is offered by email and is not yet defined]

1. Definitions#

1.1 "Data Protection Laws" means all laws applying to the Processing under this DPA, including, where applicable, Regulation (EU) 2016/679 ("GDPR"), the UK GDPR with the Data Protection Act 2018, the Swiss Federal Act on Data Protection ("FADP"), and applicable US state privacy laws (see Section 6A).

1.2 "Personal Data", "Controller", "Processor", "Data Subject", "Processing", "Personal Data Breach" and "Supervisory Authority" have their GDPR meanings, read across to other Data Protection Laws.

1.3 "Customer Personal Data" means Personal Data of which Customer is the Controller (or Processor for its own customers) and which Varrock Processes on Customer's behalf. Section 2 states what this is in practice.

1.4 "Products" means the OasisGUI desktop application for macOS, Linux and Windows, the oasis-runner per-host daemon, the oasisnet mesh daemon with its coordinator and relay roles, the bundled virtual-machine helpers, and Oasis Mobile [DECISION: confirm Oasis Mobile is distributed to customers and by which channel (TestFlight / App Store); the repository records no customer release — docs/enterprise/00-overview.md, OasisMobile/TESTFLIGHT.md is a how-to, not a release record].

1.5 "Customer Infrastructure" means every machine, virtual machine, mesh coordinator, relay, chat relay and push gateway that Customer or its users install, operate or control.

1.6 "Varrock Infrastructure" means the systems operated by or for Varrock: the website oasisgui.com (including /downloads/, the update manifest latest.json and the enterprise documentation portal under /docs/ with its account database — the "Portal"), the binary download host start.oasis.cooking used by the NixOS virtual-machine templates, and, if and when enabled, the mobile push gateway at push.oasis.cooking.

1.7 "SCCs" means the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914, Module Two (controller to processor), as applied in Section 6.

1.8 "Subprocessor" means a third party engaged by Varrock to Process Customer Personal Data on Varrock's behalf.

2. Scope: what Varrock does and does not process#

2.1 Self-hosted architecture. The Products run on Customer Infrastructure: mesh coordinators, relays, chat relays, oasis-runner daemons, virtual machines, agent sessions, transcripts, backups and the mail server all run on machines Customer controls. The desktop application ships with no built-in coordinator (src-tauri/src/mesh_manager/mesh_config.rs); Customer points it at a coordinator Customer stands up. The Products have no accounts, no telemetry, no analytics and no crash reporting, and Varrock has no administrative access to Customer Infrastructure. In the normal operation of the Products, Varrock does not receive, store or otherwise Process any Customer Personal Data on Customer's behalf, and nothing on Customer Infrastructure reports operational or personal data to Varrock. The only connections from Customer Infrastructure to Varrock Infrastructure are the three flows in Section 2.2(a)–(c), for which Varrock is an independent Controller, and the push flow in Section 2.3, which is the sole subject of Sections 4 to 7. Separately from the Products, Customer's personnel may hold accounts on the Portal (Section 2.2(d)); Varrock is the Controller of those accounts.

2.2 Varrock's own Processing (as Controller, outside this DPA). Four flows reach Varrock Infrastructure; for all four Varrock is an independent Controller, not Customer's Processor:

(a) Update check. At launch and, unless the user disables the periodic check, every ten minutes, the desktop application sends an HTTP GET for https://oasisgui.com/downloads/latest.json. The request carries only the updater library's defaults (an Accept header and the User-Agent string tauri-plugin-updater/2.10.1); it carries no installed version, operating system, machine identifier or user identifier (src-tauri/tauri.conf.json; src/UpdatePrompt.tsx; src/updater.ts). Downloading an installer is a second request to the same host. The server observes the connecting IP address, the user agent and the time. Installations managed by Nix make no update check.

(b) Website and download logs. The web server for oasisgui.com does not log requests for installer artifacts or the update manifest at the application layer (deploy/k8s/oasisgui.yaml: access_log off for those extensions). Page requests may be recorded in ordinary web-server access logs (IP address, user agent, URL, referrer, time). The logging policy of the TLS-terminating front proxy is not in the repository. [DECISION: state the actual front-proxy access-log setting and retention period for oasisgui.com]

(c) NixOS template build. When Customer builds the inference NixOS virtual-machine template on a Nix host, the build fetches the pinned oasisnet binary from https://start.oasis.cooking/oasisnet as a hash-verified fixed-output derivation (nix/vm-templates/lib/mesh.nix, embedded in the application by src-tauri/src/vm_templates.rs), unless that binary is already present in the host's Nix store. The server observes the building host's IP address, user agent and time. No other data is sent. The other shipped templates do not import this module.

(d) Documentation portal accounts. The enterprise documentation on oasisgui.com/docs/ is restricted to approved enterprise customers. A member of Customer's personnel who wants to read it creates an account on the Portal (email address, name, password stored as an Argon2id hash), creates or joins a tenant record for Customer (company name, web domain, optional message), and Varrock's administrators approve or reject that tenant by hand, recording a note. The Portal keeps a session record (a keyed hash of the sign-in token carried by the strictly necessary cookie oasis_portal_session — 30 days, 7 days idle; the cookie is first set, anonymously and for the browser session only, when the sign-in page is opened, and nothing is stored about it until sign-in), each account's membership status in the tenant (a colleague joins by a join code that only the tenant's owner sees and is confirmed as a member by that owner or by Varrock; the owner can remove members and replace the code), an audit log of sign-ins, sign-ups, sign-outs, failed sign-ins against existing accounts (once per account and 15-minute window), tenant and membership events and administrator actions with the requesting IP address and time (180 days, at most 200 000 lines), per-IP counters of failed or rejected requests (7 days), and short-lived per-IP and per-email rate-limit counters. Administrator accounts are created only from Varrock's command line; signing up with an administrator's address is refused. No email is sent and addresses are not verified; administrators judge each sign-up from the data entered. Varrock determines the purposes and means of this Processing — deciding whom to admit to its own documentation and securing its own site — and is its Controller; the Privacy Policy, Section 5.7, is the notice to the individuals concerned. Customer does not instruct Varrock in this Processing and is not its Controller, although Customer may ask Varrock, on its personnel's behalf, to delete the tenant and the accounts of people who have left [DECISION: whether a departing employee's account is deleted on Customer's request alone, on the employee's request alone, or either — the Portal has no self-service deletion in its first version]. [COUNSEL: confirm that vendor-portal accounts held by Customer's employees are Varrock's independent controller processing (the usual position for supplier portals) rather than joint control with Customer, given that Customer's tenant owner creates the company record and that approval is tied to Customer's status as a customer; if Customer insists on a controller-to-controller clause, add one rather than extending Sections 4–7.] (Verified against portal/src/ on 2026-10-06, same change set; the Privacy Policy, Section 20, 22e, lists the files.)

These flows are disclosed to end users in the Privacy Policy. They are not Processing "on behalf of" Customer within Article 28 GDPR, and Sections 4 to 7 do not apply to them. [COUNSEL: confirm that the update check, web logs, template-build download and the Portal accounts are Varrock's own controller processing and need no Article 28 terms]

2.3 The only candidate Processor activity: the mobile push gateway. Oasis Mobile defaults to the Varrock-operated gateway https://push.oasis.cooking for push notifications to Apple devices (OasisMobile/Oasis/Notifications/NotificationModel.swift, NotificationPrefs.defaultGatewayURL) and tells each of Customer's oasis-runner daemons which gateway to use when a phone registers (runner/oasis-runner/src/notify/mod.rs, validate_device); the runner itself has no built-in gateway and stores the URL per registered device. When a user of Customer enables mobile notifications, Customer's runners send each notification to the gateway the phone named, which forwards it to the Apple Push Notification service ("APNs") and stores nothing (push/README.md). As at the date of this draft the push feature is not operational: no APNs key has been provisioned, the deployment procedure refuses to deploy the gateway without one (push/deploy/deploy.sh), and a gateway running without a key answers every push with HTTP 503 (apns_not_configured); accordingly no notification data reaches Varrock Infrastructure. [DECISION: confirm whether any gateway is currently deployed at push.oasis.cooking] Customer may point its devices at a gateway Customer hosts. Varrock shall give Customer advance notice before first enabling the gateway for production use (Section 4.11). Sections 4 to 7 and Annexes I to III apply only to this push flow and only from the date Varrock enables it. [DECISION: whether push.oasis.cooking goes live as the shipped default or the product documents self-hosting only; if the latter, Sections 4–7 and the Annexes can be deleted and this DPA reduces to Section 2]

2.4 Third-party services engaged by Customer's users. The Products can contact third-party services with credentials or at the direction of Customer's users (for example Anthropic, OpenRouter, ElevenLabs, Customer's S3-compatible storage, VM image mirrors, and the geolocation service api.country.is, which the Mesh view queries with mesh peers' public endpoint IP addresses). Varrock receives no data from those exchanges; Customer holds its own agreements with those providers. [COUNSEL: wording for user-directed third-party services as independent controllers rather than Subprocessors] [DECISION: api.country.is runs without an off switch and sends peer IP addresses; keep and disclose, gate behind a setting, or remove before this DPA is offered]

3. Roles of the Parties#

3.1 For the Processing in Section 2.3, Customer is the Controller (or, where Customer acts for its own customers, a Processor) and Varrock is Customer's Processor.

3.2 Customer warrants that it has a lawful basis for the Processing, has given Data Subjects any required notice, and that its instructions comply with Data Protection Laws. Each Party is responsible for its own compliance as a Controller.

4. Processor obligations#

4.1 Instructions. Varrock shall Process Customer Personal Data only on Customer's documented instructions, including as to third-country transfers, unless Union or Member State law to which Varrock is subject requires otherwise, in which case it shall inform Customer beforehand unless that law prohibits it on important grounds of public interest; requests under the law of a third country are handled under Section 4.10 and Clause 15 of the SCCs. This DPA, the Agreement and the user's act of enabling mobile notifications are Customer's complete instructions. Varrock shall inform Customer if an instruction, in its opinion, infringes Data Protection Laws. [COUNSEL: scope of the legal-compulsion carve-out for a US processor — Article 28(3)(a) and SCC Clause 8.1 permit deviation only for Union or Member State law; US-law demands fall under Clause 15]

4.2 Confidentiality. Varrock shall ensure that every person it authorises to Process Customer Personal Data is bound by a contractual or statutory obligation of confidentiality.

4.3 Security. Varrock shall implement the measures in Annex II and such further measures as are appropriate to the risk under Article 32 GDPR.

4.4 Subprocessors. Customer gives general written authorisation to the Subprocessors in Annex III. Varrock shall give at least thirty (30) days' prior notice of any intended addition or replacement [DECISION: notice channel — a page on oasisgui.com, email, or both]. Customer may object on reasonable data-protection grounds within that period; if the objection is not resolved in good faith within a further thirty (30) days, Customer may end the affected Processing without penalty (in practice by pointing its devices at a self-hosted gateway or disabling mobile notifications). Where a Subprocessor must be replaced urgently to keep the service secure or available, Varrock may make the change first and give notice as soon as practicable with the reason; Customer's objection right applies from that notice. [COUNSEL: acceptability of the emergency-replacement carve-out under Article 28(2); it mirrors §9.4 of the Subprocessor list] Varrock shall impose on each Subprocessor, by written contract, obligations no less protective than this DPA and remains liable for the Subprocessor's performance.

4.5 Assistance. Taking into account the nature of the Processing, Varrock shall assist Customer, insofar as possible, in responding to Data Subject requests and in meeting Customer's obligations under Articles 32 to 36 GDPR, taking into account the information available to Varrock. Because the gateway stores no data, Varrock will normally be unable to retrieve, correct or delete any specific Data Subject's Personal Data and will confirm this in writing on request. [DECISION: whether assistance beyond a reasonable amount is chargeable]

4.6 Personal Data Breach. Varrock shall notify Customer without undue delay after becoming aware of a Personal Data Breach affecting Customer Personal Data, and in any event within [DECISION: 24 / 48 hours — note Customer's own 72-hour deadline under Article 33(1) runs from Customer's awareness, so the Varrock deadline should be materially shorter than 72 hours] hours, giving the information reasonably available at the time and supplementing it as it becomes available. [DECISION: breach-notification mailbox]

4.7 Deletion and return. The push gateway retains no Customer Personal Data after forwarding a notification, so nothing remains to be returned. On termination of the Processing, Varrock shall delete any Customer Personal Data that nevertheless exists in its possession (for example in operational logs) within [DECISION: 30] days unless law requires longer storage, and shall certify deletion on request.

4.8 Audits. Varrock shall make available all information necessary to demonstrate compliance with Article 28 GDPR and shall allow for and contribute to audits, including inspections, by Customer or an auditor it mandates. Varrock may first answer with its published security description (the Security and Enterprise readiness documents) and the gateway source in push/, provided on request under the confidentiality undertakings below; it holds no third-party certification or audit report and this DPA claims none. Inspections occur at most once per twelve (12) months unless a Supervisory Authority requires otherwise or a Personal Data Breach has occurred, on thirty (30) days' notice, in business hours, under reasonable confidentiality undertakings. [DECISION: whether inspections are at Customer's cost]

4.9 Records. Varrock shall keep the record of Processing required by Article 30(2) GDPR.

4.10 Requests from Data Subjects and authorities. Varrock shall, to the extent permitted by law, forward any Data Subject or Supervisory Authority request concerning Customer Personal Data to Customer without undue delay and not otherwise respond; for a legally binding public-authority access request it shall notify Customer, challenge the request where there are reasonable grounds, and disclose only the minimum required.

4.11 Go-live notice. Varrock shall give Customer at least thirty (30) days' written notice, through the channel in Section 4.4, before it first enables the gateway at push.oasis.cooking for production use. That notice is also the Section 4.4 notice for the Subprocessors in Annex III marked conditional, and Customer may object or opt out under Section 4.4 (including by disabling mobile notifications or pointing its devices at a self-hosted gateway) before the Processing begins. This matches the "promotion of a conditional entry to active" event in §9.2 of the Subprocessor list.

5. Customer obligations#

5.1 Customer is responsible for the configuration and security of Customer Infrastructure and for the content of notifications its runners send; a notification body contains the cleaned last lines of a terminal pane, which may include whatever an agent printed.

5.2 Customer acknowledges that the Products are not designed to Process special categories of Personal Data (Article 9 GDPR), criminal-conviction data or children's data, that a notification body is an unfiltered excerpt of terminal output (the last three readable lines, at most 240 characters, with only decoration stripped — runner/oasis-runner/src/notify/tail.rs), and that the controls in Annex II.10 are the means to keep such data out of the push flow. Customer shall not knowingly direct such data to Varrock. [COUNSEL: risk allocation for incidental special-category content in agent output; the product has no content filter, so Customer cannot warrant its absence]

6. International transfers#

6.1 Varrock is established in the United States. The Processing in Section 2.3 takes place on Varrock Infrastructure [DECISION: location and provider of the host behind oasis.cooking; not named in the repository] and at Apple's APNs service.

6.2 To the extent the Processing involves a transfer of Personal Data subject to the GDPR from Customer (data exporter) to Varrock (data importer), the Parties enter into the SCCs, Module Two, incorporated by reference and completed as follows: Clause 7 (docking) applies; Clause 9 option 2 (general written authorisation) applies with the notice period in Section 4.4; the optional language in Clause 11(a) does not apply; Clause 13 applies according to the data exporter's establishment; Clause 17 governing law and Clause 18 forum are [COUNSEL: choose an EU Member State whose law allows third-party beneficiary rights; Ireland is customary — the Delaware law of the Agreement cannot govern the SCCs]; SCC Annex I.A and I.B are completed by Annex I of this DPA; Annex I.C is the Supervisory Authority of the exporter's Member State; SCC Annexes II and III are Annexes II and III of this DPA. [COUNSEL: confirm Module Two is right where Customer is itself a Processor for its own customers — Module Three may be required]

6.3 United Kingdom. For transfers subject to the UK GDPR, the SCCs apply as amended by the International Data Transfer Addendum issued by the Information Commissioner (version B1.0, in force 21 March 2022), Tables 1 to 3 completed by this DPA and Table 4 allowing either Party to end the Addendum when it is revised. [COUNSEL: confirm the UK Addendum is wanted]

6.4 Switzerland. For transfers subject to the FADP, the SCCs apply with the Federal Data Protection and Information Commissioner as competent authority, references to the GDPR read as references to the FADP, and "Member State" read so as not to exclude Swiss Data Subjects from enforcing their rights in Switzerland. [COUNSEL: confirm Swiss wording]

6.5 Transfer impact. The Parties have considered the matters in Clause 14 of the SCCs, and Varrock shall document that assessment and make it available to Customer on request and to the competent Supervisory Authority as Clause 14 requires. Varrock represents that, as at signature, it has received no public-authority request for access to Customer Personal Data, and shall notify Customer under Section 4.10 and Clause 15 of the SCCs if that changes. Varrock does not claim certification under the EU-U.S. Data Privacy Framework. [COUNSEL: Clause 14 assessment for a US-hosted gateway — FISA 702 / EO 12333 exposure, whether Varrock qualifies as an electronic communication service provider under 50 U.S.C. §1881(b)(4), and the content of the written transfer impact assessment] [DECISION: whether to self-certify under the DPF; never claim it until done]

6.6 Onward transfers. Apple's APNs service receives notification data under Apple's developer terms. [COUNSEL: whether Apple APNs is a Subprocessor under SCC Clause 9 or an independent service under the Apple Developer Program License Agreement]

6A. United States state privacy laws#

6A.1 To the extent a US state privacy law applies to Customer Personal Data, Varrock acts as Customer's service provider, processor or contractor (as those terms are defined in the applicable law). Varrock shall not sell or share Customer Personal Data; shall not retain, use or disclose it for any purpose other than the business purpose described in Annex I, or outside the direct business relationship with Customer; and shall not combine it with Personal Data it receives from other sources except as the applicable law permits. Varrock shall notify Customer if it determines it can no longer meet these obligations, and Customer may take reasonable and appropriate steps to stop and remediate unauthorised use of Customer Personal Data. Varrock certifies that it understands these restrictions and will comply with them.

6A.2 [COUNSEL: confirm the clause tracks Cal. Civ. Code §1798.100(d) and §1798.140(ag)(1), 11 CCR §7051, Va. Code §59.1-579(B), Colo. Rev. Stat. §6-1-1305(5) and the parallel state statutes; whether Varrock also needs to grant the assessment right in 11 CCR §7051(a)(8) and the deletion/subcontractor flow-down terms those statutes require; whether Section 4 already satisfies them]

7. Liability#

7.1 Each Party's liability arising out of this DPA, under any theory, is subject to the exclusions and limitations of liability in the Agreement, and this DPA does not add to the aggregate cap there. [COUNSEL: confirm the cap wording works alongside SCC Clause 12, which cannot be limited against Data Subjects] [DECISION: the EULA cap is the greater of fees paid and USD 50 — zero fees for the free download (eula.md §13.2); decide whether the Business License Agreement carries a separate data-protection liability cap (commonly 1–2× annual fees or a fixed floor) and whether this DPA should reference it]

7.2 Nothing in this DPA limits either Party's liability to Data Subjects under Clause 12 of the SCCs or to the extent liability cannot be limited under Data Protection Laws.

7.3 Where both Parties are involved in the same Processing and are responsible for damage, each may be held liable to the Data Subject for the entire damage (Article 82(4) GDPR). As between the Parties, the Party that has paid full compensation may claim back from the other the part corresponding to the other Party's share of responsibility (Article 82(5) GDPR), subject to Section 7.1. [COUNSEL: whether the inter-party recourse should itself be capped]

8. Term, precedence and governing law#

8.1 This DPA takes effect on signature. Sections 4 to 7 and the Annexes apply from the date Varrock first Processes Customer Personal Data under Section 2.3, which Varrock shall announce in advance under Section 4.11, and continue for as long as that Processing lasts.

8.2 In case of conflict, the following prevail in the order listed, the first listed prevailing over all later ones: (a) the SCCs (with the UK Addendum and Swiss amendments where they apply); (b) this DPA; (c) the Agreement; (d) the Privacy Policy, which is a notice to end users and creates no obligations between the Parties.

8.3 Except for the SCCs (Section 6.2), this DPA is governed by the laws of the State of Delaware, without prejudice to mandatory provisions of Data Protection Laws. The courts of the State of Delaware have exclusive jurisdiction over disputes between the Parties under this DPA, without prejudice to Clause 18 of the SCCs, to Data Subjects' rights under Clause 12 of the SCCs, and to the right of a Supervisory Authority to act. [COUNSEL: Delaware law and venue for the DPA body alongside Member-State law and forum for the SCCs; interaction with the Agreement's forum once one exists — eula.md §19.2 has none drafted; Brussels I bis exposure toward EU Customers]

8.4 Varrock may update Annex II from time to time provided the overall level of protection is not reduced, giving notice through the channel in Section 4.4; changes to Annex III follow Section 4.4. If the European Commission, the Information Commissioner or the Federal Data Protection and Information Commissioner adopts replacement or amended standard clauses, the Parties shall adopt them in place of Section 6 without further signature, and Varrock may publish the completed replacement with notice. Where a change in Data Protection Laws requires it, the Parties shall negotiate in good faith an amendment to this DPA. Any other amendment must be in writing, signed by both Parties.

9. Signatures#

Varrock Inc. Registered agent: LegalInc Corporate Services Inc., 131 Continental Drive, Suite 305, Newark, DE 19713, USA [DECISION: a business address for notices other than the registered agent is not known; add one if it exists] Signature / Name / Title / Date: ______________________ Notices under this DPA: [DECISION: contact mailbox — only sales@oasisgui.com exists today; do not use it for breach notices unless the owner decides so]

Customer Legal name and address: ______________________ Signature / Name / Title / Date: ______________________ Contact for data-protection notices: ______________________ Data Protection Officer or EU representative, if any: ______________________


Annex I: Description of the Processing#

Completes SCC Annex I.A and I.B. Applies only to the push flow of Section 2.3 and only once it is live.

A. Parties. Data exporter: Customer (Section 9), as Controller. Data importer: Varrock Inc. (Section 9), as Processor.

B. Description of the transfer.

Item Description
Subject matter Forwarding of push notifications from Customer's oasis-runner daemons to Apple devices used by Customer's personnel, via push.oasis.cooking.
Duration While a user of Customer keeps mobile notifications enabled against the Varrock gateway; ends when the user disables notifications, points the device at a self-hosted gateway, or the Agreement terminates.
Nature Receipt over HTTPS, validation, in-memory rate limiting per device token, immediate forwarding to APNs; one request per notification event; no storage.
Purpose Delivery of session-state alerts (for example "agent waiting") and update notices to the user's phone, at the user's request.
Categories of Personal Data Apple device push token; APNs environment and bundle topic; notification title and body, the body being a cleaned terminal-pane tail of up to 240 characters that may contain any text an agent printed; session name; hostname of the originating machine; an opaque server reference chosen by the device (client_ref), which also appears inside the thread and collapse identifiers together with the session name; event class, level, id and timestamp; and, at the transport layer, the IP address of the sending runner as seen by the front proxy (runner/oasis-runner/src/notify/push.rs, build_request). The device's user-chosen name is held on Customer Infrastructure only (the runner's device registry) and is not sent to the gateway.
Special categories None intended; incidental content in a pane tail cannot be excluded by design (Section 5.2).
Data Subjects Customer's personnel and contractors who use Oasis Mobile; incidentally, any person named in a pane tail.
Retention by the importer None at the application layer. Gateway logs record only the last six hexadecimal characters of a device token (push/README.md). Web-server access logs: [DECISION: access-log retention for push.oasis.cooking — push/deploy/nginx-push.conf has no explicit access_log directive].
Onward transfers Apple Inc. (APNs), United States, for delivery to the device.

C. Competent Supervisory Authority. The authority of the Member State in which the data exporter is established.

Annex II: Technical and organisational measures#

Completes SCC Annex II. Only measures the repository documents are listed. Varrock holds no SOC 2, ISO 27001 or similar certification.

  1. Transport encryption. HTTPS only (runners reject non-HTTPS gateway URLs other than loopback); delivery to APNs over HTTP/2 TLS with an ES256 provider token (push/README.md).
  2. No persistence. Stateless gateway: no database, accounts or queue; each notification is forwarded and discarded; rate limiting in memory only.
  3. Log minimisation. Device tokens appear in gateway logs truncated to their last six hexadecimal characters.
  4. Access control. The gateway runs as a container in a Varrock-controlled Kubernetes namespace (push/deploy/); administrative access is by SSH key. [DECISION: who holds administrative access, how keys are managed, whether MFA applies]
  5. Key management. The gateway holds at most two secrets: the APNs authentication key (.p8), mounted from a Kubernetes Secret, and an optional shared bearer token that gates /v1/push (push/deploy/k8s.yaml; push/README.md, Environment table). Neither is in the repository; the key is streamed to the cluster at deploy time and never written to the host's disk (push/deploy/deploy.sh). [DECISION: where the key is stored and who can rotate it]
  6. Availability. [DECISION: no SLA exists; state "best effort, no availability commitment" or define one]
  7. Self-hosting. The gateway source and deployment material are in Varrock's source repository (push/) and can be made available to Customer for review or self-hosting. [DECISION: whether the push/ source is published or provided on request — the repository is not publicly readable today] [DECISION: self-hosting the gateway is not yet documented as a supported procedure (docs/enterprise/05-operations.md)]
  8. Incident response. Personal Data Breaches are handled under Section 4.6; vulnerability reports under the Vulnerability Disclosure Policy. [DECISION: no published security contact exists yet; add once the security mailbox exists]
  9. Personnel. [DECISION: confirm which persons have access and that they are bound by confidentiality; do not state a headcount]
  10. Customer-side controls. Customer may disable notifications per device, restrict the classes sent, or host its own gateway, removing Varrock from the flow entirely.

Annex III: Subprocessors#

Completes SCC Annex III. The Subprocessor list is the public register; in case of conflict this Annex prevails for Customer. Applies only to the push flow unless a conditional row is activated under Section 4.4. The hosting provider of Varrock Infrastructure is not named in the repository and must not be invented.

Subprocessor Purpose Location Status
Apple Inc. (Apple Push Notification service) Delivery of notifications to iOS devices United States Conditional — engaged only once the APNs key is provisioned and the Section 4.11 notice has been given [COUNSEL: Subprocessor or independent service — Section 6.6]
Hosting provider of oasis.cooking Runs the gateway container and the TLS-terminating front proxy [DECISION: provider name and country] Conditional — as above [DECISION: confirm and name]
Hosting provider of any coordinator or relay Varrock offers to Customer — currently Worldstream B.V., Netherlands, for the host relic (nix/hosts/relic/configuration.nix) Coordinator: peer table (public keys, mesh and endpoint IP addresses, host names). Relay: forwarding of WireGuard-encrypted packets it cannot read Netherlands Conditional [DECISION: only if hosted coordinators or relays are offered to Customers; today these hosts serve Varrock's own mesh and a fresh install ships no coordinator. If they are never offered, delete this row]

No other Subprocessor is engaged. If Varrock offers a hosted coordinator or relay to Customer, that Processing must also be added to Section 2.3 and Annex I before it begins. [DECISION: confirm whether Varrock offers hosted coordinators or relays to customers]


Open decisions#

Every marker in this document, collected for grepping.

Owner decisions [DECISION]

  1. Which agreement this DPA attaches to; the business license is undefined (Preamble).
  2. Confirm Oasis Mobile is distributed to customers and by which channel (§1.4).
  3. Front-proxy access-log setting and retention for oasisgui.com (§2.2(b)). 3a. Whether a departing employee's Portal account is deleted on Customer's request, the employee's request, or either (§2.2(d)). 3b. Resolved 2026-10-06: §2.2(d) verified against portal/src/ (§2.2(d)).
  4. Confirm whether any gateway is currently deployed at push.oasis.cooking (§2.3).
  5. Whether push.oasis.cooking goes live as the shipped default or self-hosting only; if the latter, §§4–7 and the Annexes fall away (§2.3).
  6. api.country.is sends mesh peers' IP addresses with no off switch: keep and disclose, gate, or remove (§2.4).
  7. Subprocessor-change and go-live notice channel (§4.4, §4.11).
  8. Whether assistance beyond a reasonable amount is chargeable (§4.5).
  9. Breach-notification deadline (24 or 48 hours; not 72) and mailbox (§4.6).
  10. Deletion period after termination (§4.7).
  11. Whether inspections are at Customer's cost (§4.8).
  12. Location and provider of the host behind oasis.cooking (§6.1, Annex III).
  13. Whether to self-certify under the EU-U.S. Data Privacy Framework (§6.5).
  14. Whether the Business License Agreement carries a separate data-protection liability cap, and whether this DPA references it (§7.1).
  15. A business address for notices other than the registered agent (§9).
  16. Contact mailbox for notices; only sales@oasisgui.com exists today (§9).
  17. Access-log retention for push.oasis.cooking (Annex I).
  18. Administrative access, key management and MFA on the gateway host (Annex II.4).
  19. Where the APNs key is stored and who can rotate it (Annex II.5).
  20. Availability commitment: none, or define one (Annex II.6).
  21. Whether the push/ source is published or provided on request (Annex II.7).
  22. Document self-hosting the gateway as a supported procedure (Annex II.7).
  23. Security contact mailbox (Annex II.8).
  24. Which persons have access; their confidentiality obligations (Annex II.9).
  25. Whether hosted coordinators or relays (Worldstream B.V., host relic) are offered to customers; if never, delete the row (Annex III).

Counsel questions [COUNSEL]

  1. Update check, web logs, template-build download and Portal accounts as Varrock's own controller processing, outside Article 28 (§2.2). 1a. Vendor-portal accounts of Customer's employees as Varrock's independent controller processing rather than joint control; whether a controller-to-controller clause is wanted (§2.2(d)).
  2. Wording for user-directed third-party services as independent controllers (§2.4).
  3. Scope of the legal-compulsion carve-out for a US processor (§4.1).
  4. Acceptability of the emergency Subprocessor-replacement carve-out under Article 28(2) (§4.4).
  5. Risk allocation for incidental special-category content in agent output (§5.2).
  6. SCC Clause 17/18 governing law and forum: an EU Member State, not Delaware (§6.2).
  7. Whether Module Three is needed where Customer is itself a Processor (§6.2).
  8. Whether the UK Addendum is wanted (§6.3).
  9. Swiss wording (§6.4).
  10. Clause 14 transfer impact assessment for a US-hosted gateway: FISA 702 / EO 12333, electronic-communication-service-provider status, content of the written assessment (§6.5).
  11. Apple APNs as Subprocessor under SCC Clause 9 or independent service under Apple's developer terms (§6.6, Annex III).
  12. Whether Section 6A tracks the CCPA/CPRA regulations and the parallel state statutes, and whether the assessment right and other flow-down terms are needed (§6A).
  13. Liability cap wording alongside SCC Clause 12 (§7.1).
  14. Whether the inter-party recourse under Article 82(5) should itself be capped (§7.3).
  15. Delaware law and venue for the DPA body alongside Member-State law and forum for the SCCs; interaction with the Agreement's forum; Brussels I bis exposure (§8.3).

Sibling documents to align (not edited here)

  • subprocessors.md §9.3 should adopt the thirty-day notice period this DPA fixes in §4.4, and its §9.2 go-live event now has a counterpart in §4.11.
  • privacy-policy.md §6.3 agrees with Annex I that the device name stays on Customer's machines; it should also mention the server reference (client_ref) and the event class and level if it is meant to list every field.
  • terms-of-service.md §5.2 and §12 state that the Site has no user accounts; now that the Portal ships they must carve out the documentation portal and point to Privacy Policy §5.7 — Terms owner. Until then the Portal's sign-up form does not ask for agreement to the Terms; it links only the Privacy Policy and the Cookie Statement (portal/src/views/pages.ts, signupForm).
  • subprocessors.md row B1 (hosting provider of oasis.cooking) should add the Portal and its account database to the "what it holds" column; no new Subprocessor is introduced because the Portal runs on the same host — Subprocessor-list owner.

Source: docs/legal/data-processing-addendum.md in the repository · draft for attorney review · 31 [DECISION] markers and 18 [COUNSEL] markers on this page.