Data Processing Agreement

This Data Processing Agreement ('DPA') is entered into between Buildlr Ltd, a private limited company registered in Cyprus (registration number HE 465133, VAT number CY60106289I), registered office Charilaou Xylophorou 13, Agios Athanasios, 4103 Limassol, Cyprus (the 'Processor' or 'Buildlr') and the customer accepting the Buildlr Terms of Service (the 'Controller' or 'Customer'). It is incorporated into and governed by the Terms of Service. In case of conflict regarding the processing of personal data, this DPA prevails.

Terms such as 'personal data', 'processing', 'data subject', 'controller', 'processor' and 'personal data breach' have the meaning given in the GDPR (Regulation (EU) 2016/679) and, where applicable, the UK GDPR. 'Customer Data' means the personal data the Customer and its users store in or submit to the Buildlr workspace, as described in Annex I.

The Customer is the controller of Customer Data; Buildlr processes Customer Data as processor, only (a) to provide, maintain and secure the Service as described in the Terms, (b) as documented in this DPA, and (c) per further documented instructions the Customer gives through the Service's settings and features (e.g. enabling an accounting integration, configuring lead forms). The Terms, this DPA and the Customer's product configuration are the Customer's complete documented instructions. Buildlr processes Customer Data only on these documented instructions, unless required to do so by Union or Member State law to which Buildlr is subject; in that case, Buildlr informs the Customer of that legal requirement before processing, unless that law prohibits it.

Buildlr will immediately inform the Customer if, in its opinion, an instruction infringes the GDPR. This DPA applies for as long as the Customer has an account, plus the deletion period in section 9.

Where the Customer uses Buildlr features to collect personal data directly from third parties (public lead forms, inbound email intake), the Customer is the controller of that data from the moment of collection and is responsible for providing the information required by Articles 13-14 GDPR to those data subjects, including configuring a privacy-notice link on its lead forms.

If a public authority requests access to or disclosure of Customer Data, Buildlr will assess the legal validity of the request, challenge it where there are reasonable grounds to do so, notify the Customer before any disclosure unless legally prohibited, and disclose no more than the minimum required.

Buildlr ensures that persons authorized to process Customer Data are bound by confidentiality obligations and access Customer Data only as needed to provide and support the Service.

Buildlr implements and maintains the technical and organizational measures described in Annex II. Buildlr may update Annex II from time to time, provided the overall level of protection is not reduced.

The Customer grants Buildlr general authorization to engage the sub-processors listed in Annex III. Buildlr imposes data-protection obligations on each sub-processor equivalent to those in this DPA and remains liable for their performance.

Buildlr will give the Customer at least 30 days' notice before adding or replacing a sub-processor (by email, and by updating the sub-processor list). The Customer may object on reasonable data-protection grounds; if the parties cannot resolve the objection, the Customer may terminate the affected part of the Service and receive a pro-rata refund of prepaid fees.

Optional integrations the Customer itself connects (e.g. Fortnox, QuickBooks) are engaged on the Customer's instruction; the receiving provider acts as the Customer's own processor or as an independent controller under its own terms, as indicated in Annex III.

Map display and address search use public services of the OpenStreetMap Foundation, accessed directly from the user's device: the device requests map tiles and geocoding results directly from OpenStreetMap Foundation servers and in doing so transmits the search text and the device's IP address. The OpenStreetMap Foundation receives this data as an independent controller under its own privacy policy; it is not a sub-processor of Buildlr, and no Customer Data is sent to it from Buildlr's servers. Use of the map and address-search features constitutes the Customer's documented instruction for this transmission.

Buildlr processes Customer Data in the EU/EEA by default (hosting: Germany). Where a sub-processor processes personal data outside the EU/EEA, the transfer is protected by an adequacy decision (including the EU-US Data Privacy Framework where the recipient is certified) or the EU Standard Contractual Clauses (2021/914), with supplementary measures where required. Details per sub-processor are in Annex III. For UK GDPR transfers, the UK Addendum or IDTA applies as relevant.

Taking into account the nature of the processing, Buildlr assists the Customer with appropriate technical and organizational measures to fulfil data-subject requests (access, rectification, erasure, restriction, portability, objection): the Service provides in-product editing and deletion capabilities, including erasure of an individual user's personal data, Buildlr supplies data exports on request, and Buildlr provides reasonable additional assistance on request. If a data subject contacts Buildlr directly about Customer Data, Buildlr will refer them to the Customer without undue delay and will not respond on the merits except on the Customer's instruction or where legally required.

Buildlr also provides the Customer with reasonable assistance regarding security, breach notification, data protection impact assessments and prior consultation, taking into account the nature of processing and the information available to Buildlr.

Buildlr notifies the Customer without undue delay, and at the latest 72 hours, after becoming aware of a personal data breach affecting Customer Data. The notification includes, to the extent known: the nature of the breach, categories and approximate numbers of data subjects and records affected, likely consequences, measures taken or proposed, and a contact point. Buildlr documents breaches and cooperates with the Customer's own notification obligations under Articles 33-34 GDPR. Notification is not an admission of fault.

During the term, the Customer can delete Customer Data through the Service and can export Customer Data using the product's export capabilities.

Upon termination of the account, Buildlr deletes all Customer Data within 90 days, including from backups as backup cycles expire (backup retention: 30 days), except where Union or Member State law requires longer storage (e.g. bookkeeping records relating to Buildlr's own invoicing to the Customer). Before deletion, the Customer may export its data as set out in the Terms. On written request within the deletion window, Buildlr confirms deletion in writing.

Buildlr makes available the information reasonably necessary to demonstrate compliance with Article 28 (including summaries of security measures, sub-processor agreements and, when available, third-party audit reports or certifications). Where this is insufficient, the Customer may conduct an audit (itself or via an independent auditor bound by confidentiality) at most once per 12 months, on at least 30 days' notice, during business hours, without disrupting operations, at the Customer's cost. The frequency limit does not apply where an audit is required by a competent supervisory authority or is conducted following a personal data breach affecting Customer Data. Audit results are confidential.

The Service includes an AI assistant that processes Customer Data to produce suggestions, briefings and assisted actions, as a processing operation within the Service (Annex I). The LLM providers used are sub-processors listed in Annex III.

Buildlr: (a) contractually ensures with each LLM provider that Customer Data is not used to train any models; (b) on the primary route, enforces per-request and account-level restrictions with the routing provider that limit routing to endpoints with a zero-data-retention policy and to providers that do not collect inputs, and contractually requires the routing provider to honor these restrictions; (c) configures the routing so that, where no endpoint meeting these controls is available, the request fails rather than proceeding on a less-protective route; the alternative provider named in Annex III is a per-workspace routing option under equivalent no-training terms, not an automatic failover; (d) requires human confirmation in the product for AI actions with significant effect; and (e) records AI interactions in a tamper-evident per-workspace audit log available to the Customer.

Liability under this DPA is subject to the limitations of the Terms of Service, except where mandatory data-protection law provides otherwise. This DPA replaces any prior data-processing terms between the parties.

Categories of data subjects: the Customer's users (owners, admins, office staff, field workers); the Customer's own clients and prospective clients; the Customer's employees and subcontractors; suppliers' contact persons; individuals who contact the Customer via its lead forms or by email.

Categories of personal data: identification and contact data (names, emails, phone numbers, addresses); national tax or identity numbers where the Customer's market requires them for services such as tax-deduction schemes; employment-related data of the Customer's workers (role, trade, certifications, compensation, working time, absence, date of birth, nationality, emergency contacts); project and commercial data containing personal references (estimates, quotes, contracts, change orders, invoices, e-acceptance records including signer name, IP and timestamp); communications (messages, notes, inbound emails); media (photos and documents); location data (site addresses; worker GPS check-in data where the Customer enables time-tracking features); device and push identifiers.

Special categories: the Service is not designed for special-category data; free-text fields may incidentally contain such data entered by the Customer, who is responsible for its lawfulness.

Processing operations: hosting and storage; synchronization to the Customer's devices (offline-first replication); rendering and PDF generation; sending communications on the Customer's behalf (email, SMS, push); providing client-portal access on the Customer's behalf (portal accounts and invitations for the Customer's clients to view and respond to documents shared with them); AI-assisted analysis and drafting (section 11); backup and restore; deletion.

• Tenant isolation: every API operation derives the workspace identity from the authenticated token server-side; client-supplied workspace identifiers are ignored. Isolation is enforced at the query layer across all data stores.
• Encryption in transit: TLS for all client-server and server-to-sub-processor traffic.
• Credentials and tokens: passwords hashed with a modern adaptive algorithm (PBKDF2, 600,000 iterations, per-user salt); session, refresh and public document tokens stored only as cryptographic hashes, refresh tokens rotated with reuse detection; third-party integration credentials encrypted with AES-256-GCM.
• Device protection: sensitive fields encrypted at rest on end-user devices; the device encryption key is server-issued and deleted at logout.
• Access control: role-based access within workspaces; administrative operations separately logged; production infrastructure reachable only via a private network overlay with per-person device authorization.
• AI auditability: all AI interactions recorded in an append-only, hash-chained per-workspace audit log with integrity verification.
• Backups: nightly database backups stored in the EU, 30-day retention, tested restore procedures.
• Monitoring: error and availability monitoring (EU-hosted), with security-relevant event alerting.
• Personnel: confidentiality obligations for all personnel with access; least-privilege access to production; documented breach-response procedure.

The authorized sub-processors - with purposes, processing locations and transfer safeguards - are published on the sub-processor page, which forms this Annex and is updated as set out in section 5.

Service sub-processors (engaged for all customers): Hetzner Online GmbH (hosting, Germany), OpenRouter, Inc. and Anthropic (AI processing), Functional Software, Inc. (Sentry) (error monitoring), Twilio Inc. (SendGrid) (transactional email), CloudMailin (inbound email), Google LLC (Firebase Cloud Messaging) (push notifications) and Cloudflare, Inc. (bot protection).

Customer-connected integrations (engaged only on the Customer's own instruction, section 5): Fortnox AB and Intuit Inc. (QuickBooks) (accounting).

Providers that process personal data solely for Buildlr's own operations as controller (e.g. Stripe for Buildlr's billing of the Customer, Vonage for signup SMS verification) are not sub-processors of Customer Data; they are disclosed in the Privacy Policy.