Data Processing Addendum

1. Parties and scope

This DPA forms part of the agreement between the customer identified on the applicable account ("Customer" — controller, or processor on behalf of its own controllers) and Hosam Hassan LLC ("Artica," processor), and governs Artica's processing of Personal Data contained in Customer Data in connection with the Artica service. "Personal Data," "processing," "controller," and "processor" have the meanings given in applicable data-protection law (GDPR / UK GDPR / CCPA as applicable).

2. Subject matter, nature, and purpose

Artica processes Customer's Zendesk support data to (a) generate a topic taxonomy and help-center coverage report from recent tickets, (b) support drafting of help-center articles, including analysis of workflow screenshots captured and redacted in Customer's browser, and (c) export drafts back to Customer's Zendesk. Duration: the term of the agreement plus the deletion period in §8.

Data subjects: Customer's end users (support requesters) and agents appearing in ticket data; Customer's workspace users.

Categories of Personal Data: support-ticket content and metadata (processed transiently — §3); names and emails of Customer's workspace users; the identity of the Zendesk authorizing user; content of screenshots and articles Customer creates. No special categories are requested or required; Customer controls what its tickets and captures contain.

3. The transient-processing commitment

Artica's architecture processes ticket text ephemerally: ticket content is held in memory in the processing environment, converted to numerical embeddings and topic labels, and discarded as it is processed. Ticket subjects, bodies, and requester identities are not written to Artica's persistent stores — an automated schema check in Artica's build pipeline blocks changes that would create storage for them. What persists: AI-synthesized topic labels, descriptions and example questions, embedding vectors, monthly volume counts, and Zendesk ticket ID numbers.

4. Artica's obligations

Artica will:

1. process Personal Data only on Customer's documented instructions — the agreement, this DPA, and Customer's use of the product's settings and features constitute those instructions — unless required by law, in which case Artica will notify Customer unless legally prohibited;
2. ensure persons authorized to process Personal Data are bound by confidentiality;
3. implement the technical and organizational measures in Annex II;
4. engage subprocessors only per §6;
5. taking into account the nature of the processing, assist Customer with data-subject requests (§7) and, insofar as information is available to Artica, with Customer's security, breach-notification, DPIA, and consultation obligations;
6. notify Customer without undue delay after becoming aware of a Personal Data breach affecting Customer Data, with the information reasonably available at the time, supplemented as it becomes available;
7. delete Personal Data per §8 at termination;
8. make available information reasonably necessary to demonstrate compliance: Artica responds to reasonable written security questionnaires and provides its Security Overview and supporting evidence; audits beyond that to be agreed in scope, frequency, and cost, proportionate to the engagement.

5. Customer's obligations

Customer is responsible for the lawfulness of the Personal Data it connects — including an appropriate lawful basis and any required notices to its own end users — for its Zendesk configuration, for what its users capture with the extension, and for reviewing redacted screenshots before publication.

6. Subprocessors

Customer generally authorizes the subprocessors listed at askartica.com/subprocessors (mirrored in Annex III). Artica will update that page and give workspace Owners email notice at least 30 days before adding or replacing a subprocessor; Customer may object on reasonable data-protection grounds within that window, and if no resolution is found, may terminate and request deletion under §8. Artica remains responsible for its subprocessors' performance and imposes data-protection obligations materially no less protective than this DPA.

7. Data-subject requests

By design, Artica cannot search stored data for a ticket requester's personal data — ticket text and requester identities are not retained — so requests concerning ticket content should be handled by Customer directly in Zendesk. For Personal Data Artica does hold (workspace-user account data; content Customer authored, including screenshots), Artica will assist Customer in fulfilling access, correction, and deletion requests. If a data subject contacts Artica directly, Artica will redirect them to Customer.

8. Deletion and return

On termination or on Customer's request, Artica deletes the Customer workspace: deletion cascades through all persisted workspace data — taxonomy, embeddings, articles, connection records including encrypted tokens, memberships — and workspace-scoped stored media, within 30 days of the request. Customer may export its article content to Zendesk before deletion. Residual copies in provider-managed backups expire per those providers' schedules.

9. International transfers

Artica's subprocessors are US-based. For personal data transferred from the EU/UK/Switzerland, the parties rely on appropriate safeguards such as the EU Standard Contractual Clauses (and UK/Swiss addenda) as incorporated on execution of this DPA.

10. Liability and precedence

Liability under this DPA is subject to the limitations in the agreement. In case of conflict, this DPA prevails over the agreement with respect to Personal Data processing.

Annex I — Processing details

As set out in §2. Frequency: continuous while a Zendesk connection is active; ticket pulls run at connection and on the plan's re-check cadence.

Annex II — Technical and organizational measures (as implemented)

• Transient ticket processing: ticket text confined to ephemeral compute memory; never written to database, disk, or file; enforced by an automated CI schema check on every code change.
• Encryption: TLS in transit; provider-managed encryption at rest (database, object storage); application-level AES-256-GCM for Zendesk OAuth tokens.
• Access control: authenticated sessions on all product routes; role-based workspace membership (Owner/Editor/Viewer) with single-use, revocable, hash-stored invitations; machine endpoints authenticated by signature or token; server-side plan and permission enforcement at every mutating entry point.
• Tenant isolation: per-workspace scoping of all queries and storage keys; object retrieval checked against the session's workspace. (Database-layer row-level security: planned, not yet implemented.)
• Client-side redaction: screenshot redaction (emails, checksum-validated card numbers, credentials and tokens, phone numbers, SSNs, IBANs, password fields, page-flagged elements) performed in the user's browser before upload; destructive raster blurring; hard delete of discarded captures.
• Secrets handling: no production secrets in source control; environment validated at boot; CI uses placeholder credentials tied to no real instance.
• Resilience: durable, resumable background jobs; managed platform redundancy.

Annex III — Subprocessors

The list at askartica.com/subprocessors, as most recently updated there.