Enterprise Privacy and Compliance Framework

Last Updated: 23.12.25

Table of content

Introduction

This Enterprise Privacy and Compliance Framework supplements the Global Privacy Policy of BlueNexus Tech Pty Ltd (“we”, “us”, “our”) and provides detailed regulatory compliance information for enterprise customers, developers, partners, and auditors.

It is intended to support due diligence, security reviews, and regulatory assessments across jurisdictions in which the BlueNexus Platform operates.

Clarification on “We”, “Us”, and Platform Access

References in this Framework to “we”, “us”, “our”, or “BlueNexus” refer to BlueNexus as a legal entity and its personnel (including employees, contractors, and administrators). They do not refer to automated processing performed by the BlueNexus platform or systems where such processing occurs without human access to decrypted data.

While the platform may technically encrypt, decrypt, or process data as required to provide the services (including within secure compute or confidential processing environments), BlueNexus personnel do not have access to decrypted customer or end user content, or encryption keys, except where such access is explicitly provided by the customer or user for support, debugging, compliance, or lawful purposes.

For the avoidance of doubt, automated processing by the platform constitutes “processing” under applicable data protection laws, but does not imply human access to personal data.

It includes:

  1. Data Sovereignty Principles
  2. ANNEX A - GDPR & UK GDPR Compliance
  3. ANNEX B - CCPA/CPRA Compliance
  4. ANNEX C - Australian Privacy Act Compliance
  5. ANNEX D - U.S. State Privacy Laws
  6. ANNEX E - International Data Transfers
  7. ANNEX F - Subprocessor Annex
  8. ANNEX G - HIPAA Disclaimer
  9. ANNEX H - Definitions & Roles
  10. ANNEX I - Technical Architecture Overview
  11. Jurisdiction / Governing Law Disclaimer

This Enterprise Privacy and Compliance Framework forms part of the contractual documentation between Bluenexus Tech Pty Ltd and the enterprise customer and should be read together with:

  • the Enterprise Agreement
  • the Data Processing Agreement (DPA)
  • the Developer Terms
  • the Global Privacy Policy

DATA SOVEREIGNTY PRINCIPLES

We design the Platform around the concept of data sovereignty-providing users and developers control over how their data is stored, processed, encrypted, and routed. These principles describe the operational approach underlying the Services and inform the structure of our privacy practices.

1. User-Controlled Encryption & Permissions

Certain features of the Platform allow users to create non-custodial, user-controlled environments. Users control:

  • encryption and decryption keys

  • access permissions granted to applications

  • deletion, region, and routing preferences

  • compute mode (TEE or non-TEE)

We cannot decrypt content stored in or processed by these environments.

2. Developer-Controlled Routing & Processing

Developers integrating the Platform may route data through the Services to support application functionality. Developers are responsible for:

  • selecting processing regions

  • defining data flows

  • ensuring lawful bases and user notices

  • retaining, modifying, or deleting data in accordance with their obligations

We process developer-routed data solely on documented instructions as their Processor.

3. Confidential Compute & Zero-Access Design

For certain supported workloads, where data is processed inside Trusted Execution Environments (TEEs), the Platform may rely on trusted third-party hardware and software vendors. These hardware-backed secure enclaves are designed to provide:

  • encrypted-in-use processing

  • memory isolation

  • hardware attestation

  • operator isolation

This architecture is designed to prevent BlueNexus personnel from accessing decrypted enclave content, while allowing automated processing by the Platform solely for the purpose of providing the Services. 

4. Region Selection & Data Localisation

Where supported, users and developers may select preferred regions for:

  • data routing

  • storage

  • compute operations

The Platform enforces these selections and does not redirect data to other regions unless required to maintain security or performance and only where permitted by contract.

ANNEX A - GDPR & UK GDPR COMPLIANCE

1. Roles Under GDPR / UK GDPR

1.1 Controller / Processor

Depending on the processing context:

  • Developer-Managed Data

    • The developer is the Data Controller
    • We are the Data Processor
    • Governed by the DPA

  • Sovereign or User-Controlled Accounts

    • The user is the Controller
    • We do not act as a Controller or Processor
    • Content stored in user-controlled environments (e.g., vaults, confidential compute) is encrypted and inaccessible to us

  • Operational Account & Platform Data

    • We act as Controller
    • For authentication, fraud detection, platform security, billing, etc.

1.2 Joint Controllers

We do not become a Joint Controller unless explictly agreed in writing.

2. Lawful Bases for Processing (Article 6)

When we are a Controller, processing is based on:

Processing Activity Purpose Lawful Basis
Account creation and authentication Access to Services Article 6(1)(b) - Contract
Security logs and fraud detection Platform integrity Article 6(1)(f) - Legitimate Interests
Support communications Responding to inquiries Article 6(1)(b) or (a)
Website analytics Improve performance Article 6(1)(f)
Compliance obligations AML/CTF, tax, legal duties Article 6(1)(c)

When we are the Processor, the Development/Enterprise Customer determines the lawful basis. 

3. Special Category Data (Articles 9 & 10)

  • We do not determine the lawful basis for processing special category data.
  • If developers or enterprise customers route or submit health, biometric, or other sensitive data, they must supply an Article 9 lawful basis.
  • Processing of such data typically occurs inside secure environments such as TEEs (Trusted Execution Environments).

4. Data Subject Rights (Articles 12-23)

Sovereign / User-Controlled Accounts

Rights are exercised directly through the user’s dashboard or authorized applications that act on their behalf.

Developer-Managed Data

Data subjects must contact the Controller (developer or enterprise customer).

We will assist under DPA Art. 28(3)(e).

When we are Controller

Requests may be submitted to: legal@bluenexus.ai

Response periods follow:

  • GDPR: 1 month
  • UK GDPR: 1 month

5. International Transfers (Chapter V)

We use: 

  • EU Standard Contractual Clauses (SCCs) Modules 2 & 3
  • UK GDPR Addendum
  • Additional technical and organisational safeguards, including:

    • encryption in transit, at rest, and in use
    • confidential compute (TEE) isolation
    • hardware-backed attestation
    • role-based access controls
    • verified machine identities
    • zero-access design (no ability to read decrypted enclave memory)

If an EU/UK representative is required under Article 27, We will appoint one and update this Annex.

6. Processor Commitments (Article 28)

We shall:

  • process data only on documented instructions
  • maintain confidentiality
  • implement Art. 32 security measures
  • assist with rights requests and DPIAs
  • return or delete data upon termination
  • maintain records of processing
  • permit audits as agreed
  • engage subprocessors only with authorisation

7. Supervisory Authorities

  • EU Supervisory Authority: determined by Controller
  • UK ICO: https://ico.org.uk

ANNEX B - CALIFORNIA CCPA / CPRA COMPLIANCE

1. Notice at Collection

We may collect:

  • identifiers (email, device metadata)
  • commercial information (billing data)
  • internet or network activit
  • geolocation (approximate)
  • developer-submitted data (only if routed)

We do not: 

  • sell personal information
  • share personal information for cross-context behavioural advertising
  • use sensitive personal information beyond essential services

2. California Consumer Rights

Consumers may have rights to:

  • know
  • delete
  • correct
  • opt out of sale/sharing (not applicable but mechanisms offered)
  • data portability
  • limit use of sensitive personal information (not applicable)
  • non-discrimination

Requests: legal@bluenexus.ai

3. Appeals Process

If a request is denied, users may appeal by submitting an email referencing the decision. We will respond within required timelines.

ANNEX C - AUSTRALIAN PRIVACY ACT (APPs)

This Annex outlines compliance with the Australian Privacy Principles (APPs).

APP 1 - Open & Transparent Management

We maintain internal governance and data handling policies.

APP 2 - Anonymity & Pseudonymity

Anonymous browsing permitted; identification required for account creation.

APP 3 - Collection

Personal information collected only where reasonably necessary.

APP 4 - Unsolicited Information

Deleted when not required.

APP 5 - Notification

Users are informed of:

  • our identity/contact details
  • purposes of collection
  • consequences if data is not provided
  • disclosures to subprocessors
  • cross-border transfers (regions listed)

APP 6 - Use & Disclosure

Used only for the primary purpose or as permitted by law.

APP 7 - Direct Marketing

No direct marketing without consent.

APP 8 - Cross-Border Disclosure

Reasonable steps taken to ensure overseas recipients handle data appropriately.

APP 11 - Security

Technical and organisational measures used, including TEE-based confidential compute.

APP 12-13 - Access & Correction

Users may request access or correction by contacting us. 

ANNEX D - U.S. STATE PRIVACY LAWS

1. Rights Provided

Residents may exercise rights to:

  • access
  • correction
  • deletion
  • portability
  • opt out of targeted advertising / sales / profiling

We do not engage in targeted advertising or selling without explicit consent from users.

2. Sensitive Data

If developers route sensitive data, they must obtain affirmative consent.

3. Appeals

Denied requests may be appealed within the statutory timeframe.

4. Processor Duties

Where we act as Processor:

  • follow controller instructions
  • implement safeguards
  • permit audits
  • disclose subprocessors

ANNEX E - INTERNATIONAL DATA TRANSFERS

1. Regions of Processing

Processing may occur in:

  • Australia
  • United States
  • European Union
  • United Kingdom
  • Regions selected by users or developers

We do not process or store data in geographic regions other than those explicitly selected or authorised by the user or developer. 

2. Transfer Safeguards

Where required:

  • SCCs (Modules 2 & 3)
  • UK Addendum
  • Encryption at rest, in transit, and in use
  • TEE-based confidential compute to minimise transfer risk
  • Zero-access data architecture
  • Transfer risk assessments (TRAs / TIAs) where applicable

3. Data Localisation Support

If specific customers require data residency restrictions, we can restrict regions at the customer’s direction (subject to availability).

ANNEX F - SUBPROCESSOR ANNEX

We use the following categories of subprocessors:

1. Infrastructure & Compute Providers

  • Cloud hosting
  • Confidential compute / enclave providers
  • Load balancing and routing

2. Authentication & Security Providers

  • Identity verification
  • Fraud prevention
  • Abuse detection

3. Observability & Monitoring

  • System availability monitoring
  • Performance monitoring
  • Security event logging

4. Payments

  • Payment gateways
  • Subscription management tools

5. Communications

  • Email delivery
  • Customer messaging tools

A public list of subprocessors is available on the https://bluenexus.ai/.

Enterprise customers will receive prior notice of material changes in accordance with the DPA.

ANNEX G - HIPAA DISCLAIMER

Some developers or enterprise customers may route health or medical information through the Services.

The Platform is designed to support HIPAA-compliant deployments. However, BlueNexus does not act as a Business Associate under HIPAA unless a separate, written Business Associate Agreement (BAA) is agreed between the parties.

By default, the Services are not provided on a HIPAA-compliant basis unless explicitly agreed in writing.

Developers and customers are responsible for obtaining any required consents,authorisations, or approvals in respect of health-related data they process using the Services.

ANNEX H - DEFINITIONS & ROLES

Personal Information” / “Personal Data”: Information relating to an identified or identifiable individual.

Developer” / “Controller”: Entity determining the purpose and means of data processing.

Processor”: Entity processing personal information on behalf of a Controller.

“Sovereign Account / User-Controlled Account”: Non-custodial account where the user controls access keys, encryption keys and permissions.

Confidential Compute / TEE”: Hardware-backed secure environment providing encrypted-in-use processing.

Subprocessor”: Third party engaged by us to support service functionality.

ANNEX I - TECHNICAL ARCHITECTURE OVERVIEW

This section provides a high-level technical overview of the Platform. It is intended for compliance teams, auditors, and enterprise customers evaluating the security and data protection capabilities of the Services.

1. Confidential Compute (Trusted Execution Environments - TEEs)

The Platform supports processing within Trusted Execution Environments (TEEs), which provide:

  • Encrypted-in-use processing - data is decrypted only within CPU/GPU-level secure enclaves
  • Hardware-backed isolation - OS, hypervisor, and operator isolation
  • Remote attestation - verifying enclave integrity
  • Tamper resistance - detection of attempts to inspect or alter enclave memory

We cannot view, modify, or extract data processed inside TEEs.

2. Encrypted Storage & Routing Layers

All data handled by the Services is protected with:

  • encryption in transit (TLS)
  • encryption at rest
  • encryption-in-use (for enclave-supported workloads)

Routing metadata may be collected to maintain availability, performance and security, but decrypted content is never logged.

3. Machine Identity & Attestation

The Platform uses:

  • hardware-attested identities
  • verified compute nodes
  • isolated hardware-backed workloads
  • region-bound execution constraints

These controls restrict workloads to authorised environments only.

4. Zero-Access Operational Model

The technical architecture is designed to ensure we cannot access decrypted user or developer content, through:

  • restricted operator privileges
  • isolated runtime environments
  • strict RBAC on system metadata
  • no access to decrypted TEEs
  • no logging of decrypted data

This model supports compliance with GDPR recommendations on supplementary measures, including EDPB Recommendations 01/2020.

5. Supported Processing Modes

Developers and enterprise customers may be able to choose:

  • TEE mode
  • Non-TEE mode
  • Developer-hosted or hybrid compute
  • Region-specific routing

Details vary by product configuration and customer contract.

JURISDICTION / GOVERNING LAW DISCLAIMER

This Enterprise Privacy and Compliance Framework and the Global Privacy Policy do not establish governing law, forum, or venue for disputes.

Jurisdiction, venue, and dispute resolution procedures are governed solely by the Enterprise Agreement, Terms of Service, or other applicable contractual documents between the parties.