Data Processing Addendum

This Data Processing Addendum (this "DPA") is entered into between DailyBuilt, Inc., a Delaware corporation ("DailyBuilt", "we", "us"), and the customer that accepts the DailyBuilt Terms of Service ("Customer", "you"), and is incorporated into and forms part of the Agreement.

This DPA is self-executing. It takes effect, without signature, on the earlier of (a) the date Customer accepts the Terms of Service, and (b) the date Customer first submits Customer Data to the Service. No countersignature is required for this DPA to bind both parties. Customer may request a copy identifying the version in force at hello@dailybuilt.co.

---

1. Definitions

1.1 Capitalized terms not defined here have the meanings given in the Terms of Service. In this DPA:

"Agreement" means the DailyBuilt Terms of Service, all documents incorporated into it (including this DPA, the Acceptable Use Policy, the SMS Terms, and the Billing Terms), and any Order Form.

"BAA" means the DailyBuilt Platform Business Associate Agreement that self-executes when the Healthcare Edition is enabled for a Customer workspace, or a separately executed business associate agreement between the parties.

"Customer Data" means data that Customer submits to the Service, or causes or permits to be submitted to the Service, including data submitted by End Users through DailyBuilt-hosted surfaces. Customer Data includes Personal Information.

"Customer Personnel Data" means personal information about Customer's own owners, employees, contractors, and authorized users that DailyBuilt processes to create and administer Customer's account, authenticate users, bill Customer, provide support, and secure the Service.

"End User" means an individual who interacts with a DailyBuilt-hosted surface operated for Customer (including a booking page, signing page, payment page, hosted invoice, inquiry form, email sent on Customer's behalf, and SMS sent on Customer's behalf) and who has no DailyBuilt account.

"Personal Information" means information within Customer Data that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular individual or household, and that is regulated as "personal information," "personal data," or an equivalent term under an applicable State Privacy Law.

"PHI" means Protected Health Information as defined at 45 C.F.R. § 160.103.

"Security Incident" means a confirmed unauthorized acquisition of, or unauthorized access to, Personal Information in DailyBuilt's possession or under DailyBuilt's control that compromises the security, confidentiality, or integrity of that Personal Information. A Security Incident does not include an unsuccessful attempt or an activity of the kind that routinely occurs on internet-facing infrastructure without compromising Personal Information, such as pings, port scans, failed log-in attempts, denial-of-service attempts, or packet sniffing of network headers.

"State Privacy Laws" means the California Consumer Privacy Act of 2018 as amended by the California Privacy Rights Act and its implementing regulations ("CCPA"); the Colorado Privacy Act; the Virginia Consumer Data Protection Act; the Connecticut Data Privacy Act; the Texas Data Privacy and Security Act; and any other United States state privacy or consumer-data-protection law that applies to Customer's processing of Personal Information through the Service.

"Subprocessor" means a third party engaged by DailyBuilt that processes Personal Information on DailyBuilt's behalf in connection with the Service.

1.2 The terms "business," "business purpose," "collect," "commercial purpose," "consumer," "contractor," "controller," "personal information," "processing," "processor," "sell," "service provider," "share," and "third party" have the meanings given in the applicable State Privacy Law.

---

2. Roles and scope

2.1 Customer is the business / controller. As to Customer Data, Customer is the "business" under the CCPA and the "controller" under the other State Privacy Laws. Customer determines the purposes and means of processing, decides what data to submit to the Service, decides which features to enable, and is responsible for the lawfulness of the processing it directs.

2.2 DailyBuilt is the service provider / processor. As to Customer Data, DailyBuilt is a "service provider" under the CCPA and a "processor" under the other State Privacy Laws. DailyBuilt processes Customer Data only on Customer's documented instructions and for the limited and specified business purposes set out in Annex 1.

2.3 Where DailyBuilt acts as a business / controller. DailyBuilt is a "business" and a "controller" with respect to Customer Personnel Data, Site visitors, prospective customers, DailyBuilt's own billing and tax records, DailyBuilt's security and audit logs, and aggregate service-usage statistics. That processing is governed by the DailyBuilt Privacy Policy at dailybuilt.co/privacy and not by this DPA, except that DailyBuilt's security obligations in Section 8 and its Security Incident obligations in Section 9 apply to Customer Personnel Data as well.

2.4 End Users. DailyBuilt processes End User data as Customer's service provider / processor. DailyBuilt does not establish a direct relationship with End Users for its own purposes, does not market to End Users on DailyBuilt's own behalf, and does not build profiles of End Users across Customers. The End User Terms at dailybuilt.co/end-user-terms and the Consumer Privacy Notice at dailybuilt.co/consumer-privacy-notice describe the DailyBuilt-hosted surfaces to the individuals who use them; they do not change the role allocation in this Section 2.

2.5 Details of processing. Annex 1 sets out the subject matter, nature and purpose, duration, categories of Personal Information, and categories of data subjects, as required by Colo. Rev. Stat. § 6-1-1305(5), Va. Code § 59.1-579(B), Conn. Gen. Stat. § 42-521(b), and Tex. Bus. & Com. Code § 541.104(b).

---

3. Customer instructions and Customer obligations

3.1 Instructions. Customer instructs DailyBuilt to process Customer Data (a) as described in Annex 1, (b) as reasonably necessary to provide, secure, support, maintain, and bill for the Service, (c) as further documented in Customer's use of the Service's features and configuration settings, and (d) as otherwise agreed in writing. DailyBuilt will not process Customer Data for any other purpose unless required by applicable law, in which case Section 10.6 applies.

3.2 Unlawful instructions. DailyBuilt will notify Customer if, in DailyBuilt's reasonable judgment, an instruction from Customer violates an applicable State Privacy Law. DailyBuilt may suspend performance of the affected instruction until the parties resolve the issue. DailyBuilt has no obligation to audit Customer's instructions for legal compliance and is not liable for processing performed in accordance with Customer's instructions.

3.3 Customer's compliance duties. Customer represents and warrants that, for all Customer Data:

(a) it has provided all notices and obtained all consents, permissions, and rights required by applicable law for DailyBuilt and its Subprocessors to process Customer Data as contemplated by the Agreement;

(b) it has a lawful basis and the necessary rights to submit each contact record it uploads or imports, including records imported by file upload or from a device address book;

(c) where it enables email or SMS campaigns, it has captured and retained records of the consents those channels require, including, for marketing SMS, prior express written consent that satisfies 47 C.F.R. § 64.1200(f)(9) for each recipient, and it has honored opt-out requests received outside the Service. Marketing SMS is not enabled on DailyBuilt's currently registered messaging program; where DailyBuilt makes marketing SMS available, Customer may use it only where Customer has captured and retained compliant consent records;

(d) where it enables the session-recording or heatmap features described in Annex 1, it has provided the notices and obtained the consents required by applicable law, including state wiretap and session-recording statutes;

(e) where it submits health, biometric, precise geolocation, or other sensitive Personal Information, it has satisfied the additional notice, consent, and — where applicable — consumer-health-data requirements that attach to that category, including those described at dailybuilt.co/consumer-health-data; and

(f) it will not submit to the Service any category of data the Service is not designed to receive, including payment card numbers, government-issued identification images that Customer has no lawful basis to hold, and data subject to the Gramm-Leach-Bliley Act, the Fair Credit Reporting Act, or export-control regimes.

3.4 Customer configuration. Customer is responsible for the settings it selects, the retention it chooses within the limits the Service allows, the individuals to whom it grants access, the intake questions and templates it publishes, and the content of the documents, emails, and messages it sends through the Service.

---

4. General processing obligations of DailyBuilt

4.1 Confidentiality. DailyBuilt limits access to Customer Data to personnel who need it to perform DailyBuilt's obligations under the Agreement. Each person with access is bound by a written confidentiality obligation or a statutory duty of confidentiality that survives termination of their engagement.

4.2 No sale, no share. DailyBuilt does not sell Customer Data and does not share Customer Data for cross-context behavioral advertising. DailyBuilt receives no consideration, monetary or otherwise, for Customer Data.

4.3 No independent use. DailyBuilt does not use Customer Data for its own commercial purposes, does not build or modify consumer or household profiles from Customer Data, and does not clean or augment Customer Data with data acquired from another source.

4.4 Service improvement. Customer instructs DailyBuilt, and this Addendum constitutes Customer's documented processing instruction for the purposes of C.R.S. § 6-1-1305(1) and (5)(a), Conn. Gen. Stat. § 42-521(b), Va. Code § 59.1-579(B), Tex. Bus. & Com. Code § 541.104(b) and RCW 19.373.060(1)(a)(ii), that DailyBuilt may use Customer Data for its own internal use to build or improve the quality of the Service it provides to Customer, as permitted by 11 CCR § 7050(a)(3) and as a business purpose under Cal. Civ. Code § 1798.140(e)(3) and (e)(8). That use does not include building or modifying consumer or household profiles, cleaning or augmenting data acquired from another source, performing services on behalf of any other person, or any advertising or marketing purpose. DailyBuilt does not use PHI, Sensitive Personal Information, sensitive data, or consumer health data for this purpose. DailyBuilt does not disclose Customer Data to any third-party model provider for the purpose of training that provider's models. Customer may withdraw this instruction on written notice, in which case DailyBuilt will limit its use of Customer Data to the other purposes in this Section 4.

4.5 Aggregated and de-identified data. DailyBuilt may create and use aggregated or de-identified data derived from Customer Data for the operation, security, benchmarking, and improvement of the Service, provided DailyBuilt (a) takes reasonable measures to ensure the data cannot be associated with a consumer or household, (b) publicly commits to maintain and use the data in de-identified form and not to attempt to re-identify it, except that DailyBuilt may attempt re-identification solely to test whether its de-identification measures are effective, and (c) contractually obligates any recipient to the same restrictions. De-identified data derived from PHI is de-identified in accordance with 45 C.F.R. § 164.514(b) before any such use.

4.6 Combination. DailyBuilt does not combine Customer Data with personal information it receives from or on behalf of another person, or collects from its own interaction with a consumer, except to perform a business purpose permitted by the CCPA and its regulations.

4.7 Retention. DailyBuilt retains Customer Data for the period stated in Annex 1 and Section 12 and not longer, except where a longer period is required by law or by a legal hold.

---

5. CCPA service-provider terms

This Section 5 applies to Personal Information subject to the CCPA. It is the written contract required by Cal. Civ. Code §§ 1798.100(d) and 1798.140(ag)(1) and the CCPA regulations.

5.1 Limited and specified purposes. Customer discloses Personal Information to DailyBuilt only for the limited and specified business purposes described in Annex 1. DailyBuilt processes that Personal Information only on Customer's behalf and only for those business purposes.

5.2 Statutory prohibitions. DailyBuilt is prohibited from, and will not:

(a) sell or share the Personal Information;

(b) retain, use, or disclose the Personal Information for any purpose other than for the business purposes specified in this DPA for Customer, including retaining, using, or disclosing the Personal Information for a commercial purpose other than the business purposes specified in this DPA, or as otherwise permitted by the CCPA;

(c) retain, use, or disclose the Personal Information outside the direct business relationship between DailyBuilt and Customer; or

(d) combine the Personal Information that DailyBuilt receives pursuant to this DPA with personal information that DailyBuilt receives from or on behalf of another person, or collects from its own interaction with the consumer, except that DailyBuilt may combine Personal Information to perform a business purpose as permitted by the CCPA regulations.

5.3 Certification. DailyBuilt certifies that it understands the restrictions and obligations set out in this Section 5 and will comply with them.

5.4 Compliance and equivalent protection. DailyBuilt will comply with the obligations applicable to it as a service provider under the CCPA and will provide the same level of privacy protection to Personal Information as the CCPA requires of businesses.

5.5 Customer's monitoring right. Customer may take reasonable and appropriate steps to help ensure that DailyBuilt uses Personal Information in a manner consistent with Customer's obligations under the CCPA. The documentation, summary reports, and other materials described in Section 11 satisfy this right; Customer may exercise the right no more than once in any twelve-month period absent a Security Incident affecting Customer or a documented, good-faith belief that DailyBuilt is processing Personal Information in violation of this DPA.

5.6 Notice of inability to comply. DailyBuilt will notify Customer in writing without unreasonable delay if DailyBuilt determines that it can no longer meet its obligations under the CCPA with respect to Personal Information.

5.7 Stop and remediate. On written notice from Customer identifying an unauthorized use of Personal Information, Customer may take reasonable and appropriate steps to stop and remediate that use. DailyBuilt will cooperate with those steps.

5.8 Subcontractors. DailyBuilt may engage Subprocessors to assist in performing the business purposes described in Annex 1. DailyBuilt binds each Subprocessor by a written contract that imposes on the Subprocessor the restrictions required of a service provider's subcontractor by Cal. Civ. Code § 1798.140(ag)(1), and remains responsible for each Subprocessor's performance as described in Section 10.

5.9 Contractor fallback. If DailyBuilt is deemed a "contractor" rather than a "service provider" for any processing under the Agreement, this Section 5 applies to DailyBuilt as a contractor, and DailyBuilt certifies that it understands and will comply with the restrictions in this Section 5 in that capacity.

5.10 Advertising integrations. Where Customer connects an advertising account and directs DailyBuilt to create, configure, or launch advertising through the Service, DailyBuilt acts only on Customer's instruction. As of the Effective Date, the Service does not upload Customer's contact lists to, or create matched or custom audiences on, any advertising platform. If DailyBuilt later makes such a feature available and Customer enables it, Customer is the business that determines whether the resulting disclosure is a "sale" or "share," is responsible for providing the required notice at collection and an opt-out mechanism, and is responsible for the representations it makes to the advertising platform. Customer's use of Meta and Google advertising, Google Business Profile, and Google Search Console through the Service is additionally subject to those providers' own terms, which Customer accepts directly when it connects its account.

5.11 Sensitive personal information. DailyBuilt does not use or disclose sensitive personal information for any purpose other than those permitted by Cal. Civ. Code § 1798.121(a) and the CCPA regulations. Customer determines whether to submit sensitive personal information to the Service; the Service is capable of receiving it, including through Customer-defined intake questions, clinical records in the Healthcare Edition, and free-text fields.

---

6. Processor terms under other State Privacy Laws

This Section 6 applies to Personal Information subject to the Colorado Privacy Act, the Virginia Consumer Data Protection Act, the Connecticut Data Privacy Act, the Texas Data Privacy and Security Act, or any other State Privacy Law that imposes contractual requirements on processors. It is the controller-processor contract those laws require.

6.1 DailyBuilt will:

(a) process Personal Information only on Customer's documented instructions, as set out in Section 3.1 and Annex 1;

(b) ensure that each person processing Personal Information is subject to a duty of confidentiality as described in Section 4.1;

(c) at Customer's direction, delete or return all Personal Information to Customer at the end of the provision of the Service, except where retention is required by law, as further described in Section 12;

(d) on Customer's reasonable written request, make available to Customer all information in DailyBuilt's possession that is reasonably necessary to demonstrate DailyBuilt's compliance with its obligations under this DPA, as described in Section 11;

(e) allow and cooperate with reasonable assessments by Customer or Customer's designated assessor, or arrange for a qualified and independent assessor to conduct an assessment of DailyBuilt's policies and technical and organizational measures using an appropriate and accepted control standard or framework and assessment procedure, and provide a report of that assessment to Customer on request, in each case as described in Section 11;

(f) engage Subprocessors only pursuant to a written contract that requires the Subprocessor to meet the obligations of DailyBuilt with respect to the Personal Information, and only after giving Customer the notice and opportunity to object described in Section 10;

(g) taking into account the nature of the processing and the information available to DailyBuilt, assist Customer by appropriate technical and organizational measures, insofar as reasonably practicable, in fulfilling Customer's obligations to respond to consumer rights requests, as described in Section 7;

(h) assist Customer in meeting its obligations in relation to the security of processing and in relation to the notification of a breach of security of Personal Information, as described in Sections 8 and 9; and

(i) provide information reasonably necessary to enable Customer to conduct and document any data protection assessment required by an applicable State Privacy Law.

6.2 Failure to meet obligations. If DailyBuilt determines that it can no longer meet its obligations under an applicable State Privacy Law with respect to Personal Information, DailyBuilt will notify Customer in writing without unreasonable delay, and Customer may take reasonable and appropriate steps to stop and remediate any unauthorized processing.

6.3 No controller determinations. DailyBuilt does not determine the purposes or means of processing Customer Data. If DailyBuilt begins, alone or jointly with others, to determine the purposes and means of processing any Customer Data, DailyBuilt will be a controller as to that processing and will notify Customer before doing so.

---

7. Consumer rights requests

7.1 Requests received by DailyBuilt. If DailyBuilt receives a request from an individual to exercise a right under a State Privacy Law with respect to Customer Data, DailyBuilt will not respond to the substance of the request. DailyBuilt will, within ten (10) business days of receipt, forward the request to the email address on record for the workspace owner of the affected workspace, together with the information DailyBuilt has that is needed to identify the requester and the workspace, unless applicable law prohibits DailyBuilt from doing so. DailyBuilt may inform the requester that the request has been forwarded to the business that controls the data and identify Customer.

7.2 Assistance. Taking into account the nature of the processing and the information available to DailyBuilt, DailyBuilt will provide reasonable assistance to Customer in responding to a verified consumer request, including by making the relevant records accessible to Customer through the Service, by locating records at Customer's written direction, and by deleting or correcting records at Customer's written direction, in each case subject to the retention limits in Section 12.

7.3 What the Service provides today. Customer acknowledges that, as of the Effective Date, the Service does not provide a self-serve bulk export of a workspace's records, does not generate an accounting-of-disclosures report, and does not provide an automated individual-request workflow. Assistance under Section 7.2 is performed manually by DailyBuilt on written request. DailyBuilt may charge its reasonable costs for assistance that is disproportionate to the ordinary operation of the Service, on prior written notice to Customer.

7.4 Verification. Customer is responsible for verifying the identity of any requester before instructing DailyBuilt to act. DailyBuilt may decline to act on an instruction that would disclose Personal Information to a person whose identity Customer has not verified.

7.5 Opt-out signals. Customer is responsible for honoring opt-out preference signals on the surfaces Customer operates. Where DailyBuilt operates a hosted surface on Customer's behalf, DailyBuilt will honor an opt-out preference signal to the extent the Service supports it and will not treat the signal as an instruction to delete Customer Data.

---

8. Security

8.1 DailyBuilt maintains the technical and organizational measures described in Annex 2, which are designed to protect Customer Data against a Security Incident and are appropriate to the nature of the Personal Information the Service is designed to process.

8.2 DailyBuilt may update the measures in Annex 2 from time to time provided the updates do not materially reduce the overall level of protection of Customer Data.

8.3 Annex 2 states what DailyBuilt does. It also states, at Section A2.10, measures DailyBuilt does not currently represent. Customer should read A2.10 as part of its vendor diligence. DailyBuilt makes no representation of compliance with any certification or attestation framework, and holds none.

8.4 Customer is responsible for the security of its own environment, including the security of the credentials and devices its personnel use to access the Service, the access it grants to its workspace members, and the disposition of data it exports from the Service.

---

9. Security Incidents

9.1 Notice. DailyBuilt will notify Customer of a Security Incident affecting Customer Data without undue delay and in any event no later than five (5) business days, and in no event more than ten (10) calendar days, after Discovery. "Discovery" means the first day on which the Security Incident is known to DailyBuilt, or by exercising reasonable diligence would have been known to DailyBuilt.

9.2 Content; duty to supplement. The initial notice will contain the information available to DailyBuilt at the time, which at a minimum will describe the nature of the Security Incident, the categories and approximate volume of Personal Information involved to the extent then known, the steps DailyBuilt is taking to investigate and mitigate, and a contact for further information. DailyBuilt will supplement the notice as additional information becomes available, without waiting for the investigation to conclude.

9.3 Subprocessor incidents. Where a Security Incident originates with a Subprocessor and DailyBuilt is awaiting the Subprocessor's disclosure, the five-business-day period in Section 9.1 is tolled from the time DailyBuilt requests the disclosure until DailyBuilt receives it, provided DailyBuilt (a) notifies Customer within the original period that a Subprocessor-originated incident may affect Customer and that DailyBuilt is awaiting disclosure, and (b) uses reasonable efforts to obtain the disclosure. Tolling under this Section never extends the ten (10) calendar-day outer limit in Section 9.1, the sixty (60) calendar-day limit in 45 C.F.R. § 164.410(b), or any statutory deadline, including the ten (10) calendar-day period in Fla. Stat. § 501.171(6)(a).

9.4 Cooperation; no admission. DailyBuilt will reasonably cooperate with Customer's investigation and with Customer's own notification obligations. Customer is responsible for determining whether the Security Incident triggers a notification obligation owed by Customer to individuals, regulators, or others, for the content and timing of that notification, and for its costs. DailyBuilt will not notify individuals on Customer's behalf without Customer's prior written instruction, except where DailyBuilt is independently required by law to do so. A notice under this Section 9 is not an acknowledgment of fault or liability by DailyBuilt.

9.5 Relationship to HIPAA and Florida law. Where the affected Personal Information is PHI, the reporting obligations of the BAA govern and the five-business-day period in Section 9.1 is the same period the BAA applies, within the sixty-calendar-day outer bound of 45 C.F.R. § 164.410(b). Where Fla. Stat. § 501.171(6) applies to DailyBuilt as a third-party agent, the five-business-day period is within, and does not extend, the ten-calendar-day period that statute requires.

---

10. Subprocessors

10.1 General authorization. Customer generally authorizes DailyBuilt to engage Subprocessors to process Customer Data in connection with the Service.

10.2 Current list. The current list of Subprocessors is published at dailybuilt.co/subprocessors. If that page is unavailable, DailyBuilt will provide the current list on written request to hello@dailybuilt.co.

10.3 Obligations flowed down. DailyBuilt enters into a written contract with each Subprocessor that binds the Subprocessor to the data-protection obligations required of a subprocessor by the applicable State Privacy Laws and appropriate to its processing activity, which for hyperscale cloud providers takes the form of that provider's standard data-processing terms. DailyBuilt remains liable to Customer for the acts and omissions of its Subprocessors to the same extent DailyBuilt would be liable if performing the service itself, subject to Section 15.

10.4 Notice of additions. DailyBuilt will give Customer at least thirty (30) days' advance notice before a new Subprocessor begins processing Customer Data. Notice is given by email to the address on record for each workspace owner. Customer is responsible for keeping that address current and for internally distributing the notice. DailyBuilt does not commit to any other notice channel.

10.5 Objection. Customer may object to a new Subprocessor on reasonable, documented data-protection grounds by written notice to hello@dailybuilt.co within thirty (30) days after DailyBuilt's notice. The parties will work in good faith for thirty (30) days to resolve the objection, which may include DailyBuilt offering a configuration that avoids the Subprocessor for Customer's workspace. If the parties do not resolve the objection within that period, Customer's sole and exclusive remedy is to terminate the affected portion of the Service on written notice, and DailyBuilt will refund prepaid, unused fees attributable to the terminated portion for the remainder of the then-current term, calculated pro rata by whole month. Continued use of the affected portion of the Service after the resolution period is deemed withdrawal of the objection. DailyBuilt may proceed with the engagement during the notice, objection, and resolution periods; where Customer has objected, DailyBuilt will use commercially reasonable efforts not to route Customer Data to the objected-to Subprocessor until the objection is resolved or Customer's termination takes effect.

10.6 Emergency replacement. DailyBuilt may replace a Subprocessor without advance notice where the change is required to address a material security risk, a Subprocessor's failure, or a legal requirement. DailyBuilt will notify Customer as soon as reasonably practicable and Section 10.5 then applies from the date of that notice.

10.7 Legal process. If DailyBuilt receives a subpoena, warrant, court order, or other legally binding demand for Customer Data, DailyBuilt will, unless legally prohibited, (a) promptly notify Customer, (b) redirect the requesting party to Customer where the demand can lawfully be directed to Customer, and (c) not produce Customer Data before the time legally required, so Customer has a reasonable opportunity to seek protective relief. DailyBuilt will challenge a demand it reasonably believes to be unlawful or overbroad. DailyBuilt's handling of legal process is further described at dailybuilt.co/legal-process. Where the demand seeks PHI, DailyBuilt will handle it in accordance with 45 C.F.R. § 164.512(e) and the BAA.

---

11. Documentation and audit

11.1 How audit rights are satisfied. On Customer's written request, and no more than once in any twelve-month period, DailyBuilt will provide (a) a written description of the technical and organizational measures then in place, (b) responses to a reasonable security questionnaire, and (c) any then-current third-party assessment or summary report DailyBuilt has obtained. Together these satisfy Customer's audit and assessment rights under this DPA and under the State Privacy Laws, including Colo. Rev. Stat. § 6-1-1305(5)(b) and Va. Code § 59.1-579(B)(5).

11.2 Additional audits. Customer may request an additional audit within a twelve-month period only following a Security Incident affecting Customer or a documented, good-faith belief that DailyBuilt is materially in breach of this DPA. Any such audit is conducted during business hours, on at least thirty (30) days' written notice, under a confidentiality agreement, in a manner that does not disrupt the Service or compromise the confidentiality or security of another customer's data, and at Customer's cost.

11.3 Exclusions. Audit rights under this DPA do not include penetration testing, vulnerability scanning, load testing, or any other active testing against production systems; access to DailyBuilt's source code, internal risk assessments, or another customer's data; or physical access to a Subprocessor's facilities. DailyBuilt may satisfy a request for information about a Subprocessor by providing the documentation that Subprocessor makes available to DailyBuilt.

11.4 Confidentiality. All information DailyBuilt provides under this Section 11 is DailyBuilt's confidential information.

11.5 No certifications. DailyBuilt does not hold, and this Section 11 does not promise, a SOC 2 report, an ISO 27001 certificate, a HITRUST certification, or any equivalent attestation. If DailyBuilt obtains one, DailyBuilt will make the report or certificate available under Section 11.1.

---

12. Deletion and return of Customer Data

12.1 During the term. Customer may delete records through the Service at any time. Deletion through the Service marks the record as deleted, removes it from the Service's interfaces and from DailyBuilt's ordinary query paths, and starts the purge clock in Section 12.4. It does not immediately erase the record from the database or from backups.

12.2 On termination. Within thirty (30) days after the effective date of termination or expiration of the Agreement, and on Customer's written request made within that period, DailyBuilt will provide Customer a machine-readable extract of the Customer Data then held in Customer's workspace. DailyBuilt will then delete Customer Data in accordance with Section 12.4. If Customer makes no request within that period, DailyBuilt may proceed to delete without further notice. Customer acknowledges that the extract is produced manually because the Service provides no self-serve bulk export; DailyBuilt may charge its reasonable costs for an extract of unusual size or complexity, on prior written notice.

12.3 What deletion means. "Delete" means removing the record from DailyBuilt's active production systems. Data in encrypted backups is not individually erased; it is overwritten in the ordinary course as backups age out of their rotation, and any restored data remains subject to this DPA until it is deleted again.

12.4 Retention floors. DailyBuilt applies mandatory minimum retention periods to categories of records so it can meet its own legal, tax, audit, and evidentiary obligations. A record is not purged before the applicable floor expires, even where Customer has instructed deletion. The floors are, measured from the record's retention anchor:

12.5 Audit log carve-out. The audit log is append-only. DailyBuilt's data-access layer rejects any update or deletion against it, the log is excluded from the soft-delete and purge machinery, and entries are not removed on Customer's instruction. Audit entries record who did what, when, and to which record; entries relating to clinical or contact-linked records store structural identifiers and status, not a verbatim copy of the record's contents. Customer acknowledges that a deletion instruction under this DPA does not reach the audit log, and that retaining it is necessary for DailyBuilt to comply with 45 C.F.R. § 164.312(b) and with its own security and legal-hold obligations.

12.6 Suppression records. Opt-out, unsubscribe, complaint, bounce, and STOP records are retained indefinitely and are not deleted on Customer's instruction. Deleting them would cause DailyBuilt to re-contact an individual who has opted out.

12.7 Legal hold. DailyBuilt will suspend deletion of records subject to a legal hold, a preservation demand, or a pending or threatened claim, and will notify Customer where permitted.

12.8 Healthcare Edition. A Healthcare Edition workspace cannot be deleted through the Service. Deletion of a Healthcare Edition workspace's records is governed by the BAA and by Section 12.4.

---

13. Protected health information

13.1 Where Customer has enabled the Healthcare Edition for a workspace, the BAA governs DailyBuilt's use and disclosure of PHI in that workspace. In the event of a conflict between this DPA and the BAA as to PHI, the BAA controls.

13.2 PHI is excluded from the CCPA and from the other State Privacy Laws to the extent those statutes exempt protected health information collected by a covered entity or business associate, or medical information governed by the Confidentiality of Medical Information Act. Sections 5 and 6 do not apply to PHI. Sections 8, 9, 10, 11, and 12 apply to PHI in addition to, and as supplemented by, the BAA.

13.3 Customer is responsible for determining whether it is a covered entity or business associate, for enabling the Healthcare Edition before submitting PHI, and for the accuracy of that determination. Submitting PHI to a workspace on which the Healthcare Edition is not enabled is a breach of the Agreement and of Section 3.3(f).

13.4 Health-related data that is not PHI — including information Customer collects from wellness clients, health data collected on a booking or intake form by a Customer that is not a covered entity, and consumer health data as defined by state consumer-health-data statutes — remains within the scope of this DPA and of dailybuilt.co/consumer-health-data.

---

14. Location of processing; international transfers

14.1 United States only. The Service is offered to businesses located in the United States and to their customers. DailyBuilt processes and stores Customer Data in the United States and instructs its Subprocessors to do the same for Customer Data.

14.2 No EU/UK/Swiss offering. DailyBuilt does not target, offer the Service to, or monitor the behavior of individuals in the European Economic Area, the United Kingdom, or Switzerland. This DPA does not grant rights under the EU General Data Protection Regulation, the UK GDPR, or the Swiss FADP, and DailyBuilt makes no representation of compliance with those regimes. Customer will not use the Service to process personal data of individuals in those jurisdictions without DailyBuilt's prior written agreement.

14.3 Future transfer mechanism. If the parties later agree in writing that the Service will be used to process personal data subject to the GDPR, the UK GDPR, or the Swiss FADP, the parties will execute (a) the European Commission's Standard Contractual Clauses, Module Two (controller to processor), (b) the UK Information Commissioner's International Data Transfer Addendum to those clauses, and (c) any Swiss adaptations, in each case as then in force, together with the transfer-impact documentation the transfer requires. Until executed, no transfer mechanism is in place and Section 14.2 applies.

14.4 Canada and other jurisdictions. Nothing in this Section 14 prevents an End User located outside the United States from interacting with a DailyBuilt-hosted surface. Customer remains responsible for the lawfulness of processing data it directs DailyBuilt to collect from individuals outside the United States.

---

15. Liability

15.1 Each party's liability arising out of or related to this DPA is subject to the exclusions, limitations, and caps set out in the Limitation of Liability section of the Terms of Service, including the trailing-twelve-month cap and the enhanced cap that applies to claims arising from DailyBuilt's breach of its data-security, confidentiality, or HIPAA obligations. This DPA does not create a separate or additional cap.

15.2 Any claim by Customer against a Subprocessor arising from the Subprocessor's processing of Customer Data is brought against DailyBuilt under the Agreement and is subject to Section 15.1. Nothing in this DPA gives Customer a direct claim against a Subprocessor.

15.3 Customer's indemnification obligations in the Terms of Service apply to claims arising from Customer Data, from Customer's instructions, and from Customer's breach of Section 3.

---

16. Term, precedence, and general

16.1 Term. This DPA takes effect as described in the preamble and remains in effect for as long as DailyBuilt processes Customer Data. Sections 4.1, 9, 12, 13, 15, and 16 survive termination.

16.2 Precedence. In the event of a conflict, the order of precedence is: (1) an Order Form signed by both parties, except as to Protected Health Information, where Section 13.1 and the BAA govern; (2) the BAA, as to PHI; (3) this DPA; (4) the Terms of Service; (5) the policies incorporated into the Terms of Service, including the Acceptable Use Policy, the SMS Terms, and the Billing Terms. No term of any Order Form operates to reduce the protections the BAA affords Protected Health Information below what the HIPAA Rules require, and any such term is of no effect as to Protected Health Information. As to a subject matter this DPA addresses, this DPA controls over the Terms of Service.

16.3 Changes. DailyBuilt may update this DPA (a) to reflect a change in applicable law, (b) to reflect a change in the Service, or (c) where the update does not materially reduce Customer's rights or DailyBuilt's obligations. DailyBuilt will post the updated DPA at dailybuilt.co/dpa with a new version and effective date and, for a material change, will give at least thirty (30) days' notice by email to the address on record for each workspace owner. If a material change materially and adversely affects Customer, Customer may terminate the affected portion of the Service before the change takes effect, with the same pro-rata refund described in Section 10.5. Prior versions of this document are archived by date and are available on request to hello@dailybuilt.co.

16.4 Notices. Notices to DailyBuilt under this DPA go to hello@dailybuilt.co and to DailyBuilt, Inc., c/o Corporation Service Company, 251 Little Falls Drive, Wilmington, DE 19808. Notices to Customer go to the email address on record for the workspace owner.

16.5 Governing law; disputes. This DPA is governed by the law of the State of Florida, without regard to its conflict-of-laws rules, and is subject to the dispute-resolution provisions of the Terms of Service, including the arbitration agreement, the class-action waiver, and the jury-trial waiver.

16.6 Severability. If a provision of this DPA is held unenforceable, it is modified to the minimum extent necessary to make it enforceable, and the remainder of this DPA remains in effect.

16.7 No third-party beneficiaries. This DPA does not create rights in any person other than the parties, except as expressly provided by an applicable State Privacy Law.

16.8 Entire agreement. This DPA, together with the rest of the Agreement, is the entire agreement of the parties as to the processing of Customer Data and supersedes any prior data-processing terms, including any terms in a Customer-supplied vendor form that DailyBuilt has not signed.

---

Annex 1 — Details of processing

A1.1 Subject matter. DailyBuilt's provision of the Service to Customer under the Agreement.

A1.2 Duration. The term of the Agreement, plus the retention floors in Section 12.4.

A1.3 Nature and purpose of processing. Hosting, storage, transmission, retrieval, organization, display, backup, deletion, and secure disposal of Customer Data, in order to: operate Customer's contact records and client files; publish Customer's booking pages and accept appointment requests and intake responses; create, send, and collect invoices and record payment outcomes; generate, deliver, execute, seal, and store documents and signatures; send and receive email and SMS on Customer's behalf; connect and operate the advertising, business-listing, and search-performance integrations Customer enables; produce web analytics for Customer's hosted pages; authenticate and authorize Customer's personnel; provide support; secure the Service and investigate abuse; and bill Customer.

A1.4 Categories of data subjects.

• Customer's owners, employees, contractors, and other authorized users of the Service.
• Customer's clients, patients, customers, and prospects, including individuals whose records Customer imports from a file or a device address book.
• Individuals who book an appointment, complete an intake or inquiry form, view or sign a document, view or pay an invoice, or reply to an email sent through the Service.
• Recipients of email or SMS Customer sends through the Service.
• Visitors to DailyBuilt-hosted pages operated for Customer, and to Customer's registered external sites where Customer has enabled analytics.
• Individuals named within free-text fields, uploaded files, document content, or message content that Customer submits.

A1.5 Categories of Personal Information, by surface.

A1.6 Sensitive Personal Information. The Service is capable of receiving sensitive Personal Information, including health information, insurance identifiers, date of birth, precise contact details, and information revealing racial or ethnic origin where Customer chooses to collect it. Whether sensitive Personal Information is submitted is determined solely by Customer's configuration and by the questions Customer publishes. DailyBuilt does not use sensitive Personal Information for any purpose other than performing the Service.

A1.7 Data of minors. Customer determines whether it collects information about individuals under 18. Customer is responsible for any parental-consent, guardian-authority, and minor-record requirements that apply, including the clinical retention rule in Section 12.4.

A1.8 Frequency of processing. Continuous, for the term of the Agreement.

A1.9 Countries of processing. United States.

---

Annex 2 — Technical and organizational measures

DailyBuilt maintains the following measures. This annex describes the Service as built as of the Effective Date.

A2.1 Encryption. Data is encrypted in transit using TLS 1.2 or higher on every network path between the browser, the Service, and DailyBuilt's Subprocessors. Data is encrypted at rest using AES-256 or stronger across the primary database, automated backups, the secret store, log storage, and object storage. Documents, sealed PDFs, superbills, and file attachments are held in encrypted object storage with a provider that is bound by a business associate agreement, and are retrieved through short-lived signed URLs that expire in minutes rather than through public links. Object storage is accessed with ambient workload credentials rather than long-lived static keys.

A2.1.1 Payment data. DailyBuilt does not receive, transmit, or store full payment card numbers, card verification values, or bank account credentials. Card data is collected in the payment processor's own hosted elements on the Customer's connected account. DailyBuilt stores only processor identifiers, amounts, and outcome status.

A2.2 Tenant isolation. Every authenticated request resolves its workspace from a trusted source — the workspace bound to the API key, or a session whose workspace claim is validated against an active membership record — never from an unverified client-supplied value. Every data-access query is then scoped to that workspace identifier, and the requesting member's role gates the action. Tenant isolation is enforced in the application layer; DailyBuilt does not represent that it is additionally enforced by a database-level tenancy policy.

A2.2.1 Row-level security. PostgreSQL row-level security is enabled and forced on the tenant tables. The policies in force make deleted rows invisible to every database role unless the transaction explicitly opts in, so a record that has been deleted cannot be returned by an ordinary query or updated back into visibility. These policies enforce deletion state; they do not enforce workspace separation, which is the application-layer control described in A2.2.

A2.2.2 Public surfaces. Booking, signing, payment, and inquiry pages are served without an End User account. Access to a specific record from those surfaces requires a capability token that is stored only as a hash, and origin access to the public API is constrained by per-workspace publishable-key origin rules. Bot and abuse protection on public form submissions is provided by a challenge service.

A2.3 Append-only audit logging of writes. Every create, update, and delete is recorded at the data-access layer, not at the call site, so no code path can perform a write without producing an audit entry. Each entry records the workspace, the actor type and identity, the action, the entity type and identifier, the request identifier, the IP address, and the user agent. The audit table is append-only: updates and deletes against it are rejected by the data layer, and the table is excluded from the soft-delete and purge machinery. Audit snapshots of clinical and contact-linked records retain structural identifiers and status only, not a verbatim copy of the record's contents.

A2.4 Access logging of reads. Reads of clinical and contact-linked records, and downloads of documents and file attachments, are recorded as access events in the same audit log, with the same actor, request, IP address, and user-agent attribution. Access logging is bounded to records classified as clinical or contact-linked so that log growth tracks access to sensitive records rather than general traffic.

A2.5 Authentication and access control. Customer's users and DailyBuilt's operators authenticate through a hosted identity provider (WorkOS AuthKit); DailyBuilt does not store user passwords. Access within a workspace is governed by role. DailyBuilt's internal operator console is restricted to an explicit allowlist of operator identities configured per environment, and every operator action is attributed to the operator's identity in the audit log. Shared or generic operator accounts are not used.

A2.6 Secrets and key management. Credentials and API keys are held in a managed secret store, injected into the runtime at deploy time, scoped per environment, and are not committed to source control. API keys issued to Customer are stored as hashes.

A2.7 Environment segregation. Production, staging, and development run in separate cloud projects with separate databases and separate credentials. DailyBuilt does not copy production Customer Data into staging or development environments for testing. Authorized DailyBuilt operators can read and administer production records through DailyBuilt's internal operator console, subject to A2.5 and to the audit logging in A2.3 and A2.4.

A2.8 Resilience. The primary database is backed up automatically with point-in-time recovery. Backups are encrypted and are subject to a rotation schedule.

A2.9 Data lifecycle controls. Deletion is implemented as a soft delete enforced at the data layer and made invisible by row-level security, coupled with a retention manifest that assigns every table a retention class, a retention root, and a purge floor. A new table cannot ship without a retention decision; a validation routine compares the manifest against the live schema and fails when a table is missing from it.

A2.10 Measures DailyBuilt does not represent. Customer should treat the following as not in place, and should not rely on any contrary statement:

• DailyBuilt holds no SOC 2 report, ISO 27001 certificate, HITRUST certification, or equivalent third-party attestation.
• DailyBuilt does not enforce multi-factor authentication as an organization-wide policy for its operators. Multi-factor authentication is available through the identity provider and DailyBuilt intends to enforce it; until it does, no such control is represented.
• The Service does not provide a self-serve bulk export of a workspace's records.
• The Service does not generate an accounting-of-disclosures report.
• DailyBuilt does not currently make a penetration-test report available.
• DailyBuilt has not bound a cyber-liability or errors-and-omissions insurance policy, and makes no representation about coverage, limits, or additional-insured status.

A2.11 Subprocessor diligence. DailyBuilt reviews the security posture of a Subprocessor before engaging it for Customer Data and binds it by written contract as described in Section 10.3.

A2.12 Updates. DailyBuilt may update this Annex 2 as the Service changes, subject to Section 8.2.

---

Annex 3 — Subprocessors

A3.1 The current list of Subprocessors, the service each performs, and the categories of Customer Data each processes is published at dailybuilt.co/subprocessors and is incorporated into this DPA by reference.

A3.2 Where Customer has enabled the Healthcare Edition, Exhibit C to the BAA sets out the Subprocessors that create, receive, maintain, or transmit PHI, and the HIPAA basis on which each does so. As to PHI, Exhibit C to the BAA controls over Annex 3.

A3.3 Additions to the Subprocessor list are notified, and may be objected to, as described in Section 10.

---

DailyBuilt, Inc. c/o Corporation Service Company, 251 Little Falls Drive, Wilmington, DE 19808 hello@dailybuilt.co