Trust & Security

Built for Australian healthcare, secured for it too.

Patient data stays in Australia, encrypted on a per-practice basis, with the audit trail and breach response process you'd expect from a clinical system.

The essentials

Six things every practice manager and IT reviewer wants to know.

Australian-hosted

All patient data is stored and processed in AWS Sydney (ap-southeast-2). AI processing stays in-region.

Encrypted everywhere

Files are encrypted with per-practice master keys. Sensitive fields like Medicare numbers and IHIs are encrypted on top of that.

Practice-isolated

Every practice gets its own database. No shared rows, no shared sessions, no cross-practice leakage.

Strong sign-in

Passkeys, single sign-on, and 2FA. Practices can enforce 2FA or SSO across their team.

Australian compliance

Privacy Act, Australian Privacy Principles and the Notifiable Data Breaches scheme. SOC 2 on the roadmap.

Backed up daily

Automated, encrypted backups with a managed lifecycle and tested restoration process.

Where your data lives

Patient health information never leaves Australia. The only services that touch data outside Australia are billing and edge networking — and neither receives patient health information.

Service Data Region
Application & databases All patient data AWS Sydney
File storage & backups Clinical documents (encrypted) AWS Sydney
AI document processing Document text for classification & extraction AWS Bedrock, Sydney
Email, SMS, Fax Communication content Australian providers
Billing Practice account info only — no patient data Stripe (US)
DDoS & CDN In-memory only, not persistently stored Cloudflare (global edge)

How we protect your data

Three architectural choices that do most of the heavy lifting.

Encryption

Every file gets its own encryption key, and each practice has its own master key. Even if our raw storage were accessed, files cannot be read without those keys. Sensitive fields like Medicare numbers, IHIs and dates of birth are individually encrypted on top of that.

Tenant isolation

Every practice gets a dedicated PostgreSQL database. A security issue affecting one practice cannot expose another practice's data — that's an architectural guarantee, not a configuration choice. This level of isolation exceeds the industry norm for multi-tenant SaaS.

In transit

All connections use HTTPS with HSTS enforced for one year including subdomains. Database connections are encrypted. The platform is fronted by Cloudflare for DDoS protection and TLS termination at the edge.

Who can sign in — and how we know it's them

Authentication is configurable per practice, with sensible defaults and the option to enforce stronger requirements across your team.

  • Multiple sign-in methods. Passwords with TOTP 2FA, SAML SSO, and WebAuthn passkeys.
  • Practice-level enforcement. Require 2FA or SSO for everyone in your team.
  • Brute-force protection. Per-IP rate limiting and timing-attack mitigation on login.
  • Session fingerprinting. Hijack attempts are detected and sessions invalidated automatically.
  • Role-based permissions. Only people with the right role can see referrals, patient records, billing, or admin settings.
  • 365-day audit log. Logins, permission changes and policy enforcement events are recorded in your practice's database.

AI Processing

The AI question — answered plainly

We use AI to classify incoming documents, extract patient details, and summarise resolved conversation threads. Here's exactly how that works for your data:

In-region only

AI runs in AWS Bedrock, Sydney region. Patient data does not leave Australia for AI processing.

Not used to train models

The AI provider does not use your data to train models and does not retain it after processing.

Humans stay in the loop

AI output is presented for clinician or staff review. AI does not make clinical decisions.

Logged and auditable

Every AI call is logged in your practice's database, so you can see what was processed and when.

Compliance & frameworks

We're honest about what we have today and what's still on the roadmap.

Privacy Act 1988 (Cth) & APPs

Designed to support practice obligations under the Australian Privacy Principles.

Notifiable Data Breaches scheme

Documented breach response plan covering OAIC and tenant notification.

My Health Records & HI Acts

Relevant controls in place for handling Medicare numbers and IHIs.

ASD Essential Eight

Used as the security baseline for the platform's controls.

SOC 2 Type I

Controls in place across all five Trust Services Criteria. Formal certification on the roadmap.

ISO/IEC 27001:2022

ISMS aligned to Annex A controls. Certification a longer-term goal.

Sub-processors

The third parties that process data on behalf of practices using Clinically. We maintain a public register and review it regularly.

Sub-processor Service Data Location
AWSInfrastructure, AIAll patient dataAustralia
CloudflareDDoS, CDN, TLSHTTP data (transient)Global edge
SMTP2GOEmail relayEmail contentAustralia
NotifyreSMS & FaxPhone numbers, message contentAustralia
StripeBillingPractice billing data onlyUnited States
SlackError alertsSanitised error logsUnited States
HalaxyEMR syncPatient data (tenant-directed)Australia
GenieEMR syncPatient data (tenant-directed)Australia (local)
Services AustraliaMedicare / IHI verificationGovernment identifiers, demographicsAustralia

If something goes wrong

We don't pretend incidents never happen. We've documented exactly what we'll do if one does.

  • Documented Data Breach Response Plan aligned to the Notifiable Data Breaches scheme.
  • Maximum 30-day assessment window from when a suspected breach is identified.
  • Affected practices notified promptly so they can meet their own NDB obligations to patients.
  • OAIC notification where the eligible-data-breach threshold is met.
  • Annual tabletop exercise to test the plan and surface gaps.
  • Post-incident review with root-cause analysis and remediation tracking.

Reporting a vulnerability

Found something? Email security@clinically.com.au. We respond promptly, work on coordinated disclosure, and don't pursue legal action against good-faith security researchers.

Shared responsibility

Security is a partnership. Here's the line between what we own and what your practice owns.

Clinically is responsible for Your practice is responsible for
Platform infrastructure security Managing user accounts and permissions within your practice
Encryption of data at rest and in transit Enforcing appropriate security policies (2FA, SSO) for your users
Tenant isolation and access controls Training staff on appropriate use of the platform
Security monitoring and incident response Reporting suspected security incidents to us promptly
Backup and disaster recovery Maintaining your own privacy policy and patient consent processes
Vulnerability management and patching Reviewing and responding to data access requests from patients
Compliance with our security policies Configuring integrations (EMR sync, webhooks) appropriately

Documents

Our public security documents are available at policies.clinically.com.au. More detailed material is available on request, typically under NDA.

Public

On request

Email security@clinically.com.au.

  • Security Posture Document (under NDA)
  • Penetration test summaries
  • Insurance certificates
  • Custom security questionnaires (CAIQ, SIG, vendor-specific)
  • Data Processing Agreement template

Questions about our security?

We're happy to walk through our controls, complete your security questionnaire, or arrange a security briefing as part of your evaluation.

Last reviewed: May 2026 · Reviewed annually and after material changes.

Ready to streamline your referrals?

Start your 2-month free trial today. No commitment required.