Data Processing Agreement (DPA)

Version 1.0.0

This Data Processing Agreement is offered by OMESTA SYSTEMS LLC (operating the Hyper Tracking service) for execution with customers of the Service. It is a binding legal document. Each party should obtain its own legal advice before signing. Capitalised terms have the meanings given below or in the Agreement.

This Data Processing Agreement ("DPA") forms part of, and is governed by, the Hyper Tracking Terms of Service available at https://hypertracking.io/legal/terms (the "Agreement") between OMESTA SYSTEMS LLC, a Wyoming limited liability company with its principal place of business at 5830 E 2nd St, Ste 7000 #33555, Casper, Wyoming 82609, United States, which operates the Hyper Tracking server-side ad-attribution service ("Hyper Tracking" or the "Processor"), and the customer identified in the Agreement (the "Customer" or "Controller"). It is effective as of the date the Customer accepts the Agreement (the "Effective Date").

This DPA reflects the parties' agreement on the processing of Personal Data in connection with Hyper Tracking's server-side ad-attribution service (the "Service"), and is intended to satisfy the requirements of Article 28 of Regulation (EU) 2016/679 (the "GDPR"), the United Kingdom General Data Protection Regulation as it forms part of UK domestic law (the "UK GDPR"), the Federal Data Protection Act of 25 September 2020 (the "Swiss FADP"), and the California Consumer Privacy Act as amended by the California Privacy Rights Act (the "CCPA"), in each case to the extent applicable.

1. Definitions

Capitalised terms used but not defined in this DPA have the meanings given to them in the Agreement or in the GDPR. The following definitions apply throughout:

• "Affiliate" means any entity that directly or indirectly controls, is controlled by, or is under common control with a party.
• "Controller", "Processor", "Data Subject", "Personal Data", "Processing", "Personal Data Breach", "Special Categories of Personal Data", and "Supervisory Authority" have the meanings given to them in Article 4 of the GDPR.
• "Customer Personal Data" means Personal Data that the Processor processes on behalf of the Controller in connection with the Service, as further described in Annex I.B.
• "Data Privacy Framework" or "DPF" means the EU-U.S. Data Privacy Framework, the UK Extension to the EU-U.S. DPF, and the Swiss-U.S. DPF, as applicable, administered by the U.S. Department of Commerce.
• "Data Subject", in the context of Customer Personal Data, refers to the end users (visitors and customers) of the Controller's website whose data is processed via the Service.
• "Restricted Transfer" means a transfer of Customer Personal Data from a jurisdiction in which the transfer is regulated (including the EEA, the UK, and Switzerland) to a jurisdiction not subject to an applicable adequacy decision.
• "SCCs" means the standard contractual clauses approved by the European Commission in Implementing Decision (EU) 2021/914 of 4 June 2021, as amended or superseded.
• "Sub-processor" means any third party engaged by the Processor to process Customer Personal Data on behalf of the Controller, as listed in Annex III.
• "Technical and Organisational Measures" or "TOMs" has the meaning given in Annex II.
• "UK Addendum" means the International Data Transfer Addendum to the EU Commission SCCs issued by the UK Information Commissioner under section 119A of the UK Data Protection Act 2018, as amended.

2. Roles, scope, and instructions

2.1 Roles

For the purposes of Customer Personal Data, the Customer is the Controller and Hyper Tracking is the Processor. The parties acknowledge that this allocation reflects the operational reality of the Service: the Customer determines the purposes and means of processing the Personal Data of its website's end users (the Data Subjects); Hyper Tracking processes that data solely on the Customer's documented instructions to provide the Service.

For Hyper Tracking's own processing of the Customer's account data (the names and contact details of the Customer's authorised users, billing information, and similar) Hyper Tracking acts as an independent Controller. That processing is described in Hyper Tracking's Privacy Policy available at https://hypertracking.io/legal/privacy and is not subject to this DPA.

For the avoidance of doubt: Hyper Tracking does not sell or share (as those terms are defined in the CCPA) Customer Personal Data, and the parties agree that Hyper Tracking is a Service Provider to the Customer within the meaning of CCPA § 1798.140(ag).

2.2 Documented instructions

The Processor will Process Customer Personal Data only:

(a) on the documented instructions of the Controller, including with regard to transfers to a third country, and as set out in this DPA, the Agreement, the configuration of the Service that the Controller selects, and the operations that the Controller performs through the Service; and

(b) where required to do so by Union or Member State law to which the Processor is subject, in which case the Processor will (unless that law prohibits it on important grounds of public interest) inform the Controller of that legal requirement before processing.

The Controller's use of the Service in accordance with the Agreement constitutes documented instructions. Any additional or alternate instructions must be in writing (email is sufficient) and may be subject to additional fees where they materially expand the scope of the Service.

The Processor will inform the Controller without undue delay if, in its opinion, an instruction infringes the GDPR or other applicable data protection law. In such case, the Processor may suspend performance of the affected instruction until the Controller has confirmed or modified it.

2.3 Subject matter, duration, nature, purpose, types of data, categories of subjects

These are set out in Annex I.B in compliance with Article 28(3) GDPR.

2.4 Limits on processing

The Processor will not:

(a) Process Customer Personal Data for its own commercial purposes, including training or improving general-purpose machine-learning models that are not exclusively dedicated to the Controller's instance of the Service;

(b) Sell or Share Customer Personal Data, as those terms are defined in the CCPA;

(c) Combine Customer Personal Data with Personal Data obtained from any other source, except as strictly necessary to provide the Service to the Controller (for example, joining a click identifier captured from the Controller's website with conversion data received from the Controller's Stripe or Shopify account);

(d) Process Customer Personal Data outside the direct business relationship between the parties, except as required by law.

3. Data minimisation; the data boundary

The Processor warrants that the Service is engineered to collect from the Controller's website only the discrete fields necessary for ad attribution, and to pass all other request and response content through unread. The canonical, code-enforced enumeration of fields read, fields denied, paths denied, and request bodies inspected is maintained by the Processor as its Data Boundary Policy, which is incorporated into this DPA by reference, reproduced in summarised form in Annex I.B, and provided to the Controller on request.

In particular, the Processor warrants that:

(a) The Service does not read passwords, payment-card data, session tokens, or any HTTP request body other than email-field values on a small allowlist of checkout-related URL paths; that allowlist is enumerated in the Data Boundary Policy.

(b) The Service does not read HTTP response bodies for any purpose.

(c) Where an email value is read on a checkout path, the Service computes a SHA-256 hash of the lower-cased email at the network edge and transmits only that hash to its central API. The plaintext email is never stored, logged, or transmitted off the edge node.

(d) Where an IP address is observed (via the CF-Connecting-IP header provided by Cloudflare), the Service computes a SHA-256 hash and transmits only that hash. The plaintext IP is never stored.

(e) Compliance with these constraints is enforced by automated tests in the Processor's continuous-integration pipeline, including regex scans for PCI-Luhn, U.S. Social Security Number, JSON Web Token, and API-key patterns. A violation fails the build and prevents the offending code from reaching production.

The Processor will provide a copy of the then-current Data Boundary Policy to the Controller on request, including any subsequent amendments. Material amendments that reduce the scope of fields read or that harden constraints will take effect immediately. Material amendments that expand the scope of fields read will be subject to the change-notification mechanic in Section 6 (sub-processors) by analogy: the Processor will notify the Controller at least thirty (30) days in advance.

4. Confidentiality

The Processor will ensure that any natural person authorised to Process Customer Personal Data has committed themselves to confidentiality or is under an appropriate statutory obligation of confidentiality.

The Processor will limit access to Customer Personal Data to those of its personnel and Sub-processor personnel who need access to provide the Service or to comply with applicable law, and will require all such personnel to complete training in data protection appropriate to their role.

5. Security — Technical and Organisational Measures

The Processor will implement and maintain the Technical and Organisational Measures set out in Annex II, and will not materially decrease the overall level of security those measures provide during the term of the Agreement.

The Controller acknowledges that the Service operates as a shared multi-tenant platform on the infrastructure of the Sub-processors listed in Annex III, and that the Technical and Organisational Measures of those Sub-processors form part of the security posture of the Service.

6. Sub-processors

6.1 General authorisation

The Controller grants the Processor a general authorisation to engage the Sub-processors listed in Annex III, and to engage additional Sub-processors in accordance with this Section 6.

6.2 Notice of new Sub-processors

The Processor will inform the Controller of any intended addition or replacement of a Sub-processor at least thirty (30) days before that Sub-processor begins Processing Customer Personal Data, by updating the public Sub-processor list at https://hypertracking.io/legal/subprocessors and by sending notice to the email address designated by the Controller in the Service.

6.3 Right to object

The Controller may object to the engagement of a new Sub-processor on reasonable data-protection grounds, by sending written notice to the Processor within fifteen (15) days of the Processor's notice. The parties will work in good faith to resolve the objection. If the parties cannot resolve the objection within thirty (30) days of the Controller's notice, the Controller may terminate the affected portion of the Service for convenience and receive a pro-rata refund of any prepaid fees attributable to the period after termination.

6.4 Sub-processor obligations

The Processor will impose, by written contract, data-protection obligations on each Sub-processor that are no less protective than those imposed on the Processor under this DPA. The Processor will remain fully liable to the Controller for the performance of each Sub-processor's obligations.

6.5 Sub-processor list

The Sub-processors authorised on the Effective Date are set out in Annex III.

7. International transfers

7.1 Transfer mechanisms

To the extent the Processor's or any Sub-processor's processing of Customer Personal Data constitutes a Restricted Transfer, the parties will rely on the following transfer mechanisms in the order listed, and the Processor will at all times maintain a valid transfer mechanism for each Restricted Transfer:

(a) Adequacy. Where the European Commission, the UK Secretary of State, or the Swiss Federal Council (as applicable) has issued an adequacy decision in respect of the recipient's jurisdiction or certification, the parties will rely on that adequacy decision. As of the Effective Date, this includes transfers to recipients certified under the EU-U.S. Data Privacy Framework (and the UK Extension and Swiss-U.S. DPF, as applicable). The Processor will notify the Controller without undue delay if a recipient on which it relies ceases to be DPF-certified, and will fall back to the mechanism in (b).

(b) Standard Contractual Clauses. Where adequacy is not available or ceases to be available, the parties will rely on the 2021 SCCs (Module 2 or Module 3 as applicable to the transfer), which are incorporated into this DPA by reference and form an integral part of it. The annexes to the SCCs are populated by the corresponding annexes of this DPA: SCC Annex I.A by Annex I.A of this DPA; SCC Annex I.B by Annex I.B; SCC Annex II by Annex II of this DPA; SCC Annex III (where Module 3 applies) by Annex III. The optional docking clause is adopted. The optional Clause 7 is adopted. Clause 9 option 2 (general written authorisation) is selected, with the time period set in Section 6.2 of this DPA. Clause 11(a) optional language (independent dispute resolution) is not adopted. Clause 17 governing law: the laws of Ireland. Clause 18 forum: the courts of Ireland.

(c) UK Addendum. Where the Restricted Transfer is from the United Kingdom, the parties incorporate the UK Addendum by reference, with Tables 1, 2, and 3 populated from the corresponding annexes of this DPA, and Table 4 ("which Parties may end this Addendum when the ICO issues a revised Approved Addendum") selected as both Parties.

(d) Swiss FADP. Where the Restricted Transfer is from Switzerland, the parties incorporate the SCCs as adapted by the Swiss Federal Data Protection and Information Commissioner's notice of 27 August 2021, with references to the GDPR construed as references to the FADP and references to EU Member State authorities construed as references to the FDPIC, where applicable.

7.2 Transfer Impact Assessment

The Processor has performed a Transfer Impact Assessment ("TIA") for each of its current Restricted Transfers and the assessment is available to the Controller on request. The Processor will update the TIA on a material change to applicable law in any recipient jurisdiction.

For a Controller configured region='eu', the visitor Customer Personal Data described in Annex I.B is stored in and read from the EU data plane (an EU Supabase project physically located in the EU) and does not leave the EU; to that extent, the Processor's storage of that data is not a Restricted Transfer. The Controller's account/config data and operator-side authentication remain in the U.S. control plane and continue to rely on the transfer mechanisms set out in Section 7.1 (DPF adequacy, with the 2021 SCCs as fallback). This residency split does not affect Section 7.3 (onward transfers to ad platforms selected by the Controller), which remain transfers to those platforms as independent Controllers.

7.3 Onward transfers by ad-platform sub-processors

The Controller acknowledges that the Service's purpose is to push conversion events to advertising platforms (Meta, Google, TikTok) selected by the Controller in the Service's configuration. Each such push is a transfer of Customer Personal Data to that platform, which in turn acts as an independent Controller of the data it receives for its own attribution and measurement purposes. The Controller is responsible for:

(a) selecting which platforms to enable;

(b) maintaining a lawful basis under the GDPR (typically consent under Art. 6(1)(a)) for each such transfer;

(c) ensuring that its end users are informed of those transfers in its own privacy notice; and

(d) reviewing the recipient platform's own privacy and transfer terms.

The Processor disclaims responsibility for the recipient platform's processing of Customer Personal Data once received. Status of common recipients as of the Effective Date: Meta is DPF-certified; Google is DPF-certified; TikTok is not DPF-certified and relies on its own SCCs for transfers out of the EEA. The Controller is encouraged to consult the recipient platform's documentation directly. These statuses can change; the Controller should re-verify the current certification status of each enabled platform.

8. Data subject rights

8.1 Assistance to the Controller

Taking into account the nature of the processing, the Processor will assist the Controller by appropriate technical and organisational measures, insofar as this is possible, in fulfilling the Controller's obligations to respond to requests from Data Subjects exercising their rights under the GDPR (Articles 12–22), the UK GDPR, the Swiss FADP, and analogous rights under the CCPA (including the rights to know, delete, correct, and limit use of sensitive personal information).

8.2 Self-service tooling

The Processor exposes the following endpoints for the Controller's use in fulfilling Data Subject rights without further Processor involvement:

(a) Right of access (GDPR Art. 15) / Right to know (CCPA). POST /api/data-subject/export — returns, as a JSON document, all Customer Personal Data the Processor holds in respect of the identified Data Subject. The export deliberately excludes the Controller's operational secrets (e.g. encrypted Stripe API keys, ad-platform OAuth tokens) which are not Personal Data of the Data Subject. The endpoint accepts a SHA-256 hash of the email address (the Processor never holds the plaintext email and so identifies the Data Subject by hash).

(b) Right to erasure (GDPR Art. 17) / Right to delete (CCPA). DELETE /api/data-subject — atomically deletes from the Service's database all Customer Personal Data the Processor holds in respect of the identified Data Subject, in a single transaction so a partial delete is not possible. The endpoint preserves cross-tenant data integrity (visitors that another identity in the same Controller's account also references are not orphaned). Each invocation writes one row to the Data Subject Request audit log; the audit row is preserved for 36 months as required by Section 10.

Both endpoints are scoped to the Controller's account by an admin token and filter every query by the Controller's merchant_id. The Controller is responsible for forwarding lawful Data Subject requests to these endpoints within the Controller's own response timeline (one calendar month under the GDPR, with the possibility of extension under Article 12(3); 45 days under the CCPA).

8.3 Direct requests to the Processor

If a Data Subject contacts the Processor directly with a request to exercise their rights in respect of Customer Personal Data, the Processor will, without undue delay, forward the request to the Controller and will not respond substantively to the Data Subject except to acknowledge receipt and direct the Data Subject to the Controller, unless instructed otherwise by the Controller or required to respond by applicable law.

9. Personal Data Breach

9.1 Notification

The Processor will notify the Controller without undue delay, and in any event within seventy-two (72) hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data. The notice will include, to the extent then known:

(a) the nature of the Personal Data Breach, including (where possible) the categories and approximate number of Data Subjects and Customer Personal Data records concerned;

(b) the likely consequences of the Personal Data Breach;

(c) the measures taken or proposed to be taken to address the Personal Data Breach, including, where appropriate, measures to mitigate its possible adverse effects; and

(d) the contact details of the Processor's contact point from whom more information can be obtained (privacy@hypertracking.io).

The Processor's notice is informational and does not constitute an acknowledgement by the Processor of any fault or liability with respect to the Personal Data Breach.

9.2 Cooperation

The Processor will cooperate with the Controller and provide reasonable assistance to enable the Controller to meet its own notification obligations under Articles 33 and 34 of the GDPR (and analogous obligations under other applicable law).

9.3 Mitigation

The Processor will take, without undue delay, the steps reasonably required to investigate, contain, and remediate the Personal Data Breach.

10. Retention; deletion and return

10.1 Default retention

The Processor will retain Customer Personal Data only for as long as necessary to provide the Service or as required by law. Default retention periods are:

These periods are enforced automatically by a daily automated retention process. The Controller may configure shorter retention via the dashboard; the Controller may not extend retention beyond these defaults.

10.2 End of services

On termination of the Agreement, the Processor will, at the Controller's choice (made in writing within thirty (30) days of termination), either:

(a) delete all Customer Personal Data within sixty (60) days of termination (or of the Controller's notice, whichever is later); or

(b) return all Customer Personal Data to the Controller in a structured, commonly-used, and machine-readable format (the same JSON format produced by the POST /api/data-subject/export endpoint, aggregated across the Controller's account), and then delete it.

If the Controller does not make a choice within the thirty-day window, the Processor will delete the data per option (a).

10.3 Backups

The Processor's encrypted database backups are retained on a rolling 30-day basis. Customer Personal Data deleted under Section 10.1 or 10.2 may persist in such backups for up to 30 days after deletion before being overwritten by the standard backup-rotation process. During that window the Processor will not restore the data except to recover from a Personal Data Breach or comply with applicable law.

10.4 Statutory retention

Notwithstanding the foregoing, the Processor may retain Customer Personal Data for longer where required to comply with applicable law. Such retained data will continue to be subject to the confidentiality and security obligations of this DPA.

11. Audit

11.1 Audit reports

The Processor will, on the Controller's written request and no more than once per twelve-month period (except following a Personal Data Breach affecting Customer Personal Data, where the limit does not apply), make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Article 28 of the GDPR and this DPA.

As of the Effective Date, the Processor does not hold a SOC 2 Type II report or an ISO/IEC 27001 certification. In their place, and to demonstrate compliance, the Processor will make available:

(a) its then-current Data Boundary Policy and the summary of Technical and Organisational Measures in Annex II;

(b) a written response to the Controller's reasonable security questionnaire; and

(c) once obtained, any third-party audit attestation (such as a SOC 2 report or ISO/IEC 27001 certificate) and any penetration-test summary (sanitised for confidentiality). The Processor will notify the Controller when such attestations become available.

11.2 Audits and inspections

If the information listed in Section 11.1 is not sufficient to demonstrate compliance with this DPA, the Controller may, after first requesting and considering that information, conduct an on-site inspection of the Processor's relevant facilities. Such inspections will be:

(a) carried out at the Controller's expense (except where the inspection reveals a material non-compliance with this DPA, in which case the Processor will bear the Controller's reasonable costs);

(b) conducted at a mutually-agreed time on at least thirty (30) days' written notice;

(c) conducted by the Controller or by a mutually-agreed independent third-party auditor, which auditor is not a competitor of the Processor and is bound by appropriate confidentiality obligations;

(d) limited to the Processor's processing of Customer Personal Data and not extended to the Processor's processing of any other customer's data; and

(e) carried out in a manner that does not disrupt the Processor's normal business operations or compromise the security or confidentiality of any other customer's data.

The Processor may redact or refuse access to information that, if disclosed, would compromise the security or confidentiality of another customer or of the Processor's own infrastructure (e.g. specific cryptographic keys, production credentials, or other-customer Personal Data).

11.3 Supervisory Authority

Nothing in this Section 11 limits the audit rights of a Supervisory Authority under applicable data protection law.

12. Data Protection Impact Assessments and prior consultations

The Processor will, on the Controller's reasonable request, provide information to assist the Controller in carrying out Data Protection Impact Assessments and prior consultations with Supervisory Authorities under Articles 35 and 36 of the GDPR, taking into account the nature of the processing and the information available to the Processor.

The Processor will respond within a reasonable time, which will be no more than thirty (30) days for routine requests. The Processor may charge a reasonable fee for assistance that is non-routine, materially time-consuming, or repeated; the Processor will agree any such fee with the Controller in advance.

13. Liability

The parties' respective liabilities arising out of or in connection with this DPA are subject to the limitations and exclusions of liability set out in the Agreement, except to the extent such limitation or exclusion would render this DPA non-compliant with the GDPR or other applicable data protection law, in which case the maximum permitted limitation will apply.

For the avoidance of doubt: liability of either party to a Data Subject under Article 82 of the GDPR is allocated as set out in the GDPR and the SCCs (where applicable), without regard to any limitation in the Agreement.

14. Term and termination

This DPA takes effect on the Effective Date and continues for the term of the Agreement. The Processor's obligations under Sections 4 (Confidentiality), 9 (Personal Data Breach — to the extent the breach occurred during the term), 10 (Retention; deletion and return), 11 (Audit — for one year following termination), and any applicable transfer-mechanism Section (7) survive termination of the Agreement until the Processor has deleted or returned all Customer Personal Data.

15. Order of precedence; miscellaneous

In the event of a conflict between the documents that govern the parties' relationship, the order of precedence is:

1. The SCCs and the UK Addendum (where applicable to a Restricted Transfer);
2. This DPA;
3. The Agreement;
4. Any other document the parties have signed.

This DPA may be updated by the Processor from time to time to reflect changes in applicable law, regulatory guidance, or the operation of the Service. The Processor will provide the Controller with at least thirty (30) days' notice of any material amendment by posting the new version at https://hypertracking.io/legal/dpa and emailing the Controller's designated contact. If the Controller does not accept the amendment, the Controller's exclusive remedy is to terminate the Agreement for convenience under the relevant termination provision of the Agreement.

This DPA is governed by, and construed in accordance with, the law specified in the Agreement, except where mandatory data-protection law specifies otherwise. The parties submit to the jurisdiction specified in the Agreement for any disputes arising out of or in connection with this DPA, except where mandatory data-protection law specifies otherwise.

Annex I.A — Parties

Controller (data exporter)

• Name: the Customer identified in the Agreement
• Address: as set out in the Customer's account in the Service
• Contact person: as set out in the Customer's account in the Service
• Activities relevant to the data transferred: operation of the website(s) served by Hyper Tracking and ad campaigns associated therewith
• Role: Controller

Processor (data importer)

• Name: OMESTA SYSTEMS LLC, a Wyoming limited liability company, operating the Hyper Tracking service
• Address: 5830 E 2nd St, Ste 7000 #33555, Casper, Wyoming 82609, United States
• Contact person for data-protection enquiries: privacy@hypertracking.io
• Activities relevant to the data transferred: operation of the Service
• Role: Processor

Annex I.B — Description of the processing

Subject matter

The Processor's provision of the Service to the Controller, including:

(a) operation of a per-Controller "thin Worker" that proxies HTTP requests between the Controller's website visitors and the Controller's origin server, captures click identifiers and (on checkout-related URL paths only) email hashes, and forwards a small set of attribution events to the Processor's central API. Where the Controller instead installs the Service via the customer-CDN edge module or the backend SDK (the "producer" shapes) or the first-party pixel, the same allowlisted signals are read by code running in the Controller's own infrastructure and posted to the same central API;

(b) operation of a central API that ingests those events, processes Stripe and Shopify webhook payloads to record purchases, stitches visitor and identity data using deterministic and probabilistic methods, and pushes resulting conversion events to advertising platforms selected by the Controller;

(c) operation of a dashboard that allows the Controller's authorised users to view, export, and delete the data described above.

Duration

The duration of the Agreement, plus the retention periods set out in Section 10 of this DPA.

Nature and purpose of the processing

Server-side ad attribution, including: capture of click identifiers and UTM parameters from URL query strings; setting of a first-party identification cookie (_ht_id); hashing of email addresses on checkout paths; hashing of visitor IP addresses; reception of webhooks from Stripe and Shopify recording purchases; identity stitching; and outbound transmission of conversion events to ad platforms selected by the Controller.

Location of processing

Where the Personal Data is processed depends on the Controller's configured region. By default (region='us'), all Personal Data is processed in the U.S. data plane. For a Controller configured region='eu', the visitor Customer Personal Data in the Field List (sessions, identities, purchases, attribution, and Halo matches) is stored in and read from an EU data plane (an EU Supabase project physically located in the EU), while the Controller's account/config data and operator-side authentication remain in the U.S. control plane. See Annex III and Section 7.2.

Categories of Data Subjects

End users (visitors and customers) of the Controller's website.

Categories of Personal Data

The following Personal Data is processed (the "Field List"):

The full enumerated list, including denied paths and never-read fields, is maintained in the Processor's Data Boundary Policy, which is incorporated by reference and provided to the Controller on request.

Special Categories of Personal Data

The Service is not intended to process Special Categories of Personal Data. The Controller will not configure the Service in a manner that causes Special Categories of Personal Data to be sent to the Service (e.g. by routing a checkout flow whose body contains health data, religious affiliation, or similar through the email-allowlist code path; the Service's body parser walks only an email-field allowlist and will not extract such fields, but the Controller is responsible for not provoking inadvertent collection).

Frequency of processing

Continuous during the Controller's operational hours, plus daily batch processes (retention sweep at 02:00 UTC, Stripe reconciliation hourly, spend sync at 03:00 UTC, click enrichment at 04:00 UTC).

Sub-processors

See Annex III.

Retention

See Section 10 of this DPA.

Annex II — Technical and Organisational Measures

The Processor implements and maintains the following Technical and Organisational Measures, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the risks of varying likelihood and severity for the rights and freedoms of natural persons.

II.1 Pseudonymisation and encryption

• Encryption in transit. All connections between the Controller's website, the Service, and the Service's Sub-processors are TLS 1.2 or higher. Cloudflare provides edge TLS termination on the Controller's domain via Cloudflare for SaaS Custom Hostnames.
• Encryption at rest. All Customer Personal Data is stored on encrypted storage volumes managed by the Sub-processors (Supabase: AES-256 at the Postgres-storage layer; Cloudflare KV / R2 / Durable Objects: AES-256 at the Cloudflare-storage layer).
• Field-level encryption. Sensitive fields (Stripe webhook secrets, ad-platform OAuth tokens) are encrypted at the application layer with AES-256-GCM using a key (ENCRYPTION_KEY) held in Cloudflare Workers' encrypted secrets store, separately from the database. A breach of the database alone does not yield those secrets.
• Pseudonymisation. Email addresses and IP addresses are SHA-256-hashed before being stored or transmitted off the network edge. The Service does not store plaintext emails or plaintext IPs at any point.

II.2 Confidentiality, integrity, availability, and resilience

• Logical access control. Postgres Row-Level Security ("RLS") policies scope every database query to the Controller's merchant_id. The service-role key that bypasses RLS is held only by the central API in Cloudflare Workers' encrypted secrets store. Database access is over TLS with IP-allowlisted endpoints where supported by the platform.
• Network access control. All access to the Service's central API is over HTTPS. Webhook endpoints verify upstream signatures (Stripe Stripe-Signature HMAC; Shopify X-Shopify-Hmac-Sha256). The /ingest endpoint verifies a per-merchant HMAC-SHA256 signature.
• Multi-tenant isolation. Every database query filters by merchant_id; per-merchant kill-switches (Cloudflare KV flag) propagate within 30 seconds.
• Resilience. The Service runs on Cloudflare's global edge network and Supabase's managed Postgres with automated daily backups. The thin Worker uses passThroughOnException so a Worker crash never breaks the Controller's site availability.
• Vulnerability management. Dependencies are reviewed via automated pull-request checks. Critical vulnerabilities are patched within 7 days of public disclosure; high vulnerabilities within 30 days.

II.3 Restoration after a physical or technical incident

• Daily encrypted backups of the Postgres database with a 30-day rolling retention.
• Disaster-recovery procedures are tested at least annually.

II.4 Testing, assessing, and evaluating

• All code changes are subject to peer review before merge.
• Continuous-integration pipeline includes unit, integration, and property-based tests, plus regex scans for known sensitive-data patterns (PCI-Luhn, U.S. SSN, JWT, API-key formats). The build fails on any hit.
• Independent penetration testing is planned; a sanitised summary will be made available to the Controller once completed.

II.5 User identification and authorisation

• All Controller-side dashboard access is authenticated via Supabase Auth (email-and-password with optional second factor). Sessions are bound to a signed JWT.
• All operator-side admin endpoints are gated behind a constant-time comparison of an admin token (X-Admin-Token).
• The principle of least privilege applies to internal-personnel access.

II.6 Data minimisation

• The Service is engineered to read only the fields enumerated in the Data Boundary Policy and to pass all other request and response content through unread. See Section 3 of this DPA.

II.7 Accountability

• The Processor maintains records of processing activities under Article 30 of the GDPR.
• The Processor logs every Data Subject Request through a dedicated audit log (Section 8.2 of this DPA), retained for 36 months.
• The Processor logs every identity-merge action through a dedicated audit log, retained for 36 months.

II.8 Personnel

• All personnel with access to Customer Personal Data are subject to written confidentiality obligations.
• All personnel receive data-protection training appropriate to their role on joining and at least annually thereafter.
• Departing personnel have access revoked within one business day of separation.

II.9 Sub-processor controls

• Each Sub-processor is contractually bound to data-protection terms no less protective than those in this DPA.
• The Processor reviews each Sub-processor's security posture before onboarding and at least annually thereafter.

Annex III — Sub-processors

The following Sub-processors are authorised on the Effective Date.

The current Sub-processor list is also maintained at https://hypertracking.io/legal/subprocessors. Transfer-mechanism statuses (including DPF certification) can change; the Processor commits under Section 7.1 to maintaining a valid transfer mechanism for each Restricted Transfer at all times.

For the avoidance of doubt: the Processor's transmission of conversion events to Meta Platforms, Inc., Google LLC, and TikTok / ByteDance Ltd. on the Controller's instructions is not a sub-processor relationship. Those platforms are independent Controllers of the data they receive for their own attribution and measurement purposes, as set out in Section 7.3 of this DPA.

Acceptance

This DPA is entered into electronically. By clicking "I agree" (or a substantially similar control), by creating an account, or by otherwise accepting the Agreement or using the Service, the Customer accepts and agrees to be bound by this DPA, and the DPA is deemed executed by both parties as of the Effective Date. The Customer does not need to sign or return a copy for it to be binding.

OMESTA SYSTEMS LLC has authorised and adopted this DPA for electronic acceptance by its customers; no separate countersignature by OMESTA SYSTEMS LLC is required.

The individual accepting this DPA represents and warrants that they have authority to bind the Customer. The parties are identified by Annex I.A and by the Customer's account record in the Service (legal name, address, and contact details); the Customer is responsible for keeping that record accurate.

Electronic acceptance has the same legal effect as a handwritten signature under the U.S. Electronic Signatures in Global and National Commerce Act (E-SIGN), the Uniform Electronic Transactions Act (UETA), the EU eIDAS Regulation (EU) No 910/2014, and comparable laws. The Processor records the date, time, document version, and accepting user for each acceptance, and will provide the Customer with a copy of that acceptance record on request.

Manual execution (optional)

A Customer that requires a countersigned copy — for example, for its procurement process — may instead execute this DPA by signing below and returning it to privacy@hypertracking.io; OMESTA SYSTEMS LLC will countersign and return it. Manual execution and electronic acceptance have equal effect; the Customer need not do both.

OMESTA SYSTEMS LLC (operating the Hyper Tracking service)

By: ________________________ Name: ______________________ Title: _____________________ Date: ______________________

Customer

By: ________________________ Name: ______________________ Title: _____________________ Date: ______________________