Apptonomy Data Processing Agreement

1. Roles, instructions and term

• The Controller determines the purposes and means of processing personal data. Apptonomy processes personal data on the Controller’s documented instructions, including the instructions in the Agreement and this DPA.
• Apptonomy may process account, billing, security, fraud-prevention and business records as an independent controller where applicable law requires or permits.
• This DPA applies while Apptonomy processes personal data on the Controller’s behalf, including any applicable post-termination retention period described in Section 9.
• The Controller will ensure that its instructions and disclosure of personal data to Apptonomy comply with applicable law. The Controller must not intentionally submit special-category personal data unless the parties first agree appropriate written safeguards.

2. Subject matter, nature and purpose

Apptonomy processes data to provide its app-store-optimization platform and related support. Processing includes authenticating users; connecting App Store Connect and Google Play accounts; storing, analyzing, translating and publishing listing content; processing screenshots; importing store analytics and public reviews; producing audits and recommendations; measuring product use; communicating with users; and securing, operating and supporting the service.

3. Data subjects and data categories

Data subjects may include the Controller’s users and personnel, support participants, affiliate participants where the Controller uses those functions, and authors of public app reviews whose text may incidentally contain personal data.

Personal data may include:

• names, business email addresses, authentication identifiers, session and device data;
• audit records of account, organization and support activity: actor identifiers and names, actions, affected resources, IP addresses and user-agent strings;
• organization, project, support-channel and workspace identifiers;
• encrypted App Store Connect and Google Play credentials or authorization descriptors;
• app listings, screenshots, localized content, connected-account analytics, sales and performance data;
• support messages and related page, project and organization context;
• product-usage events — from the browser only with consent, and from Apptonomy’s servers without that consent check, with the IP address and IP-derived location — browser/session replay data where consented, and user-profile identifiers;
• billing, subscription, affiliate identity, tax and payout metadata handled through Stripe;
• AI prompts derived from listing, screenshot, review or connected-account content, and the resulting output;
• search queries typed in the product, sent with the user’s IP address and browser user agent to the search provider;
• application telemetry, including user identifiers, hashed IP addresses, device/user-agent fields and coarse or derived location fields; and
• public app-review text, which may incidentally identify a third party.

4. Subprocessors

The Controller gives Apptonomy general authorization to use the subprocessors below. The versioned Subprocessor List is the canonical list and provides the applicable legal entity, purpose, data categories, processing location and standard online contractual basis.

Changes. Apptonomy manages customer notice through info@apptonomy.ai. Apptonomy will give at least 30 days’ prior notice before adding or replacing a subprocessor, except where an urgent security, legal or service-continuity need makes advance notice impracticable. In that case Apptonomy will give notice as soon as reasonably possible. Where the Standard Contractual Clauses in Section 6 govern the transfer, the advance-notice period selected for Clause 9(a) applies and prevails over this exception. A Controller may object on reasonable data-protection grounds during the notice period. The parties will work in good faith on a commercially reasonable solution; if none is available, either party may terminate the affected service as provided in the Agreement.

AI services. The verified published terms for the commercial API services used from OpenAI, Anthropic and Perplexity exclude submitted API content from model training by default. The same position applies to Google's Gemini paid service, and the production key is confirmed in Apptonomy's billing-enabled project. Apptonomy does not intentionally opt in to provider training or data-sharing programs. AI-assisted operations and development sessions run on Claude subscription plans under Anthropic’s consumer terms, with the use of conversations for model training turned off. Provider retention for abuse prevention remains separate from model training: Anthropic retains API inputs and outputs for 30 days by default, and Apptonomy does not represent that any provider offers zero retention.

Cloudflare AI Gateway. The gateway processes AI request metadata such as provider, model, status, duration, token count, cost and cache status. Request and response payload logging is disabled, historical payload logs have been purged, and retained gateway metadata is swept at about 30 days. The gateway also caches eligible AI responses for about 30 days. Most AI request paths, including those for draft listings and screenshots, use the cache-eligible classification, so Apptonomy does not represent that connected-account-derived requests bypass gateway caching. Anthropic requests go directly to Anthropic if the gateway itself fails, and sampled quality-review batches are always sent directly to Anthropic. One AI-assisted search feature records its prompt text in application telemetry, retained as stated in Section 9.

5. Security measures

Apptonomy maintains the following measures appropriate to the assessed production service:

• TLS for data in transit and provider-managed encryption for supported data stores at rest.
• Store credentials encrypted with AES-256-GCM using a per-user derived key. The user seed is wrapped twice with separate Google Cloud KMS keys before storage. Service-account impersonation records contain an authorization descriptor rather than a stored customer secret.
• KMS-backed encryption for connected Slack bot tokens, and separate production, staging and development KV/R2 bindings except one shared object-storage bucket that holds no customer data.
• Authentication and server-side project-role checks on credential-management and publishing operations; enforcement of those roles across every operation is being completed.
• Fail-closed cross-origin controls and security response headers at the application edge.
• Application-log redaction controls and payload-free AI Gateway logging.
• Automated secret scanning with pinned Gitleaks in required pull-request checks, pre-push verification, post-push checks and scheduled full-history audits.
• A documented credential-rotation process covering every store a credential lives in, with phased cutover and verified pickup before a superseded value is destroyed.
• Persistent Cloudflare Workers invocation logging and Google Cloud logging, subject to the retention periods in Section 9.
• Personnel confidentiality obligations and restricted operational access based on job responsibility.

These measures do not represent a security certification. Apptonomy will not materially reduce the overall security of the processing during the term.

6. International transfers and processing locations

Where the Controller transfers EEA personal data to Apptonomy for processing in a country without an adequacy decision, the parties incorporate the EU Standard Contractual Clauses in Commission Implementing Decision (EU) 2021/914, Module Two (controller to processor). For restricted transfers from the United Kingdom, the parties also incorporate the UK International Data Transfer Addendum to those clauses. If another lawful transfer mechanism applies, the parties may rely on it to the extent permitted by law.

Apptonomy’s supplementary measures include the transport and storage safeguards described in Section 5, credential envelope encryption, access authorization, redaction and payload-free gateway logging.

Selections under the Standard Contractual Clauses

• Module: Module Two (controller to processor). Where the Controller acts as a processor for its own customer, Module Three (processor to processor) applies on the same selections.
• Clause 7 (docking clause): included.
• Clause 9(a) (use of sub-processors): Option 2, general written authorisation; the time period for prior notice is 30 days, as in Section 4.
• Clause 11(a) (redress): the optional independent dispute-resolution wording is not included.
• Clause 13 (supervision): the competent supervisory authority is determined under Clause 13(a), as recorded in Annex I.C.
• Clause 17 (governing law): Option 1, the law of the Netherlands.
• Clause 18(b) (choice of forum): the courts of Amsterdam, the Netherlands.

Annex I — list of parties, description of transfer and competent supervisory authority

• I.A Data exporter: the Controller identified in the Agreement, acting as controller (or as processor under Module Three); contact details and signature as in the Agreement and Section 12. Data importer: Apptonomy Inc., business address as stated above, contact security@apptonomy.ai, acting as processor; signature as in Section 12.
• I.B Description of transfer: categories of data subjects and of personal data as in Section 3; no special-category data is intended (Section 1); frequency continuous for the term of the Agreement; nature and purpose of processing as in Section 2; retention as in Section 9; transfers to sub-processors for the purposes and data categories in Section 4 and the Subprocessor List.
• I.C Competent supervisory authority: determined under Clause 13(a) by the data exporter’s establishment or representative.

Annex II — technical and organisational measures: the measures in Section 5. Annex III — list of sub-processors: not required under Clause 9(a) Option 2; the versioned Subprocessor List referenced in Section 4 is provided for information and change notice.

UK International Data Transfer Addendum

• Table 1 (parties): as in Annex I.A.
• Table 2 (selected SCCs, modules and selected clauses): the Approved EU SCCs with the module and clause selections above.
• Table 3 (appendix information): Annexes I and II above, and the Subprocessor List for Annex III information.
• Table 4 (ending this Addendum when the Approved Addendum changes): neither party.

7. Confidentiality, incidents and assistance

• Apptonomy will ensure that personnel authorized to process personal data are subject to confidentiality obligations.
• Apptonomy will notify the Controller without undue delay and, in any event, within 48 hours after becoming aware of a personal data breach affecting the Controller’s personal data.
• The monitored operational contact is security@apptonomy.ai, with primary and backup responders. The published reporting route was verified on 2026-08-01, and delivery of an external test report to the monitored inbox was confirmed on 2026-09-22. The published vulnerability disclosure policy and reporting route are available at Apptonomy’s security policy and security.txt.
• Taking into account the nature of processing and information available, Apptonomy will reasonably assist the Controller with data-subject requests, breach and security obligations, data-protection impact assessments and supervisory-authority consultations.

8. Data-subject requests

Where legally permitted, Apptonomy will promptly forward a request it receives relating to personal data processed for the Controller. Apptonomy will provide reasonable assistance for the Controller to respond. The Controller remains responsible for assessing the request and giving lawful instructions.

9. Return, deletion and retention

• Active service records. On termination or the Controller’s written request, Apptonomy will begin deletion or return of personal data in active application stores without undue delay, subject to the Controller’s instructions, technical dependencies and the exceptions below. The account cascade revokes identity sessions, deletes projects and project artifacts, removes store credentials and memberships, deletes the active user and encryption-key records, and deletes support threads and messages. The operation is multi-step and may require remediation if an individual step reports an error.
• Managed Firestore backups. Point-in-time recovery is disabled. The current daily managed-backup schedule retains encrypted snapshots for 3 days; those snapshots expire on that schedule.
• Business-data exports. A separate daily encrypted export of selected Firestore collections is retained for up to 90 days. It includes encrypted credentials and user encryption-key records. A snapshot made before deletion cannot be selectively redacted, so those records may remain recoverable from that snapshot until it expires.
• AI Gateway. Request/response payload logs are disabled. AI request metadata and eligible cached responses are retained for about 30 days under Apptonomy’s sweep and cache controls.
• Audit records. Organization activity-log and administrative audit records are retained for 90 days and then deleted automatically.
• Publish queue. When a listing change is published, the queued publish task carries the decrypted store credential, encrypted at rest by the queue provider, until the task completes or expires after 31 days.
• Cloud and application logs. Google Cloud’s default application-log bucket retains logs for 90 days and its required audit bucket is locked for 400 days. Cloudflare Workers Logs are enabled on the Workers Paid plan and retain persisted logs for 7 days.
• Application telemetry. Operational telemetry in Apptonomy’s United States BigQuery telemetry table is retained for a fixed 90 days and then expires automatically: the table is day-partitioned on its event timestamp and carries a 90-day partition expiration, so partitions older than the window are deleted by the platform without operator action. That fixed window is the erasure mechanism for this table — account deletion does not perform targeted row deletion against it, and Apptonomy does not represent that it does. Imported App Store Connect / Google Play analytics remain outside this window: they currently have no automatic expiration, account deletion does not automatically remove their rows, and where a deletion instruction applies to those attributable records Apptonomy will assess and carry out the required targeted operational action.
• Object and KV storage. The R2 buckets that hold customer credential snapshots carry a 7-day credential-snapshot object-expiry lifecycle rule, so objects in those buckets are deleted by the platform 7 days after creation. Other production R2 buckets have no object-expiry lifecycle and depend on explicit application deletion. KV entries use purpose-specific retention: short-lived authentication/credential state expires from minutes to one hour; analytics caches expire from one minute to seven days; some operational state persists until overwritten or deleted.
• Subprocessors. Provider-held data remains subject to the applicable provider terms, legal obligations and provider retention windows. The Resend Pro account retains delivered-message content and attachments for 30 days. Account deletion removes the identity provider’s user record and any waitlist entry held against that email address, and submits a compliance deletion request to the product-analytics provider covering that person’s profile and event history. Two provider surfaces are deliberate, documented exceptions rather than omissions. First, Stripe customer objects and their associated billing, invoice, payout and tax records are retained — not deleted and not redacted — because Apptonomy requires them for accounting, bookkeeping, tax and audit obligations. This is an application of the residual-records item of this Section 9 and does not extend it. Second, deletion of Mixpanel profiles/events is submitted automatically, but the provider reports only whether the submitted job finished; it does not report an outcome for an individual person. The provider states that a deletion job may take up to 30 days to complete.
• Confirmation limits. Where erasure is carried out by a subprocessor’s compliance interface rather than by direct record deletion, Apptonomy can evidence that the request was submitted and what outcome the provider reported for the job — it cannot independently confirm that a named person’s records were removed, because once a profile has been deleted there is nothing left to read back. Apptonomy records each such request, the provider’s reported job outcome, and the date, and retains only the request count and outcome after the request completes; it does not represent a specific person’s analytics records as confirmed deleted. Where a provider reports a failed, cancelled or unresolvable job, Apptonomy treats the request as outstanding and repeats or escalates it.
• Residual records. Apptonomy may retain records required for financial, tax and billing reconciliation; fraud, refund and trial-abuse prevention; email deliverability/compliance and webhook replay evidence; and de-identified attribution history. Apptonomy will limit retained records to the applicable purpose and legal period and will not use them to continue providing the terminated service.
• De-identified data. Data that has been irreversibly de-identified so it can no longer be attributed to the Controller or a person is outside the deletion obligation.

10. Compliance information and audits

Apptonomy will make available information reasonably necessary to demonstrate compliance with this DPA. On reasonable prior notice, the Controller may request a proportionate audit or written assessment, subject to confidentiality, security and non-disruption safeguards. The parties will first use current documentation and remote evidence where it reasonably satisfies the request.

11. Liability and governing terms

Liability under this DPA is subject to the limitations and exclusions in the Agreement, except to the extent applicable law prevents their application. This reusable DPA does not create a separate monetary cap. Governing law and forum are those stated in the Agreement, subject to the mandatory operation of the transfer clauses and applicable data-protection law.

12. Signatures