Security overview
This page summarises the technical and operational controls Clinically applies to protect personal information held on the platform, in support of the reasonable-steps obligation under APP 11 of the Privacy Act 1988 (Cth). It is the practical companion to the Privacy Policy and the sub-processor disclosure.
In transit
TLS forced for one year
HTTP Strict Transport Security with a one-year max-age and includeSubDomains, so browsers refuse plain-text fallbacks across the entire aob.clinically.com.au domain.
No referrer leakage
The patient consent page sends no referrer to any external site. Practice-side identifiers that sit in the URL fragment cannot leak through outbound clicks.
Non-cacheable consent page
Cache-Control: no-store on the consent page so it is never cached at the edge, in browsers, or in proxy infrastructure between us and the patient.
No identifiers in the load request
When the patient opens the consent link, their given name, surname, URN and date sit in the URL fragment (the part after the # symbol). HTTP clients never transmit the fragment, so our servers learn nothing about the patient when they open the page. We only receive identifiers when the patient submits a signed consent — at which point they are sent over the TLS-encrypted connection above and stored in our encrypted database, accessible only to the patient's practice. See the Privacy Policy for a plain-English explanation of this design.
At rest
Managed encryption at rest
Personal information is held in a managed, encrypted database located in an Australian region. Block-level encryption is provided by the managed platform; key management is handled by the platform vendor.
Per-practice data isolation
Each practice's data is locked to its members at the storage layer. Staff from one practice cannot reach another practice's records, providers, services, or branding.
One administrator per practice
Only one administrator account can be linked to a practice. A single account cannot pivot across multiple practices' data.
DOB never in the link
Date of birth is deliberately never carried in the SMS or email link. The patient enters it on the consent screen so it cannot leak through a forwarded link or device history.
Authentication and access
Passwordless sign-in
Practice administrators sign in via a one-tap email link. There are no passwords to phish, leak, or reuse.
Need-to-know support access
Clinically support staff may access a practice's records only on a strict need-to-know basis to diagnose a reported fault. Every access is audit-logged.
No patient mobile collection
We never collect or hold the patient's mobile number. The practice sends the link from its own messaging system to a number it has already validated against the patient record.
Application hardening
Per-IP rate limiting
Public endpoints, including the patient submit endpoint, are throttled per source IP so an attacker cannot script-submit a flood of fake consents.
Server-side sanitisation
Practice-supplied branding (logo, favicon, colour) is filtered on our servers before storage to block stored cross-site scripting via tampered images or links.
No third-party framing
X-Frame-Options: SAMEORIGIN and frame-ancestors 'self' prevent the consent page or dashboard from being embedded in third-party iframes (clickjacking protection).
No MIME sniffing
X-Content-Type-Options: nosniff prevents browsers from reinterpreting responses as a different content type.
Permissions policy
Camera, microphone, and geolocation are disabled at the browser level on every page.
Content Security Policy
Restricts where the page can submit forms, the base URI it can resolve relative URLs against, and forces every subresource onto HTTPS.
Per-consent audit trail
Tamper-evident fingerprint
Each signed consent records a cryptographic fingerprint of exactly what the patient was shown — so any later tampering with the stored record is detectable.
Timestamps and device metadata
The moment the link was opened, the moment the patient signed, the source IP address, and the browser identifier (user agent) are all recorded against the signed consent.
Service-date binding
Each consent is bound to a specific service date and item list at the moment of signing — a signed consent cannot be retroactively reused for a different service.
Operational practices
Database advisor sweeps
Security advisor checks run after every schema migration. Any ERROR-level finding is resolved before the migration is considered complete.
NDB-scheme runbook
A documented response runbook covers detection sources, severity assessment, the 30-day clock under Part IIIC of the Privacy Act, and notification to affected practices within 72 hours of confirmation of an eligible data breach.
Sub-processor evaluation
New sub-processors are subject to Data Processing Addendum review, country-of-processing checks, and independent security attestations where they touch personal information.
Vendor secret hygiene
Cron-triggered endpoints are protected by a shared internal secret. Production secrets are rotated on schedule and on demand if a compromise is suspected.
What we have not yet implemented
In the interest of transparency, the following controls are on our roadmap but not yet live. They are not required for our current compliance posture, but represent further hardening we are working towards:
- Column-level encryption of the most sensitive patient identifiers, behind a separately-held key — strengthens at-rest protection beyond managed disk encryption.
- Automated retention sweeper that destroys consent records past the practice's configured retention window (default 7 years, regulatory minimum 2 years).
Contact
Security questions, vulnerability reports, or requests for further detail on any of the controls above: security@clinically.com.au.