BuildOS product privacy

1. Who is responsible

The contracting entity and privacy contact have not yet been supplied. The customer decides which people and business information belong in its workspace, which administrators can access them, and which integrations or sharing links it enables. The signed agreement and any data-processing addendum must define the parties' roles, instructions, subprocessors and required transfer safeguards before commercial use.

2. Information processed in BuildOS

• Accounts and consent: names, email, password verifiers, company/contact details, membership roles, verification/recovery records and the document version accepted at registration.
• Workspace records: contacts, companies, deals, tasks, notes, tickets, messages, pipeline settings, reports, activity history and information entered into forms or shared estimates.
• Uploaded files: project documents, images, models, document templates and their metadata. The customer chooses their contents and recipients.
• Connected services: authorized mailbox content, CRM imports, accounting/signing identifiers and encrypted credentials or OAuth grants needed for enabled integrations.
• Security and diagnostics: session records, authenticator/passkey verification data, request identifiers, security events and sampled route-level performance aggregates. Hosting and network providers also process connection information needed to deliver and protect requests.

This information supports the agreed service, permission checks, requested provider actions, support, abuse prevention and recovery. Customers should minimize unnecessary personal or sensitive information and avoid putting secrets into ordinary records.

3. Hosting and optional processors

Optional providers receive information only through enabled workflows and their own terms. The separate published connected-email notice retains its existing effective date, contact and provider-specific commitments; this general product draft does not replace it. This list describes implemented service paths; approved subprocessor identity, location and international-transfer details must be completed in the customer agreement. BuildOS does not collect card details for its current free trial; a QuickBooks payment handoff opens the provider's payment page.

4. Access, sharing and protection

Authenticated requests use company membership and role permissions. Workspace administrators can grant access within their company. Public form, estimate and model links intentionally share the information defined by that workflow with anyone who holds a valid link. Treat those links as sensitive and revoke them when no longer needed.

Passwords are stored as verifiers. Integration secrets and Credential Vault entries use application-managed encryption; authorized infrastructure operators remain trusted. Credential Vault encryption is not end-to-end or zero-knowledge encryption. A passkey stores a public verification key in BuildOS; the private key remains with the authenticator. Encryption-key recovery copies must be secured separately from data backups.

Session cookies support sign-in and are not advertising cookies. Public HAT marketing measurements are described in the separate website policy. Product diagnostics must not intentionally include record bodies, credentials or private file contents. Security controls reduce risk but do not eliminate it.

5. Retention, export and deletion

The customer-data retention period, account closure process, backup retention, legal-hold handling and deletion timetable remain unfilled and must be approved before commercial use. Deactivation removes workspace access while retaining historical work. Archiving a record does not mean it has been permanently erased.

Specific product jobs have narrower technical lifetimes: performance aggregate queries/cleanup use seven days, and generated report exports expire after seven days. Cleanup can be delayed by a backlog; expiry is not an assurance of immediate physical deletion. Those policies do not define how long all customer records, hosting logs or backups are retained.

Authorized users can use available record/report exports. Those exports do not constitute a complete workspace backup. An owner should agree any additional export or deletion request with HAT through the approved support/privacy contact before closing service.

6. Requests, incidents and changes

Workspace users should first contact their company's authorized administrator for access and data corrections. Requests involving the service operator, account ownership, export or deletion need an identity-checked process. Do not send passwords, MFA codes, recovery links, provider tokens or private customer documents in an initial support message. Help and setup explains safe request details.

The privacy contact, rights-request process, breach-notification commitments, lawful processing grounds and applicable jurisdiction must be completed during legal review. The approved notice must identify its effective date and explain material changes. This draft makes no claim of a completed regulatory certification or independent security audit.

Contracting entity and country

Privacy contact

Effective date

Customer and backup retention

Request and incident process

Approved transfer safeguards