Data Processing Addendum
This Data Processing Addendum ("DPA") forms part of the Eave Desk Terms of Service or other written agreement (the "Agreement") between Columbia Groundwork Inc., a corporation organized under the laws of Washington, doing business as Columbia Data Group ("Eave Desk," "Processor"), and the Customer identified in the Agreement ("Customer," "Controller").
This DPA takes effect on the effective date of the Agreement and controls over the Agreement and the Privacy Policy to the extent of any conflict regarding the processing of Customer Personal Data.
1. Definitions
"Applicable Data Protection Law" means all privacy and data protection laws applicable to a party's processing of Customer Personal Data, including the California Consumer Privacy Act as amended by the California Privacy Rights Act ("CCPA"), the comprehensive consumer privacy statutes of other US states, and, where they apply, the EU General Data Protection Regulation 2016/679 ("GDPR") and the UK GDPR.
"Buyer" has the meaning in the Agreement: a person who uses Customer's designer link, a saved or shared design link, a customer portal, or a package link.
"Customer Personal Data" means personal data contained in Customer Data that Eave Desk processes on Customer's behalf under the Agreement, including Buyer personal data.
"Data Subject Request" means a request from a data subject or consumer to exercise a right under Applicable Data Protection Law, including access, correction, deletion, portability, restriction, objection, or opt-out.
"Personal Data Breach" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Customer Personal Data.
"Subprocessor" means a third party engaged by Eave Desk to process Customer Personal Data.
The terms controller, processor, data subject, personal data, processing, business, service provider, consumer, sell, and share have the meanings given in Applicable Data Protection Law.
2. Roles and scope
2.1 Roles. Customer is the controller (or business) of Customer Personal Data, including the personal data of its Buyers. Eave Desk is the processor (or service provider) and processes Customer Personal Data only on Customer's behalf.
2.2 Eave Desk as controller. Eave Desk is an independent controller only for: account administration and billing contacts, platform security and audit logs it must keep for its own compliance, and visitors to the Eave Desk website. That processing is governed by the Privacy Policy, not by this DPA.
2.3 Customer obligations. Customer is responsible for: the lawfulness of its own collection and use of Customer Personal Data; deciding which contact details, if any, a Buyer must supply at a lead gate; providing any notices and obtaining any consents required from data subjects beyond those the Service presents; the accuracy of Customer Personal Data; and configuring the Service's roles, price visibility, file release, retention, and deletion settings appropriately for its own obligations.
2.4 Instructions. Eave Desk will process Customer Personal Data only on Customer's documented instructions, which consist of the Agreement, this DPA, the Order Form, the configuration choices Customer makes in the Service, requests Customer makes through the integration API, and any further written instructions Customer gives that the parties agree to. Eave Desk will inform Customer if, in its opinion, an instruction infringes Applicable Data Protection Law, unless prohibited from doing so.
2.5 Legally required processing. If law requires Eave Desk to process Customer Personal Data other than on Customer's instructions, Eave Desk will inform Customer of that requirement before processing unless the law prohibits it on important grounds of public interest.
2.6 No sale, no sharing, no secondary use. Eave Desk will not sell or share Customer Personal Data, will not retain, use, or disclose it for any purpose other than performing the Service and the business purposes specified in Annex A, will not use it for its own marketing, will not combine it with personal data from other sources except as permitted by Applicable Data Protection Law, and will not use it to train machine learning models made available to other customers.
2.7 Government and legal requests. If Eave Desk receives a legally binding demand from a public authority or a private litigant for Customer Personal Data, Eave Desk will notify Customer promptly unless legally prohibited, direct the requester to Customer where possible, challenge a demand it considers overbroad or unlawful, disclose only the minimum required, and keep a record of the demand that it will describe to Customer on request to the extent the law allows.
2.8 The operator's construction business. Eave Desk's operator is affiliated with a post-frame construction business. Eave Desk will not use or disclose Customer Personal Data, Customer's leads, or Customer's pricing for or to that business or any Affiliate, and will not use them to compete with Customer for a Buyer. This section restates section 7.8 of the Terms so that it applies where this DPA is executed standalone.
3. Details of processing
The subject matter, duration, nature and purpose of processing, types of personal data, and categories of data subjects are described in Annex A.
4. Confidentiality and personnel
4.1 Confidentiality. Eave Desk will treat Customer Personal Data as Customer's Confidential Information under the Agreement.
4.2 Personnel. Eave Desk will ensure that personnel authorized to process Customer Personal Data are bound by written confidentiality obligations, including the obligation in section 2.8, and will limit access to those personnel who need it to perform the Agreement.
4.3 Training. Eave Desk will provide its personnel with data protection and security awareness training appropriate to their role.
5. Subprocessors
5.1 General authorization. Customer gives Eave Desk general written authorization to engage Subprocessors. The Subprocessors engaged as of the effective date are listed in Annex B.
5.2 Notice of changes. Eave Desk will notify Customer at least 30 days before adding or replacing a Subprocessor that will process Customer Personal Data. Notice will be given by email to Customer's administrative contact or by an update to the subprocessor list in the Privacy Policy, and will identify the Subprocessor, its role, and its processing location.
5.3 Objection. Customer may object to a new Subprocessor on reasonable data protection grounds by written notice within 30 days of Eave Desk's notice. The parties will work in good faith to resolve the objection. If they cannot, Customer may terminate the affected subscription without penalty and receive a prorated refund of prepaid unused fees, as its sole remedy.
5.4 Flow-down and responsibility. Eave Desk will impose on each Subprocessor data protection obligations no less protective than those in this DPA, and remains fully liable to Customer for each Subprocessor's performance.
6. Security
6.1 Measures. Eave Desk will implement and maintain the technical and organizational measures described in Annex C, taking into account the state of the art, the costs of implementation, the nature, scope, context, and purposes of processing, and the risks to data subjects.
6.2 Changes. Eave Desk may update the measures in Annex C provided the updates do not materially reduce the overall level of security.
6.3 No certification claimed. Eave Desk states formal security certifications and attestations only once they are earned. As of the effective date of this DPA, Eave Desk holds no third-party security certification. Annex C describes controls Eave Desk actually operates, not controls it aspires to.
7. Personal Data Breach
7.1 Notification. Eave Desk will notify Customer without undue delay, and in any event within 72 hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data.
7.2 Contents. The notification will describe, to the extent known and as information becomes available: the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, the measures taken or proposed to address it, and a point of contact.
7.3 Cooperation. Eave Desk will take reasonable steps to contain and investigate the breach, will document it, and will provide Customer with information reasonably available to it so Customer can meet its own notification obligations, including to Buyers. Eave Desk will not notify a regulator or data subject about a breach on Customer's behalf unless Customer instructs it to or law requires it.
7.4 No admission. Notification under this section is not an acknowledgment of fault or liability.
8. Audits and information
8.1 Documentation. Eave Desk will make available to Customer the information reasonably necessary to demonstrate compliance with this DPA, including this DPA's annexes, its security documentation, and its responses to a reasonable security questionnaire.
8.2 Audits. Where Applicable Data Protection Law gives Customer an audit right that documentation under section 8.1 does not satisfy, Customer may audit Eave Desk's processing no more than once per twelve months, on at least 30 days' written notice, during business hours, without unreasonably disrupting Eave Desk's operations, and subject to confidentiality obligations. Customer bears its own costs and Eave Desk's reasonable costs of supporting the audit.
8.3 More frequent audits. An additional audit is permitted where a regulator requires it or following a confirmed Personal Data Breach affecting Customer Personal Data.
8.4 Third-party auditors. Customer may use an independent auditor who is not a competitor of Eave Desk, provided the auditor is bound by confidentiality obligations at least as protective as those in the Agreement.
9. Data subject rights
9.1 Assistance. Taking into account the nature of the processing, Eave Desk will assist Customer by appropriate technical and organizational measures, insofar as possible, in fulfilling Customer's obligation to respond to Data Subject Requests. The Service's own functions are the primary means of that assistance: the customer record and lead grid for access and correction, the company export for portability, and the contact-scope deletion request in the Retention settings for deletion.
9.2 Requests received by Eave Desk. If Eave Desk receives a Data Subject Request relating to Customer Personal Data, including from a Buyer who found Eave Desk's name in the Privacy Policy on Customer's designer link, it will not respond to the substance of the request except to acknowledge it and direct the individual to Customer, and will forward it to Customer within 5 business days.
9.3 Additional assistance. Where the Service's functions are insufficient, Eave Desk will provide reasonable additional assistance at Customer's request. Eave Desk may charge a reasonable fee for assistance that is unreasonable in scope or frequency, on notice before incurring it.
10. Additional assistance
Taking into account the nature of processing and the information available to it, Eave Desk will provide reasonable assistance to Customer with data protection impact assessments and prior consultations with supervisory authorities, to the extent required by Applicable Data Protection Law and relating to Eave Desk's processing.
11. Return and deletion
11.1 During the term. Customer may export Customer Personal Data at any time through the Service, and may set per-class retention periods and submit deletion requests in the Retention settings. A contact-scope deletion request executes after a 14-day pending window during which Customer may cancel it; a whole-account request additionally requires Eave Desk's confirmation. Records removed by retention or deletion are recoverable by Customer for 30 days and then purged.
11.2 After termination. Eave Desk will make Customer Personal Data available for export during the 30-day read-only period after termination of the Agreement, and will delete it within 60 days after that period, in accordance with section 15.4 of the Terms of Service.
11.3 Design geometry. Saved design revisions are stored immutably and contain no personal data. Deletion of a design severs its identity, ownership, recovery, and contact linkage and excludes it from every list, link, and export; the anonymous geometry may persist.
11.4 Backups. Customer Personal Data present in routine backups is deleted on the backup rotation cycle rather than on demand. Until deletion, it remains subject to this DPA.
11.5 Legally required retention. Eave Desk may retain Customer Personal Data where law requires, for as long as required, and will continue to protect it under this DPA.
11.6 Certification. Eave Desk will certify deletion in writing at Customer's written request.
12. International transfers
Eave Desk processes Customer Personal Data in the United States. Where Eave Desk processes Customer Personal Data subject to GDPR or UK GDPR and transfers it outside the EEA or the UK, Annex E applies.
13. General
13.1 Liability. Each party's liability under this DPA is subject to the limitations and exclusions in the Agreement.
13.2 Term. This DPA continues for as long as Eave Desk processes Customer Personal Data.
13.3 Conflict. In the event of a conflict, the order of precedence is: Annex E (where it applies), then Annex D (where it applies), then this DPA, then the Agreement, then the Privacy Policy.
13.4 Changes in law. If Applicable Data Protection Law changes such that this DPA no longer satisfies it, the parties will negotiate in good faith to amend it.
13.5 Severability. If a provision is held invalid, the rest remains in effect.
Annex A: Details of processing
Subject matter. Eave Desk's provision of the building design, sales, and takeoff platform to Customer under the Agreement.
Duration. The term of the Agreement, plus the retention and deletion periods in section 11.
Nature and purpose of processing. Hosting, storage, retrieval, organization, structuring, transmission, display, and deletion of Customer Personal Data for the purpose of: publishing Customer's branded designer and capturing Buyer designs and contact details as leads; storing saved designs and revisions and letting Buyers return to and share them; managing Customer's customers, projects, pipeline, tasks, and files; producing quantities, estimates, quotes, drawings, and document packages; delivering packages and portal links to Buyers by email or link; routing engineering review; serving Customer's integration API requests; recording an audit trail; and providing support to Customer.
Categories of data subjects.
| Category | Description |
|---|---|
| Buyers | Members of the public and businesses who design, view, price, or request a quote on a building through Customer's designer link, saved or shared design links, the customer portal, or package links |
| Customer personnel | Owners, administrators, managers, sales staff, and estimators with a User sign-in |
| Reviewers | Engineers or other reviewers Customer names in an engineering request |
| API integrators | Individuals identified in Customer's connected systems, to the extent Customer's API calls carry their data |
Types of personal data.
| Type | Examples |
|---|---|
| Buyer identity and contact | Name, email, phone, organization, preferred contact method, mailing address, city; captured at a lead gate, a quote request, or by Customer staff |
| Buyer project | Building site address, region, postal code, project scope (kit or installed), order reference, notes |
| Buyer design linkage | A hashed visitor identifier, the designs saved under it, the device that owns a design, a hashed recovery secret |
| Lead and pipeline | Stage, owner, follow-up tasks, private notes entered by Customer staff, saved list views |
| Customer personnel account | Email, salted password hash, display name, role, invitations, sessions, API keys created |
| Communications | Emails queued and sent from Customer's account, recipient address, delivery status, link secrets |
| Files | Documents Customer uploads, engineering returns, generated packages, with version history and digests |
| Audit and activity | Actor, action, record, and timestamp for significant actions; API request audit by resource and status, never URLs, bodies, or credentials |
| Analytics | Per-source counts of designer opens, unique hashed visitors, saved designs, and quote requests. Source labels contain no contact data |
Special categories of data. None are collected by design. Free-text fields (notes, project notes, quote messages) exist and Customer controls what goes in them.
Frequency of processing. Continuous, for the duration of the Agreement.
Annex B: Subprocessors
Accurate as of the effective date. Eave Desk maintains the current list and notifies Customer of changes under section 5.2.
| Subprocessor | Purpose | Data processed | Location |
|---|---|---|---|
| Render (Render Services, Inc.) | Application hosting, the persistent disk holding the database and uploaded files, and daily disk snapshots | All Customer Personal Data | United States (Oregon) |
| Stripe, Inc. | Subscription payment processing | Customer's billing contact and payment details; no Buyer data | United States |
[EMAIL PROVIDER: none deployed. Code supports Resend, Postmark, and Amazon SES. Fill this row when one is switched on.] | Delivery of emails sent from Customer's account | Recipient name and email address, message content, link secrets, delivery status | United States |
| Google Workspace (Google LLC) | Eave Desk's own business email and documents | Correspondence with Customer contacts and any data Customer sends by email | United States |
| GitHub, Inc. | Source code hosting and deployment trigger | No Customer Personal Data in the ordinary course | United States |
Systems that Customer connects to the Service through the integration API receive Customer Personal Data on Customer's instruction and under Customer's own contracts with those vendors. They are not Eave Desk Subprocessors. An engineer or reviewer Customer names in an engineering request is Customer's contractor, not Eave Desk's Subprocessor.
Annex C: Technical and organizational measures
These describe controls Eave Desk operates as of the effective date. Nothing here is aspirational. Where a common control is absent, this annex says so.
Access control
- Role-based access control. Tenant roles (admin, manager, sales) and per-capability checks such as cost read, takeoff read, and engineering export gate every workspace action; a permission that was not granted does not exist for that user.
- Account isolation enforced in the database. Every tenant-scoped table carries the tenant identifier, and database triggers abort any write that would link a record to another tenant's design, contact, or project.
- Platform operator access is a separate platform account. A platform operator can be granted time-limited support access to a Customer account by that Customer, and platform reads of a Customer's summary are themselves written to a platform audit table.
- Session management. Sessions are stored as token hashes with expiry and can be revoked. The session cookie is HTTP-only. Every browser API request is checked against the configured application origin, and API keys are never accepted on browser routes.
- Passwords are stored only as salted scrypt hashes. Eave Desk cannot recover a plaintext password.
- Rate limiting on sign-in, on design recovery attempts (15-minute lockout), on the integration API (120 requests per minute per key), and on other request paths.
- Integration API keys are shown once, stored hashed, scoped per resource and per read, write, and delete, expire within 365 days, can be revoked immediately by any Customer administrator, and belong to the Customer account rather than the person who created them.
- Buyer-facing pages are reached by secret links. Saved designs additionally have a hashed owner recovery secret and a per-device ownership record; shared designs are read-only copies; released files carry expiring links that Customer controls.
- Not in place: multi-factor authentication for any account, and self-service password reset. State this plainly to a Customer that asks.
Encryption
- In transit: TLS for all connections to the Service, terminated by the hosting provider. Cookies are marked Secure on HTTPS. API responses are marked no-store.
- At rest: the database and uploaded files live on the hosting provider's persistent disk. Render encrypts persistent disks and their automatic daily snapshots at rest (https://render.com/docs/disks).
- Field-level encryption: none. The Service does not hold data of a class that would warrant it, and it does not claim to.
Integrity
- Design revisions and published site versions are immutable at the database level: triggers abort any update or deletion. A saved design can be hidden, severed from its owner, and excluded from exports, but its geometry cannot be altered after the fact.
- Generated document packages are pinned to a design revision and carry a SHA-256 digest of the exact PDF bytes.
- Integration API writes are idempotent by request key, use optimistic version checks, and commit the business change, the replay record, and the request audit in one transaction; audit failure rolls the change back.
- Where a User turns off opening placement rules, the revision records who did it and why, and every output is marked NOT ENGINEERED.
Logging and monitoring
- An audit trail records actor, action, record, and timestamp for significant workspace actions. Rows are appended by the application and are not edited or deleted by any application path.
[CONFIRM: there is no database trigger enforcing audit immutability the way design revisions have one. Either add the trigger or keep this sentence as written. To be completed by 10/12/26.] - A separate platform audit records platform-operator actions, including views of Customer summaries.
- Integration API request audit records resource, method, record identifier, status, and time; never URLs, query strings, bodies, or credentials.
- Operation alerts record generation and worker errors, and unrecognized billing prices, for operator review.
Software development and change management
- Version-controlled source with automated unit, integration, and browser test suites run before a release.
- Database changes applied through additive, idempotent migration files that run on open.
- Secrets held in the hosting provider's environment configuration, never in source control. The billing integration refuses live-mode keys and live-mode objects in code until deliberately enabled.
- Every release restarts the single application instance; restarts are treated as planned maintenance.
Availability and resilience
- Single application instance, single region (Oregon). No zero-downtime deploys.
- Backups are the hosting provider's daily disk snapshots, kept seven days. Restore is a hosting-dashboard action.
[CONFIRM: whether a restore has been rehearsed against the pilot, and whether off-host copies with longer retention are wanted before the Service carries real quotes. The operations runbook proposes daily encrypted off-host snapshots with 30-day retention; that is not built. To be completed by 10/12/26.] - Retention is configurable per data class by Customer, within any floor and ceiling the platform sets, and defaults to keep-forever. Records removed by retention or deletion are recoverable for 30 days, then purged.
Vulnerability management
- Dependency updates applied on a regular cadence.
- Not in place: a formal third-party penetration testing or vulnerability scanning program. State this plainly rather than implying one exists. Update this annex when one starts.
Personnel and organizational
- Access to production data limited to personnel who require it.
- Written confidentiality obligations for personnel with access, including the obligation in section 2.8 not to use Customer pricing or leads for the operator's affiliated construction business.
- Access removed on role change or departure.
Data minimization by design
- The Service asks a Buyer for what Customer's lead gate requires and nothing more. Design geometry is stored separately from identity and contains no personal data. Analytics keep only hashed visitor identifiers and source labels. Payment card data is entered only on Stripe's forms.
Annex D: US state privacy law terms
This annex applies where Customer is a business, controller, or equivalent under a US state privacy law and Eave Desk processes Customer Personal Data on its behalf.
D.1 Service provider and processor status. Eave Desk is a "service provider" under the CCPA and a "processor" under the other state comprehensive privacy laws. Customer discloses Customer Personal Data to Eave Desk only for the limited and specified business purposes in Annex A.
D.2 Restrictions. Eave Desk will not:
(a) sell or share Customer Personal Data;
(b) retain, use, or disclose Customer Personal Data for any purpose other than the business purposes specified in Annex A, including for a commercial purpose other than those purposes, or as otherwise permitted by the CCPA;
(c) retain, use, or disclose Customer Personal Data outside the direct business relationship between Eave Desk and Customer;
(d) combine Customer Personal Data with personal information received from or on behalf of another person, or collected from its own interactions with a consumer, except as the CCPA permits a service provider to do. In particular, Eave Desk will not combine one Customer's Buyer data with another Customer's, even where the same person designed a building on two Customers' links.
D.3 Certification. Eave Desk understands the restrictions in D.2 and will comply with them.
D.4 Notice of inability. Eave Desk will notify Customer if it determines it can no longer meet its obligations under Applicable Data Protection Law.
D.5 Remediation. On notice of unauthorized use of Customer Personal Data, Eave Desk will take reasonable and appropriate steps to stop and remediate it. Customer may take reasonable and appropriate steps to stop and remediate unauthorized use.
D.6 Consumer requests. Eave Desk will assist Customer in responding to verifiable consumer requests as described in section 9. A Buyer is Customer's consumer; Customer is responsible for verifying and answering the request.
D.7 Sensitive personal information. Customer Personal Data is not intended to include sensitive personal information. Where Customer nonetheless enters it, Eave Desk processes it only for the purposes in Annex A and applies the measures in Annex C.
D.8 Deidentified data. Where Eave Desk uses deidentified or aggregated data as permitted by section 2.6 and section 7.5 of the Terms of Service, it will take reasonable measures to prevent reidentification, publicly commit to maintaining it in deidentified form, and contractually obligate any recipient to the same.
Annex E: International transfers
Eave Desk offers the Service to businesses in the United States and processes Customer Personal Data there. This annex is inoperative unless Customer is established in, or Customer Personal Data is subject to the law of, the European Economic Area, the United Kingdom, or Switzerland.
Signature block
Where this DPA is executed as a standalone document rather than incorporated by reference into the Agreement.
Columbia Groundwork Inc., doing business as Columbia Data Group
Signature: ______________________________
Name: ______________________________
Title: ______________________________
Date: ______________________________
Customer: ______________________________
Signature: ______________________________
Name: ______________________________
Title: ______________________________
Date: ______________________________