DATA PROCESSING ADDENDUM
Finale Labs, Inc., doing business as Theo (“Theo”, which is “Provider” below and “we” or “the Company” in Theo’s Legal Terms), publishes this document as its Data Processing Addendum (“DPA”). Theo’s Legal Terms (Terms of Service) incorporate it, and the party that accepted the Legal Terms for the Theo account (“you” in the Legal Terms) is “Customer”. Where the Legal Terms or Theo’s Privacy Notice refer to Theo’s Data Processing Addendum, they mean this document.
This Data Processing Addendum (“DPA”) is a set of standard terms entered into between Customer and Provider by completing the DPA Details below, which are incorporated into the Main Agreement as Additional Term 1 provides.
1. Definitions.
1.1. “Additional Terms” means any additions to, or modifications of, this DPA (including any Exhibits) agreed by the parties.
1.2. “Affiliate” means an entity controlled, controlling or under common control with a party, where control means at least 50% ownership or power to direct an entity’s management.
1.3. “Audit” and “Audit Parameters” are defined in Section 9.3 below.
1.4. “Audit Report” is defined in Section 9.2 below.
1.5. “Controller” means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of Processing of Personal Data.
1.6. “Customer” is identified in the DPA Details.
1.7. “Customer Data” means Customer Data as defined in the Main Agreement.
1.8. “Customer Instructions” is defined in Section 3.1 below.
1.9. “Customer Personal Data” means Personal Data in Customer Data.
1.10. “Data Protection Laws” means all laws and regulations applicable to the Processing of Customer Personal Data under the Main Agreement, including, as applicable: (i) U.S. state privacy laws, including the California Consumer Privacy Act, as amended by the California Privacy Rights Act, and any binding regulations promulgated thereunder (“CCPA”), (ii) the General Data Protection Regulation (Regulation (EU) 2016/679) (“EU GDPR” or “GDPR”), (iii) the Swiss Federal Act on Data Protection (“FADP”), (iv) the EU GDPR as it forms part of the law of the United Kingdom by virtue of section 3 of the European Union (Withdrawal) Act 2018, as amended by the Data (Use and Access) Act 2025 (collectively, the “UK GDPR”) and (v) the UK Data Protection Act 2018; in each case, as updated, amended or replaced from time to time.
1.11. “Data Subject” means the identified or identifiable natural person to whom Customer Personal Data relates.
1.12. “DPA Details” means the Key Terms, Processing Details and any Additional Terms as set forth below.
1.13. “DPA Effective Date” is specified in the DPA Details.
1.14. “EEA” means European Economic Area.
1.15. “EU Standard Contractual Clauses” or “EU SCCs” means the Standard Contractual Clauses approved by the European Commission in decision 2021/914.
1.16. “Exhibit” means each of Exhibit A (Cross-Border Transfer Mechanisms) and Exhibit B (Region-Specific Terms), as may be modified or replaced by the parties through Additional Terms.
1.17. “Key Terms” means Main Agreement, DPA Effective Date, Subprocessor List, Designated EU Governing Law and Designated EU Member State as specified by the parties in the DPA Details.
1.18. “Main Agreement” means the agreement between Customer and Provider under which Provider provides the Service to Customer.
1.19. “Personal Data” means information about an identified or identifiable natural person or which otherwise constitutes “personal data”, “personal information”, “personally identifiable information” or similar terms as defined in Data Protection Laws.
1.20. “Processing” and inflections thereof refer to any operation or set of operations that is performed on Personal Data or on sets of Personal Data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.
1.21. “Processing Details” means the Subject Matter and Details of Processing and Security Measures specified by the parties in the DPA Details.
1.22. “Processor” means a natural or legal person, public authority, agency or other body which Processes Personal Data on behalf of the Controller.
1.23. “Provider” is identified in the DPA Details.
1.24. “Restricted Transfer” means: (i) where EU GDPR applies, a transfer of Customer Personal Data from the EEA to a country outside the EEA that is not subject to an adequacy determination, (ii) where UK GDPR applies, a transfer of Customer Personal Data from the United Kingdom to any other country that is not subject to an adequacy determination or (iii) where FADP applies, a transfer of Customer Personal Data from Switzerland to any other country that is not subject to an adequacy determination.
1.25. “Security Incident” means any breach of security that leads to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Customer Personal Data being Processed by Provider.
1.26. “Security Measures” means the technical and organizational security measures for the Service as set forth in the Main Agreement or, if not set forth in the Main Agreement, as specified in the DPA Details.
1.27. “Service” means the services provided by Provider to Customer under the Main Agreement.
1.28. “Specified Notice Period” is 48 hours.
1.29. “Subprocessor” means any third party authorized by Provider to Process any Customer Personal Data.
1.30. “Subprocessor List” means the list of Provider’s Subprocessors as identified or linked to in the DPA Details.
1.31. “Subprocessor Notice Method” means email or in-product notification to an administrator.
2. Scope and Duration.
2.1. Roles of the Parties. This DPA applies to Provider as a Processor of Customer Personal Data and to Customer as a Controller or Processor of Customer Personal Data.
2.2. Scope of DPA. This DPA applies to Provider’s Processing of Customer Personal Data under the Main Agreement to the extent such Processing is subject to Data Protection Laws. This DPA is governed by the governing law of the Main Agreement unless otherwise required by Data Protection Laws.
2.3. Duration of DPA. This DPA commences on the DPA Effective Date and terminates upon expiration or termination of the Main Agreement (or, if later, the date on which Provider has ceased all Processing of Customer Personal Data).
2.4. Exhibits. Exhibit A (Cross-Border Transfer Mechanisms) and Exhibit B (Region-Specific Terms) are incorporated into this DPA.
2.5. Relationship to Main Agreement. This DPA (including the DPA Details) is incorporated into the Main Agreement.
2.6. Order of Precedence. In the event of any conflict or inconsistency among the following documents, the order of precedence will be: (1) any Standard Contractual Clauses or other measures set forth in Exhibit A (Cross-Border Transfer Mechanisms), (2) Exhibit B (Region-Specific Terms), (3) any Additional Terms, (4) this DPA and (5) the Main Agreement. To the fullest extent permitted by Data Protection Laws, any claims brought in connection with this DPA will be subject to the terms and conditions, including, but not limited to, the exclusions and limitations, set forth in the Main Agreement.
3. Processing of Personal Data.
3.1. Customer Instructions.
(a) Provider will Process Customer Personal Data as a Processor only: (i) in accordance with Customer Instructions or (ii) to comply with Provider’s obligations under applicable laws, subject to any notice requirements under Data Protection Laws.
(b) “Customer Instructions” means: (i) Processing to provide the Service and perform Provider’s obligations in the Main Agreement (including this DPA) and (ii) other reasonable documented instructions of Customer consistent with the terms of the Main Agreement.
(c) Details regarding the Processing of Customer Personal Data by Provider are set forth in the Processing Details.
(d) Provider will notify Customer if it receives an instruction that Provider reasonably determines infringes Data Protection Laws (but Provider has no obligation to actively monitor Customer’s compliance with Data Protection Laws).
3.2. Confidentiality.
(a) Provider will protect Customer Personal Data in accordance with its confidentiality obligations as set forth in the Main Agreement.
(b) Provider will ensure personnel who Process Customer Personal Data either enter into written confidentiality agreements or are subject to statutory obligations of confidentiality.
3.3. Compliance with Laws.
(a) Provider and Customer will each comply with Data Protection Laws applicable to their respective Processing of Customer Personal Data.
(b) Customer will comply with Data Protection Laws in its issuing of Customer Instructions to Provider. Customer will ensure that it has established all necessary lawful bases under Data Protection Laws to enable Provider to lawfully Process Customer Personal Data for the purposes contemplated by the Main Agreement (including this DPA), including, as applicable, by obtaining all consents from, and giving all necessary notices to, Data Subjects, as required by Data Protection Laws.
3.4. Changes to Laws. The parties will work together in good faith to negotiate an amendment to this DPA as either party reasonably considers necessary to address the requirements of Data Protection Laws from time to time.
4. Subprocessors.
4.1. Use of Subprocessors.
(a) Customer generally authorizes Provider to engage Subprocessors to Process Customer Personal Data. Customer further agrees that Provider may engage its Affiliates as Subprocessors.
(b) Provider will: (i) enter into a written agreement with each Subprocessor imposing data Processing and protection obligations substantially the same as those set out in this DPA and (ii) remain liable for Provider’s compliance with its obligations under this DPA and for any acts or omissions of a Subprocessor that cause Provider to breach any of its obligations under this DPA.
4.2. Subprocessor List. Provider will maintain an up-to-date list of its Subprocessors, including their functions and locations, as specified in the Subprocessor List.
4.3. Notice of New Subprocessors. Provider may update the Subprocessor List from time to time. At least 30 days before any new Subprocessor Processes any Customer Personal Data, Provider will add such Subprocessor to the Subprocessor List and notify Customer in accordance with the Subprocessor Notice Method.
4.4. Objection to New Subprocessors.
(a) If, within 30 days after notice of a new Subprocessor, Customer notifies Provider in writing that Customer objects to Provider’s appointment of such new Subprocessor based on reasonable data protection concerns, the parties will discuss such concerns in good faith.
(b) If the parties are unable to reach a mutually agreeable resolution to Customer’s objection to a new Subprocessor, Customer, as its sole and exclusive remedy, may terminate the affected portion of the Service by providing written notice to Provider, and Provider will refund any prepaid, unused fees attributable to the terminated portion of the Service as of the date of such termination.
5. Security.
5.1. Technical and Organizational Measures. Provider will implement and maintain reasonable and appropriate technical and organizational measures, procedures and practices, as appropriate to the nature of the Customer Personal Data, that are designed to protect the security, confidentiality, integrity and availability of Customer Personal Data and protect against Security Incidents, in accordance with Provider’s Security Measures. Provider will regularly monitor its compliance with such Security Measures.
5.2. Incident Notice and Response.
(a) Provider will implement and follow procedures to detect and respond to Security Incidents.
(b) Provider will: (i) notify Customer without undue delay and, in any event, not later than the Specified Notice Period, after becoming aware of a Security Incident affecting Customer and (ii) make reasonable efforts to identify the cause of the Security Incident, mitigate the effects and remediate the cause to the extent within Provider’s reasonable control.
(c) Upon Customer’s request and taking into account the nature of the applicable Processing, Provider will assist Customer by providing, when available, information reasonably necessary for Customer to meet its Security Incident notification obligations under Data Protection Laws.
(d) Customer acknowledges that Provider’s notification of a Security Incident is not an acknowledgment by Provider of its fault or liability.
(e) Security Incidents do not include unsuccessful attempts or activities that do not compromise the security of Customer Personal Data, including unsuccessful login attempts, pings, port scans, denial of service attacks or other network attacks on firewalls or networked systems.
5.3. Customer Responsibilities.
(a) Customer is responsible for reviewing the information made available by Provider relating to data security and making an independent determination as to whether the Service meets Customer’s requirements and legal obligations under Data Protection Laws.
(b) Customer is solely responsible for complying with Security Incident notification laws applicable to Customer and fulfilling any obligations to give notices to government authorities, affected individuals or others relating to any Security Incidents.
6. Data Protection Impact Assessment. Upon Customer’s request and taking into account the nature of the applicable Processing, to the extent such information is available to Provider, Provider will assist Customer in fulfilling Customer’s obligations under Data Protection Laws to carry out a data protection impact or similar risk assessment related to Customer’s use of the Service, including, if required by Data Protection Laws, by assisting Customer in consultations with relevant government authorities.
7. Data Subject Requests.
7.1. Assisting Customer. Upon Customer’s request and taking into account the nature of the applicable Processing, Provider will assist Customer by appropriate technical and organizational measures, insofar as possible, in complying with Customer’s obligations under Data Protection Laws to respond to requests from individuals to exercise their rights under Data Protection Laws, provided that Customer cannot reasonably fulfill such requests independently (including through use of the Service).
7.2. Data Subject Requests. If Provider receives a request from a Data Subject in relation to the Data Subject’s Customer Personal Data, Provider will notify Customer and advise the Data Subject to submit the request to Customer (but not otherwise communicate with the Data Subject regarding the request except as may be required by Data Protection Laws), and Customer will be responsible for responding to any such request.
8. Data Return or Deletion.
8.1. During the Term of the Main Agreement. During the term of the Main Agreement, Customer may, through the features of the Service or such other means specified in the Additional Terms, access, return to itself or delete Customer Personal Data.
8.2. Post Termination.
(a) Following termination or expiration of the Main Agreement, Provider will, in accordance with its obligations under the Main Agreement, delete all Customer Personal Data from Provider’s systems. If the Main Agreement contains no such obligations, Provider will delete or return to Customer all Customer Personal Data in Provider’s possession, custody or control as soon as reasonably practicable after such termination or expiration.
(b) Deletion will be in accordance with industry-standard secure deletion practices. Provider will issue a certificate of deletion upon Customer’s request.
(c) Notwithstanding the foregoing, Provider may retain Customer Personal Data: (i) as required by Data Protection Laws or (ii) in accordance with its standard backup or record retention policies, provided that, in either case, Provider will
(x) maintain the confidentiality of, and otherwise comply with the applicable provisions of this DPA with respect to, retained Customer Personal Data and (y) not further Process retained Customer Personal Data except for such purpose(s) and duration specified in such applicable Data Protection Laws.
9. Audits.
9.1. Provider Records Generally. Provider will keep records of its Processing in compliance with Data Protection Laws and, upon Customer’s request, make available to Customer any records reasonably necessary to demonstrate compliance with Provider’s obligations under this DPA and Data Protection Laws.
9.2. Third-Party Compliance Program.
(a) Upon Customer’s written request at reasonable intervals, Provider will describe its third-party audit and certification programs (if any) and make summary copies of its audit reports (each, an “Audit Report”) available to Customer (subject to confidentiality protections for Provider).
(b) Customer may share copies of Audit Reports with relevant government authorities as required upon their request.
(c) Customer agrees that any audit rights granted by Data Protection Laws will be satisfied by Audit Reports and the procedures of Section 9.3 (Customer Audit) below.
9.3. Customer Audit.
(a) Subject to the terms of this Section 9.3, Customer has the right, at Customer’s expense, to conduct an audit of reasonable scope and duration pursuant to a mutually agreed-upon audit plan with Provider that is consistent with the Audit Parameters (an “Audit”).
(b) Customer may exercise its Audit right: (i) to the extent Provider’s provision of an Audit Report does not provide sufficient information for Customer to verify Provider’s compliance with this DPA or the parties’ compliance with Data Protection Laws, (ii) as necessary for Customer to respond to a government authority audit or (iii) in connection with a Security Incident.
(c) Each Audit must conform to the following parameters (“Audit Parameters”): (i) be conducted by an independent third party that will enter into a confidentiality agreement with Provider, (ii) be limited in scope to matters reasonably required for Customer to assess Provider’s compliance with this DPA and the parties’ compliance with Data Protection Laws, (iii) occur at a mutually agreed date and time and only during Provider’s regular business hours, (iv) occur no more than once annually (unless required under Data Protection Laws or in connection with a Security Incident), (v) cover only facilities controlled by Provider, (vi) restrict findings to Customer Personal Data only and (vii) treat any results as confidential information to the fullest extent permitted by Data Protection Laws.
10. Cross-Border Transfers/Region-Specific Terms.
10.1. Cross-Border Data Transfers.
(a) Provider (and its Affiliates) may Process and transfer Customer Personal Data globally as necessary to provide the Service.
(b) If Provider engages in a Restricted Transfer, it will comply with Exhibit A (Cross-Border Transfer Mechanisms).
10.2. Region-Specific Terms. To the extent that Provider Processes Customer Personal Data protected by Data Protection Laws in one of the regions listed in Exhibit B (Region-Specific Terms), then the terms specified therein with respect to the applicable jurisdiction(s) will apply in addition to the terms of this DPA.
Exhibit A: Cross-Border Transfer Mechanisms
1. EU Transfers. Where Customer Personal Data is protected by EU GDPR and is subject to a Restricted Transfer, the following applies:
1.1. The EU SCCs are hereby incorporated by reference as follows:
(a) Module 2 (Controller to Processor) applies where Customer is a Controller of Customer Personal Data and Provider is a Processor of Customer Personal Data;
(b) Module 3 (Processor to Processor) applies where Customer is a Processor of Customer Personal Data (on behalf of a third-party Controller) and Provider is a Processor of Customer Personal Data;
(c) Customer is the “data exporter” and Provider is the “data importer”; and
(d) by entering into this DPA, each party is deemed to have signed the EU SCCs (including their Annexes) as of the DPA Effective Date.
1.2. For each Module, where applicable the following applies:
(a) the optional docking clause in Clause 7 does not apply;
(b) in Clause 9, Option 2 will apply, the minimum time period for prior notice of Subprocessor changes shall be as set out in Section 4.3 of this DPA, and Provider shall fulfill its notification obligations by notifying Customer of any Subprocessor changes in accordance with Section 4.3 of this DPA;
(c) in Clause 11, the optional language does not apply;
(d) in Clause 13, all square brackets are removed with the text remaining;
(e) in Clause 17, Option 1 will apply, and the EU SCCs will be governed by Designated EU Governing Law;
(f) in Clause 18(b), disputes will be resolved before the courts of the Designated EU Member State;
(g) the Processing Details contain the information required in Annex I of the EU SCCs; and
(h) the Processing Details contain the information required in Annex II of the EU SCCs.
1.3. Where context permits and requires, any reference in this DPA to the EU SCCs shall be read as a reference to the EU SCCs as modified in the manner set forth in this Section 1.
2. Swiss Transfers. Where Customer Personal Data is protected by the FADP and is subject to a Restricted Transfer, the following applies:
2.1. The EU SCCs apply as set forth in Section 1 (EU Transfers) of this Exhibit A with the following modifications:
(a) in Clause 13, the competent supervisory authority shall be the Swiss Federal Data Protection and Information Commissioner;
(b) in Clause 17 (Option 1), the EU SCCs will be governed by the laws of Switzerland;
(c) in Clause 18(b), disputes will be resolved before the courts of Switzerland;
(d) the term Member State must not be interpreted in such a way as to exclude Data Subjects in Switzerland from enforcing their rights in their place of habitual residence in accordance with Clause 18(c); and
(e) all references to the EU GDPR in this DPA are also deemed to refer to the FADP.
3. UK Transfers. Where Customer Personal Data is protected by the UK GDPR and is subject to a Restricted Transfer, the following applies:
3.1. The EU SCCs apply as set forth in Section 1 (EU Transfers) of this Exhibit A with the following modifications:
(a) each party shall be deemed to have signed the “International Data Transfer Addendum to the EU Commission Standard Contractual Clauses” (“UK Addendum”) issued by the Information Commissioner’s Office under section 119A of the Data Protection Act 2018;
(b) the EU SCCs shall be deemed amended as specified by the UK Addendum in respect of the transfer of Customer Personal Data;
(c) in Table 1 of the UK Addendum, the parties’ key contact information is located in the Processing Details;
(d) in Table 2 of the UK Addendum, information about the version of the EU SCCs, modules and selected clauses which this UK Addendum is appended to are located above in this Exhibit A;
(e) in Table 3 of the UK Addendum:
(i) the list of parties is located in the Processing Details;
(ii) the description of transfer is located in the Processing Details;
(iii) Annex II is located in the Processing Details; and
(iv) the list of Subprocessors is located in the Processing Details.
(f) in Table 4 of the UK Addendum, both the Importer and the Exporter may end the UK Addendum in accordance with its terms (and the respective box for each is deemed checked); and
(g) Part 2: Mandatory Clauses of the Approved Addendum, being the template Addendum B.1.0 issued by the ICO and laid before Parliament in accordance with section 119A of the Data Protection Act 2018 on 2 February 2022, as it is revised under Section 18 of those Mandatory Clauses.
4. Data Privacy Framework. For clarity, a transfer of Customer Personal Data from the EEA, UK or Switzerland to Provider in the United States subject to the EU-U.S. Data Privacy Framework, the UK Extension to the EU-U.S. Data Privacy Framework, and/or the Swiss-U.S. Data Privacy Framework, as applicable (collectively, the “DPF”), shall not constitute a Restricted Transfer so long as Provider maintains an active certification to the DPF and certification to the DPF remains a legal basis for transfer of Personal Data to the United States under the GDPR, UK GDPR or FADP, as applicable.
Exhibit B: Region-Specific Terms
A. CALIFORNIA
1. Definitions. CCPA and other capitalized terms not defined in this Exhibit are defined in the DPA.
1.1. “business purpose”, “commercial purpose”, “personal information”, “sell”, “service provider” and “share” have the meanings given in the CCPA.
1.2. The definition of “Data Subject” includes “consumer” as defined under the CCPA.
1.3. The definition of “Controller” includes “business” as defined under the CCPA.
1.4. The definition of “Processor” includes “service provider” as defined under the CCPA.
2. Obligations.
2.1. Customer is providing the Customer Personal Data to Provider under the Main Agreement for the limited and specific business purposes of providing the Service as described in the Processing Details and otherwise performing under the Main Agreement.
2.2. Provider will comply with its applicable obligations under the CCPA and provide the same level of privacy protection to Customer Personal Data as is required by the CCPA.
2.3. Provider acknowledges that Customer has the right to: (i) take reasonable and appropriate steps under Section 9 (Audits) of this DPA to help to ensure that Provider’s use of Customer Personal Data is consistent with Customer’s obligations under the CCPA, (ii) receive from Provider notice and assistance under Section 7 (Data Subject Requests) of this DPA regarding consumers’ requests to exercise rights under the CCPA and (iii) upon notice, take reasonable and appropriate steps to stop and remediate unauthorized use of Customer Personal Data.
2.4. Provider will notify Customer promptly after it makes a determination that it can no longer meet its obligations under the CCPA.
2.5. Provider will not retain, use or disclose Customer Personal Data: (i) for any purpose, including a commercial purpose, other than the business purposes described in Section A.2.1 of this Exhibit or (ii) outside of the direct business relationship between Provider and Customer, except, in either case, where and to the extent permitted by the CCPA.
2.6. Provider will not sell or share Customer Personal Data received under the Main Agreement.
2.7. Provider will not combine Customer Personal Data with other personal information except to the extent a service provider is permitted to do so by the CCPA.
B. VIRGINIA
1. Definitions. The Virginia Consumer Data Protection Act, Va. Code Ann. §§ 59.1-575 et seq. (“VCDPA”), and other capitalized terms not defined in this Exhibit are defined in the DPA.
2. Obligations. Where Provider Processes Customer Personal Data protected by the VCDPA, Provider will: (a) ensure that each person Processing Customer Personal Data is subject to a duty of confidentiality with respect to the data; (b) at Customer's direction, delete or return Customer Personal Data as provided in Section 8 of this DPA; (c) upon Customer's reasonable request, make available to Customer the information in Provider's possession necessary to demonstrate Provider's compliance with its obligations under the VCDPA; (d) allow, and cooperate with, reasonable assessments by Customer or provide an independent assessment as described in Section 9 of this DPA; and (e) engage Subprocessors only as permitted by Section 4 of this DPA, which requires each Subprocessor to meet Provider's obligations with respect to Customer Personal Data by written contract.
C. COLORADO
1. Definitions. The Colorado Privacy Act, Colo. Rev. Stat. §§ 6-1-1301 et seq. (“CPA”), and other capitalized terms not defined in this Exhibit are defined in the DPA.
2. Obligations. Where Provider Processes Customer Personal Data protected by the CPA, Provider will: (a) ensure that each person Processing Customer Personal Data is subject to a duty of confidentiality with respect to the data; (b) engage a Subprocessor only after Customer has had an opportunity to object, in accordance with Section 4 of this DPA, and pursuant to a written contract requiring the Subprocessor to meet Provider's obligations with respect to Customer Personal Data; (c) at Customer's direction, delete or return Customer Personal Data as provided in Section 8 of this DPA; (d) make available to Customer the information necessary to demonstrate compliance with the CPA; and (e) allow for, and contribute to, reasonable audits and inspections by Customer or provide an independent audit, as described in Section 9 of this DPA.
D. CONNECTICUT
1. Definitions. The Connecticut Data Privacy Act, Conn. Gen. Stat. §§ 42-515 et seq. (“CTDPA”), and other capitalized terms not defined in this Exhibit are defined in the DPA.
2. Obligations. Where Provider Processes Customer Personal Data protected by the CTDPA, Provider will: (a) ensure that each person Processing Customer Personal Data is subject to a duty of confidentiality with respect to the data; (b) at Customer's direction, delete or return Customer Personal Data as provided in Section 8 of this DPA; (c) upon Customer's reasonable request, make available to Customer the information in Provider's possession necessary to demonstrate Provider's compliance with its obligations under the CTDPA; (d) after Customer has had an opportunity to object, engage a Subprocessor only pursuant to a written contract requiring the Subprocessor to meet Provider's obligations with respect to Customer Personal Data, in accordance with Section 4 of this DPA; and (e) allow, and cooperate with, reasonable assessments by Customer or provide an independent assessment as described in Section 9 of this DPA.
E. TEXAS
1. Definitions. The Texas Data Privacy and Security Act, Tex. Bus. & Com. Code §§ 541.001 et seq. (“TDPSA”), and other capitalized terms not defined in this Exhibit are defined in the DPA.
2. Obligations. Where Provider Processes Customer Personal Data protected by the TDPSA, Provider will: (a) ensure that each person Processing Customer Personal Data is subject to a duty of confidentiality with respect to the data; (b) at Customer's direction, delete or return Customer Personal Data as provided in Section 8 of this DPA, unless retention is required by law; (c) upon Customer's reasonable request, make available to Customer the information in Provider's possession necessary to demonstrate Provider's compliance with the TDPSA; (d) allow, and cooperate with, reasonable assessments by Customer or provide an independent assessment as described in Section 9 of this DPA; and (e) engage Subprocessors only as permitted by Section 4 of this DPA, which requires each Subprocessor to meet Provider's obligations with respect to Customer Personal Data by written contract. The Processing Details and this DPA set out the instructions for Processing, the nature and purpose of Processing, the type of Customer Personal Data subject to Processing, the duration of Processing, and the rights and obligations of both parties, as required by Tex. Bus. & Com. Code § 541.104(b).
DPA Details
The following information has been completed by Provider for every Customer whose Theo website takes bookings or receives messages through a contact form.
Key Terms
| Term | Entry |
|---|---|
| Main Agreement | Theo’s Legal Terms (Terms of Service), published at https://theo.site/terms-of-service, in the version last updated October 21, 2026 and as updated from time to time, which incorporate this DPA in Section 23 (User Data). |
| DPA Effective Date | The date Customer first turns on online booking or publishes a contact form on a website under its Theo account or, for a website already taking bookings or receiving messages on the day this DPA is first published at https://theo.site/data-processing-addendum, that day. |
| Subprocessor List | The “Subprocessors” table in these DPA Details, published at https://theo.site/data-processing-addendum#subprocessors and updated as Section 4.3 provides. |
| Designated EU Governing Law | The laws of Ireland. |
| Designated EU Member State | Ireland. |
Processing Details
Subject Matter and Details of Processing
| Customer / “Data Exporter” Details | |
|---|---|
| Name: | The person or business that holds the Theo account that owns the website on which bookings are taken or messages are received, being the party that accepted the Legal Terms for that account (“you” in the Legal Terms). For an End-User Account this is the business that takes the bookings. For an Agency Account this is the Agency Account holder, as Section 6B of the Legal Terms provides. |
| Contact details for data protection: | The email address on the Theo account. |
| Main address: | The business address given in the Theo account or shown on the website. |
| Customer activities: | Offering its services to its clients and prospective clients, taking bookings from them and receiving their messages through its Theo website. |
| Role: | Controller, or Processor where Customer is an Agency Account holder acting for the business whose website it manages (see Additional Term 4). |
| Provider / “Data Importer” Details | |
|---|---|
| Name: | Finale Labs, Inc. (doing business as Theo) |
| Contact details for data protection: | privacy@theo.site |
| Main address: | 131 Continental Dr, Suite 305, Newark, DE 19713, United States |
| Provider activities: | Builds and hosts websites for small businesses, including an online booking feature that takes, confirms, reminds, moves, cancels and records appointments on the business’s behalf, and contact forms that store visitors’ messages and deliver them to the business. |
| Role: | Processor |
Details of Processing
| Categories of Data Subjects: | |
|---|---|
| ☒ | Customer’s customers: clients who book, request or hold an appointment, and the person named for the visit. |
| ☒ | Customer’s prospective customers: people who start a booking or request a time, and visitors who send a message through a contact form on Customer’s website. |
| ☐ | Customer’s business contacts |
| ☐ | Users |
| ☒ | Employees, other personnel and job candidates: the staff or instructors Customer lists as hosts on its booking page (name and email address). |
| ☐ | Other |
| Categories of Customer Personal Data: | |
|---|---|
| ☒ | Contact information: name, email address, phone number if Customer asks for it, and the address for a visit at the client’s location; for a contact form, whatever contact details Customer’s form asks for, usually name, email address and phone number. |
| ☐ | Account information |
| ☐ | Demographic information |
| ☐ | Professional information |
| ☒ | Transaction information: the service booked, the appointment time and time zone, the price, the amount and status of any deposit or payment or refund, Stripe’s payment reference, and the name and email address the client gives on Stripe’s payment page. Provider never receives or stores card numbers. |
| ☒ | Communications information: the booking, reminder, change, cancellation and follow-up emails and whether they were delivered; any message sent with a cancellation. |
| ☒ | User generated content: the client’s answers to any questions Customer adds to its booking form, and the message and any other fields a visitor fills in on Customer’s contact form. |
| ☒ | Unique identifiers: the booking reference, the signed link the client uses to move or cancel, calendar event identifiers, the technical identifiers of the hosting, payment and email providers, and the client’s IP address, which the booking page keeps for up to two hours to limit abuse and which appears in ordinary server logs. With each contact-form message, the sender’s IP address and browser details are stored, with the website address it was sent from and the address it was emailed to; the sender’s IP address is likewise kept for up to two hours to limit abuse and appears in ordinary server logs. |
| ☒ | Other: attendance (whether the client confirmed or missed the appointment) and video meeting links. |
| Sensitive or Special Categories of Personal Data: | |
|---|---|
| ☐ | Yes, sensitive or special categories of Personal Data |
| ☒ | None/Not Applicable. Provider does not ask for sensitive or special categories of Personal Data and the Service is not designed for them. Customer controls the questions on its booking form and the fields on its contact form. If Customer chooses to ask a question whose answer could reveal sensitive information, or a visitor volunteers it in a message, Customer is responsible for that information, as the Privacy Notice explains. Provider only stores it and shows it to Customer; a contact-form message is also emailed to Customer and passed through the spam screen described in the Subprocessor List. A booking answer is removed 90 days after the appointment; a message stays until Customer deletes the website. |
| Frequency of transfer: | |
|---|---|
| ☒ | Continuous |
| ☐ | Other |
| Item | Entry |
|---|---|
| Nature of the Processing: | Processing operations required to provide the Service in accordance with the Main Agreement: collecting booking details through the booking page on Customer’s website; storing them; showing them to Customer and the team members Customer invites, in the Theo editor and in exports; sending booking emails to the client and to Customer; writing appointments to Customer’s Google Calendar if Customer connects it; carrying out Customer’s cancellation and refund rules on Customer’s connected Stripe account; answering Customer when it manages its bookings by chatting with Theo; and, for contact forms, receiving each visitor’s message, screening it for spam, storing it, showing it to Customer and the team members Customer invites in the Forms tab, and emailing it to the address or addresses Customer sets for the form (Theo proposes the business’s public contact email when it builds the form; if none is set, the email address on the Theo account). |
| Purpose of the Processing: | To provide the Service and carry out Customer Instructions. |
| Duration of Processing / retention period: | Concurrent with the term of the Main Agreement and thereafter pursuant to Section 8 (Data Return or Deletion) of the DPA, as modified by Additional Term 3. Provider keeps each booking so that Customer can see its history and its books balance. A client’s phone number and form answers are removed from the booking 90 days after the appointment. The website owner can delete a client’s name, email address, phone number, address and answers from that client’s bookings and payment records at any time in the Bookings tab, by the client’s email address, and Customer can export its bookings at any time; amounts and payment references stay so that refunds and disputes can be handled. Test bookings made from the editor preview are kept for one hour and then deleted by an hourly sweep. If Customer’s plan ends, its booking page stops taking new bookings; bookings already made continue to run (clients keep their reminders and can still move or cancel, and refunds follow Customer’s settings) and the 90-day rule above still applies to them. After Customer’s website is deleted, upcoming appointments run until they take place. Once a booking has taken place, a daily sweep removes the client’s name, email address, phone number, address and form answers from it, and the name, email address and phone number on its payment record are removed 90 days after the payment. The service, the appointment time, attendance, any message sent with a cancellation, the booking and calendar identifiers, the amounts and Stripe’s payment reference remain for accounting, tax, fraud-prevention and dispute-resolution purposes, for as long as necessary for those purposes. Booking details that Customer asks about in its chat with Theo stay in that chat history for the life of the website; the chat is deleted with the website, apart from a text archive kept for 30 days. Contact-form messages are kept, with the sender’s IP address and browser details, until Customer deletes the website, which deletes them at once; a form can be paused but not deleted, and pausing stops new messages and keeps the ones already received. A message the spam screen holds back is deleted after 30 days. Customer reads its messages in the Forms tab; each message that passes the spam screen is also emailed to the address or addresses Customer set for the form. Customer can ask Provider to delete a sender’s messages as set out in Additional Term 2. |
| Transfers to Subprocessors: | As described in the Subprocessor List for the purposes described therein. |
| Competent EU Supervisory Authority: | If the EU SCCs apply, the competent supervisory authority is determined in accordance with Clause 13 of the EU SCCs. |
Subprocessors
Provider’s Subprocessors for Customer Personal Data, their functions and locations. Provider gives notice of changes as set out in Section 4.3 of the DPA. Stripe and Google are services that Customer connects; see Additional Term 7.
| Subprocessor | Function | Location |
|---|---|---|
| Render, Inc. | Hosts Provider’s application servers and Customer’s published website. Booking requests, contact-form submissions and the Theo editor run on it. | United States (Ohio) |
| PlanetScale, Inc. | The managed PostgreSQL database where booking details and contact-form messages are stored. Data and backups are encrypted at rest and in transit. | United States |
| Cloudflare, Inc. | Content delivery and security network in front of Provider’s own sites and API (booking requests and contact-form messages pass through it on their way to Provider’s servers), and the image store and delivery network for Customer’s website, including the photos and logo Customer adds to its booking page. For a free website left idle, holds an encrypted archive of the assistant’s workspace, which can include booking details Customer asked about. | Edge network: global (a request may pass through the Cloudflare data center nearest the visitor). Storage: North America, under Cloudflare’s automatic placement. |
| Stripe, Inc. | Connected by Customer. Payments on Customer’s connected Stripe account, under Stripe’s own terms with Customer. To create a payment, Provider sends Stripe the service, the appointment time, the amount, the booking reference and the client’s email address, and it stores Stripe’s payment reference together with the name and email address the client gives on Stripe’s payment page; refunds are sent against that reference. | United States |
| Google LLC | Connected by Customer. If Customer connects Google Calendar, Provider writes each appointment (service, client’s first name, time, any visit address, and a link to the booking in the Theo editor; never the form answers) to Customer’s calendar and creates Google Meet links for video appointments. Google acts under its own terms with Customer. | United States |
| Resend, Inc. | Sends the booking emails to the client and to Customer, delivers each contact-form message that passes the spam screen to the address or addresses Customer set for the form (with the sender’s email address as the reply-to), and reports whether they were delivered. Data is stored in the United States, encrypted at rest and in transit. | United States |
| OpenAI, L.L.C. | When Customer manages its bookings by chatting with Theo, the relevant details are sent to OpenAI’s API to produce Theo’s answer. When a contact form’s spam screen is on (it is on unless Customer turns it off), each message (its fields, with a short description of Customer’s business) is sent to OpenAI’s API to be judged as spam or not; if OpenAI does not answer, the message is delivered unscreened. Both are under OpenAI’s API terms, which do not permit API data to be used to train OpenAI’s models. | United States |
| Daytona Platforms, Inc. | Runs the isolated workspace in which Theo’s assistant works on Customer’s website. Booking details that Customer asks about are returned to the assistant there and remain in the assistant’s conversation log on that workspace. Contact-form messages are never sent to the workspace; the assistant can create, change, pause and list forms but cannot read messages. | United States |
| Functional Software, Inc. (Sentry) | Error monitoring for Provider’s software. Reports omit user identifiers, the values the failing code was handling, and the content of a client’s booking request or a visitor’s contact-form message; a report may include a booking’s or a message’s technical identifiers. | United States |
Security Measures
| Technical and Organizational Measures | |
|---|---|
| Encryption in transit | All traffic between clients’ browsers, Customer’s website, the Theo editor, Provider’s servers and the Subprocessors uses HTTPS (TLS). |
| Encryption at rest | Booking details and contact-form messages are stored in a managed PostgreSQL database that encrypts data and backups at rest. The database provider reports on SOC 1 and SOC 2 Type 2 controls. |
| Backups | The database provider keeps encrypted automated backups of the database. |
| Access control | Provider’s production systems and database are reachable only by named Provider personnel with individual credentials. Secrets are held in the hosting provider’s environment store, not in source code. Staff access to Customer Personal Data is limited to operating and supporting the Service. |
| Separation between customers | Every booking record and contact-form message is tied to one website. On every request to the Bookings tab, its exports and its deletion tools, and to the Forms tab, the application checks that the signed-in user is a member of that website’s team (the owner or a person the owner invited). The client deletion tool, the payment and calendar connections, decline-all, and the choice of who receives a form’s messages are limited to the owner. |
| Client links | A client’s move-or-cancel link carries a signed token. The database stores only a hash of that token, so a read of the database cannot be used to forge a client’s link. |
| Card data | Provider never receives or stores card numbers. Payments are taken by Stripe on Customer’s connected account. |
| Minimization and retention | Phone numbers and form answers are removed from the booking 90 days after the appointment. Test bookings are deleted by an hourly sweep after one hour. Past bookings of deleted websites are pseudonymized by a daily sweep. Contact-form messages held back as spam are deleted after 30 days, and every message is deleted with its website. |
| Monitoring and incident response | Error and uptime monitoring, with user identifiers, the values the failing code was handling, and the content of booking requests and contact-form messages excluded from error reports. Provider investigates Security Incidents and notifies Customer as set out in Section 5.2 of the DPA. |
| Personnel | Provider’s personnel and contractors who may access Customer Personal Data are bound by confidentiality obligations. |
| Software changes | Changes are run through an automated test suite and reviewed before they are pushed. A push to the main branch deploys automatically once the database migrations have run. |
| Subprocessors | Each Subprocessor is bound by its own data processing terms with Provider, and is listed with its function and location above. |
Additional Terms
The following additions to or modifications of this DPA (including any Exhibits) are agreed by the parties and control in the event of any conflicts:
Electronic acceptance. This DPA is accepted electronically, as Section 24 of the Legal Terms provides, and no separate signature is required. Customer enters into this DPA by accepting the Legal Terms, which incorporate it, and either turning on online booking or publishing a contact form on a website, or continuing to take bookings or receive messages on a website after this DPA is published. The Legal Terms together with this DPA are the written agreement between the parties for the purposes of Data Protection Laws, and each party is deemed to have signed the EU SCCs as Exhibit A provides.
Section 8.1 (During the Term of the Main Agreement). The website owner may delete a client’s details in the Bookings tab of the Theo editor, and any team member Customer invites may export the bookings as a CSV spreadsheet file, at any time during the term of the Main Agreement. Customer reads its contact-form messages in the Forms tab, and each message that passes the spam screen is also emailed to the address Customer set for the form; Customer may ask Provider to delete a sender’s messages by email to privacy@theo.site, and Provider will do so within 30 days of the request.
Section 8.2 (Post Termination). For a website, the Main Agreement ends for the purposes of Section 8.2 when Customer deletes the website or Customer’s Theo account is closed, whichever is first (closing the account does not itself delete a website: a website Customer alone owns must be deleted first, and a website with another owner continues under that owner). Notwithstanding Section 8.2: (a) for each appointment booked before that date that has not yet taken place, Provider will continue to Process the related Customer Personal Data as Section 6B of the Legal Terms describes (reminders, moving or canceling, and refunds under Customer’s settings) until the appointment takes place or is canceled, and Customer instructs Provider to do so; (b) once each booking has taken place, Provider will remove the client’s details and may keep the remaining record as described under “Duration of Processing / retention period” in the Processing Details, for as long as necessary for the purposes stated there; (c) contact-form messages are deleted when the website is deleted; and (d) a certificate of deletion under Section 8.2(b) will describe the removal in (b) and (c).
Agency Accounts. Where the Theo account that owns the website is an Agency Account (as described in the Legal Terms), the Agency Account holder is Customer under this DPA and acts as a Processor on behalf of the business whose website it manages, which is the Controller. Customer confirms that it has that business’s authority to enter into this DPA and to give Customer Instructions. Section 2.1 applies with Customer as a Processor, and Module 3 of the EU SCCs applies under Exhibit A.
Sections 1.31 and 4.3 (Subprocessor notice). Replace the definition of “Subprocessor Notice Method” with: “Subprocessor Notice Method” means email to the address on Customer’s Theo account. Add to the end of Section 4.3: If Provider must replace a Subprocessor at short notice to keep the Service running or secure, Provider may give less than 30 days’ notice and will notify Customer as soon as reasonably possible; Customer keeps its rights under Section 4.4.
Customer Data and confidentiality. For Section 1.7, “Customer Data” means the booking details, contact-form messages and other information that Provider collects, stores or sends on Customer’s behalf through the online booking feature and the contact forms on Customer’s website, as described in the Processing Details. For Section 3.2(a), Provider will keep Customer Personal Data confidential, will disclose it only to its Subprocessors, to Customer and the people Customer invites to its website, or as this DPA or the Legal Terms allow, and will use it only to provide the Service and carry out Customer Instructions.
Connected services. Stripe (for Customer’s connected Stripe account) and Google (for Customer’s Google Calendar and Google Meet) are services that Customer connects and that act under their own terms with Customer. Provider sends them the Customer Personal Data described in the Subprocessor List on Customer’s instruction. They are listed there so that Customer can see the transfer, but Section 4.1(b) does not apply to them.
Sections 1 to 10, Exhibit A and section A of Exhibit B are reproduced from the Bonterms Data Protection Addendum Version 2.0 (Attachment Version), © 2026 Bonterms, Inc., used under the Creative Commons Attribution 4.0 International license (https://creativecommons.org/licenses/by/4.0/), and the paragraph before Section 1 is adapted from it. Bonterms is not a party to this DPA and does not endorse it. The opening paragraph, sections B to E of Exhibit B and the DPA Details, including the Additional Terms, were prepared by Finale Labs, Inc.