Data Processing Addendum

1. Introduction

This Data Processing Addendum ("DPA") forms part of the agreement between Mobiah, Inc. ("Mobiah" or "Processor") and the customer identified in the applicable Terms of Use, order, or Master Services Agreement ("Customer" or "Controller") (together, the "Agreement"), and governs the Processing of Personal Data in connection with the Omniview product (the "Service").

This DPA applies primarily under U.S. state privacy laws, with limited incorporation of GDPR-aligned principles where EU/EEA Personal Data is processed incidentally. Where the Service is provided as a layer within a Mobiah services engagement, this DPA governs data protection for the Service, and any signed Master Services Agreement governs the services engagement.

2. Applicability of U.S. State Privacy Laws

This DPA applies to Personal Data processed in connection with the Service where such processing is subject to U.S. state privacy laws, including the California Consumer Privacy Act as amended by the California Privacy Rights Act (CCPA/CPRA), and comparable laws in Virginia, Colorado, Connecticut, Utah, and other states as they take effect.

3. Incorporation of GDPR Principles

To the extent Personal Data of individuals located in the EU/EEA is processed incidentally through the Service, Mobiah will apply GDPR-aligned data-protection principles — lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity, and confidentiality — to the extent relevant to the Service. This incorporation does not imply full GDPR territorial applicability to Mobiah under Article 3 of GDPR.

4. No EU Establishment

Mobiah, Inc. is a United States company with no establishment in the EU/EEA and does not direct the Service to EU individuals. The GDPR-aligned commitments in this DPA do not constitute acknowledgment of full GDPR applicability to Mobiah unless required by law.

5. Roles of the Parties

Processor role (Customer source data). With respect to the data drawn from the systems the Customer connects and processed through the Service, the Customer is the Controller and Mobiah is the Processor. The Customer's connected systems remain the system of record. Mobiah processes such Personal Data only on the Customer's documented instructions (including the Customer's configuration and use of the Service) and to provide and support the Service.

Controller role (account data). With respect to Omniview account, authentication, tenant-configuration, and usage-log data, Mobiah acts as a Controller, as described in Schedule 1 and Mobiah's Privacy Policy.

6. Scope, Nature, and Duration of Processing

The subject matter, nature, purpose, categories of data subjects, and categories of Personal Data are described in Schedule 1 (Processing Description). Processing continues for the term of the Customer's subscription or engagement, plus the limited periods described in Schedule 1 for working copies, backups, and lawful retention.

7. Processor Obligations

With respect to Personal Data for which it acts as Processor, Mobiah will:

• Process such Personal Data only on the Customer's documented instructions, including as configured through the Service, unless required otherwise by law (in which case Mobiah will notify the Customer unless legally prohibited);
• Ensure personnel authorized to process the data are bound by confidentiality;
• Maintain records of processing activities as required;
• Notify the Customer if, in Mobiah's opinion, an instruction infringes applicable data-protection law;
• Not sell Customer source Personal Data, and not use it for advertising or to train foundation models;
• Access source systems on a read-only basis; the Service does not write back into the Customer's connected systems as part of this processing;
• Assist the Customer, taking into account the nature of the processing, with data-subject requests and with security, breach-notification, and (where applicable) data-protection-impact-assessment obligations.

8. Security Measures

Mobiah maintains administrative, physical, and technical safeguards appropriate to the risk, described in detail in Schedule 2. These currently include:

• TLS encryption of data in transit (edge termination; the production service rejects non-HTTPS connections);
• AES-256-GCM encryption at rest of (i) the integration credentials the Customer supplies, (ii) the canonical B2B cache, and (iii) persisted report snapshots, with ciphertext cryptographically bound to the tenant; envelope encryption uses a managed key-management service (GCP Cloud KMS);
• Password hashing, encryption of multi-factor-authentication secrets, and hashing of AI-client (MCP) access tokens;
• Role-based access control, with optional per-tenant multi-factor-authentication and IP allowlisting;
• Tenant isolation: every stored record is scoped by tenant identifier, with no cross-tenant read path;
• A drop-by-default allowlist on canonical ingestion that removes contact-level and free-text fields before write;
• Audit logging of report and MCP access (metadata, not source payloads).

9. Subprocessors

Mobiah uses the infrastructure subprocessors listed in Schedule 1 §7 to provide the Service. Mobiah imposes data-protection obligations on its subprocessors substantially similar to those in this DPA and remains responsible for their performance. Mobiah will make its current subprocessor list available and will give the Customer a reasonable opportunity to object to a new subprocessor on reasonable data-protection grounds.

Customer-connected systems. The third-party systems the Customer connects (for example, its CRM, enrichment, analytics, and AI-client providers) are the Customer's own processors, not Mobiah's subprocessors. Mobiah reads from them on the Customer's instruction; that read does not make them Mobiah subprocessors.

10. Data Subject Requests

Mobiah will assist the Customer, insofar as reasonably possible and taking into account the nature of the processing, in responding to requests to exercise data-subject rights (access, correction, deletion, restriction, portability, and objection) with respect to Personal Data Mobiah processes as Processor. Mobiah will not respond directly to a data subject regarding such data except on the Customer's instruction or as required by law.

11. International Data Transfers

The Service's production application and database, and the key-management service for the canonical cache, are located in the United States (see Schedule 1 §10). Mobiah primarily processes data within the United States. Where Personal Data subject to EU/EEA transfer requirements is processed incidentally, Mobiah will implement appropriate safeguards (such as Standard Contractual Clauses) to support lawful transfer where applicable.

12. Personal Data Breach Notification

Mobiah will notify the Customer without undue delay after becoming aware of a confirmed Personal Data breach affecting Customer Personal Data. The notification will describe, to the extent known, the nature of the breach, the categories and approximate volume of data affected, likely consequences, and the measures taken or proposed to address it. Mobiah will provide reasonable updates as further information becomes available.

13. Audits and Compliance Demonstration

Mobiah will make available information reasonably necessary to demonstrate compliance with this DPA, including relevant third-party audit reports or certifications where available (for example, Mobiah's SOC 2 report once issued). Where a Customer reasonably requires a direct audit, it will be conducted virtually on at least thirty (30) days' notice, no more than once per year (except following a breach or where required by law), during business hours, and in a manner that does not unreasonably disrupt Mobiah's operations or compromise other customers' confidentiality.

14. Return or Deletion of Data

On expiry or termination, and on the Customer's written request, Mobiah will delete or return Customer Personal Data processed as Processor, except to the extent retention is required by law.

Deletion practice. As described in Schedule 1 §8, on termination Mobiah erases the tenant's processor data — persisted report snapshots, the canonical cache, stored credentials, associated records, and audit logs — through a documented tenant-erasure procedure. Transient in-memory working copies expire on their own short cycle, and expired canonical-cache and snapshot rows are automatically purged. Disaster-recovery backups are retained for a limited rolling window (currently fourteen (14) days) and are then deleted; Customer Personal Data contained in a backup persists only until that backup expires. Mobiah will confirm to the Customer when live working copies have been removed and, where relevant, the date by which the last pre-deletion backup is expected to expire.

15. Liability

Each party's liability under this DPA is subject to, and counts toward, the limitations and exclusions of liability in the Agreement. Nothing in this DPA expands either party's liability beyond those limits, except to the extent applicable data-protection law does not permit such limitation.

16. Governing Law

This DPA is governed by the law that governs the Agreement, which for the standalone Service is the State of Delaware. Where mandatory data-protection law requires otherwise for a specific data subject or transfer, that law applies to the extent required.

17. Order of Precedence

In the event of a conflict between this DPA and the rest of the Agreement regarding the processing of Personal Data, this DPA controls. In the event of a conflict between this DPA and the Standard Contractual Clauses (where they apply), the Standard Contractual Clauses control.

Schedule 1 — Processing Description

1.1 Nature of the Processing

Omniview is a multi-tenant application that: (a) authenticates the Customer's authorized users; (b) stores encrypted credentials the Customer supplies so the Service can call the systems the Customer has connected (for example HubSpot, Apollo, Snitcher, Valley, Google, LinkedIn, and similar connectors the Customer enables); (c) queries those systems at runtime, over TLS, to build purpose-built reports; (d) holds the resulting working copies as described in §1.5 below; (e) writes an audit record of who queried which integration or report (metadata only, not the source payload); and (f) where the Customer enables MCP, serves allowlisted cache reads to the Customer's chosen AI client over an authenticated connection. Source adapters are read-only; the Service does not write back into the Customer's connected systems.

1.2 Purpose

To provide the Customer's authorized users (and, where enabled, the Customer's authorized AI clients) with curated reports and organization-level intelligence drawn from systems the Customer already operates or has connected, for the Customer's own sales, marketing, and operations use. Mobiah does not sell Customer source data and does not use it to train foundation models.

1.3 Lawful Basis

Canonical B2B cache: Mobiah relies on legitimate interests (GDPR Art. 6(1)(f) or equivalent) in providing organization-level B2B sales and marketing intelligence. The cache is designed not to identify or profile natural persons. Account / authentication data: performance of the contract and Mobiah's legitimate interest in securing the Service.

1.4 Categories of Data Subjects

• Customer personnel — users who sign in to Omniview (accounts, roles, MFA, IP allowlists).
• Customer prospects and contacts — only where a report snapshot or an in-memory view includes them. The current persisted snapshot stores contact name and email, plus company and deal fields; other reports may hold similar contact fields in memory only, for the cache TTL.
• Organizations (not natural persons) in the canonical cache — company-level records only.

1.5 Categories of Personal Data and Customer Data

A. Controller data (Omniview accounts). Name, email, password hash, encrypted MFA secret and backup codes, session tokens, optional Google OAuth tokens (encrypted at rest), tenant membership and role, optional IP allowlist, allowlisted user emails, and company website captured at trial signup.

B. Processor — credentials. API tokens, OAuth tokens, and connection parameters for each connected system, stored in PostgreSQL as AES-256-GCM ciphertext. These credentials can be used to retrieve further Customer data from the source system.

C. Processor — transient working copies (memory only). Report payloads fetched from connected systems to render a view (CRM records, visitor lists, revenue or pipeline aggregates, and similar). Held in application-server memory with time-to-live from minutes up to seven days for some historical views; not written to the Omniview database; lost on application-server restart. This is a copy for the duration of the TTL on Mobiah-operated infrastructure.

D. Processor — persisted report snapshot (PostgreSQL, encrypted). One row per tenant per report (currently the Outbound ICP Funnel v2 report), overwritten on refresh (approximately hourly), encrypted at rest (AES-256-GCM) with tenant-bound AAD and GCP Cloud KMS envelope encryption, and subject to a custody TTL after which the row is unreadable and automatically purged. The payload includes HubSpot company name, domain, ICP segment, and deal counts; HubSpot deal name, amount, stage, pipeline, and close/create dates; HubSpot contact name and email and lifecycle/engagement flags; and Valley outbound identity/match metadata. This is Customer CRM data, including deal-value and contact personal data.

E. Processor — canonical B2B cache (PostgreSQL, encrypted). Allowlisted organization-level records only: firmographic fields (organization name, canonical domain, employee band, region, industry code, firm/practice type); activity fields (metric name from a controlled vocabulary, metric value, occurred-at timestamp, campaign identifier); and provenance (tenant id, source integration, fetched-at, resolution status). Encrypted at rest (AES-256-GCM) with tenant-bound AAD and GCP Cloud KMS envelope encryption. Custody TTL: activity 30 days, firmographic 90 days from fetch. Expired rows are unreadable at query time.

F. Processor — audit metadata. Tenant id, user id, integration name, report id, endpoint, HTTP method, success/status code, latency, error message, correlation id, IP address, and user agent — not the source payload.

G. Processor — MCP credentials. Personal access tokens and OAuth access/refresh/authorization codes for AI-client access, stored as SHA-256 hashes only (no plaintext token in the database).

1.6 Special-Category Data

The Service is not designed to ingest special-category data. The canonical-cache allowlist drops free-text and contact-level fields. Report snapshots and in-memory views will contain whatever the connected source system returns for the fields the report requests; the Service does not separately classify or filter those fields for special-category content. The Customer is responsible for not directing special-category data into the Service through its connected systems.

1.7 Recipients and Subprocessors

Mobiah does not disclose Customer source data to other Omniview customers; isolation is by tenant id on every store read and write. Mobiah's infrastructure subprocessors are:

Customer-initiated onward transfer. If the Customer connects an MCP client, allowlisted cache records (category E) are sent to that client under the Customer's credentials; that client is the Customer's processor. Customer-connected third parties (HubSpot, Apollo, Snitcher, Valley, Google, LinkedIn, and any other connector the Customer enables) are the Customer's processors and are not Mobiah subprocessors by virtue of Mobiah's read.

1.8 Retention, Backups, and Deletion

The Service's PostgreSQL runs on a plan providing daily scheduled backups plus manual pre-deploy snapshots. Backups are operational restore points, retained on a rolling window (currently fourteen (14) days) and then deleted. Tenant deletion is a controlled administrative action performed through a documented erasure procedure. Mobiah does not delete global domain/entity identity records that are shared across tenants.

1.9 International Transfers

The production application and database run on Heroku in the United States. Canonical-cache key material is in GCP Cloud KMS, us-central1 (United States). Where EU/EEA Personal Data is processed incidentally, the transfer safeguards in Section 11 apply.

Schedule 2 — Technical and Organizational Security Measures

• Encryption in transit: TLS with edge termination; the production service rejects non-HTTPS connections.
• Encryption at rest: AES-256-GCM for integration credentials, the canonical-cache payload, and persisted report snapshots, with tenant-bound additional authenticated data and GCP Cloud KMS envelope encryption. Expired canonical-cache and snapshot rows are automatically purged.
• Authentication: password hashing; encryption of MFA secrets; hashing of MCP access tokens.
• Access control: role-based access; optional per-tenant MFA requirement and IP allowlisting.
• Tenant isolation: every store read and write is scoped by tenant id; no cross-tenant read path.
• Data minimization: drop-by-default allowlist on canonical ingestion, removing contact-level and free-text fields before write; read-only source adapters.
• Logging: audit logging of report and MCP access (metadata, not source payloads).