Are you sure?

>_ jssh

jssh Data Processing Agreement

Last updated: July 27, 2026

Plain-language summary. This Data Processing Agreement is part of the jssh Terms of Service and applies automatically to every customer — no signature or separate request needed. It covers the personal data jssh processes on your behalf when you use the Service (device and fleet metadata, other content your organization submits, and the transient transmission of session content through the relay — which is never stored or recorded), commits jssh to GDPR Article 28 processor obligations, includes the EU Standard Contractual Clauses (deemed signed), the UK Addendum, and Swiss adaptations for international transfers, and lists our subprocessors. Data about your own account with jssh (your login email, billing, security and audit logs, product metrics) is handled by jssh as an independent controller under our Privacy Policy, not this DPA.

1. Introduction; Scope; Roles

1.1 Incorporation and deemed execution. This Data Processing Agreement ("DPA") is entered into between Tanor LLC ("jssh") and the customer entity or person that has agreed to the jssh Terms of Service available at app.jssh.io/terms or another written agreement with jssh governing use of the Service (in each case, the "Agreement") ("Customer"). This DPA is incorporated by reference into, and forms part of, the Agreement for all Customers. By accessing or using the Service, Customer and jssh are deemed to have executed this DPA, effective as of the earlier of the date Customer first uses the Service and the effective date of the Agreement. No further action or signature is required.

1.2 Scope — jssh as processor. This DPA applies where and to the extent jssh processes Customer Personal Data (defined in Section 2) as a processor on behalf of Customer in the course of providing the Service — principally the device and fleet metadata and other Organization Content described in Annex I, together with the transient transmission of session content over the relay data plane (see the note in Annex I).

1.3 Carve-out — jssh as independent controller. jssh processes certain personal data as an independent controller, not as Customer's processor: (a) account and authentication data of Customer's users (e.g., email addresses, SSO identifiers); (b) billing and payment-related data; (c) security and audit logs generated by the Service (metadata such as actor, action, the timestamp of the logged event, and client IP addresses), which jssh maintains for security, integrity, abuse prevention, and legal compliance — device connectivity timestamps are not part of this category (they are Organization Content processed under this DPA), and to the extent audit entries embed Organization Content (such as device names), that embedded content remains Customer Personal Data processed under this DPA; and (d) first-party product usage metrics. Such data ("Account Data") is not Customer Personal Data and is governed by the jssh Privacy Policy, not this DPA.

1.4 Customer responsibilities. Customer acts as a controller of Customer Personal Data or, where Customer uses the Service on behalf of a third-party controller (for example, a managed service provider administering its end clients' organizations), as a processor. Customer is responsible for: (a) the lawfulness of the Customer Personal Data it submits and of its processing instructions; (b) providing all required notices to, and obtaining all required consents and authorizations from, data subjects and any third-party controller; and (c) its own compliance with Data Protection Laws, including its configuration and use of the Service.

2. Definitions

"Customer Personal Data" means (a) Personal Data contained in Organization Content that jssh processes on behalf of Customer in providing the Service, and (b) Personal Data contained in session content transiently transmitted over the relay data plane, which jssh processes solely as transmission, without recording or storage, in each case as described in Annex I. It excludes Account Data (Section 1.3).

"Data Protection Laws" means all data protection and privacy laws applicable to the processing of Personal Data under the Agreement, including as applicable: (a) Regulation (EU) 2016/679 ("EU GDPR"); (b) the EU GDPR as incorporated into United Kingdom law by the Data Protection Act 2018 and the European Union (Withdrawal) Act 2018 ("UK GDPR"); (c) the Swiss Federal Act on Data Protection of 25 September 2020 ("FADP"); and (d) applicable United States state privacy laws, such as the California Consumer Privacy Act as amended ("US State Privacy Laws"). "GDPR" means the EU GDPR and/or UK GDPR, as applicable.

"Organization Content" means data Customer or its users submit to the Service concerning Customer's organizations, devices, and fleet, including device names, tags, platform and operating-system information, agent versions, device public keys, connectivity timestamps, declared service names, and organization and group names.

"SCCs" means the standard contractual clauses annexed to European Commission Implementing Decision (EU) 2021/914 of 4 June 2021.

"Subprocessor" means a processor engaged by jssh to process Customer Personal Data on Customer's behalf.

"UK Addendum" means the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses (version B1.0) issued by the UK Information Commissioner under s.119A of the Data Protection Act 2018.

"Personal Data", "controller", "processor", "data subject", "processing" (and "process"), "personal data breach", and "supervisory authority" have the meanings given in Article 4 of the GDPR (and, under other Data Protection Laws, the meanings given to those or equivalent terms there). "Service" has the meaning given in the Agreement.

3. Processing of Customer Personal Data

3.1 Documented instructions. jssh will process Customer Personal Data only on Customer's documented instructions, including with regard to transfers to a third country, unless required to do otherwise by law to which jssh is subject; in that case, jssh will inform Customer of that legal requirement before processing, unless the law prohibits it on important grounds of public interest. The Agreement (including this DPA), together with Customer's configuration and use of the Service (including enrolling devices, declaring services, setting access rules, and using the Service's features and APIs), constitutes Customer's complete documented instructions. Additional or alternate instructions require the parties' prior written agreement. jssh will inform Customer if, in its opinion, an instruction infringes Data Protection Laws (without any obligation to monitor or to provide legal advice).

3.2 Confidentiality of personnel. jssh ensures that all persons it authorizes to process Customer Personal Data are bound by written confidentiality obligations or are under an appropriate statutory obligation of confidentiality, and process Customer Personal Data only as needed to provide the Service.

3.3 Security. Taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing, as well as the risks to data subjects, jssh implements and maintains the technical and organizational measures described in Annex II, designed to ensure a level of security appropriate to the risk as required by Article 32 GDPR. jssh may update those measures from time to time, provided the updates do not materially reduce the overall security of the Service.

3.4 Subprocessors. jssh engages Subprocessors in accordance with Section 6.

3.5 Data subject requests. jssh will assist Customer in accordance with Section 4.

3.6 Assistance with Articles 32–36. Taking into account the nature of the processing and the information available to jssh, jssh will provide reasonable assistance to Customer in ensuring compliance with its obligations under Articles 32 to 36 GDPR, including security of processing, personal data breach notification (Section 5), data protection impact assessments, and prior consultation with supervisory authorities.

3.7 Deletion and return. jssh will delete or return Customer Personal Data in accordance with Section 8.

3.8 Information and audits. jssh will make available to Customer information reasonably necessary to demonstrate compliance with its obligations under Article 28 GDPR and this DPA, and will allow for and contribute to audits, as follows: upon Customer's written request, no more than once in any twelve (12) month period (except following a personal data breach affecting Customer Personal Data or where required by a supervisory authority), jssh will respond in writing to reasonable information requests and provide copies of relevant documentation describing its security and compliance measures. If the written process does not reasonably demonstrate jssh's compliance, or where required by the SCCs or a supervisory authority, jssh will allow and contribute to an audit, which may include an inspection, conducted at reasonable intervals or where there are indications of non-compliance, on reasonable prior notice; the parties will agree in good faith on reasonable scope, timing, and duration for any such audit. Audits are conducted at Customer's cost, must not unreasonably interfere with jssh's operations, and are subject to reasonable confidentiality obligations.

3.9 US State Privacy Laws. To the extent US State Privacy Laws apply to Customer Personal Data, jssh acts as a "service provider" or "processor": jssh will not sell or share Customer Personal Data, will not retain, use, or disclose it other than to provide the Service or as permitted by those laws, will not combine it with personal data received from other sources except as permitted, and certifies that it understands and will comply with these restrictions.

4. Data Subject Requests

If jssh receives a request from a data subject relating to Customer Personal Data (for example, a request for access, rectification, erasure, restriction, portability, or objection), jssh will promptly redirect the data subject to Customer and will not respond substantively, except to acknowledge receipt and direct the data subject to Customer, unless required by law. Taking into account the nature of the processing, jssh will assist Customer by appropriate technical and organizational measures, insofar as reasonably possible, in fulfilling Customer's obligation to respond to data subject requests under Data Protection Laws. Customer can address most Customer Personal Data directly through the Service (for example, by renaming or removing devices and tags); for anything else, Customer may contact privacy@jssh.io.

5. Personal Data Breach

5.1 Notification. jssh will notify Customer without undue delay, and in any event within seventy-two (72) hours, after becoming aware of a personal data breach affecting Customer Personal Data. Notification will be made to the email address(es) associated with Customer's account administrators.

5.2 Content. The notification will describe, to the extent known and as information becomes available (in phases if necessary): (a) the nature of the breach, including where possible the categories and approximate number of data subjects and Customer Personal Data records concerned; (b) the likely consequences of the breach; and (c) the measures taken or proposed by jssh to address the breach, including, where appropriate, measures to mitigate its possible adverse effects. jssh will provide reasonable cooperation and further information reasonably requested by Customer in connection with the breach.

5.3 Roles. jssh's notification obligation runs to Customer only. As between the parties, Customer is solely responsible for determining whether and how to notify supervisory authorities, data subjects, or any other party, and for making any such notifications. jssh will not make public statements or notifications concerning a breach that identify Customer without Customer's prior written consent, except as required by applicable law. jssh's notification of, or response to, a breach is not an acknowledgment of fault or liability.

6. Subprocessors

6.1 General authorization. Customer provides a general written authorization for jssh to engage Subprocessors to process Customer Personal Data. The Subprocessors currently engaged are listed in Annex III.

6.2 Changes and objection. jssh will give Customer notice of any intended addition or replacement of a Subprocessor by email to Customer's account administrators (and by updating the subprocessor list on this page, app.jssh.io/dpa) at least thirty (30) days before the new Subprocessor processes Customer Personal Data. Customer may object within that 30-day period on reasonable, documented data-protection grounds. The parties will then discuss the objection in good faith; if it cannot be resolved, Customer may, as its sole and exclusive remedy, terminate the portion of the Service that cannot be provided without the objected-to Subprocessor (or, if none can be separated, the Agreement) on written notice, and jssh will refund any prepaid fees for the terminated Service covering the period after termination.

6.3 Flow-down and liability. jssh will impose on each Subprocessor, by written contract, data protection obligations that are no less protective in substance than those in this DPA, including with respect to security and, where the Subprocessor processes Customer Personal Data subject to the GDPR outside an adequate jurisdiction, an appropriate transfer mechanism (the SCCs, Module Three, or another valid mechanism under Data Protection Laws). jssh remains fully liable to Customer for the performance of each Subprocessor's obligations.

7. International Transfers

7.1 EU transfers — SCCs deemed signed. To the extent Customer Personal Data protected by the EU GDPR is transferred to jssh in a country not recognized by the European Commission as providing adequate protection, the SCCs are incorporated into this DPA by reference and apply as follows: Module Two (controller to processor) applies where Customer is a controller, with Customer as data exporter and jssh as data importer; Module Three (processor to processor) applies mutatis mutandis where Customer acts as a processor on behalf of a third-party controller. Where Module Three applies, references to Customer's instructions include the documented instructions of the underlying third-party controller; Customer warrants that it is authorized to pass those instructions and to agree to these Clauses on that controller's behalf. By entering into this DPA (including by deemed execution under Section 1.1), the parties are deemed to have signed the SCCs, including their Annexes, as of the effective date of this DPA.

7.2 SCC options. For the purposes of the SCCs: (a) Clause 7 (docking clause) does not apply; (b) in Clause 9(a), Option 2 (general written authorisation) applies, with a time period of thirty (30) days per Section 6.2; (c) in Clause 11(a), the optional language regarding an independent dispute resolution body does not apply; (d) in Clause 17, Option 1 applies and the SCCs are governed by the law of Ireland; (e) in Clause 18(b), disputes shall be resolved before the courts of Ireland; and (f) Annexes I, II, and III of this DPA serve as Annexes I, II, and III (the Appendix) of the SCCs.

7.3 UK transfers. To the extent Customer Personal Data protected by the UK GDPR is transferred to jssh in a country without UK adequacy regulations, the UK Addendum is incorporated by reference and is deemed executed by the parties upon entering into this DPA. The UK Addendum amends the SCCs as described in Section 7.1–7.2, and its Tables are completed as follows: Table 1 (Parties) by reference to Annex I.A; Table 2 (Selected SCCs, Modules and Clauses) by reference to Sections 7.1 and 7.2; Table 3 (Appendix Information) by reference to Annexes I, II, and III; and Table 4 (Ending the Addendum when the Approved Addendum changes): either party may end the UK Addendum as set out in its Section 19.

7.4 Swiss transfers. To the extent Customer Personal Data protected by the FADP is transferred to jssh in a country without an adequacy decision of the Swiss Federal Council, the SCCs as set out in Sections 7.1–7.2 apply with the following adaptations: (a) references to the EU GDPR are, insofar as the transfer is subject to the FADP, read as references to the FADP; (b) the competent supervisory authority is the Swiss Federal Data Protection and Information Commissioner (FDPIC); (c) references to "EU Member State" shall not be interpreted to exclude data subjects in Switzerland from exercising their rights in their place of habitual residence, and Clause 18(c) applies accordingly; and (d) the SCCs also protect the data of legal entities to the extent (if any) the FADP so requires.

7.5 Conflict. If there is any conflict between the SCCs (or the UK Addendum or Swiss adaptations) and this DPA or the Agreement, the SCCs (as so amended or adapted) prevail.

8. Term; Deletion and Return

8.1 Term. This DPA takes effect as set out in Section 1.1 and remains in force for as long as jssh processes Customer Personal Data under the Agreement.

8.2 Deletion and return. Upon termination or expiration of the Agreement, or upon Customer's earlier written request, jssh will, at Customer's choice, either (a) delete Customer Personal Data (including copies) within sixty (60) days, or (b) return Customer Personal Data to Customer by making it available for export in a machine-readable format for thirty (30) days and then delete it as under (a). If Customer does not communicate a choice, jssh will delete. The foregoing is subject to the following exceptions: (i) to the extent retention is required by applicable law, jssh will protect the retained data under this DPA and delete it once the legal requirement lapses; and (ii) Customer Personal Data residing in backup or archival systems is purged or overwritten in the ordinary course of jssh's backup cycle within ninety (90) days and remains protected under this DPA until deleted. Before termination, Customer may also retrieve Organization Content at any time through the Service and its APIs. In either case, jssh will certify deletion in writing.

9. Liability

Each party's and its affiliates' total, aggregate liability arising out of or relating to this DPA (including the SCCs, the UK Addendum, and the Swiss adaptations), whether in contract, tort, or otherwise, is subject to the exclusions and limitations of liability set out in the Agreement, and any liability under this DPA counts toward (and does not add to) the aggregate liability cap in the Agreement. Nothing in this Section limits any liability to data subjects under Clause 12 of the SCCs or any liability that cannot be limited under applicable law.

10. Order of Precedence; General

10.1 Precedence. With respect to the subject matter of data protection, in the event of a conflict the following order of precedence applies: (1) the SCCs (including the UK Addendum and Swiss adaptations); (2) this DPA; (3) the Agreement. The Agreement otherwise remains in full force and effect.

10.2 Updates. jssh may update this DPA from time to time as required by Data Protection Laws or to reflect changes to the Service or Subprocessors (per Section 6.2). Material updates will be notified as provided in the Agreement; the current version is always available at app.jssh.io/dpa.

10.3 Contact. Questions about this DPA: legal@jssh.io. Privacy requests: privacy@jssh.io.


Annex I — Description of the Processing

A. List of Parties

  • Data exporter: Customer (name and contact details as provided in Customer's account). Role: controller (or processor, per Section 1.4). Activities: use of the jssh Service to enroll, manage, and connect to its devices. Contact: Customer's account administrator email.
  • Data importer: Tanor LLC, provider of the jssh Service (a device-isolated remote-access relay for device fleets). Role: processor. Contact: privacy@jssh.io.

B. Description of Transfer / Processing

  • Categories of data subjects: Customer's personnel and authorized users (operators, administrators); and, where Customer's device names, tags, or other Organization Content identify individuals, personnel of Customer or of Customer's end clients (for example, in managed-service-provider deployments).
  • Categories of personal data: device and fleet metadata submitted to or generated for Customer in the Service — device names, tags, platform and operating-system information, agent versions, device public keys, connect/disconnect timestamps, and declared service names — together with organization and group names and any other personal data Customer chooses to include in Organization Content; and transient session content in transit (relay data-plane connections only; never stored or recorded), to the extent it contains personal data.
  • Special categories of data: none intended or required by the Service. Customer must not submit special categories of personal data (Article 9 GDPR) or data relating to criminal convictions and offences (Article 10 GDPR) as Customer Personal Data.
  • Frequency of the transfer/processing: continuous, for the duration of the Agreement.
  • Nature and purpose: hosting, storage, transmission, display, and related processing strictly as necessary to provide, secure, maintain, and support the device-access relay Service under the Agreement.
  • Duration and retention: for the term of the Agreement, then deletion per Section 8. Aggregated product metrics (Account Data, Section 1.3) reference only an internal organization identifier and are retained on our analytics platform's fixed rolling window (approximately three months); they cannot be deleted earlier.
  • Transfers to subprocessors: as described in Annex III; each Subprocessor processes Customer Personal Data only for the activity listed there, for the same duration.

Note on session content. jssh does not record or store session content on any connectivity path. Content of sessions carried over the relay data plane is transiently transmitted through the Service; to the extent such content contains personal data, that transient transmission is processing covered by this DPA, performed solely on Customer's instruction to convey the session, with no storage and no inspection (subject to the abuse-detection reservation in the Agreement). Session traffic is end-to-end encrypted between the jssh CLI and the agent on the Device, on every connectivity path and independently of the protocol carried inside (SSH, RDP, VNC, HTTP, database or generic TCP). Session keys are derived between those two endpoints and do not exist on jssh's systems, so any such transient transmission is of ciphertext jssh cannot read, and jssh cannot produce plaintext in response to legal process. Where connections are established peer-to-peer or via TURN relay, traffic flows directly between endpoints or through Cloudflare's TURN service and jssh's relay carries only signaling. The Agreement describes these encryption boundaries in detail, including that "end-to-end" denotes the span between the CLI and the agent (the final hop on each machine is a local loopback connection), and that jssh remains the directory and authorization authority for which operator keys may reach which Devices.

C. Competent Supervisory Authority

For the SCCs, the competent supervisory authority is: where Customer is established in an EU Member State, the supervisory authority of that Member State; otherwise, the supervisory authority determined under Clause 13(a) of the SCCs, being the supervisory authority of Ireland where Customer has no EU establishment but has appointed an EU representative there — [CONFIRM with counsel]. Where the UK Addendum applies, the UK Information Commissioner; where the Swiss adaptations apply, the FDPIC.

Annex II — Technical and Organizational Measures

jssh implements and maintains the following measures for the Service. jssh does not currently hold security certifications (such as SOC 2 or ISO/IEC 27001) and makes no representation of certification; the measures below describe what is actually in place.

  1. Encryption in transit. All connections to the Service — dashboard, API, device agents, and operator clients — use TLS (HTTPS/WSS). Device agents establish only outbound connections; no inbound ports are required on devices. SSH sessions are additionally end-to-end encrypted between operator and device (see the note in Annex I).
  2. Per-device isolation. Each device's relay connections and session traffic are handled by a dedicated, isolated relay instance; connection state is never shared between devices.
  3. Device identity and authentication. Each device holds an Ed25519 key pair; devices authenticate to the relay via public-key challenge–response. Enrollment uses single- or limited-use tokens or explicit in-browser approval.
  4. User authentication. Passwordless authentication only: short-lived emailed magic links or customer-configured single sign-on (OIDC). Browser sessions use limited-lifetime signed session tokens in httpOnly, Secure cookies. API and enrollment tokens are stored only as SHA-256 hashes computed with a server-side secret pepper; plaintext tokens are shown once and are not recoverable by jssh.
  5. Authorization. Role-based access control per organization, with per-user, per-device, and per-service access rules enforced when each connection is established; on peer-to-peer/TURN paths, per-service restrictions are enforced by the device agent under relay control.
  6. Encryption at rest. Customer-configured OIDC client secrets are encrypted at rest with AES-256-GCM. All stored data benefits from platform-level encryption at rest provided by the hosting infrastructure (Cloudflare).
  7. Logging and monitoring. Security-relevant events (enrollment, approvals, token issuance, session opens, configuration changes, revocations) are recorded in an audit log containing metadata only — never session content.
  8. Abuse and availability controls. Rate limiting on authentication and sensitive endpoints.
  9. Infrastructure. The Service runs entirely on Cloudflare's global platform (compute, storage, database, connectivity). Physical, environmental, and network security of the infrastructure is provided by Cloudflare under its own security and compliance programs (which are Cloudflare's, as hosting provider, and are not certifications held by jssh).
  10. Personnel and organizational measures. Access to production systems and Customer Personal Data is restricted to authorized personnel bound by confidentiality, on a need-to-know basis.
  11. Subprocessor security. Measures per Section 6.3 (written flow-down contracts and transfer mechanisms).
  12. Assistance measures. The Service's self-serve controls (device rename/removal, tag editing, access-rule management, token revocation) enable Customer to fulfil most data subject requests directly; jssh provides further assistance per Sections 3.6 and 4.

Annex III — Subprocessors

SubprocessorProcessing activityLocation
Cloudflare, Inc.Hosting and infrastructure for the entire Service: compute (Workers), per-device relay state (Durable Objects), database (D1), key-value storage (KV), object storage for downloads (R2), NAT-traversal relay (Realtime/TURN), and first-party usage metrics (Analytics Engine)United States / Cloudflare's global network
Resend, Inc.Transactional email delivery (login magic links, verification emails)United States
Stripe, Inc.Payment processing and billing (hosted checkout, customer portal)United States
Telegram FZ-LLCInternal operational alerts to jssh staff. Receives only an organization identifier (e.g. org_a1b2c3), the event type, and a link back to jssh — no organization names, no email addresses, no device or session data, and no text entered by Customer. Aggregate, cross-tenant counters may also be sent; those identify no organization.United Arab Emirates

Customer-configured identity providers (OIDC SSO) are engaged by Customer, not by jssh, and are not jssh Subprocessors. Stripe additionally acts as an independent controller of the payment data it collects under its own terms.

Note on Telegram. The organization identifier it receives is a pseudonym that jssh can re-identify, so it is listed here rather than treated as anonymous data. The United Arab Emirates is not the subject of a European Commission adequacy decision; jssh therefore keeps what is sent over this channel to the minimum described above, and Customer Personal Data in the ordinary sense — names, addresses, device or session data — is never transmitted to it. Customers who prefer that no identifier reach this channel may say so at support@jssh.io and jssh will disable it for their organization.

The current subprocessor list is maintained on this page. Changes are subject to the notice and objection process in Section 6.2.


Related documents: Terms of Service · Privacy Policy