Data Protection & Disaster Recovery

1. Overview

Bildr is committed to protecting the integrity, availability, and confidentiality of your project data. This document outlines our technical safeguards, backup procedures, disaster recovery capabilities, and data resilience commitments. It supplements our Privacy Policy and Terms of Service.

Bildr is operated by Bildr Labs Pty Ltd (ACN 696 230 350), registered in Australia. Our infrastructure is hosted on enterprise-grade cloud platforms with industry-standard security certifications.

2. Infrastructure & Hosting

Bildr's architecture is distributed across the following service providers:

All providers are SOC 2 Type II certified or equivalent. Data is encrypted in transit (TLS 1.2+) and at rest (AES-256) across all services. By using Bildr, you consent to your data being transferred to and processed in the United States by these providers, as detailed in our Privacy Policy.

3. Backup Procedures

Database backups: Our PostgreSQL database (hosted on Supabase) is backed up daily with automated snapshots. Backups are retained for 7 days, enabling restoration to the most recent daily snapshot in the event of data loss or corruption.

File storage backups: Uploaded documents (architectural plans, engineering reports, site photos) are stored in Supabase Storage with built-in redundancy. Files are replicated across multiple availability zones within the hosting region.

Application code: All source code is version-controlled in a private Git repository. Every deployment is immutable and can be rolled back to any previous version within minutes via the Vercel dashboard.

Payment data: Stripe maintains its own PCI DSS Level 1 certified infrastructure with independent backup and disaster recovery procedures. Bildr does not store credit card numbers, CVVs, or full payment credentials. Only Stripe customer IDs and subscription status are stored in our database.

4. Disaster Recovery

Our disaster recovery objectives are as follows:

Failure scenarios and response:

• —Database failure: Supabase provides automated failover with standby replicas. In the event of a primary database failure, traffic is automatically routed to the standby with minimal interruption. If a full restore is required, the most recent daily backup is used.
• —Application failure: Vercel deployments are immutable and distributed across a global edge network. If a deployment introduces a defect, the previous version is restored via one-click rollback. No user data is lost during a rollback.
• —Storage failure: Supabase Storage uses multi-availability-zone replication. File loss from a single zone failure is automatically recovered from replicas.
• —Third-party service outage (Anthropic, Stripe): AI features and payment processing degrade gracefully. Users retain full access to their existing project data during outages. A circuit breaker mechanism detects sustained API failures and returns immediate error responses rather than waiting for timeouts.
• —DNS/CDN failure: Vercel's edge network provides automatic DNS failover and CDN redundancy across multiple global points of presence.

5. Data Integrity & Security

Encryption: All data is encrypted in transit using TLS 1.2 or higher. Data at rest is encrypted using AES-256 encryption across all storage systems.

Authentication: User authentication is managed by Supabase Auth with bcrypt-hashed passwords. All API endpoints require valid authentication tokens. Service-to-service communication uses separate credentials that are never exposed to clients.

Row-Level Security (RLS): Our database enforces row-level security policies ensuring users can only access their own project data. Even in the event of an application-level vulnerability, the database layer prevents cross-user data access.

Rate limiting: All API endpoints are protected by distributed rate limiting (via Upstash Redis) to prevent abuse and protect against denial-of-service attacks. AI generation routes include spending caps to prevent runaway costs.

Error monitoring: Application errors are tracked in real-time via Sentry with source map support, enabling rapid identification and resolution of issues before they affect users at scale. Service availability is continuously monitored via a public health endpoint at /api/health.

Vulnerability management: Automated dependency scanning (via GitHub Dependabot) monitors all third-party packages for known vulnerabilities. A continuous integration pipeline runs lint, type-checking, and security audits on every code change.

6. Data Retention & Deletion

Our data retention policies are detailed in our Privacy Policy. In summary:

• —Active accounts: All project data is retained for the lifetime of the account and active subscription.
• —After cancellation: Data is retained for 90 days after subscription cancellation, then deleted from active systems. Residual copies in encrypted backups may persist until those backups are rotated in the ordinary course of operations (up to 7 days for daily backups).
• —Account deletion: Upon request, all user data is removed from active systems. This includes project data, uploaded files, conversation history, and authentication credentials. The deletion process follows a multi-step sequence — billing cancellation, database records (removed atomically in a single transaction), file storage cleanup, and finally authentication credentials — with safeguards to prevent data from being left in an inconsistent state.
• —Data export: Users may request a complete export of their project data at any time by emailing support@bildr.au. Exports are provided in standard formats within 7 business days.

7. Incident Response

In the event of a data breach or security incident, Bildr Labs will:

• —Investigate and contain the incident within 24 hours of detection
• —Notify affected users via email within 72 hours, as required under the Notifiable Data Breaches (NDB) scheme of the Privacy Act 1988 (Cth)
• —Notify the Office of the Australian Information Commissioner (OAIC) if the breach is likely to result in serious harm
• —Provide affected users with a clear description of the breach, the data involved, and recommended actions
• —Implement corrective measures to prevent recurrence

Security concerns can be reported to support@bildr.au.

8. Compliance

Bildr's data protection practices are designed to comply with:

• —Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs)
• —Notifiable Data Breaches (NDB) scheme — mandatory breach notification to the OAIC and affected individuals
• —Australian Spam Act 2003 — marketing emails are sent only with explicit opt-in consent
• —APP 8 (Cross-border disclosure) — we take reasonable steps to ensure overseas service providers handle personal information in accordance with the APPs

Our third-party service providers (Supabase, Vercel, Stripe, Anthropic) each maintain SOC 2 Type II certification or equivalent, and are contractually bound to maintain appropriate data protection standards.

9. Business Continuity

Bildr's architecture is designed to minimise single points of failure:

• —No single-server dependency: All compute is serverless (Vercel), database has automatic failover (Supabase), and caching is managed (Upstash Redis).
• —Immutable deployments: Every release is preserved and can be rolled back independently of the database or storage layers.
• —Graceful degradation: If AI services (Anthropic) are unavailable, users retain full access to all existing project data, budgets, timelines, and documents. Only AI-powered features (chat, generation) are temporarily unavailable.
• —Financial continuity: Stripe handles all payment processing and maintains its own business continuity and disaster recovery procedures independently of Bildr's infrastructure.

This document is reviewed and updated periodically. For questions about our data protection practices, contact support@bildr.au.

© 2026 BILDR LABS PTY LTD · ACN 696 230 350 · ABN 80 696 230 350