Data processing addendum. For teams on Team and Business.

1. Scope and acceptance

This addendum (“DPA”) is part of the terms of service between Affluent Labs LLC (“we”, the “processor”) and the organization that creates or owns a team on the Team or Business plan (the “customer”). It applies to the personal data we process for the customer’s team (“team data”), described in Annex I. It is accepted with the terms when the team is created or its seats are bought; no signature is needed. If the customer needs a countersigned copy, write to support@zestssh.com.

Words such as “personal data”, “processing”, “controller”, “processor”, “data subject” and “personal data breach” mean what they mean in the GDPR (Regulation (EU) 2016/679) and the UK GDPR (“data protection law”).

2. Roles

For team data, the customer is the controller (or a processor for its own client, in which case we are its sub-processor), and we are its processor. For the accounts of the people in the team (their sign-in, personal space and purchases) and for billing records, we are a controller under our privacy policy, not under this DPA.

3. Instructions

We process team data only on the customer’s documented instructions, which are: the terms and this DPA; what the customer’s owners and admins set in the apps (members, roles, access, rules, what the team records, company sign-in, directory sync); and other written instructions we agree to. We tell the customer if we believe an instruction breaks data protection law. Where a law requires us to process team data otherwise, we tell the customer first, unless that law forbids it.

4. The customer’s duties

The customer is responsible for having a lawful basis for the team data, for giving its members and invited people the notices the law requires (in particular before turning on activity records or session logs), for the accuracy of what its directory sends, and for whom it invites and gives access. The apps tell every member what the team records whenever it changes; that does not replace the customer’s own notices.

5. Confidentiality

Only people we authorize may process team data, and only as this DPA allows; each is bound to confidentiality. Today that is one person, ZestSSH’s developer.

6. Security

We keep the technical and organizational measures in Annex II, appropriate to the risk. Most team data is encrypted on the members’ devices with keys we never hold, so we cannot read it: item contents, team, vault and role names, key copies, activity notes and session logs. We may improve these measures; we will not reduce their overall level.

7. Sub-processors

• The customer authorizes the sub-processors in Annex III, which is kept up to date on the sub-processors page, and generally authorizes us to engage others under this section.
• We list a new sub-processor there at least 30 days before it handles team data. The customer may object on reasonable data protection grounds within that time by writing to us. We then try in good faith to resolve it; if we cannot, the customer may stop using the affected part of ZestSSH, and we refund in proportion any Business fees paid for time after that.
• We bind each sub-processor by contract to data protection duties no less protective than this DPA’s, and we remain responsible to the customer for its performance.

8. Requests from people

If a person asks us to exercise a data protection right over team data, we pass the request to the customer and do not answer it ourselves unless the customer tells us to. The apps let owners and admins answer most requests themselves: see who is in the team and with what access, remove a member, turn recording off (which deletes what was recorded), and delete session logs. Where they cannot, we help, as far as we reasonably can.

9. Assistance

We give the customer the information it reasonably needs for a data protection impact assessment, a prior consultation with a supervisory authority, or its own security duties. Most of it is public in the security whitepaper, which ties each claim to the code.

10. Personal data breaches

We notify the customer of a personal data breach affecting team data without undue delay, and no later than 72 hours after we become aware of it, at the email addresses of the team’s owners. The notice says what we know: what happened, the categories and rough numbers of people and records concerned, the likely consequences, and what we have done and propose. Information we do not have yet follows as we learn it. We take reasonable steps to contain the breach and limit its effects. A notice is not an admission of fault.

11. Deletion and return

The customer can see and use its team data in the apps for as long as the team exists. When the team is deleted (which happens automatically when it has no members left), or the customer asks us at the end of the service, we delete the team data from our live systems at once and from our backups as they expire, within 6 weeks, unless a law requires us to keep it. Data on members’ own devices is under the customer’s and the members’ control, not ours. Replaced item versions, activity, session logs and invitations are deleted earlier, on the schedule in Annex I.

12. Information and audits

We make available the information needed to show we meet this DPA: the whitepaper, this DPA, the sub-processors page, and answers to a reasonable security questionnaire once a year. We hold no third-party certification (such as SOC 2 or ISO 27001) and claim none. Where this is not enough, or a supervisory authority requires it, the customer (or an independent auditor bound to confidentiality) may audit our compliance once a year, with 30 days’ notice, during business hours, without access to other customers’ data, at the customer’s cost.

13. International transfers

We process team data in the United States, where we and our servers are. Where data protection law requires safeguards for that transfer:

• EU and EEA: the Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914 are incorporated into this DPA: Module Two (controller to processor), or Module Three (processor to processor) where the customer is a processor. Clause 7 (docking) applies. In Clause 9, Option 2 applies, with the notice period in section 7 above. The option in Clause 11 does not apply. In Clause 13, the supervisory authority is the one competent for the customer. In Clauses 17 and 18, the law and the courts are those of Ireland. Annexes I, II and III of the Clauses are completed by the annexes below.
• United Kingdom: the International Data Transfer Addendum to those Clauses, issued by the Information Commissioner (version B1.0), is incorporated. Its tables are completed by this DPA and its annexes, and either party may end it as its section 19 allows.
• Switzerland: the same Clauses apply, read with the changes the Swiss Federal Act on Data Protection requires, with the Swiss Federal Data Protection and Information Commissioner as the competent authority.

Where a sub-processor is certified under the EU-US Data Privacy Framework (or its UK extension, or the Swiss framework), we may rely on that for its part.

14. Liability and precedence

Each party’s liability under this DPA is subject to the limits in the terms, except where data protection law or the Standard Contractual Clauses do not allow it. If this DPA conflicts with the terms, this DPA prevails for team data; the Standard Contractual Clauses prevail over both. This DPA lasts as long as we process team data.

Annex I: the processing

Annex II: security measures

• Encryption on the device: each vault has its own key; items, names, key copies, activity notes and session logs are encrypted with AES-256-GCM on members’ devices, and keys reach members only sealed to their own X25519 keys. We never hold these keys.
• A signed record: every change to who is in a team and what they may do is signed by its author’s Ed25519 key and checked by every device, so our server cannot add a member or raise anyone’s access. The server applies the same rules before it stores a change.
• Access control in the team: roles with a level per vault; rules an owner can require (two-step sign-in, approved devices, an app lock, no export, company sign-in); a recent sign-in (within 10 minutes) for changes to membership and access; removal replaces the keys a removed person held.
• In transit: HTTPS only, with HSTS, through Cloudflare; live session shares are encrypted between the devices with keys the relay never sees.
• Minimal logging: no request log, no stored IP addresses and no user agents; error lines carry no account ids, email addresses or IP addresses, which a test of the server code enforces. Rate limits are kept in memory.
• Secrets we hold as hashes only: invite codes (a lookup id derived from the code), the directory sync token, recovery codes.
• Infrastructure: servers we operate ourselves, with storage mirrored across two drives, services in separate virtual machines, and Cloudflare in front; administrative access limited to the processor’s authorized personnel.
• Backups: every 24 hours, encrypted with AES-256 before storage, an encrypted offsite copy, expiring within 6 weeks.
• Deletion on a schedule: jobs on the server delete expired data (Annex I) every few hours.
• Openness: the SSH engine is open source, the whitepaper ties claims to the code, and a disclosure policy invites reports.

Annex III: sub-processors

© 2026 Affluent Labs LLC. All rights reserved.