Sign inGet started
← All policies

Data Processing Agreement (DPA)

Last updated: 2026-08-05

0. Status, scope, and how to read this DPA

This Data Processing Agreement, including its Annexes and any module incorporated by reference (the "DPA"), forms part of and is incorporated into the agreement between the customer identified in the applicable Order Form or click-through acceptance ("Customer") and Recovea, Inc., a Delaware corporation with its registered notice address at 2810 N Church St STE 89986, Wilmington, DE 19802 ("Recovea"), governing Customer's access to and use of the Recovea Service (the "Agreement"). Recovea is a bootstrap-funded US company; nothing in this DPA concerns investment or securities.

The Agreement consists, in the order of precedence stated in Section 17 below, of any signed Order Form, the Master Services Agreement or click-through Terms of Service (the "ToS/MSA"), this DPA, the BYO-Key Addendum, and the incorporated policies (including the Acceptable Use Policy ("AUP"), the Privacy Notice, and the Security Statement). This DPA governs the Processing of Customer Personal Data by Recovea on Customer's behalf in connection with the Service. Where the Agreement and this DPA conflict with respect to the Processing of Personal Data, this DPA controls; in all other respects the Agreement controls.

Automatic incorporation. Where Recovea Processes Customer Personal Data on Customer's behalf, this DPA is automatically incorporated into and forms part of the Agreement; no separate signature is required for it to take effect, and it is effective on the effective date of the Agreement. This DPA includes the US-state-law Service-Provider terms (Annex III) by default. The international-transfer terms (Section 13 and Annex IV) are included and executable but remain dormant while the Service is operated on a United-States-only basis (see below). A Customer that requires a counter-signed copy (for example, to execute the Standard Contractual Clauses) may request one at legal@recovea.ai, and the signature block in Annex V may be completed by both parties.

Recovea operates a United States–only Service. The Service is hosted in Amazon Web Services in the United States (region us-east-1, Northern Virginia). The Service is offered to business customers only, to natural persons who are at least eighteen (18) years of age and acting in a business capacity, and is not intended for personal, family, or household use. The international data-transfer mechanics in Section 13 and Annex IV (EEA/UK/Swiss Standard Contractual Clauses, the UK International Data Transfer Addendum, and the Swiss amendments) are in force on acceptance but operative only with respect to a Restricted Transfer, so that the first such transfer is already covered. The ToS/MSA, Privacy Notice, and Security Statement are pointers to this DPA for all transfer matters and contain no independent transfer representations.

1. Definitions

Capitalized terms used but not defined in this DPA have the meanings given in the Agreement. For the purposes of this DPA:

1.1 "Affiliate" means any entity that directly or indirectly controls, is controlled by, or is under common control with a party, where "control" means ownership of more than fifty percent (50%) of the voting interests.

1.2 "Agreement" has the meaning given in Section 0.

1.3 "Aggregated/De-identified Data" means data created by or derived from Customer Data or the operation of the Service that has been aggregated and/or de-identified so that it no longer identifies, and cannot reasonably be used to identify, re-identify, link to, or be associated with any identified or identifiable natural person, Customer, Authorized User, or end user, and that meets the de-identification standard of, at minimum, Cal. Civ. Code § 1798.140(m) and, to the extent European Data Protection Law applies, the standard under that law for data that is no longer personal data. The content-free Ledger integrity record described in Section 14.3 is distinct from Aggregated/De-identified Data: it is pseudonymized integrity metadata retained under legal-obligation and legal-claims exceptions, and Recovea does not assert that it satisfies the anonymization threshold of European Data Protection Law. Recovea's processing of Aggregated/De-identified Data is governed by Section 11.

1.4 "Authorized User" means an individual whom Customer permits to access and use the Service under Customer's account.

1.5 "CCPA" means the California Consumer Privacy Act of 2018, as amended by the California Privacy Rights Act of 2020, and its implementing regulations.

1.6 "Controller" means the entity that determines the purposes and means of the Processing of Personal Data, and includes a "business" under the CCPA and equivalent terms under other US State Privacy Laws.

1.7 "Customer Data" means all data, content, and information submitted to, transmitted through, stored in, or generated by Customer's or its Authorized Users' use of the Service, including Inference Content and Usage Data attributable to Customer.

1.8 "Customer Personal Data" means Personal Data within Customer Data that Recovea Processes on Customer's behalf as a Processor / Service Provider under this DPA. "Customer Personal Data" is used consistently throughout this DPA and is the subject matter of the Processing described in Annex I.

1.9 "Data Protection Law" means all privacy and data protection laws and regulations applicable to a party's Processing of Personal Data under the Agreement, including, as and when applicable: (a) the US State Privacy Laws; (b) other US federal and state privacy, data-security, and breach-notification laws; and (c) European Data Protection Law (to the extent it applies — see Section 13).

1.10 "Data Subject" means an identified or identifiable natural person to whom Personal Data relates, and includes a "consumer" under US State Privacy Laws.

1.11 "European Data Protection Law" means, to the extent applicable: Regulation (EU) 2016/679 (the "GDPR"); the GDPR as incorporated into the law of the United Kingdom by the Data Protection Act 2018 and the European Union (Withdrawal) Act 2018 (the "UK GDPR"); the Swiss Federal Act on Data Protection (the "FADP"); and the EU and UK ePrivacy rules, in each case as amended or superseded.

1.12 "Inference Content" means the request and response payloads (including prompts, inputs, model outputs, completions, embeddings, and associated parameters and metadata) that traverse the in-path gateway when Customer routes traffic to one or more Providers using Customer's own Provider Keys.

1.13 "the Ledger" means Recovea's hash-chained, append-only, offline re-derivable cost record described in the Agreement, which serves as the basis for usage measurement and billing.

1.14 "Personal Data" means any information relating to an identified or identifiable natural person, and includes "personal information" and "personal data" as defined under applicable Data Protection Law.

1.15 "Processing" (and "Process") means any operation performed on Personal Data, whether or not by automated means, including collection, recording, organization, structuring, storage, adaptation, retrieval, consultation, use, disclosure, transmission, dissemination, alignment, combination, restriction, erasure, or destruction.

1.16 "Processor" means the entity that Processes Personal Data on behalf of a Controller, and includes a "service provider" under the CCPA and equivalent terms under other US State Privacy Laws.

1.17 "Provider" means a third-party model, inference, or AI service provider (for example, OpenAI, Anthropic, or OpenRouter and the providers it routes to) with which Customer holds its own account and to which Customer's traffic is directed using Customer's own credentials.

1.18 "Provider Keys" means the API keys, tokens, and credentials that Customer issues, owns, and controls for its own Provider accounts.

1.19 "Restricted Transfer" means a transfer of Personal Data that is subject to European Data Protection Law to a country or recipient that is not the subject of an adequacy decision and for which an Article 46 (or UK/Swiss equivalent) transfer mechanism is required.

1.20 "Security Incident" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Customer Personal Data Processed by Recovea. A Security Incident does not include an unsuccessful attempt or activity that does not compromise the security of Customer Personal Data, including unsuccessful log-in attempts, pings, port scans, denial-of-service attacks, or other network attacks on firewalls or networked systems.

1.21 "Standard Contractual Clauses" or "SCCs" means the standard contractual clauses for the transfer of personal data to third countries adopted by the European Commission in Implementing Decision (EU) 2021/914 of 4 June 2021, as amended or replaced.

1.22 "Sub-processor" means a third party engaged by Recovea (other than a Recovea employee) that Processes Customer Personal Data on Recovea's behalf in order to provide the Service. For the avoidance of doubt and as set out in Section 5, Providers are not Recovea Sub-processors.

1.23 "Sensitive Data" means Personal Data that is classified as "special category," "sensitive," or equivalent under applicable Data Protection Law (for example, data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health, sex life, or sexual orientation; precise geolocation; government identifiers; financial-account credentials; and the personal data of a known minor), and includes the regulated categories addressed in Section 2.7.

1.24 "TOMs" means the technical and organizational security measures described in Annex II and the Security Statement.

1.25 "UK Addendum" means the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018, in force 21 March 2022, as amended.

1.26 "Usage Data" means metering and observability metadata generated by the Service, such as model and provider identifiers, token counts, latency, status codes, request hashes, timestamps, and cost figures, as further described in the Privacy Notice.

1.27 "US State Privacy Laws" means, as applicable, the CCPA; the Virginia Consumer Data Protection Act; the Colorado Privacy Act; the Connecticut Data Privacy Act; the Utah Consumer Privacy Act; the Texas Data Privacy and Security Act; the Oregon Consumer Privacy Act; the Montana Consumer Data Privacy Act; and other comprehensive US state consumer-privacy statutes, in each case as and when in effect and applicable.

2. Roles of the parties and scope of Processing

2.1 Roles. With respect to Customer Personal Data Processed under the Service, Customer is the Controller (or, where Customer is itself a Processor for a third party, the Processor) and Recovea is the Processor (or, where applicable, the sub-processor) and the Service Provider under the CCPA and US State Privacy Laws. Each party will comply with its obligations under Data Protection Law in its respective role.

2.2 Recovea as Controller of its own data. Separately and outside the scope of the Processor relationship in this DPA, Recovea acts as an independent Controller of certain Personal Data it collects in its own right, including account-registration, prospect, marketing, billing, support-interaction, and personnel data, and Personal Data within Usage Data that Recovea Processes for the limited internal purposes described in Section 2.4 and the Privacy Notice, and the de-identification Processing described in Section 11. Recovea's Processing of that data as an independent Controller is governed by the Privacy Notice and applicable Data Protection Law, not by the Processor terms of this DPA. The split between Recovea-as-Processor (Customer Personal Data inside Inference Content) and Recovea-as-Controller (Recovea's own account, prospect, marketing, billing, and personnel data, and the de-identification Processing in Section 11) is stated identically across the Privacy Notice, this DPA, the Security Statement, the Retention Schedule, and the Incident-Response materials.

2.3 Scope and instructions. Recovea will Process Customer Personal Data only: (a) to provide, maintain, secure, and support the Service in accordance with the Agreement; (b) in accordance with Customer's documented lawful instructions, including the instructions set out in this DPA and the Agreement, instructions given through the configuration and use of the Service (for example, routing, caching, retention, and feature settings selected by Customer), and any further written instructions agreed by the parties; and (c) as required by applicable law, in which case Recovea will inform Customer of that legal requirement before Processing unless the law prohibits such notice on important grounds of public interest.

The Agreement (including this DPA), together with Customer's configuration of and use of the Service, constitutes Customer's complete and final documented instructions to Recovea regarding the Processing of Customer Personal Data. Additional or alternate instructions must be agreed in writing and may be subject to additional fees where they require materially different Processing. If Recovea reasonably believes an instruction infringes Data Protection Law, Recovea will inform Customer without undue delay (Recovea is not obligated to perform a comprehensive legal review and acts on a reasonable-belief basis).

2.4 Permitted internal use. Recovea may Process Customer Personal Data as reasonably necessary to: (a) deliver, secure, monitor, meter, and bill for the Service; (b) prevent, detect, and respond to fraud, abuse, security incidents, and violations of the AUP; (c) maintain and improve the Service's operability, reliability, and safety; (d) comply with law and respond to lawful requests; and (e) generate and use Aggregated/De-identified Data in accordance with Section 11. Recovea will not Process Customer Personal Data for any purpose other than those set out in this DPA and the Agreement.

2.5 No sale; no sharing; no cross-context advertising. As a Service Provider / Processor, Recovea will not: (a) sell Customer Personal Data, nor share it for cross-context behavioral advertising, in each case as those terms are defined under the CCPA and US State Privacy Laws; (b) retain, use, or disclose Customer Personal Data for any purpose other than the business purposes specified in this DPA and the Agreement, including any commercial purpose other than providing the Service, except as permitted by Data Protection Law; (c) retain, use, or disclose Customer Personal Data outside the direct business relationship between the parties; or (d) combine Customer Personal Data with Personal Data Recovea receives from or on behalf of another person, or collects from its own interaction with a Data Subject, except as permitted by Data Protection Law to perform a business purpose. Recovea hereby certifies that it understands the restrictions in this Section 2.5 and will comply with them.

2.6 No-training commitment. Recovea does not use Customer Personal Data, Inference Content, prompts, inputs, model outputs, other Service outputs, or the Ledger to train, fine-tune, or develop any machine-learning or artificial-intelligence model for Recovea's own benefit or for the benefit of any third party, and does not disclose Inference Content to any third party for such purposes. This commitment is stated identically across the Privacy Notice, this DPA, the AI-Governance materials, and the BYO-Key Addendum. Recovea's use of Aggregated/De-identified Data (which by definition is not Personal Data and not Inference Content body content attributable to a person) is governed solely by Section 11.

2.7 Sensitive and regulated data. Customer is responsible for determining whether it will transmit Sensitive Data through the Service and for ensuring it has a lawful basis to do so. The Service is not designed or intended as a repository for Sensitive Data. In particular, Customer must not submit through the Service protected health information governed by HIPAA, cardholder data governed by PCI DSS, biometric identifiers, government-issued identification numbers, children's data, or other special-category or regulated data, unless separately agreed by the parties in a signed writing. Recovea is not a HIPAA Business Associate, and the Service is not HIPAA- or PCI-validated. Customer is solely responsible for compliance and for not transmitting such data in breach of this Section 2.7. Recovea applies the same TOMs to all Customer Personal Data and makes no representation that the Service provides Sensitive-Data-specific safeguards beyond those TOMs. Customer's transmission of regulated or Sensitive Data in breach of this Section is addressed by the indemnity in Section 15.4.

3. Customer (Controller-side) obligations and warranties

3.1 Customer is responsible for the accuracy, quality, legality, and means by which Customer acquired Customer Personal Data, and for determining the purposes and means of Processing.

3.2 Customer represents and warrants that: (a) it has provided all notices and obtained all consents, permissions, and rights necessary under Data Protection Law for Recovea and its Sub-processors to Process Customer Personal Data as contemplated by the Agreement; (b) it has, and will maintain throughout the term, a valid lawful basis for the Processing; (c) its instructions to Recovea comply with Data Protection Law; (d) it will not transmit through the Service any data in violation of the AUP, Section 2.7, or applicable law; and (e) where Customer configures the Service to attribute Usage Data to identified individuals (including per-person API keys or member-level reporting), Customer is solely responsible for providing all workforce notices and obtaining all consents required by applicable employee-monitoring, electronic-surveillance, and privacy laws (including, as applicable, N.Y. Civ. Rights Law §52-c, Conn. Gen. Stat. §31-48d, and Del. Code tit. 19 §705) before enabling such attribution, and will act on individual-level Service data only under its own lawful, disclosed workplace policy.

3.3 Where Customer is itself a Processor acting on behalf of a third-party Controller, Customer warrants that its instructions and actions, including its appointment of Recovea as a sub-processor, have been authorized by the relevant Controller, and that Customer will forward to that Controller any notice Recovea provides under this DPA where required.

3.4 Customer is responsible for its use of the Service, including securing its account credentials, Provider Keys, and Recovea-issued API keys (rcv_ keys), configuring retention and feature settings appropriately, and using the Service's controls (including the Breaker budget and kill-switch controls) consistently with its own legal obligations. Customer is the deployer of any AI system it operates through its use of the Service and bears the corresponding duties under applicable AI law; see Section 12. Customer's breach of these obligations and warranties is addressed by the indemnity in Section 15.4.

4. Confidentiality and personnel

4.1 Recovea will treat Customer Personal Data as Customer's Confidential Information under the Agreement and will not disclose it except as permitted by this DPA or required by law.

4.2 Recovea will ensure that personnel authorized to Process Customer Personal Data: (a) have committed themselves to confidentiality obligations or are under an appropriate statutory obligation of confidentiality; (b) Process Customer Personal Data only on instructions consistent with this DPA; and (c) are limited to those personnel who need access to provide and support the Service. Recovea limits access to Customer Personal Data to authorized personnel on a need-to-know basis.

4.3 Single-operator operational candor. Recovea is a small organization that may at launch be operated by a single individual or a very small team. Where this DPA refers to "personnel," "staff," or "team," that language applies with equal force to a single operator. Recovea will not represent that it maintains staffing, segregation-of-duties, on-call rotations, or coverage that it does not in fact have. This candor does not narrow any substantive obligation in this DPA; it qualifies only Recovea's descriptions of its operational scale.

5. The BYO-Key conduit: Providers are not Sub-processors

5.1 Conduit characterization (stated identically across the pack). The Service operates on a bring-your-own-key, in-path conduit model. The Customer brings and owns its Provider accounts, relationships, and API keys (Provider Keys) and pays the Providers directly. Recovea is a neutral conduit that proxies the Customer's in-path traffic on the Customer's own Provider Keys. Recovea never resells, marks up, sponsors, funds, or takes custody of Provider tokens or Provider spend. When Customer directs traffic to a Provider through the Service, Customer's Inference Content is transmitted to that Provider under Customer's own account and credentials.

5.2 Providers are Customer's recipients, not Recovea's Sub-processors. Because Customer (not Recovea) determines, contracts with, and pays the Providers, each Provider acts as the Customer's own processor, recipient, and/or independent controller, and is not a Recovea Sub-processor. Recovea does not engage, instruct, or control the Providers on its own behalf, and is not a party to Customer's agreements with the Providers. The Provider's Processing of Inference Content is governed by Customer's own agreement and data-processing terms with that Provider. Customer is responsible for reviewing and accepting each Provider's terms, data-processing terms, and security and retention practices, and for ensuring a lawful basis and any required transfer mechanism for the disclosure of Inference Content to its Providers.

Routing, fallback, and optimization reservation. Where the Service provides routing, fallback, or optimization functionality that selects among Providers, Customer pre-authorizes and configures the eligible Provider set and retains the determination of the recipients of Inference Content. Such functionality does not render Recovea a Controller of, or any Provider a Recovea Sub-processor with respect to, Inference Content; Recovea's selection among Providers within the Customer-configured, pre-authorized set is an execution of Customer's instruction and configuration, not an independent determination of recipients by Recovea. This characterization is stated identically across this DPA, the Sub-processor list, the BYO-Key Addendum, the Privacy Notice, the Security Statement, the AI-Governance materials, the Export/retention materials, and the Disclaimer.

5.3 What Recovea does at the edge. Recovea strips inbound Recovea-issued credentials (rcv_ / rcva_ prefixes) before forwarding upstream and does not transmit Recovea session tokens to Providers. Recovea's role with respect to Inference Content is limited to that of a transmission conduit and the metering, caching, control, and Ledger functions described in the Agreement.

6. Sub-processors

6.1 Authorization. Customer provides general written authorization for Recovea to engage Sub-processors to Process Customer Personal Data to provide the Service, subject to this Section 6. Recovea's Sub-processors are limited to the infrastructure and operational vendors necessary to run the Service.

6.2 Current Sub-processors. As of the date of this DPA, Recovea's Sub-processors are: (a) Amazon Web Services, Inc. — cloud hosting and storage, identity infrastructure (via Amazon Cognito), and transactional and account email delivery (sign-in/verification, account, billing-notice, security, and Sub-processor-change email) through Amazon SES, which is the active and only transactional sender; United States; (b) Stripe, LLC — payment processing and subscription billing, receiving billing-contact details and invoice amounts only; (c) PostHog, Inc. — cookieless product analytics, US data region; and (d) Functional Software, Inc. d/b/a Sentry — browser error reporting for the marketing website and the authenticated dashboard, US data region, Engaged 2026-08-05 (pre-listed as Planned earlier the same day, with the Section 6.4 notice run before Processing began; see the published list at Section 2.7). The current Sub-processor list is maintained at https://recovea.ai/legal/subprocessors and is incorporated by reference. A vendor pre-listed on that list as Planned Processes nothing and is not a Sub-processor unless and until it flips to Engaged, which runs the Section 6.4 notice first; no vendor is pre-listed as Planned today. Providers are not included on this list because, as set out in Section 5, Providers are not Recovea Sub-processors.

6.2.1 PostHog — scope, classification, and the rights Recovea affords regardless of it. PostHog runs on two surfaces: anonymous, aggregate measurement on the marketing website, and, inside the authenticated dashboard, product analytics keyed to a pseudonymous account identifier, with the workspace identifier, plan tier, product-event names, and the dashboard page on which an event occurred. PostHog receives no Inference Content, no Usage Data records, no spend, cost, or token values, no Provider Keys and no Ledger data; session recording is off and nothing is stored on the user's device on either surface. Recovea's position is that this stream is Recovea's own controller-side Processing of account and product-usage data, and not Customer Personal Data as Section 1 defines it (the Personal Data of Authorized Users contained within Inference Content and Usage Data). Recovea does not rely on that classification to narrow Customer's rights. PostHog is listed on the published Sub-processor list as an Engaged Sub-processor, and Recovea affords it the full treatment of this Section 6 — the flow-down obligations of Section 6.3, the thirty (30) days' change notice of Section 6.4, and the objection and bounded remedy of Section 6.5 — as if it Processed Customer Personal Data. Recovea's controller-side disclosures for this Processing are additionally made in the Privacy Notice. Where the published Sub-processor list and this Section differ on the inventory facts (identity, purpose, location, engagement status), the published list controls; where they differ on obligations, this DPA controls.

6.3 Obligations flow-down. Before a Sub-processor Processes Customer Personal Data, Recovea will impose on it, by written contract, data-protection obligations that are no less protective than those in this DPA to the extent applicable to the services provided. Recovea remains responsible to Customer for the performance of each Sub-processor's obligations.

6.4 Change notice (stated verbatim across the pack). Recovea will give Customer at least thirty (30) days' prior notice of the addition or replacement of a Sub-processor that Processes Customer Personal Data, by updating the Sub-processor list and/or notifying Customer through the Service or by email, before that Sub-processor begins Processing. Where Recovea must engage a new or replacement Sub-processor on an emergency basis (for example, to address a security, availability, legal, or continuity event), Recovea will provide as much notice as is practicable in the circumstances. This thirty (30) day period is stated identically across this DPA, the Privacy Notice, the Sub-processor list, and the Refund Policy.

6.5 Objection and bounded remedy (stated verbatim across the pack). Customer may object to a new or replacement Sub-processor on reasonable data-protection grounds by notifying Recovea in writing within the notice period. The parties will discuss the objection in good faith. If the parties cannot resolve the objection, Customer's sole and exclusive remedy is to terminate the affected portion of the Service that cannot be provided without the objected-to Sub-processor and to receive a pro-rata refund of any prepaid, unused Fees for that affected portion. This remedy is stated identically across this DPA, the Privacy Notice, the Sub-processor list, and the Refund Policy.

7. Security measures (TOMs)

7.1 Recovea will implement and maintain appropriate technical and organizational measures designed to protect Customer Personal Data against a Security Incident, taking into account the state of the art, the costs of implementation, the nature, scope, context, and purposes of Processing, and the risks to Data Subjects. The current measures are described in Annex II and in the Security Statement, which is incorporated by reference and is the conservative anchor for Recovea's security representations; no statement in this DPA exceeds the Security Statement.

7.2 Live measures. As of the date of this DPA, Recovea's measures include: AES-256-GCM encryption of secrets at rest under AWS KMS envelope encryption, each secret sealed with a KMS-wrapped data key minted under a per-tenant KMS encryption context and with the tenant UUID additionally bound as authenticated data (so the tenant is bound at both layers); in-memory-only decryption of secrets; a strict egress allowlist limited to Provider and AWS domains; a closed server-side-request-forgery class; verified cross-tenant isolation; an opaque server-side session model with fail-closed authentication (Cognito verified once at the edge, with raw Cognito tokens never reaching the browser); server-side role-based access control across five workspace roles (Owner, Admin, Member, Billing, Viewer), enforced by a single capability matrix applied to every console route and re-resolved from the authoritative membership on every request; nightly logical database backups (pg_dump); an append-only key-lifecycle audit log; and Ledger export with offline re-derivation. Encryption in transit uses TLS.

7.3 Planned measures are not represented as live. Certain measures are on Recovea's roadmap and are not represented as currently in place, including: a bring-your-own customer-managed-key (BYO-CMK) kill switch (Recovea-managed AWS KMS envelope encryption is live); SSO/SAML/SCIM and automated user provisioning (role-based access control itself is live and enforced server-side across five roles — see Section 7.2 and Annex II); high availability / multi-AZ; tested disaster recovery (no RTO/RPO is committed and restoration is untested); SOC 2, ISO 27001, or PCI certification (roadmap / "aligned to" only — not held); region pinning beyond the single region; an independently third-party-verifiable assurance artifact (Ledger export ships today; independent verification is a future objective); and automated, probe-driven status monitoring (a human-maintained public status page is live at status.recovea.ai; it does not probe the Service and carries no availability commitment). No surface may imply that BYO-CMK or any other Planned measure is live. The AES-256-GCM-under-KMS-envelope-encryption disclosure (BYO-CMK Planned) is prominent and identical wherever security is described.

7.4 Customer is responsible for its own security configuration choices, credential hygiene, and use of available controls (including access restrictions, retention settings, and the Breaker controls). Recovea's measures protect the Service environment and do not extend to systems, networks, or Providers controlled by Customer or its Providers.

7.5 Recovea may update its TOMs from time to time, provided that the updates do not materially reduce the overall level of security of the Service.

8. Security Incident notification

8.1 Recovea will notify Customer without undue delay after becoming aware of a Security Incident. For purposes of this Section, Recovea "becomes aware" when it has a reasonable degree of certainty that a Security Incident has occurred. The trigger is not qualified by any requirement that the incident be "confirmed" beyond that reasonable-certainty standard; the sole narrowing is the carve-out for unsuccessful attempts and non-compromising activity in Section 1.20. This standard matches GDPR Article 33(2) and, where the SCCs apply, Clause 8.6(c), and is the breach-notification standard everywhere in the legal pack. Recovea does not commit to a fixed number of hours that a single operator cannot reliably meet.

8.2 The notification will, to the extent known and as it becomes available, describe the nature of the Security Incident, the categories and approximate number of Data Subjects and records affected, the likely consequences, and the measures taken or proposed to address it. Where Recovea cannot provide all information at once, it may provide it in phases without undue further delay.

8.3 Recovea will take reasonable steps to mitigate and, where possible, remediate the Security Incident, and will reasonably cooperate with Customer's investigation and any notifications Customer is required to make. Customer is responsible for determining whether a Security Incident requires notification to regulators or Data Subjects and for making any such notifications; Recovea's notification under this Section 8 is not an acknowledgment of fault or liability.

8.4 Recovea will maintain a record of Security Incidents affecting Customer Personal Data, including the facts relating to the incident, its effects, and the remedial action taken.

9. Assistance to Customer (data-subject and compliance support)

9.1 Data-subject requests. Taking into account the nature of the Processing, Recovea will provide reasonable assistance, including by appropriate technical and organizational measures and the self-service controls of the Service, to enable Customer to respond to requests by Data Subjects to exercise their rights under Data Protection Law (including access, correction, deletion, portability, and opt-out). If Recovea receives a request directly from a Data Subject relating to Customer Personal Data, Recovea will, unless legally prohibited, promptly inform the Data Subject to direct the request to Customer and/or forward the request to Customer, and will not otherwise respond except on Customer's instruction or as required by law.

9.2 Other assistance. Taking into account the nature of Processing and the information available to Recovea, Recovea will provide reasonable assistance to Customer with: (a) data-protection impact assessments and prior consultations with supervisory authorities; and (b) Customer's obligations relating to the security of Processing and the notification of Security Incidents, in each case to the extent these relate to Recovea's Processing under the Agreement.

9.3 Cost. Recovea will provide the assistance in Sections 9.1–9.2 at no charge to the extent the self-service features of the Service or reasonable support effort suffice. Where assistance requires materially more than reasonable effort, the parties will agree on reasonable, documented charges in advance.

10. Audit and compliance verification (report-based and bounded)

10.1 Recovea will make available to Customer information reasonably necessary to demonstrate compliance with this DPA and will allow for and contribute to audits, including inspections, conducted by Customer or an auditor mandated by Customer, in each case as bounded by this Section 10.

10.2 Report-based first. Recovea satisfies its audit obligation primarily by making available, on request and subject to confidentiality obligations, its then-current security documentation, including the Security Statement, a description of its TOMs (Annex II), responses to a reasonable security questionnaire, and any third-party audit reports or certifications Recovea then holds. At launch Recovea does not hold a SOC 2, ISO 27001, or PCI report; Recovea will make such reports available if and when obtained. Recovea will candidly disclose its operational scale (including single-operator operation) when responding.

10.3 On-site / direct audits — bounded. If the information made available under Section 10.2 is not sufficient for Customer to demonstrate compliance, or where a supervisory authority or Data Protection Law requires it, Customer may request a direct audit, subject to the following bounds: (a) no more than once per twelve (12) month period, except where required by a supervisory authority or following a Security Incident; (b) on at least thirty (30) days' prior written notice; (c) during regular business hours, with minimal disruption, and subject to Recovea's safety, security, and confidentiality requirements; (d) not extending to data or systems of other customers, Recovea's trade secrets, or source code; (e) conducted by Customer personnel or an independent, reputable auditor bound by confidentiality and not a competitor of Recovea; and (f) at Customer's expense, except that Recovea will bear its own internal costs. The parties will agree on scope, timing, and method in advance.

10.4 This Section 10 satisfies the audit requirements of Article 28(3)(h) GDPR and the equivalent provisions of US State Privacy Laws (including the right to take reasonable and appropriate steps to ensure Service-Provider compliance).

11. Aggregated/De-identified Data and no re-identification

11.1 Recovea may create and use Aggregated/De-identified Data derived from Customer Data and from the operation of the Service solely for operating, securing, and improving the Service. Recovea undertakes this Processing as an independent Controller (see Section 2.2), not as Customer's Service Provider or Processor. To the extent any input is Personal Data prior to de-identification, Recovea's lawful basis is its legitimate interest in operating, securing, and improving the Service, which Recovea has documented and balanced against Data-Subject interests. For purposes of US State Privacy Laws, Recovea does not combine Customer Personal Data with Personal Data from any other source, and does not use it for any commercial purpose other than as permitted in this Section; de-identification is performed in a manner permitted by Cal. Civ. Code § 1798.140 and applicable law.

11.2 Aggregated/De-identified Data must meet, at minimum, the de-identification standard of Cal. Civ. Code § 1798.140(m) and, to the extent European Data Protection Law applies, the standard under that law for data that is no longer personal data. Recovea will not attempt to re-identify, or to associate Aggregated/De-identified Data with, any identified or identifiable natural person, Customer, or Authorized User, and will maintain and use such data only in de-identified or aggregated form, will publicly commit to maintaining and using it in that form, and will contractually obligate any recipient to the same. Aggregated/De-identified Data is not Customer Personal Data and is not subject to the deletion obligations of Section 14. For the avoidance of doubt, the content-free Ledger integrity record (Section 14.3) is not Aggregated/De-identified Data and is not asserted to meet the anonymization threshold; it is pseudonymized integrity metadata retained under the legal-obligation and legal-claims exceptions.

11.3 Nothing in this Section 11 or elsewhere permits Recovea to use Customer Personal Data, Inference Content, model outputs, other Service outputs, or the Ledger to train, fine-tune, or develop any AI/ML model, which remains prohibited under Section 2.6.

12. AI-law characterization and allocation of duties

12.1 The Service is an infrastructure, observability, and cost-control conduit for Customer's own AI usage. Based on the Service's current functionality, and reserving Recovea's right to add capabilities, Recovea is not a provider, developer, or deployer of a high-risk AI system, nor a provider of a general-purpose AI model, under the EU AI Act, the Colorado AI Act, or other US state AI laws. Routing and conduit functions are not individualized automated decision-making by Recovea, and Recovea undertakes no affirmative duty to monitor, moderate, or filter the content of Inference Content. Where Recovea later makes available a capability that would change this characterization, the characterization is assessed against that capability's then-current functionality and the terms in effect when Recovea makes it available.

12.2 As between the parties, the duties of a deployer, developer, or controller of any AI system that Customer operates through the Service sit with Customer. Customer is responsible for the lawfulness, governance, transparency, human-oversight, and impact-assessment obligations applicable to its AI use. Cached responses served by the Service are byte-identical to a prior response and are never synthesized by Recovea.

13. International data transfers (executable, dormant at launch)

13.1 US-only at launch. The Service is hosted in the United States, and at launch Recovea does not direct the Service to, or knowingly Process Personal Data subject to, European Data Protection Law. This Section 13 and Annex IV are in force on acceptance of this DPA but become operative only with respect to a Restricted Transfer — that is, only with respect to Processing of Customer Personal Data subject to European Data Protection Law that constitutes a Restricted Transfer. They are included and effective so that the first such transfer is already covered, regardless of when Recovea becomes aware of it, and are the only place in the legal pack where transfer mechanics live; the ToS/MSA, Privacy Notice, and Security Statement do not contain independent transfer representations.

13.2 Module 2 SCCs (EU). To the extent Recovea Processes Personal Data subject to the GDPR on Customer's behalf in a manner that constitutes a Restricted Transfer, the parties incorporate by reference the Standard Contractual Clauses, Module Two (Controller-to-Processor), which are deemed entered into and completed as set out in Annex IV. Where Customer is itself a Processor, Module Three (Processor-to-Processor) applies instead, completed mutatis mutandis.

13.3 UK transfers. For Restricted Transfers subject to the UK GDPR, the parties incorporate the UK Addendum, which amends the SCCs as set out in Annex IV.

13.4 Swiss transfers. For Restricted Transfers subject to the FADP, the SCCs apply with the Swiss amendments set out in Annex IV (including treating references to the GDPR as references to the FADP, recognizing the Swiss Federal Data Protection and Information Commissioner as competent supervisory authority, and extending protection to legal entities and to data of Swiss-resident persons).

13.5 Order of precedence. Where the SCCs (as amended by the UK Addendum and Swiss amendments) apply, they prevail over any conflicting term of this DPA or the Agreement to the extent of the conflict and only with respect to the Processing they govern. The completed transfer annexes in Annex IV are executable, and Annex V provides a signature block so the first non-US signer is covered.

13.6 Government access / transparency. If Recovea receives a legally binding request from a public authority for Customer Personal Data, Recovea will, to the extent legally permitted, notify Customer, challenge requests that are unlawful or overbroad, and disclose only the minimum necessary.

14. Return and deletion; the immutable Ledger carve-out

14.1 Deletion or return on termination. Upon termination or expiration of the Agreement, Recovea will, at Customer's documented election, delete or return Customer Personal Data in Recovea's possession, and delete existing copies, except to the extent retention is required by applicable law or permitted by Section 14.3. Customer may make this election at any time up to thirty (30) days after termination or expiration (the "wind-down period"). If Customer does not make an election within the wind-down period, Recovea will, as the hard default, delete Customer Personal Data in accordance with the Retention Schedule and its standard deletion processes promptly following the end of the wind-down period. This Section gives effect to SCC Clause 8.5 and Article 28(3)(g) GDPR. Customer is responsible for exporting its data before the end of the wind-down period using the Service's export functionality (including Ledger export).

14.2 Retention during the term and body persistence. During the term, Recovea retains Customer Personal Data in accordance with the Retention Schedule incorporated by reference, on the following harmonized basis, stated identically across the pack:

  • Body persistence (default). By default the Service does not persist request or response bodies (Inference Content payloads); it retains only Usage Data metadata (Section 1.26). Request and response bodies are stored only (a) in the hash-keyed response cache available on the paid plan, where Customer enables caching, keyed by request hash; and (b) where Customer affirmatively opts into body capture, for a limited time-to-live (TTL), currently twenty-four (24) hours.
  • Usage Data metadata retention. Thirty (30) days on the Free plan, ninety (90) days on the Developer plan, three hundred sixty-five (365) days on the Team and Growth plans, and one thousand ninety-five (1,095) days on the Scale plan (Enterprise: per Order Form), for the data each plan governs.
  • Billing records. Approximately seven (7) years, as required by applicable tax and accounting law.
  • Opt-in captured bodies. Retained only for the configured TTL (default twenty-four (24) hours), then deleted.

This single statement of whether bodies are persisted by default governs the pack and is reflected in Annex I.E and I.H.

14.3 Immutable, content-free Ledger erasure carve-out (one verbatim paragraph reused across the pack). Notwithstanding any deletion or erasure obligation, the Ledger is a hash-chained, append-only integrity record that Recovea must preserve to maintain the verifiability and integrity of the cost record and to meet legal, audit, and billing requirements. When Customer Personal Data is deleted or erased, Recovea retains only a content-free integrity record: a cryptographic tombstone and the structural metadata necessary to preserve the hash chain, with any customer identifier severed (set to null) so that the retained record cannot be used to identify a Data Subject. This record is pseudonymized integrity metadata, not anonymized data, and Recovea retains it under the exceptions of Data Protection Law for retention required by law (legal obligation) and for the establishment, exercise, or defense of legal claims; Recovea does not assert that this record meets the anonymization threshold of European Data Protection Law. Recovea provides an operator-run erasure procedure (recoveactl erase-customer) that severs identifiers and removes Customer content while preserving this content-free integrity record. At launch this erasure procedure is operator-run and partly manual; independently audit-verifiable erasure is a future objective and is not represented as currently available. This carve-out is stated verbatim across the Privacy Notice, this DPA, the Retention Schedule, the Security Statement, the AUP, and the Data-Rights materials.

14.4 Certification of deletion will be provided on Customer's reasonable written request.

15. Liability, indemnity, and remedies

15.1 Liability architecture (consistent with the Agreement). Each party's and its Affiliates' aggregate liability arising out of or related to this DPA, whether in contract, tort, or otherwise, is subject to, and counts toward, the limitations of liability in the Agreement, which apply identically here:

  • Exclusion (mutual). Neither party is liable for any indirect, incidental, special, consequential, exemplary, or punitive damages, or for lost profits, revenue, goodwill, or data, even if advised of the possibility.
  • General cap. Each party's aggregate liability does not exceed the greater of (a) the total Fees paid by Customer to Recovea in the twelve (12) months before the event giving rise to liability and (b) US $25,000.
  • Enhanced (super) cap. For (i) breach of confidentiality and (ii) breach of the data-protection or security obligations of this DPA (including a Security Incident caused by a party's breach), each party's aggregate liability does not exceed two (2) times the General Cap. This super-cap is symmetric and identical across the pack.
  • Uncapped. The following are not subject to the General Cap or the super-cap: a party's indemnification obligations (Sections 15.3–15.4); Customer's payment obligations; Customer's breach of the license, Acceptable Use, or IP-ownership terms; and a party's fraud or willful misconduct, in each case to the extent liability cannot be limited under applicable law. A party's liability for gross negligence remains subject to the General Cap and the super-cap to the fullest extent permitted by applicable law; where, and only to the extent, applicable law does not permit liability for gross negligence to be so limited, such liability is limited to the maximum extent that law permits.

These limitations apply notwithstanding any failure of essential purpose of any limited remedy and form part of the basis of the bargain. Nothing in this DPA expands or limits liability beyond what the Agreement provides, and nothing limits liability that cannot be limited under applicable law.

15.2 SCC liability. Where the SCCs apply, the liability and indemnity provisions of the SCCs govern as between the parties with respect to the data subjects and Processing they cover, and operate alongside (and are subject to, except as the SCCs require otherwise) the Agreement's limitations.

15.3 Recovea IP indemnity (cross-reference). The Agreement's intellectual-property indemnity — under which Recovea defends third-party claims that the Service as provided infringes a US patent, copyright, or trade secret, subject to the exclusions (including Provider outputs and models, Customer Content, Data, and Provider Keys, combinations or modifications not made by Recovea, and use outside the Documentation or in breach), the sole remedy (procure / modify / replace / terminate and refund prepaid, unused Fees), and the General Cap stated in the Agreement — applies. This DPA does not modify it.

15.4 Customer indemnity. Customer will defend, indemnify, and hold harmless Recovea and its Affiliates from and against third-party claims, and resulting losses, liabilities, damages, costs, and reasonable attorneys' fees, arising out of or relating to: (a) Customer Data, Customer's documented instructions, or Inference Content, including the means by which Customer acquired, sourced, or transmitted it; (b) Customer's breach of its warranties or obligations in Section 3, the absence of a lawful basis for the Processing, or any unlawful or infringing instruction; (c) Customer's transmission of Sensitive Data or regulated data in breach of Section 2.7; (d) Customer's use of the Service in violation of the AUP or applicable law; and (e) Customer's configuration of the Service to attribute Usage Data to identified individuals without providing the notices or obtaining the consents required by Section 3.2(e). The indemnified party will give prompt notice of the claim, reasonable cooperation, and (subject to the indemnifying party's control of the defense) sole control of the defense; no settlement that admits liability of or imposes non-indemnified obligations on the indemnified party may be entered without its consent. Consistent with Section 15.1, Customer's indemnification obligations are not subject to the General Cap.

15.5 This DPA does not create any third-party-beneficiary rights except as expressly required by the SCCs (which confer rights on data subjects as set out therein) or by mandatory Data Protection Law.

16. Term, termination, and survival

16.1 This DPA takes effect on the effective date of the Agreement and continues until the Agreement terminates or expires and Recovea has ceased all Processing of Customer Personal Data under it. The SCCs in Annex IV remain in effect for as long as Recovea Processes Personal Data subject to European Data Protection Law on Customer's behalf.

16.2 Provisions that by their nature should survive termination survive, including Sections 1, 2.5, 2.6, 4, 5, 8.4 (incident records), 9 (residual assistance), 10 (audit of completed Processing), 11, 13 and Annex IV (to the extent Processing or the SCCs continue), 14, 15, and 17–22.

17. Order of precedence

In the event of any conflict, the following order of precedence applies, with respect only to the matters each instrument governs: (a) a signed Order Form (where it so states); (b) the MSA (which supersedes the click-through ToS for matters it covers); (c) this DPA (which controls for the Processing of Personal Data); (d) the BYO-Key Addendum (which controls only on Provider Key handling, Provider Terms, Provider Charges, and runaway-spend allocation, and does not displace this DPA or the Agreement's liability and indemnity architecture); (e) the incorporated policies; and (f) the ToS body. Where the SCCs apply, Section 13.5 governs their precedence over conflicting terms.

18. Governing law, venue, and dispute resolution

18.1 Governing law. This DPA is governed by the laws of the State of Delaware, excluding its conflict-of-laws rules, and excluding the UN Convention on Contracts for the International Sale of Goods, except where mandatory Data Protection Law or the SCCs require otherwise. This is the governing law of the Agreement, conformed across the entire legal pack.

18.2 Dispute resolution. Disputes between the parties arising out of or relating to this DPA are resolved under the dispute-resolution mechanism of the Agreement, which is: binding arbitration before the American Arbitration Association (AAA) under its Commercial Arbitration Rules, by one arbitrator, seated in Wilmington, Delaware; judgment on the award may be entered in any court of competent jurisdiction. The parties waive any right to bring or participate in a class, collective, or representative action, and agree that claims may be brought only in an individual capacity. The parties intend the AAA Commercial Arbitration Rules to apply, subject to the Agreement's Consumer-Rules fallback and mass-arbitration protocol (Terms of Service §24.2 and §24.7 / MSA §23.2 and §23.6): if the AAA or a court of competent jurisdiction determines that the AAA Consumer Arbitration Rules apply to a dispute involving an individual, those rules govern that dispute and Recovea pays the filing, administrative, and arbitrator fees the AAA consumer fee schedule assigns to the business (this is a business-to-business, business-property service); otherwise each party bears its own fees as provided under the AAA Commercial Rules. Carve-outs to court: either party may seek (a) injunctive or other equitable relief for actual or threatened infringement or misuse of intellectual property or breach of confidentiality, and (b) relief in small-claims matters within that court's jurisdiction, in each case in the state or federal courts located in Wilmington, Delaware, to whose jurisdiction the parties consent. The arbitration model, seat, administrator and rules, arbitrator count, fee allocation, and court carve-outs are identical across the entire legal pack and the public website terms.

18.3 Non-party forum. Where the SCCs apply, the choice of forum, supervisory authority, and governing law for those clauses is as set out in Annex IV and prevails for matters the SCCs govern.

19. Notices

Legal and data-protection notices to Recovea under this DPA must be sent to legal@recovea.ai (with privacy matters also to privacy@recovea.ai, the Privacy Contact mailbox, and security matters to security@recovea.ai) and, where a physical address is required, to 2810 N Church St STE 89986, Wilmington, DE 19802. Notices to Customer may be sent to the administrative or billing contact on Customer's account or through the Service. Recovea uses a "Privacy Contact" at privacy@recovea.ai; because the Service is US-only and the European transfer mechanics are dormant, Recovea does not name a Data Protection Officer or an Article 27 representative that it has not in fact appointed.

20. Amendments

Recovea may update this DPA from time to time, provided that no update will materially reduce the protections for Customer Personal Data during the term of the Agreement. Where Data Protection Law changes (including the adoption of new or revised SCCs or transfer mechanisms), the parties will negotiate in good faith and will be deemed to adopt updated or replacement clauses as required to remain compliant, and Recovea may incorporate such updated mechanisms by notice. Any other amendment must be in writing.

21. Severability, waiver, assignment, and electronic acceptance

21.1 Severability. If any provision of this DPA is held invalid or unenforceable, the remaining provisions remain in full force, and the invalid provision will be reformed to the minimum extent necessary to make it enforceable while preserving its intent.

21.2 Waiver. No failure or delay in exercising a right waives it, and no single or partial exercise precludes any further exercise.

21.3 Assignment. This DPA follows the assignment provisions of the Agreement and may not be assigned separately from it.

21.4 Electronic acceptance and counterparts. This DPA may be accepted electronically and, where signed, may be executed in counterparts (including by electronic signature), each of which is deemed an original and all of which together constitute one instrument, valid and enforceable under the U.S. E-SIGN Act and applicable state law.

22. Entire agreement

This DPA, together with its Annexes and the Agreement into which it is incorporated, constitutes the entire agreement between the parties regarding the Processing of Customer Personal Data and supersedes any prior or contemporaneous agreements, representations, or understandings on that subject. Except as expressly modified by this DPA, the Agreement remains in full force and effect. Recovea is a bootstrap-funded US company; nothing in this DPA concerns investment or securities.

Annex I — Description of the Processing

A. List of parties.

  • Data exporter / Controller: Customer, as identified in the Order Form or account record. Contact: Customer's administrative contact. Role: Controller (or Processor, where Customer acts on behalf of a third party).
  • Data importer / Processor: Recovea, Inc., a Delaware corporation, registered notice address: 2810 N Church St STE 89986, Wilmington, DE 19802. Contact: privacy@recovea.ai / legal@recovea.ai. Role: Processor / Service Provider.

B. Subject matter and duration. Processing of Customer Personal Data as necessary to provide the Service for the term of the Agreement and the wind-down period in Section 14.1, after which data is deleted or returned per Section 14.

C. Nature and purpose of the Processing. Provision of an in-path AI-gateway, metering, observability, cost-optimization (cache and dedup), spend-control, reporting, and verifiable cost-ledger Service; transmission of Inference Content to Customer's own Providers; account, billing, support, and security operations; and creation of Aggregated/De-identified Data — including without limitation optimization and such additional functionality as the Service may provide from time to time. Any such capability is governed by the terms in effect when Recovea makes it available and does not expand the Processing beyond what Customer instructs and configures.

D. Categories of Data Subjects. Customer's Authorized Users and administrators; and any natural persons whose Personal Data Customer or its Authorized Users include within Inference Content (determined and controlled by Customer).

E. Categories of Personal Data.

  • Account / Authorized-User data: name, business email, role, authentication identifiers, audit-log entries.
  • Usage Data: model/provider identifiers, token counts, latency, status codes, request hashes, timestamps, cost figures.
  • Inference Content: request and response payloads that may contain Personal Data placed there by Customer (content and categories determined and controlled by Customer). By default the Service does not persist these bodies; it retains only Usage Data metadata. Bodies are stored only (a) in the hash-keyed paid-tier response cache where Customer enables caching, keyed by request hash, and (b) where Customer opts into body capture, for a limited TTL (currently 24 hours) — as stated identically in Section 14.2.
  • Billing data: handled by Stripe; Recovea does not store full payment-card numbers.

F. Sensitive Data. Not intended to be Processed; the regulated categories in Section 2.7 must not be submitted absent a signed writing. If Customer transmits Sensitive Data within Inference Content, Customer is responsible per Section 2.7. No additional restrictions beyond the TOMs are represented.

G. Frequency. Continuous, for the duration of the Agreement.

H. Retention. Per Section 14.2 and the Retention Schedule: Usage Data metadata 30 days (Free) / 90 days (Developer) / 365 days (Team) / 365 days (Growth) / 1,095 days (Scale; Enterprise per Order Form); billing records ~7 years (statutory); opt-in captured bodies for the configured TTL (default 24 hours); request/response bodies not otherwise persisted by default. Subject to the content-free Ledger carve-out (Section 14.3).

I. Sub-processors. Per Section 6 and the published Sub-processor list: Amazon Web Services, Inc. (hosting, storage, identity via Cognito, and Amazon SES for transactional email); Stripe, LLC (payments); PostHog, Inc. (cookieless product analytics — marketing website and authenticated dashboard, US data region; Section 6.2.1). Functional Software, Inc. d/b/a Sentry (browser error reporting on the marketing website and the authenticated dashboard, US data region; Engaged 2026-08-05 — Section 6.2; never in-path). Providers are not Sub-processors (Section 5).

J. Capability-activation supplements. Where Customer activates an additional Service capability under the Agreement's incorporated schedules or addenda (for example, tenant-level metering identifiers, workforce-observation features, or authorized data connectors), the activating Order Form or schedule supplements Sections C–E of this Annex I with that capability's subject matter, categories of Data Subjects (for example, Customer's end customers or members of Customer's workforce), and categories of Personal Data, and constitutes a documented instruction under Section 2.3, without further amendment of this DPA.

Annex II — Technical and Organizational Measures (TOMs)

The measures below summarize Annex II for SCC purposes and are subordinate to, and may not exceed, the Security Statement.

  • Encryption. AES-256-GCM for secrets at rest under AWS KMS envelope encryption (per-tenant KMS encryption contexts) with tenant-UUID as additional authenticated data; in-memory-only decryption; TLS in transit. BYO-CMK is Planned and not live.
  • Access control. Opaque server-side sessions; fail-closed authentication (Cognito verified once at the edge; raw tokens never reach the browser); least-privilege, need-to-know access; role-based access control enforced server-side across five workspace roles (Owner, Admin, Member, Billing, Viewer) by one capability matrix applied to every console route, with the acting role re-resolved from the authoritative membership on every request and Owner-only reservation of workspace deletion, Lever activation, and Owner transfer (SSO/SAML/SCIM Planned).
  • Network / isolation. Strict egress allowlist (Provider + AWS domains); closed SSRF class; verified cross-tenant isolation.
  • Resilience / backup. Nightly logical backups (pg_dump). HA/multi-AZ and tested DR are Planned; no RTO/RPO is committed and restore is untested.
  • Integrity / auditability. Hash-chained, append-only Ledger with offline re-derivation and export; append-only key-lifecycle audit log; records of Security Incidents (Section 8.4).
  • Operational candor. Single-operator operation is disclosed; Recovea does not represent staffing or segregation of duties it lacks.
  • Vendor management. Written data-protection terms flowed down to Sub-processors (Section 6).
  • Certifications. None held at launch; SOC 2 / ISO 27001 / PCI are "aligned to" / roadmap only and are not represented as held.

Annex III — US State Privacy Law Service-Provider terms

For Processing subject to US State Privacy Laws, Recovea acts as a Service Provider / Processor and: (a) Processes Customer Personal Data only for the business purposes specified in the Agreement and this DPA; (b) will not sell or share Customer Personal Data and will not Process it for cross-context behavioral advertising; (c) will not retain, use, or disclose Customer Personal Data outside the direct business relationship or for any purpose other than the specified business purposes, except as permitted by law; (d) will not combine Customer Personal Data with other data except as permitted by law to perform a business purpose; (e) certifies it understands and will comply with these restrictions; (f) will notify Customer if it determines it can no longer meet its obligations and, on notice, will allow Customer to take reasonable steps to stop and remediate unauthorized use; (g) will assist Customer in responding to consumer-rights requests (Section 9); and (h) grants Customer the right to take reasonable and appropriate steps to ensure compliance (Section 10). These terms apply by default and control over any conflicting term for Processing they govern.

Annex IV — International data-transfer terms (dormant, executable)

This Annex applies only as provided in Section 13.

1. EU SCCs (Module Two, Controller-to-Processor; Module Three where Customer is a Processor). The SCCs are incorporated by reference and deemed executed by the parties on acceptance of this DPA, completed as follows:

  • Clause 7 (Docking): included.
  • Clause 9 (Sub-processors): Option 2 (general written authorization), with the thirty (30) day change-notice period in Section 6.4.
  • Clause 11 (Redress): the optional independent-dispute-resolution-body language is not elected.
  • Clause 13 / competent supervisory authority: where the data exporter is established in an EU Member State, the supervisory authority of that Member State; where the exporter is not established in the EU but has appointed a representative or falls within Article 27 GDPR, the supervisory authority of the Member State of that representative or of the relevant data subjects; and, as the default lead authority for transfers pre-covered under this Annex, the Data Protection Commission of Ireland.
  • Clause 17 (Governing law): the law of the Republic of Ireland.
  • Clause 18 (Forum): the courts of the Republic of Ireland.
  • Annexes I–III of the SCCs: populated by Annex I and Annex II of this DPA.

2. UK Addendum. The UK Addendum is incorporated for UK transfers; Table 1 (parties) and Table 3 (appendix) are populated by Annex I and Annex II; the "Approved Addendum" applies; either party may end the Addendum as provided in its Section 19; the start date is the effective date of the Agreement.

3. Swiss amendments. For FADP transfers, the SCCs apply with: references to the GDPR read as references to the FADP; the competent authority is the Swiss FDPIC (and, for concurrent EU transfers, the relevant EU authority identified in Section 1 of this Annex); the term "Member State" is read so as not to deprive Swiss-resident data subjects of redress in their place of habitual residence; and protections extend to data of legal entities until the FADP no longer so provides.

4. The completion of these clauses is executable so that the first transfer of Personal Data subject to European Data Protection Law is already covered; until such a transfer occurs, this Annex is dormant.

Annex V — Signature block (optional; for SCC execution)

A counter-signed copy may be requested at legal@recovea.ai. Acceptance of the Agreement constitutes acceptance of this DPA without a separate signature; this block is provided for Customers that require an executed copy.

Recovea, Inc. By: ______________________ Name: ______________________ Title: ______________________ Date: ____________

Customer By: ______________________ Name: ______________________ Title: ______________________ Date: ____________

End of Data Processing Agreement.