Data Processing Addendum

This addendum forms part of the service agreement between the Customer identified by its legal business name, registered address and account in the acceptance record (or its signed order) and ONECOMPASS LIMITED (HE 410135), at Griva Digeni, 81, Marinos Court, Floor 1 & 2, 6043, Larnaca, Cyprus (“Processor”). Privacy contact: [email protected]. It takes effect when Customer’s authorized account owner affirmatively accepts this version. Sections 2, 3 and 10–12 contain the standard service schedules; a signed order may add specific processing restrictions.

It applies to personal data processed on Customer’s behalf through the service. “Personal data”, “processing”, “controller”, “processor”, “personal data breach” and “supervisory authority” have their GDPR meanings. Customer acts as controller or, if acting for another controller, warrants that it has authority to appoint Upsurge as subprocessor and give the relevant instructions.

Processor will process data only on documented instructions, including authorized service configuration, for the agreed services and transfers. If Union or Member State law requires other processing, Processor will inform Customer before processing unless that law prohibits notice on important public-interest grounds. Processor will immediately inform Customer if, in its opinion, an instruction infringes applicable data-protection law.

Customer is responsible for lawful instructions, notices and any required consent, data accuracy and minimization, and the lawfulness of its collection and disclosure. Independent shared-intelligence or model-training purposes are not authorized by this addendum and require a separate lawful arrangement.

• Subject matter and purpose: providing the commerce, analytics, customer-profile, search, recommendation, campaign, experiment, attribution, chat, support inbox, content and workflow services specifically enabled by Customer.
• Nature of processing: collection, transmission, organization, storage, retrieval, analysis, inference, display, authorized disclosure, correction, export, suppression and deletion, including AI generation and automated actions where configured and, where Customer enables the support inbox, emailing visitors the replies of Customer’s team that they have not seen in the chat.
• Data subjects: Customer’s authorized users, storefront visitors, customers, prospects, support contacts and people whose data Customer lawfully supplies.
• Data types: contact and account details, store-scoped or pseudonymous identifiers, browser and activity data, purchase and order information, campaign and consent records, audience memberships and predictions, conversation and support content (including support tickets and a visitor’s optional reply email address), and integration or workflow records as described in the Privacy Policy and the accepted processing schedule.
• Excluded data: special-category data, criminal-record information, full payment-card credentials and children’s data unless separately agreed in writing with appropriate safeguards.
• Duration: for the agreed service term and the limited return/deletion period documented in the retention schedule in section 11, subject to legally required retention.

Processor will ensure that persons authorized to process data are bound by confidentiality or an appropriate statutory duty and receive access only as needed for their responsibilities.

Processor will implement and maintain measures appropriate to risk under GDPR Article 32, taking account of the state of the art, implementation costs and the nature, scope, context and purposes of processing. The standard security schedule is in section 10; it covers access controls, authentication and tenant separation, encryption, credential management, logging, incident handling, recovery and testing. Security changes must not materially reduce the agreed protection.

Customer is responsible for securing its accounts, endpoints, source systems and credentials, restricting user and integration permissions, and safely configuring collection and automated actions. Processor remains responsible for its own security obligations.

Customer authorizes the service providers and processing described in section 12, subject to the restrictions and transfer obligations in this addendum. Customer-selected integrations are not automatically authorized for unrelated purposes. Contact our privacy team for the applicable provider agreement and subprocessor details.

Processor will give at least 30 days’ advance written notice of a proposed addition or replacement, allowing Customer to object on reasonable data-protection grounds before the change. The parties will work to resolve the objection; if no reasonable solution is available, Customer may terminate the affected service before the change and receive a proportionate refund of its unused prepaid fees.

Processor will impose substantially the same applicable data-protection obligations on each subprocessor by written contract and remains fully liable to Customer for the subprocessor’s performance of those obligations. Providers independently selected and contracted by Customer are addressed according to their actual role; their designation does not remove Processor’s responsibilities for its own disclosures.

Taking account of the nature of processing, Processor will assist Customer through appropriate technical and organizational measures, insofar as possible, to respond to requests under GDPR Chapter III. Processor will promptly forward requests relating to Customer data and will not respond substantively except on Customer’s instructions or as required by law.

Taking account of the nature of processing and information available to it, Processor will assist Customer with security obligations, breach assessment and notification, data-protection impact assessments and prior consultation under GDPR Articles 32–36. The parties will coordinate promptly enough to allow Customer to meet applicable deadlines. Any agreed charges for additional assistance must not prevent compliance with mandatory obligations.

Processor will notify Customer without undue delay after becoming aware of a personal data breach affecting Customer data. The notice will describe the nature of the breach, affected data and subjects and approximate numbers where known, a contact point, likely consequences and measures taken or proposed to address and mitigate it. Information may be provided in phases without undue further delay.

Processor will take reasonable measures to contain, investigate and remediate the breach and cooperate with Customer. Customer determines its own authority and individual notifications, with Processor’s assistance. A controller’s potential 72-hour authority-notification deadline does not give Processor permission to delay its notice to Customer.

Processor will make restricted international transfers only on documented instructions and with a valid GDPR Chapter V mechanism. Section 12 identifies the service destinations and provider safeguards. Applicable accepted provider terms supply the transfer clauses; this addendum does not replace those clauses or remove the need for necessary supplementary measures and assessment.

Where Standard Contractual Clauses are required, the parties must execute the applicable European Commission clauses with the correct module, options and completed annexes. Those clauses prevail over conflicting terms. This addendum does not itself execute or replace the clauses, and an Article 28 processing agreement alone is not an international-transfer mechanism.

At the end of services, at Customer’s choice, Processor will return or delete the personal data and delete existing copies unless Union or Member State law requires storage. Return format, transition access, completion deadlines and backup expiry must be specified in the accepted schedule. Retained data remains protected, is restricted to the permitted purpose and is deleted when the legal requirement ends.

Where immediate selective deletion from a backup is technically impracticable, the completed schedule must define a limited expiry period, isolation from ordinary processing and reapplication of deletion instructions after any restoration. No indefinite backup exception is created. Processor will provide confirmation of completed deletion on request.

Processor will make available information necessary to demonstrate compliance with this addendum and GDPR Article 28, and allow and contribute to audits, including inspections, by Customer or an auditor mandated by Customer. The parties may use relevant reports and reasonable confidentiality, security and scheduling arrangements, without preventing a necessary audit or a supervisory authority’s lawful access.

Any commercial liability terms remain subject to mandatory GDPR rights and applicable transfer clauses. This addendum does not restrict individuals’ remedies, supervisory-authority powers, or the parties’ statutory liability and contribution rights.

The standard service schedule consists of the Customer identity in the acceptance record, the enabled services and documented instructions in section 2, the measures below, retention in section 11 and providers in section 12. Processing beyond this scope requires an agreed written amendment.

• Parties and instructions: the recorded Customer business and authorized account contact instruct ONECOMPASS LIMITED through enabled store features, scoped API requests and configured workflows. Section 2 identifies the purposes, data types and subjects. Processing continues for the service term followed by the exit period in section 11; excluded data remains prohibited unless separately agreed.
• Access and confidentiality: Firebase authentication, registered server sessions, role-based account permissions, merchant/site isolation and scoped integration credentials restrict access. Secrets are stored through managed secret services; selected sensitive integration values and erasure selectors are encrypted. Personnel access is limited to assigned responsibilities and confidentiality obligations.
• Protection and response: HTTPS protects external transport; managed cloud storage supplies encryption at rest. Application validation, consent checks and approved-field telemetry reduce unnecessary processing. Security events are investigated through restricted operational logs; incident notice and assistance follow sections 5–6. Changes are validated through automated tests and release checks.
• Recovery and testing: logical expiry, recurring cleanup and configured backup cycles apply as described in section 11. Recovery access is restricted and restored data must have current erasure/suppression instructions reapplied. Customer controls its own source-system security, notices, lawful collection, credentials and feature configuration. These measures do not promise uninterrupted availability or universal encryption that prevents provider access.

Discuss a data-processing agreement

The following retention rules apply to the production service. Daily warehouse cleanup and hourly chatbot cleanup remove eligible records while preserving documented holds and unresolved privacy work. Logical expiry can prevent ordinary access before asynchronous physical deletion. No single period applies to all records or provider copies.

These periods do not extend an earlier valid erasure instruction. Linked customer-profile erasure is a separate process; it covers records that can be reliably associated with the subject and store, not every record sharing a potentially ambiguous browser identifier. Unresolved identity links require case-specific handling.

• Chatbot sessions, stored model threads and messages: 180 days from session creation, with no extension for later activity. Messages share the session deadline.
• Chatbot tool audits, discount actions and handoffs: 365 days from record creation.
• Support tickets, support messages and reply-email records: they expire with the chatbot session the ticket belongs to, at most 180 days from session creation. A visitor’s reply email address is deleted when the visitor removes it, when it bounces (a hashed form remains on the ticket so that it is not reused) or when the ticket expires; linked customer-profile erasure removes it, and that hashed form, from Customer’s tickets. Reply-email records keep a hashed recipient address until they expire with the ticket.
• Chatbot turn observations and evaluation runs: 90 days from record creation.
• Terminal knowledge-ingestion and product-embedding jobs: 30 days from terminal completion. Active jobs and current knowledge sources/chunks have separate operational purposes and require a separate retention decision.
• Warehouse: attribution event/history partitions use 90, 120 or 763 days; profile-feature history uses 400 days. Row-level cleanup removes intent traits at their recorded expiry (a 365-day fallback where a legacy expiry is missing), expired or 400-day inactive identity edges, and 400-day inactive identifiers no longer needed by live controls. Completed privacy requests expire after 90 days; audit history, expired affirmative grants and inactive suppressions use 25 calendar months, with dependency safeguards. Active denials, active suppression and unresolved requests are preserved only for their continuing rights-handling purpose. Model history expires after 763 days.
• Other application records: merchant-assistant conversations use 30 days, imported order versions seven days and customer-profile audits 25 months. Current account settings and uploaded knowledge remain for the enabled service; support, security and legal records remain only for the documented purpose, applicable obligation or claim. Current consent/suppression controls are reviewed at service exit once reintroduction and downstream processing have ended.
• Archives and recovery: selected archive prefixes use 90 or 763 days plus seven-day soft deletion. Automatic analytics snapshots use an eight-day cycle, including after source-disk deletion; the retired manual exceptions have been deleted. BigQuery retains deleted versions during its configured time-travel window and a further seven-day fail-safe period. A successful application deletion is not a promise of immediate physical removal from every recovery copy.
• Exit: the privacy contact coordinates return/deletion, integration revocation, scoped removal from active stores and indexes, provider instructions, residual verification and confirmation. The operational target is 30 days after the agreed cutoff, subject to the deadline in the accepted order/DPA and any shorter applicable rights deadline. Disclosed backup/provider cycles and specifically documented legal holds are separate; retained copies stay restricted and restoration must reapply deletion instructions.
• Provider deletion limits are distinct from application retention: Google’s published Cloud DPA allows up to 30 days for recovery after the service term, followed by deletion within its stated maximum of 180 days, subject to its exceptions. RudderStack’s published DPA describes 30-day backups and deletion on request or termination within 30 days, with backup copies within 90 days. These are vendor contractual limits, not configured Upsurge retention periods or a completed customer exit deadline.

Google Cloud Data Processing Addendum

RudderStack Data Processing Addendum

The following standard service register describes the enabled provider families, data access and processing locations. Audits on 11–12 October 2026 established the deployed locations. ONECOMPASS has confirmed its use of Google Cloud/Firebase, Gemini, Cloudflare R2, Dash0, Typesense Cloud, RudderStack and Twilio SendGrid under company accounts and acceptance of their data-processing terms. This confirmation was received on 11 October 2026; acceptance dates, agreement versions and the account-specific transfer documents have not been independently inspected. The relevant accepted account agreement identifies the contracting entity and applicable transfer clauses. The privacy team maintains the supporting account and transfer record and supplies relevant details on request; no unobserved contract version or provider certification is asserted.

Provider-published SCC or adequacy provisions describe available safeguards. They do not establish that those provisions cover this Customer, this account, every data flow or every onward recipient. Public availability of an EU region is also not evidence that it has been selected.

• Google Cloud/Firebase: hosting, authentication, databases, storage and processing of service data. Deployed Firestore and primary runtime/storage are US-based; attribution warehouse datasets are in the EU and identity-graph datasets are in the US. The accepted Google Cloud/Firebase data-processing terms govern the account, with their applicable international-transfer provisions.
• Google Gemini/Vertex AI: prompts, permitted context, outputs and usage information. Current generation uses the direct Gemini API; knowledge embeddings use it with a Vertex fallback; product embeddings use Vertex AI in us-central1. Reviewed source does not enable Files, explicit caching, Interactions, Live or grounding. The deployed Gemini keys were matched to billing-enabled projects, including the production project whose paid tier was verified. Direct Gemini processing is not restricted to the Vertex AI region. Google’s published abuse-monitoring and feature-specific retention rules remain relevant.
• Cloudflare R2: static SDK asset storage and delivery, including request metadata. Both buckets use the default jurisdiction path and report Eastern North America (ENAM). Their only lifecycle rule aborts incomplete uploads after seven days; it does not expire completed objects. Object-access logging is not enabled. This configuration makes no EU-jurisdiction commitment.
• Dash0: monitoring through the application telemetry collector, with API and ingestion in europe-west4 on Google Cloud in the Netherlands. The default dataset retains logs, traces, metrics, profiling and web events for 30 days. The collector filters operational telemetry to approved fields before forwarding. Support and onward access must be covered in the transfer schedule.
• Typesense Cloud: search indexes and provider usage information. Search is enabled in both serving environments. The production cluster is in Frankfurt, Germany; staging is in Northern Virginia, United States. Both are single-region, single-node clusters, and the inspected console did not show Search Delivery Network enabled. Provider usage records and support access are separate from index location.
• RudderStack: platform identity/intent forwarding is enabled in both serving environments; separate merchant-selected exports have their own configuration. The platform workspace uses US Prod, with sample-event storage enabled for a rolling 30 days. Its published DPA allows selected event storage up to 30 days; ordinary transient-processing limits do not override that selection. Complete the lawful-purpose, role, field and onward-recipient assessment for each path.
• Twilio SendGrid: platform notifications, support-inbox reply emails to Customer’s visitors, and separate merchant-selected email connections. Support-inbox emails are sent from the platform address under the store’s name, with click tracking turned off; SendGrid delivery events for them are used only to stop email to an address that bounced. Both deployed accounts identify Onecompass Limited, and the production account is paid. The platform and merchant connector use the global service; no EU-specific endpoint is configured. Published retention varies by record: retry bodies up to 72 hours, scheduled messages up to six days, content samples seven days and general metadata 37 days. Suppressions and marketing records may remain until deletion; the vendor DPA provides a separate one-year backup period after termination. These are not a universal email-retention period. The accepted Twilio data-processing terms and their applicable transfer provisions govern provider processing; exit instructions follow section 11.

Twilio SendGrid retention guidance

Twilio Data Protection Addendum