Security & privacy

Overview

OneHQ is built for Australian accounting practices handling sensitive financial data — ABNs, TFNs, bank details, payroll records, and tax lodgement information. Security is built into every layer of the application, from infrastructure to application design.

All data is hosted in Australia. The platform is designed around the principle of least privilege — every user, integration, and system component has access only to what it needs, and nothing more.

Key security measures include:

• Australian-hosted infrastructure — all data stays onshore
• Row-Level Security — database-enforced practice isolation
• Encryption at rest and in transit — TLS/HTTPS everywhere
• Role-based access control — six configurable roles with granular permissions
• Immutable audit logging — 7-year retention
• OAuth 2.0 integrations — minimum required scopes, revocable at any time

Data hosting

All data is hosted on Australian infrastructure via Supabase (PostgreSQL). No data is processed offshore or routed through overseas data centres.

This includes:

• Client data — entities, contacts, ABNs, TFNs, financial records, jobs, billing
• Authentication data — user accounts, sessions, JWT tokens
• File metadata — document references, signing records, communication logs
• Audit trails — security logs, integration authorisation records

File storage (documents, signed PDFs) is managed through Dropbox, which provides its own enterprise-grade security and encryption. Your practice controls which Dropbox account is connected and can disconnect at any time.

Practice isolation

Every practice's data is completely isolated using Row-Level Security (RLS) in PostgreSQL. Practice A cannot see, query, or access Practice B's data — this is enforced at the database level, not just the application layer.

RLS policies are applied to every table in the database. Each query is automatically scoped to the authenticated user's practice using a current_practice_id() database function. This means:

• A user can only read rows belonging to their practice
• Queries that attempt to access another practice's data return zero results
• There is no application-level "filter" that could be bypassed — isolation is enforced by PostgreSQL itself

Authentication & access control

Supabase Auth handles authentication with email and password. Sessions use JWT tokens with automatic refresh, ensuring users stay authenticated without storing long-lived credentials in the browser.

Role-based access control

Every staff member is assigned one of six roles, each with configurable permissions:

• Admin — full access to all settings, integrations, and data
• Partner — full access to client and job data, limited settings
• Accountant — standard access to assigned clients and jobs
• Senior — standard access with review capabilities
• Staff — limited access to assigned work
• Bookkeeper — access scoped to bookkeeping-related functions

Permissions are configurable per role in Settings > Users & Permissions. Admins can customise what each role can see and do across the application.

Session management

Active sessions are tracked and can be reviewed by administrators. Sessions can be revoked to force a user to re-authenticate. Session tokens are automatically refreshed and expire after inactivity.

Invite-based onboarding

New staff members are added via invite links, ensuring only authorised people can join a practice. Invite tokens are single-use and hashed using SHA-256 before storage.

Encryption

Data is encrypted at rest and in transit:

• At rest — Supabase provides managed encryption for all stored data, including backups
• In transit — all connections use TLS/HTTPS. API calls between the frontend, backend, and external services are encrypted end-to-end

Sensitive fields such as Tax File Numbers (TFNs) are handled with additional care in accordance with the Privacy (Tax File Number) Rule 2015. OAuth tokens for integrations (Xero, Dropbox, Gmail, Microsoft) are stored encrypted and are never exposed to the frontend.

Audit logging

An immutable audit log records security-relevant actions across the practice. The audit_log table is practice-scoped and append-only — entries cannot be modified or deleted, even by administrators.

Logged actions include:

• User authentication events (login, logout, failed attempts)
• Permission changes and role assignments
• Integration connections and disconnections
• Data access and modification events
• Session management actions (revocation, expiry)

Audit logs are retained for 7 years per ATO DSP requirements, providing a complete trail for compliance reviews and security investigations.

AML/CTF compliance

OneHQ includes a built-in AML/CTF verification module for identity verification of clients and associated persons. This supports accounting practices in meeting their obligations under the Anti-Money Laundering and Counter-Terrorism Financing Act 2006.

The module supports:

• Primary and secondary ID verification — record and track identity documents for each person
• Customer Due Diligence (CDD) levels — standard, simplified, and enhanced due diligence workflows
• Sanctions checking — flag and record sanctions screening outcomes
• Reverification schedules — configurable reverification periods with automatic reminders
• Escalation workflows — route complex or high-risk verifications for senior review

AML/CTF settings are configurable per-practice in Settings > AML/CTF. You can enable or disable the module, configure designated services, set reverification periods, and choose whether to require secondary identification.

All AML/CTF actions are logged in a dedicated audit trail (aml_audit_log), separate from the general audit log, providing a complete record of verification activities for regulatory review.

Integration security

All integrations use OAuth 2.0 with the minimum required scopes. OneHQ never stores third-party passwords — only OAuth tokens, which can be revoked at any time.

Xero

Xero access is read-only. OneHQ requests only read-access scopes and never creates, modifies, or deletes any data in your Xero organisations. See the Xero integration guide for full details.

Dropbox

Dropbox is used for file storage and document management. OAuth access is scoped to your practice's connected Dropbox account. File operations (upload, download, rename, delete) are performed on behalf of the authenticated user.

Email providers (Gmail / Microsoft)

Email sending for campaigns uses OAuth 2.0 with Gmail or Microsoft Graph APIs. Only the minimum send-related scopes are requested. Email content is rendered server-side and sent directly via the provider's API.

ClickSend (SMS)

SMS sending uses ClickSend's API with practice-level credentials. Credentials are stored encrypted in the database and are configurable in Settings.

Token management

All OAuth tokens are stored encrypted in the oauth_tokens table, scoped to the practice. Tokens are automatically refreshed when they expire. You can revoke any integration at any time from Settings > Connections.

Integration authorisation events (connect, disconnect, token refresh) are logged in the integration_authorizations audit trail, providing a complete record of which staff member authorised each connection and when.

Frequently asked questions