Data Processing Addendum

This Data Processing Addendum ("DPA") forms part of the agreement between Lifeguard Technology, Inc., operating as aematic ("aematic"), and the customer that has entered into that agreement ("Customer") for the aematic platform and related services (the "Agreement"). It sets out the terms on which aematic processes personal data on Customer's behalf. It is incorporated into the Agreement by reference and, in the event of a conflict concerning the processing of personal data, this DPA prevails.

Where Customer is an agency or other intermediary acting for an advertiser (a "Brand"), Customer enters into this DPA on its own behalf and, to the extent Customer is authorized to do so, on behalf of each Brand. References to Customer Data include personal data of the Brand's website visitors, and the Brand is a controller (or business) of that data. Customer represents that it has the authority to bind each Brand to this DPA or has otherwise ensured that its own agreement with the Brand is consistent with it.

1. Definitions

"Data Protection Law" means all laws applicable to the processing of personal data under the Agreement, including the California Consumer Privacy Act as amended by the California Privacy Rights Act ("CCPA"), the Texas Data Privacy and Security Act, other United States state privacy laws, and, where applicable, the EU General Data Protection Regulation ("GDPR") and the UK GDPR.

"Customer Data" means personal data that aematic processes on Customer's behalf in providing the services, as described in Annex I. It does not include the account information of Customer's personnel who hold aematic logins, which aematic processes as a controller under its Privacy Policy.

"Consumer Data" means the subset of Customer Data about visitors to a Customer or Brand website, collected by the aematic measurement script or sent by Customer's or the Brand's own systems.

"Security Incident" means a confirmed unauthorized access to, or disclosure, alteration, loss, or destruction of, Customer Data in aematic's possession or control. It does not include unsuccessful attempts or activity that does not compromise Customer Data, such as blocked requests, port scans, or failed logins.

"Subprocessor" means a third party engaged by aematic to process Customer Data in providing the services.

"Controller", "processor", "business", "service provider", "sell", "share", "personal data", "data subject", and "processing" have the meanings given to them (or their nearest equivalents) in the applicable Data Protection Law.

2. Roles

For Customer Data, Customer (and, where applicable, the Brand) is the controller or business, and aematic is the processor or service provider. aematic processes Customer Data only to provide the services described in the Agreement and this DPA. Where Customer is itself a processor or service provider to a Brand, aematic acts as Customer's subprocessor, and the obligations in this DPA are intended to be at least as protective as those Customer owes the Brand.

3. Processing instructions

aematic will process Customer Data only on Customer's documented instructions. The Agreement, this DPA, Customer's configuration of the services (including which conversions to measure and whether to enable any optional data relay), and any further written instructions Customer gives constitute those instructions. aematic will inform Customer if, in its opinion, an instruction infringes Data Protection Law, and is not obliged to follow such an instruction.

The subject matter, duration, nature, and purpose of the processing, and the types of personal data and categories of data subjects, are described in Annex I.

4. Service provider commitments

Without limiting the rest of this DPA, and for the purposes of the CCPA and other United States state privacy laws, aematic:

• will not sell or share Customer Data, and will not retain, use, or disclose it for any purpose, including any commercial purpose, other than the business purpose of providing the services under the Agreement, or as otherwise permitted by Data Protection Law;
• will not retain, use, or disclose Customer Data outside the direct business relationship between aematic and Customer;
• will not combine Customer Data with personal data it receives from or on behalf of any other person, or collects from its own interaction with individuals, except as permitted by Data Protection Law for the business purpose. One customer's data is never used to benefit another;
• will comply with Data Protection Law and provide the same level of privacy protection it requires, and will notify Customer if it determines it can no longer meet its obligations under Data Protection Law;
• grants Customer the right to take reasonable and appropriate steps to ensure aematic uses Customer Data consistently with Customer's obligations, and, on notice, to stop and remediate any unauthorized use; and
• certifies that it understands and will comply with the restrictions above.

aematic may create aggregated and de-identified data from Customer Data that does not identify any individual, any Customer, or any Brand, and may use it to operate and improve its services. aematic will not attempt to re-identify such data and will maintain it in de-identified form.

5. Confidentiality

aematic ensures that every person it authorizes to process Customer Data is bound by a written confidentiality obligation, is subject to background screening before receiving access to Customer Data, and completes security awareness training annually. Access is granted on the least-privilege principle to named individuals and revoked on the day it is no longer required.

6. Security

aematic implements and maintains the technical and organizational measures described in Annex II, and will not materially reduce the overall level of protection they provide during the term of the Agreement. aematic may update those measures as its environment evolves, provided the result is at least as protective. A fuller written security program (access control, change management, vulnerability management, backup and disaster recovery, incident response, vendor management, and related policies) is maintained and available to Customer on request under confidentiality.

7. Subprocessors

Customer authorizes aematic to engage the Subprocessors listed in Annex III. aematic will give Customer at least 30 days' written notice, by email to Customer's designated contact, before engaging a new Subprocessor that will process Customer Data. Customer may object on reasonable data protection grounds within that period. If the parties cannot resolve the objection in good faith, Customer may terminate the affected services without penalty. aematic imposes data protection obligations on each Subprocessor that are no less protective than those in this DPA, and remains responsible for each Subprocessor's performance.

8. Requests from individuals

Because aematic has no direct relationship with the individuals whose Consumer Data it processes, requests from those individuals to exercise rights under Data Protection Law are directed to Customer or the Brand. If aematic receives such a request directly, it will not respond on the merits; it will refer the individual to Customer or the Brand and, where it can identify them, notify Customer that a request was received.

When Customer forwards a request, aematic will acknowledge it within 5 business days and provide a substantive response, including any matching records or confirmation of deletion, within 10 business days, so that Customer can meet its own statutory deadline. Where a request is unusually complex or voluminous, aematic will notify Customer before that period ends with the reason and a revised date, which will in any case leave Customer reasonable time to meet its statutory deadline. Consumer Data is keyed by a first-party device identifier and by hashed identifiers, not by name or email address. Customer supplies the device identifier or the identifier to be hashed; aematic cannot locate records from a name alone and will say so rather than imply a search occurred.

9. Assistance

Taking into account the nature of the processing and the information available to it, aematic will provide reasonable assistance to Customer with data protection impact assessments, prior consultations with supervisory authorities, and inquiries or complaints from regulators or individuals, to the extent they relate to aematic's processing of Customer Data.

10. Security Incidents

aematic will notify Customer without undue delay and in any case within 72 hours of confirming a Security Incident affecting Customer Data. The period runs from the point at which aematic determines that Customer Data was, or more likely than not was, accessed or disclosed without authorization. Notification is not withheld pending a complete investigation: the first notice states what is known, what is not yet known, and when the next update will follow. Notice will describe, as the information becomes available, the nature of the incident, the categories and approximate volume of Customer Data and individuals concerned, the likely consequences, the measures taken or proposed, and a contact point. aematic will cooperate reasonably with Customer's own investigation and notification obligations. Notification of a Security Incident is not an admission of fault or liability.

11. Return and deletion

For 30 days after termination or expiry of the Agreement, Customer may export Customer Data in a standard, commercially reasonable format (CSV or JSON) at no additional charge. After that period, or earlier on Customer's written request, aematic will delete Customer Data from its production systems within 30 days and, on request, confirm deletion in writing. Deletion is automated and complete in production systems on that schedule. Copies in encrypted backups persist until those backups expire, currently up to 14 days after deletion, after which they are unrecoverable. aematic may retain Customer Data only to the extent required by law, and then only for as long as required and subject to this DPA.

12. Audit

aematic will make available to Customer the information reasonably necessary to demonstrate compliance with this DPA, including its written security program, its control mapping to the NIST Cybersecurity Framework, and completed security questionnaires, and will respond to Customer's reasonable written security questionnaire once per year. Where those materials are not sufficient, Customer or an independent auditor bound by confidentiality may audit aematic's controls relevant to Customer Data on at least 30 days' written notice, no more than once in any 12-month period unless required by a regulator or following a Security Incident, during business hours, under a mutually agreed scope, and at Customer's cost unless the audit reveals a material breach of this DPA. aematic operates no facilities of its own, so an audit takes the form of documentation, configuration, and interview review rather than a site visit. aematic does not currently hold a SOC 2 or ISO 27001 attestation and does not represent otherwise.

13. Location of processing and international transfers

aematic processes and stores Customer Data in the United States. All aematic personnel and all Subprocessors are located in the United States. Where Consumer Data relates to individuals in the European Economic Area, the United Kingdom, or Switzerland (for example, visitors to a Brand's website from those regions), and its transfer to aematic is subject to the GDPR or UK GDPR, the parties agree that the European Commission's Standard Contractual Clauses (Decision 2021/914), Module Two (controller to processor) or Module Three (processor to processor) as applicable, together with the UK International Data Transfer Addendum, are incorporated into this DPA by reference, with Customer (or the Brand) as data exporter and aematic as data importer, Annex I and Annex II of this DPA serving as the corresponding annexes of the Clauses, the optional docking clause included, the Clause 9 option being general written authorization with the notice period in section 7, and the governing law and forum being those of Ireland for the EU Clauses and England and Wales for the UK Addendum. Customer is responsible for determining whether such a transfer takes place and for the lawfulness of its own collection.

14. Customer's responsibilities

Customer is responsible for the lawfulness of the Customer Data it and the Brand provide or cause to be collected, including providing any privacy notice and obtaining any consent required before the aematic measurement script fires on a website. aematic does not deploy the script, does not control any consent mechanism, and cannot verify from its position that consent was obtained. Customer will not send, and will ensure the Brand does not send, raw email addresses, phone numbers, payment card data, government identifiers, precise geolocation, or any special category of personal data through the services. Where Customer chooses to send optional pass-through fields from its own servers, such as an IP address or user agent, Customer does so on its own instruction and aematic stores and forwards them as sent.

15. Liability

Each party's liability arising out of or related to this DPA is subject to the exclusions and limitations of liability set out in the Agreement. Nothing in this DPA limits liability that cannot be limited under Data Protection Law.

16. Term and changes

This DPA applies for as long as aematic processes Customer Data under the Agreement and for the return and deletion period in section 11. aematic may update this DPA to reflect changes in law, in its services, or in its Subprocessors. Material changes are notified to Customer's designated contact by email at least 30 days before they take effect, and prior versions are available on request.

Annex I: Description of the processing

Subject matter. Measurement and optimization of Customer's or the Brand's advertising on the platforms aematic supports.

Duration. The term of the Agreement plus the return and deletion period in section 11.

Nature and purpose. Receiving events from the aematic measurement script on the Brand's website and from Customer's or the Brand's servers; attributing conversions to the advertisements that produced them; reporting campaign performance; adjusting bids and budgets on Customer's instructions; and, where Customer enables it, relaying conversion events to the advertising platform. Where Customer configures an OpenAI pixel identifier, the measurement script also loads OpenAI's own pixel on the page, which sends events directly from the visitor's browser to OpenAI under Customer's agreement with OpenAI. The processing does not involve building cross-site behavioral profiles of individuals, targeting individuals on the basis of browsing history, or automated decisions with legal or similarly significant effects on any individual.

Categories of data subjects. Visitors to Customer's or the Brand's websites, including customers and prospective customers of the Brand.

Categories of personal data.

• Page and session activity: page URL, path, and title; referring URL; event type and timestamp; session identifier.
• Device and technical context: device type, operating system, browser; country and region derived from the IP address, which is then discarded and never stored.
• Identifiers: a first-party device identifier set by the measurement script; advertising click context (campaign parameters, click identifier, click time); and SHA-256 hashed email addresses, phone numbers, names, or customer identifiers, where Customer or the Brand supplies them or, unless Customer disables it, where the visitor types an email address into a form field on the page. The script hashes these in the browser before sending, so raw values never leave the page. Raw email addresses and other direct identifiers are rejected at ingest.
• Conversions: conversion type from a fixed taxonomy (order, lead, registration, trial, subscription, appointment); order identifier; value and currency; product identifiers and quantity where sent.
• Optional server-to-server pass-through fields, only where Customer chooses to send them: IP address and user agent.

Special categories of data. None. The services have no field for them and Customer agrees not to send them.

Frequency. Continuous, for as long as the measurement script is deployed or Customer's systems send events.

Retention. Behavioral web events are retained a minimum of 90 days and, because they are deleted in monthly batches, a maximum of about 120 days. Conversion, click, and attribution records are retained for the term of the Agreement and deleted under section 11.

Annex II: Technical and organizational measures

The measures below are in operation as of the effective date. They summarize aematic's written security program, which is available in full on request.

• Hosting. All production infrastructure runs on Google Cloud Platform in United States regions, on managed services (Cloud Run, Cloud SQL for PostgreSQL, Cloud Storage, Secret Manager). aematic operates no servers, virtual machines, offices, or corporate network of its own. Physical and environmental security are provided by Google Cloud under its SOC 2, SOC 3, and ISO 27001 attestations.
• Encryption in transit. All external traffic is encrypted with TLS 1.2 or higher; HTTP is redirected to HTTPS. Service-to-database traffic stays on Google's private network.
• Encryption at rest. All data stores and backups are encrypted at rest with AES-256 using Google-managed keys, enabled by default and not disableable. Customer-provided advertising platform credentials receive an additional layer of application-level encryption, with the key held separately in Secret Manager.
• Network. The production database has no public IP address and is reachable only from within aematic's private network. The background worker has no public ingress. The production network has no ingress-permitting firewall rules, so Google Cloud's default-deny applies. The measurement ingest endpoint sits behind a Cloudflare edge providing TLS termination, DDoS protection, and rate limiting.
• Access control. Every person holds a unique named account; shared accounts are prohibited. Multi-factor authentication is enforced at the organization level on Google Cloud and GitHub. Privileges are granted per resource on the least-privilege principle; each application service runs under its own dedicated service account with access only to the secrets it needs. There is no interactive shell, SSH, or RDP access to production workloads. Access is reviewed and revoked on the day it is no longer required.
• Tenant isolation. aematic is multi-tenant. Every request is scoped to the authenticated user's organization; cross-organization reads return "not found" rather than an authorization error, so tenant existence is not disclosed.
• Data minimization. The visitor's IP address is used transiently at ingest to derive country and region and is not stored. Identifiers are accepted only pre-hashed (SHA-256); raw email addresses and direct identifiers are rejected. No payment card data, government identifiers, health data, biometrics, or precise location are collected. The measurement script records no keystrokes or session recordings, and the only form content it reads is an email address the visitor types into an email field, which it hashes in the browser and holds in memory only. It never reads password, payment card, or one-time-code fields, and Customer can turn this off with the script's autoIdentity: false setting. The script is not instrumented with any third-party monitoring.
• Change management. Every change to application and infrastructure code is submitted as a pull request, must pass an automated test suite, and is reviewed by a second person before merge. Infrastructure is defined as code (Terraform). Deployment is fully automated with no manual path, and every change is permanently attributable in version control history.
• Vulnerability management. Container images are scanned for known vulnerabilities on every build and continuously re-analyzed as new vulnerabilities are disclosed; application dependencies are monitored for vulnerable versions; findings are remediated on documented timelines. Underlying platform patching is performed by Google Cloud. Workstations are company-managed macOS devices with full-disk encryption, automatic security updates, and enforced screen lock.
• Logging and monitoring. Google Cloud Audit Logs record every administrative action with the acting identity, enabled by default and not disableable. Application and infrastructure logs are centralized in Google Cloud Logging. Application errors are monitored with Sentry. An immutable application-layer audit ledger records every action that moves advertising spend or changes campaign structure.
• Backup and recovery. Daily automated encrypted backups with point-in-time recovery, retained 14 days, stored in a United States multi-region location. The production database runs in a regional high-availability configuration with synchronous replication and automatic failover. Restore is verified twice a year against production row counts; stated objectives are a 4-hour recovery time and a recovery point under 5 minutes.
• Retention and deletion. Retention periods are implemented in code and executed by scheduled jobs. Customer offboarding follows an automated soft-delete, grace-window, permanent-purge lifecycle that revokes access immediately, halts all scheduled processing for the tenant, and hard-deletes all tenant records.
• Personnel. Background screening before access to customer data, written confidentiality obligations, and annual security awareness training for all personnel. Devices are cryptographically erased on decommission.
• Incident response. A written incident response plan with severity tiers, named roles and deputies, evidence preservation, the customer notification commitment in section 10, and a blameless written post-incident review with corrective actions. Exercised annually as a tabletop. Security reports: security@aematic.ai.
• Vendor management. Subprocessors are reviewed for security posture, data received, residency, and incident notification commitments before engagement and annually thereafter, and are listed in Annex III.

Annex III: Subprocessors

All Subprocessors are United States entities and process Customer Data in the United States. This list is maintained as the authoritative record and updated under section 7.

aematic also uses Clerk (authentication), Amplitude (product analytics), Anthropic and Amazon Web Services (AI generation over campaign and brand context), Slack (internal operations), and Stripe (invoicing). These providers process information about Customer's platform users or Customer's business, for which aematic's Privacy Policy applies; they do not receive Consumer Data.

Contact

Privacy: info@aematic.ai
Security: security@aematic.ai

Lifeguard Technology, Inc.
924 E 7th Street, Suite 200
Austin, TX 78702