BIQc.
Platform Meet BIQc Governance Integrations Pricing Trust Try for free Speak to Specialist
Trust Centre · Security

Security & Infrastructure

The technical controls protecting your data — encryption, access control, hosting, monitoring and incident response.

What this means for you
  • Stored data is encrypted by our hosting providers (AES-256), and data moving to and from BIQc is encrypted with TLS 1.2 or higher.
  • Access follows least privilege: people and systems can only reach what their role allows.
  • Administrator and billing actions are recorded in an audit log.
  • If an incident occurs, response begins within 72 hours of detection, and sooner for serious incidents. If your data is affected, we tell you within 72 hours of confirming it.

Infrastructure overview

BIQc's database, sign-in and file storage are hosted with Supabase in Sydney. The application, secrets vault and cache run in Microsoft Azure Australia East and Australia Southeast. AI model processing is performed by approved providers and can occur outside Australia, under the training restrictions disclosed in the AI Learning Guarantee. Other service providers that handle data outside Australia are named in the Privacy Policy.

Encryption

At rest

Stored data is encrypted at rest by our hosting providers (Supabase and Microsoft Azure) using AES-256. Credentials for the connectors BIQc builds itself are also encrypted by the application with AES-256-GCM.

In transit

Every public BIQc endpoint is HTTPS-only with TLS 1.2 as the minimum; TLS 1.0 and 1.1 are refused, and browsers are told to use HTTPS only (HSTS). BIQc's own calls to its service providers also use HTTPS.

Access controls

  • Role-based access control (RBAC) with the least-privilege principle.
  • Every request is checked on the server against the caller's account and role; database row-level security adds a second layer.
  • Administrative access restrictions for privileged operations.
  • Administrator and billing actions are recorded in an audit log.

Hosting and network

  • Public endpoints are protected by Microsoft Azure's built-in, platform-level DDoS infrastructure protection.
  • Microsoft Defender for Cloud monitors the Azure subscription, App Service and Key Vault and raises security alerts.
  • Production and test environments use separate databases, secrets and keys.

Monitoring & incident response

  • Azure Monitor alerts on outages, error rates, configuration changes and secret-vault changes are emailed to the Security & Privacy Officer, and application errors are reported through error monitoring.
  • Incident response initiated within 72 hours of detection, and sooner for serious incidents.
  • If a customer's data is affected, we notify the account Owner without undue delay and within 72 hours of confirming it.
  • Eligible data breaches are reported to the Office of the Australian Information Commissioner and affected individuals under the Notifiable Data Breaches scheme.
  • Post-incident review and remediation.

Compliance

  • Privacy Act 1988 (Cth) compliance and Australian Privacy Principles adherence.
  • SOC 2 Type II: not yet started (see the Trust Centre hub for current status).

Reporting a vulnerability

If you believe you've found a security issue, email security@biqc.ai with a subject line starting "Security disclosure". We acknowledge reports within 2 business days and confirm the severity within 5 business days. Our Vulnerability Disclosure Policy explains what to include, what is in scope, our fix timelines, and the safe-harbour terms for good-faith research.

Version 2 Effective: November 2026 Last reviewed: November 2026 Contact: security@biqc.ai