This policy defines the encryption standards and practices used by XBert Pty Ltd to protect data at rest, in transit, and during processing. It ensures the confidentiality and integrity of customer financial data and personal information across all XBert systems.
This policy covers all data handled by XBert systems, classified per the XBert data classification scheme:
| Classification | Examples | Encryption Requirement |
|---|
| Confidential | Customer financial records, bank transactions, payroll data | Encrypted at rest (AES-256), in transit (TLS 1.3), tenant-isolated |
| Internal | User profiles, tenant configurations, audit logs | Encrypted at rest and in transit, role-based access |
| Public | Marketing content, help documentation | Standard web hosting security |
This includes:
- Customer accounting and financial data (Confidential)
- User identity and authentication data (Internal)
- Application secrets, keys, and certificates (Confidential)
- Backup and disaster recovery data (inherits source classification)
- Data transmitted to and from third-party services (encrypted per standards below)
- Internal communications and operational data (Internal)
| Protection Layer | Standard | Implementation |
|---|
| Data in transit (external) | TLS 1.3, 256-bit | SSL certificates on all public endpoints |
| Data in transit (internal) | TLS 1.2+ | Azure service-to-service encryption |
| Data at rest (databases) | AES-256 | Azure SQL Transparent Data Encryption (TDE) |
| Data at rest (storage) | AES-256 | Azure Storage Service Encryption (SSE) |
| Data at rest (backups) | AES-256 | Azure-managed encryption for all backup stores |
| Secrets and keys | RSA-2048+ / AES-256 | Azure Key Vault |
| Password hashing | bcrypt | Via Auth0 identity provider |
- All client-facing endpoints enforce TLS 1.3 with 256-bit encryption
- SSL certificates are managed and auto-renewed via Azure App Service
- SSL scanning tools are used to verify that only current recommended cipher suites are active
- HTTP Strict Transport Security (HSTS) headers are enforced
- Legacy protocols (TLS 1.0, TLS 1.1, SSL 3.0) are disabled
- All Azure PaaS service-to-service communication uses TLS 1.2 or higher
- Azure Virtual Network service endpoints are used where available to keep traffic within the Azure backbone
- API calls between XBert microservices (App Service, Functions, SQL) are encrypted in transit
| Integration | Protocol | Notes |
|---|
| Xero API | OAuth 2.0 over TLS 1.2+ | Read/write accounting data |
| QuickBooks API | OAuth 2.0 over TLS 1.2+ | Read/write accounting data |
| MYOB API | OAuth 2.0 over TLS 1.2+ | Read/write accounting data |
| FreeAgent API | OAuth 2.0 over TLS 1.2+ | Read/write accounting data |
| Xero Payroll API | OAuth 2.0 over TLS 1.2+ | Payroll data (Australia and New Zealand) |
| Employment Hero API | API over TLS 1.2+ | Payroll and HR data integration |
| XPM API | OAuth 2.0 over TLS 1.2+ | Practice management data |
| Auth0 | TLS 1.2+ | Identity and authentication |
| Chargebee | TLS 1.2+ | Subscription management |
| Stripe | TLS 1.2+ | Payment processing (PCI-DSS Level 1) |
| OpenAI API | TLS 1.2+ | AI processing (ephemeral, per DPA) |
| Anthropic Claude API | TLS 1.2+ | AI processing (ephemeral, per DPA) |
- Azure SQL Database: Transparent Data Encryption (TDE) enabled on all databases
- Encryption algorithm: AES-256
- Key management: Azure-managed service keys (with migration path to customer-managed keys via Azure Key Vault in progress)
- Applies to: data files, log files, and temp databases
- Azure Blob Storage: Storage Service Encryption (SSE) enabled
- Encryption algorithm: AES-256
- Applies to all blobs, queues, tables, and files
- Includes backup storage and log archives
- All Azure SQL backups (PITR and long-term retention) inherit TDE encryption
- Azure Blob Storage backups are encrypted via SSE
- Geo-replicated copies maintain the same encryption standard
- All application secrets, connection strings, API keys, and certificates are stored in Azure Key Vault
- Access to Key Vault is controlled via Azure Entra ID (formerly Azure AD) with RBAC
- Key Vault access requires MFA and is restricted by Conditional Access policies
| Key Type | Rotation Frequency | Method |
|---|
| SSL/TLS certificates | Auto-renewed before expiry | Azure App Service managed |
| Application secrets | Annually or on compromise | Manual rotation via Key Vault |
| Database encryption keys | Azure-managed rotation | Automatic (TDE service-managed) |
| OAuth client secrets | Annually | Manual rotation with zero-downtime deployment |
| Auth0 signing keys | Per Auth0 rotation schedule | Auth0 managed |
- Principle of least privilege applied to all key access
- Key Vault access logged and auditable via Azure Monitor
- Emergency access procedures documented for key recovery scenarios
- No encryption keys are stored in source code, configuration files, or environment variables outside of Key Vault
- User passwords are never stored by XBert directly
- Auth0 handles password storage using bcrypt hashing with salt
- OAuth 2.0 tokens are used for session management (JWT with RS256 signing)
- Credit card details are never stored by XBert - transmitted directly to PCI-DSS Level 1 compliant providers (Chargebee/Stripe) over TLS
- Financial data sent to OpenAI API and Anthropic Claude API for AI processing is transmitted over TLS 1.2+
- Data is ephemeral and not persisted by AI providers per their respective Data Processing Agreements
- AI memory data (Mem0 service) is encrypted at rest in Azure Container Apps storage
- No customer financial data is used for AI model training
- Storing encryption keys alongside encrypted data
- Using deprecated algorithms (DES, 3DES, MD5, SHA-1 for security purposes, RC4)
- Disabling TDE or SSE on any production data store
- Transmitting sensitive data over unencrypted channels
- Hard-coding secrets or keys in application source code
- Storing customer data on local developer machines without encryption
This policy supports compliance with:
- Privacy Act 1988 (Cth) - APP 11 (security of personal information)
- PCI-DSS requirements (via compliant payment providers)
- GDPR Article 32 (security of processing) where applicable
- ISO 27001 Annex A.10 (cryptography)
- Azure compliance certifications (ISO 20000-1:2011, CSA STAR)
- SSL scanning tools continuously verify cipher suite compliance on public endpoints
- Azure Security Centre monitors encryption posture across all resources
- Key Vault access is logged and reviewed as part of security monitoring
- Non-compliant resources are flagged and remediated within 48 hours
| Version | Date | Changes |
|---|
| 1.0 | April 2026 | Initial creation |
