Data Processing Agreement

This Data Processing Agreement (the "DPA") is entered into by and between Enter the Orchard Syndicate, a Delaware corporation with its principal place of business in Minnesota, USA ("Orchard", the processor) and the customer identified in the signature block below (the "MSP" or "Customer", the controller). It forms part of, and is subject to, the Master Services Agreement or Terms of Service between the parties (the "Agreement"). Where this DPA conflicts with the Agreement on the subject of data protection, this DPA controls.

1Definitions

Capitalized terms not defined here have the meaning given in the Agreement or in applicable data-protection law. "Data Protection Law" means all laws and regulations applicable to the processing of Personal Data under this DPA, including, where applicable, the EU/UK General Data Protection Regulation ("GDPR"), the California Consumer Privacy Act as amended ("CCPA/CPRA"), and sector rules such as the Health Insurance Portability and Accountability Act ("HIPAA") or the Gramm-Leach-Bliley Act ("GLBA") that bind the Customer or its clients.

• Personal Data — any information relating to an identified or identifiable natural person processed by Orchard on the Customer's behalf under the Agreement.
• Processing — any operation performed on Personal Data, including capture, transmission, storage, structuring, retrieval, and deletion.
• Controller — the party that determines the purposes and means of Processing. The MSP is Controller for the data captured from its and its clients' endpoints.
• Processor — the party that Processes Personal Data on behalf of the Controller. Orchard is Processor.
• Sub-processor — any third party engaged by Orchard to Process Personal Data in delivering the service (see Annex C).
• Data Subject — the individual to whom Personal Data relates; here, principally the operators of monitored endpoints.
• Endpoint — a device on which the Orchard watcher (capture agent) is enrolled and running.
• Captured Activity — the semantic activity data the watcher records, as defined and bounded in Section 5.

2Roles of the parties

1. The MSP is the Controller. It decides which endpoints are enrolled, which of its end clients are subject to monitoring, the purposes of monitoring, and the retention it requires. The MSP is responsible for having a lawful basis and the necessary authority and notices in place for that monitoring.
2. Orchard is the Processor. It Processes Personal Data only to provide, secure, maintain, and support the service, and only on the Customer's documented instructions (this DPA and the Customer's configuration in the platform being such instructions).
3. End clients and downstream verticals. The MSP may serve end clients in regulated verticals (e.g. healthcare, legal, finance). Where an end client is itself a controller, the MSP is responsible for the controller-to-controller or controller-to-processor arrangements with that client; Orchard remains a (sub-)processor acting on the MSP's instructions and provides the isolation guarantees in Section 6 to support those arrangements.
4. Orchard will not sell Personal Data and will not retain, use, or disclose it for any purpose other than performing the service, including not combining it with data from other sources except as needed to provide the service to the Customer. This is a "service provider" commitment for CCPA/CPRA purposes.

3Scope, nature & purpose of processing

The subject matter, duration, nature and purpose of the Processing, the types of Personal Data, and the categories of Data Subjects are described in Annex A. In summary, Orchard Processes Captured Activity and related account and telemetry data to deliver always-on endpoint awareness, insights for MSP owners, work recording, and scheduled automation, as configured by the Customer.

Orchard will Process Personal Data only for the duration of the Agreement and for the limited period afterward required for return or deletion under Section 12, unless retention is required by law.

4Orchard's processing obligations

1. Documented instructions. Orchard Processes Personal Data only on the Customer's documented instructions, including for international transfers, unless required to do otherwise by law — in which case Orchard will inform the Customer first, unless that law prohibits it.
2. Confidentiality. Orchard ensures that personnel authorized to Process Personal Data are bound by appropriate confidentiality obligations and access it only on a need-to-know basis.
3. Security. Orchard implements and maintains the technical and organizational measures in Annex B, appropriate to the risk.
4. Sub-processors. Orchard engages Sub-processors only under Section 7 and remains responsible for their performance.
5. Assistance. Taking into account the nature of the Processing, Orchard assists the Customer with data-subject requests (Section 9), security, breach notification, and data-protection impact assessments (Sections 10–11).
6. Deletion or return. On termination, Orchard returns or deletes Personal Data per Section 12.
7. Demonstrating compliance. Orchard makes available information reasonably necessary to demonstrate compliance with this DPA and supports audits per Section 11.
8. Instruction conflicts. Orchard will notify the Customer if, in its opinion, an instruction infringes Data Protection Law.

5What Orchard captures — and never captures

The capture boundary below is enforced in the watcher itself, not merely promised in policy. It is a core property of the product. Orchard will not weaken it for a given tenant without an explicit, documented instruction from the Customer and a corresponding amendment to this DPA.

5.1Credential capture (optional tier)

The capture dial has an optional top tier, off by default, in which the watcher reads the value of a login field so an authorized automation can authenticate on the Customer's behalf. It is the only tier that reads a password field, and reaching it requires deliberate action on more than one axis: an Orchard-side ceiling raised for that specific workspace, a per-workspace encryption key provisioned, and the workspace owner then selecting the tier. Absent any of these, no credential is captured.

• Sealed on the endpoint. A captured credential is encrypted on the capturing machine, using envelope encryption, to the public half of a per-workspace key held in a hardware security module (HSM). The endpoint holds only the public key and therefore cannot decrypt what it captured; the value is opaque in transit and at rest.
• Decryption is HSM-bound and audited. A credential is decrypted only to replay an authorized workflow, via a key operation performed inside the HSM (the private key is non-exportable). Every decryption is recorded on a per-workspace ledger available to the Customer, and failed attempts are recorded as well.
• Customer control. The Customer can disable the tier or delete any stored credential at any time; deletion is immediate. Because a stored credential is only ciphertext usable for replay, no plaintext copy is retained.
• Lawful basis and scope. Enabling this tier materially changes the sensitivity of processing. The Customer is the controller for that decision and is responsible for the lawful basis, notice, and any data-protection impact assessment its enablement requires.

Customer responsibility. The MSP must ensure that monitored individuals are notified of monitoring as required by applicable law and employment rules, and that an appropriate lawful basis exists before an endpoint is enrolled.

6Security & tenant isolation

1. Multi-tenant isolation. Every record is tenant-scoped. Tenant separation is enforced at the database layer using PostgreSQL Row-Level Security (RLS), which is fail-closed: with no tenant context set, a query returns zero rows rather than leaking across tenants. Tenant context is bound from the authenticated identity before any data is read.
2. Enrollment & agent identity. Enrollment and agent tokens embed the tenant identifier so tenant context is established before any database read, keeping the watcher's writes confined to its own tenant.
3. Encryption in transit. Data transmitted between endpoints, the API, and the consoles is protected with current TLS.
4. Tenant access control. MSP console roles are least-privilege — owner / admin / member, where member is read-only.
5. Internal access is the one deliberate, audited exception to RLS. Orchard's support / platform console is separate from the tenant API: its own credentials, its own authentication secret, and mandatory TOTP multi-factor authentication. It connects to the database under a role that is SELECT-only on tenant tables — even sales-assisted tenant provisioning routes its writes through a constrained path, not the elevated platform role — and every read it performs is written to an immutable platform audit log (which staff member, which action, which tenant, when). RLS is bypassed here by design, for support and operations; that bypass is constrained and fully accountable, not silent.
6. Encryption at rest & key management. Managed database storage is encrypted at rest by the cloud provider (Google Cloud SQL, AES-256, with provider-managed keys). Selected sensitive fields — for example window titles, control names, stored integration secrets, and MFA seeds — are additionally encrypted at the application layer (AES-GCM) before they reach the database. Credentials captured under the optional tier (5.1) are handled more strictly still: each is sealed on the capturing endpoint to the public half of a per-workspace HSM key, so it reaches Orchard already encrypted and can be decrypted only by an audited operation inside the HSM.
7. Logging & monitoring. Operator actions and every cross-tenant platform read are written to append-only audit logs; application logs are structured and centrally collected, and production access is limited to authorized staff on a need-to-know basis.

The full set of measures is set out in Annex B. Orchard may update measures provided the level of protection is not materially reduced.

7Sub-processors

1. The Customer provides general authorization for Orchard to engage the Sub-processors listed in Annex C, each bound by data-protection terms no less protective than this DPA.
2. Orchard will give the Customer prior notice of any intended addition or replacement of a Sub-processor, with at least 30 days to object on reasonable data-protection grounds. If the parties cannot resolve a reasonable objection, the Customer may terminate the affected service.
3. Customer-initiated integrations. Where the Customer connects a third-party system it controls — for example a ConnectWise or other PSA connection, which Orchard ingests on a read-only basis — that third party is the Customer's own processor/integration, not an Orchard Sub-processor, and the Customer is responsible for its terms.

8International transfers & residency

Orchard hosts the platform on cloud infrastructure as described in Annex C. The primary processing region is the United States (Google Cloud region us-central1). Where Processing involves a transfer of Personal Data subject to GDPR/UK GDPR outside the EEA/UK to a country without an adequacy decision, the transfer is governed by the applicable Standard Contractual Clauses / UK IDTA, which are incorporated into this DPA by reference.

9Assistance with data-subject rights

Taking into account the nature of the Processing, Orchard provides reasonable assistance — through appropriate technical and organizational measures, insofar as possible — to help the Customer respond to requests from Data Subjects exercising rights of access, rectification, erasure, restriction, portability, and objection. If Orchard receives such a request directly, it will not respond except on the Customer's instruction and will promptly forward the request to the Customer.

10Personal-data breach notification

1. Orchard notifies the Customer without undue delay, and in any event within 72 hours, after becoming aware of a Personal Data breach affecting the Customer's data.
2. The notice will describe, to the extent known: the nature of the breach, the categories and approximate number of Data Subjects and records affected, the likely consequences, and the measures taken or proposed to address it.
3. Orchard reasonably assists the Customer with the Customer's own breach-notification obligations to regulators and Data Subjects. Notification is not, by itself, an acknowledgment of fault.

11Audits & demonstrating compliance

Orchard makes available to the Customer information reasonably necessary to demonstrate compliance with this DPA and, on reasonable prior notice and no more than once per year (or following a breach, or where required by a supervisory authority), allows for and contributes to audits, including inspections, conducted by the Customer or an auditor it mandates, subject to confidentiality and to not compromising other customers' security or data. Where available, Orchard may satisfy this obligation by providing current third-party reports or certifications (for example, a SOC 2 report).

12Return & deletion on termination

1. On termination or expiry of the Agreement, and at the Customer's choice, Orchard returns the Personal Data in a commonly used format and/or deletes it, together with existing copies, within 30 days, unless retention is required by law.
2. Backups containing Personal Data are deleted or expire within their ordinary rotation cycle, after which they are no longer restored to active use.
3. On request, Orchard certifies completion of deletion in writing.

13Liability, governing law & miscellaneous

1. Liability. Each party's liability under this DPA is subject to the limitations and exclusions of liability in the Agreement.
2. Governing law & venue. This DPA is governed by the law and subject to the venue stated in the Agreement, or, if none, the State of Delaware, USA.
3. Order of precedence. In the event of conflict on data-protection matters: this DPA, then the Agreement, then Orchard's documentation.
4. Changes. Orchard may update this DPA to reflect changes in law or the service, provided the level of protection is not materially reduced; material changes will be notified to the Customer.
5. Severability & survival. If any provision is held unenforceable, the remainder stays in effect. Obligations that by their nature should survive termination do so.

14Derived data & aggregated learning

Orchard improves the service by learning from the structure of work — never from its contents. This section defines exactly what may be derived from Captured Activity, and what may never leave a tenant boundary.

1. Structural fingerprints. Orchard may derive anonymized, aggregated structural data from Captured Activity: workflow shapes (the ordered sequence of application, action, and control identity), frequency and duration statistics, and automation-outcome statistics. Derivation strips captured field values, window titles, URL paths, and record identifiers at the moment of derivation — the boundary is enforced in the derivation code, not merely promised in policy.
2. Never included. Derived data that crosses a tenant boundary never includes captured field values, window titles, personnel identities, client or end-user names, or any content that could identify the Customer or its clients. Only the structural fingerprint and its aggregate statistics cross tenants.
3. Permitted uses. Orchard may use derived data to improve its products — including cross-customer workflow recognition, industry benchmarks, and the training of automation models. Derived data is never sold and never attributed to a Customer or its clients.
4. Capture scope unchanged. Nothing in this section expands what the watcher captures. Capture scope remains governed by Section 5 and by the monitoring-authorization statement each client affirms.
5. Client portability. Each end client's automation history and measured-savings ledger belong with that client, and are exportable to the client or a successor service provider on request.
6. Raw data rights unchanged. The Customer may export or request deletion of its raw Captured Activity at any time (Section 12). Previously derived anonymized aggregates persist, as they contain no Personal Data.

Current as of the effective date, subject to the update mechanism in Section 7.

Customer-initiated integrations (e.g. a ConnectWise/PSA connection the Customer configures and Orchard ingests read-only) are the Customer's own integrations and are not listed here as Orchard Sub-processors. See Section 7.3.

§Acceptance

By signing below, each party agrees to be bound by this DPA as of the effective date.