--- title: "Trust Center β€” Hanah (AU)" description: "Hanah Trust Center (Australia): patient records are stored in Australia, for Australian and New Zealand practices. Security and privacy controls, and service providers for the Australian deployment." source: https://hanah.health/au/trust/ --- # Trust Center Transparency for clinicians, practice owners, and institutional buyers. This page summarises how Hanah handles health information, which service providers are in scope for the production deployment, and how each security control relates to the **Privacy Act 1988** (Australian Privacy Principles). Status markers are a temporary editorial aid and will be removed once every item is production-verified. βœ… Done πŸ”§ Implemented bespoke Overview Controls Framework mapping Service providers Resources **Who this is for:** Clinics, health networks, privacy officers, and IT security teams doing due diligence on Hanah. **At a glance:** this Trust Center summarises Hanah's security controls and the service providers in scope for the production deployment. Clinical records are stored in . Speech recognition and AI drafting run with specialist providers outside the region, chiefly in the United States, under terms that prohibit training on your content. Deeper evidence sits in our Security & Operations Handbook; the **Controls** tab describes how each control is implemented. ### Security controls Encryption, access control, network segmentation, logging, backup/DR, and AI-specific safeguards β€” with an honest status per line. View controls β†’ ### HIPAA, GDPR, ISO and SOC 2 mapped to the APPs Each Australian Privacy Principle next to its HIPAA, GDPR, NZ, ISO/IEC 27001 and SOC 2 counterparts, and the Hanah control that meets it. View mapping β†’ ### Service providers Which categories of provider handle data, for what purpose, what they keep, and where they process it. View service providers β†’ ### Resources & next steps Service status and how to request full policy packs under NDA. View resources β†’[ ### Validation methodology How we measure transcription accuracy and documentation hallucination β€” one harness, one corpus, two evaluation layers (WER + LLM jury). The rules every published number is graded by. Read the methodology β†’](https://hanah.health/au/trust/wer-methodology/index.html)[ ### Validation transparency Per-recording transcripts, generated documents, and per-LLM juror verdicts against an authoritative ground-truth corpus. The full data, not just headline numbers. View report β†’](https://hanah.health/au/trust/transparency/index.html)[ ### Past results Every benchmark we have published, with the change against the run before it. Numbers are left exactly as they were measured on the day β€” including where the grading panel itself has since changed. Compare runs β†’](https://hanah.health/au/trust/benchmarks/index.html) Each row is a control in the usual ISO sense: **policy** (governance and documented procedure), **technical** (enforced by systems and configuration), or **vendor** (contractual and subprocessor assurance). Tags show the dominant evidence type; many rows combine more than one. Detail traces to our internal **Security & Operations Handbook**. The line under each row cites the Australian Privacy Principles that control supports β€” indicative only, not a substitute for legal advice. **Authority:** [_Privacy Act 1988_ (Cth)](https://www.oaic.gov.au/privacy/australian-privacy-principles), Schedule 1 (Australian Privacy Principles) and Part IIIC (Notifiable Data Breaches). Technical System and platform controls β€” infrastructure, application, cryptography, automation. Policy Organisation-level governance β€” accountability, signed policies, risk register, procedural evidence. Vendor Third-party reliance β€” DPA terms, subprocessor list, supplier certifications. ## Infrastructure & platform Infrastructure security Defines where Hanah runs for the regional deployment, how production is segmented from operations, and how encryption protects customer data between clinicians, our stack, and AI subprocessors. These are mostly technical controls with administrative backing in the Security & Operations Handbook. - βœ… Technical Policy **Region-resident production workloads** Primary application servers, databases, object storage, and backups for the deployment are located in-region. Administrative records describe regions and change approval; technical deployment pins resources to the regional project. **APP alignment:** APP 11.1 (security of personal information); APP 8 β€” holding records in Australia confines overseas disclosure to the processing listed under Service providers. - βœ… Technical **Encryption in transit** Public ingress uses modern TLS. Traffic to speech recognition and AI model providers uses TLS to each provider's configured endpoints. This is a technical control verified in architecture reviews and deployment config. **APP alignment:** APP 11.1 (protection from interference, misuse and unauthorised access). - βœ… Technical Policy **Encryption at rest** Databases, object storage, and backup objects use industry-standard algorithms (e.g. AES-256-GCM) with keys managed per our cryptography policy. WAL-G backups add client-side encryption before off-site storage. **APP alignment:** APP 11.1; APP 11.2 β€” encrypted backups stay protected until their scheduled destruction. - βœ… Technical Vendor **Edge DDoS protection and WAF** A managed edge layer fronts public hostnames, absorbing volumetric attacks and applying WAF rules for common web abuse. Provider-level protections and tight firewall posture remain in place behind the edge. **APP alignment:** APP 11.1 (protection from interference and loss). - βœ… Technical Policy **Intrusion detection** Layered detection: the hosting platform provides network-layer IDS, while each VM runs fail2ban (SSH brute-force prevention), UFW with default-deny posture, and unattended security upgrades. Authentication and access events from the auth-proxy are shipped to a central Loki/Grafana stack so anomalous login patterns surface in dashboards and alerts. Policies assign triage ownership when alerts fire. Kernel-level runtime IDS for containers is a planned enhancement on top of this baseline. **APP alignment:** APP 11.1; supports the 30-day assessment of a suspected eligible data breach under the Notifiable Data Breaches scheme (Part IIIC). ## Product & application Product security How users authenticate, how authorisation is enforced in the product and API layer, and how we build and ship software. Mixes technical enforcement (JWT, RBAC) with administrative SDLC and review requirements. - βœ… Technical Vendor **Authentication and sessions** Clinicians authenticate through a managed identity provider (OIDC/OAuth-style flows); every API path validates identity. Session lifetime and lockout behaviour align with our access-control policy. **APP alignment:** APP 11.1 (protection from unauthorised access). - βœ… Technical Policy **Role-based access control** Clinician, patient, and admin capabilities are separated in the data model and GraphQL layer so least-privilege is the default. Role definitions and review cadence are documented administratively. **APP alignment:** APP 11.1; APP 6 β€” access limited to people using the information for the purpose it was collected. - βœ… Technical Policy **Mandatory MFA for privileged paths** Mandatory MFA is enforced for accounts that can change security-sensitive settings or access high-risk data, via our identity provider. **APP alignment:** APP 11.1 (protection from unauthorised access). - βœ… Technical Policy **Secure development lifecycle** Changes flow through source control, review, and pinned dependencies. Security impact is considered for substantive features as an administrative gate; technical tools (Dependabot, etc.) support ongoing hygiene. **APP alignment:** APP 11.1; APP 1.2 (practices and systems that ensure compliance). - βœ… Technical Policy **Software bill of materials (SBOM)** Each release carries a machine-readable inventory of dependencies for vulnerability response. SBOM export is wired into CI as part of our supply-chain assurance programme. **APP alignment:** APP 11.1 (reasonable steps against interference through third-party code). ## Data & privacy Data & privacy Retention, deletion, subject rights, and visibility into security-relevant events. These controls pair automated enforcement in the product and database with administrative procedures (DSAR handling, breach notification, quarterly reporting). - βœ… Technical Policy **Retention and deletion for ambient artefacts** Audio and transcript material defaults to a short retention window with automated deletion; clinical notes follow each organisation’s retention policy. Once integrated with your record system, the authoritative clinical record remains yours. **APP alignment:** APP 11.2 (destroy or de-identify information no longer needed for any permitted purpose). - βœ… Technical Policy **Tamper-evident deletion log and quarterly reports** Retention-driven deletions are recorded in `deletion_log`, an append-only Postgres table with no `UPDATE` or `DELETE` grants to any role. Each row links to the previous one by SHA-256 hash chain (`row_hash = sha256(prev_hash β€– canonical(metadata))`), so altering or removing any earlier row breaks every subsequent hash and is detected by the in-database verifier `hanah_verify_deletion_chain()`. Companion audit tables (`ai_audit`, `secret_access_audit`) are also append-only. Quarterly customer-facing rollups are produced by `hanah_deletion_report_quarter(year, quarter)`. **APP alignment:** APP 11.2; APP 1.2 β€” evidence that destruction happened and has not been altered. - βœ… Policy Technical **Data subject access and correction** Individuals can request access to or correction of their personal information; Hanah documents timelines, formats (JSON + human-readable exports), and escalation paths. Tooling supports export where data lives in Hanah systems. **APP alignment:** APP 12 (access); APP 13 (correction). - πŸ”§ Technical Policy **Unified audit visibility** Security-relevant events (authentication, privilege use, configuration changes) are queryable for institutional customers and forwardable to your SIEM (for example Microsoft Sentinel) where contractually agreed. Configured per customer. **APP alignment:** APP 11.1; supports eligible-data-breach assessment and notification under Part IIIC. ## AI & clinical safety AI security & compliance Controls specific to ambient AI: no secondary use of health data for training, human oversight before clinical reliance, measurement of quality (WER), and abuse-resistant prompting. Combines contractual third-party controls with product workflow and clinical governance. - βœ… Vendor Policy Technical **No secondary use for model training** Our speech recognition and AI model providers' terms prohibit training on customer content, and requests are sent with provider-side storage switched off wherever the provider offers it. Hanah does not operate an internal training pipeline on your health data. Administrative vendor reviews support the claim. **APP alignment:** APP 6 (use and disclosure only for the primary purpose); APP 8 β€” overseas recipients are contractually bound not to train on or retain content beyond the terms shown under Service providers. - βœ… Policy Technical **Human-in-the-loop before clinical reliance** Generated notes require explicit clinician review and finalisation before they are treated as part of the clinical record. This is both a product control (workflow gates) and a policy commitment in the PIA. **APP alignment:** APP 10 (quality of personal information: accurate, up to date, complete and relevant). - βœ… Policy Technical **WER methodology and published cohort results** One harness, two evaluation layers, run on every grading pass: **Word Error Rate** against verbatim ground-truth transcripts (Layer A), and an **LLM jury panel** measuring both _coverage_ (does the note capture each pre-registered expectation?) and _hallucination_ (does the note contain claims the transcript does not support β€” i.e. content the model invented?). The [full methodology](https://hanah.health/au/trust/wer-methodology/index.html) is published, and [live results](https://hanah.health/au/trust/transparency/index.html) render directly from the harness's aggregate output. The corpus continues to graduate v1 (synthetic) β†’ v2 (role-play) β†’ v3 (real consent-based) β†’ v4 (joint with health-system partners). **APP alignment:** APP 10; APP 1.2 (demonstrable practices for accuracy). - βœ… Technical Policy **Prompt injection and unsafe-output monitoring** System prompts are server-controlled and inputs are bounded by the clinical workflow (no free-form chat surface). Provider safety classifiers run on every generation; when they trigger, the stream surfaces a content-filter finish reason that is captured in the per-call `ai_audit` row alongside a canonical `ai.content_policy` error code, latency, tokens, and a Tempo trace ID. Anomalous patterns surface in dashboards over that audit table. Cross-call behavioural anomaly detection for abuse patterns is a planned enhancement on top of this baseline. **APP alignment:** APP 11.1 (protection from misuse and interference). - βœ… Technical Policy **Multi-party consent capture in product** When the clinician clicks record, the product opens a consent dialog requiring explicit confirmation that consent has been obtained from the patient and any other participants in the session. Recording cannot begin until that check is acknowledged, and the confirmation is bound to the encounter alongside clinic policy referenced in the privacy impact assessment. **APP alignment:** APP 3.3 (consent to collection of sensitive information); APP 5 (notification of collection). ## Organisation & third parties Organisational security How Hanah the company governs security: accountability, policies, independent assurance, and integration with customer security tooling. These are primarily administrative controls; some have technical deliverables (e.g. SIEM connectors). - βœ… Policy **Security governance and risk register** A named executive is accountable for information security; risks are logged with owners and target dates and reviewed on a fixed cadence. This matches what buyers typically expect from an ISO-style management system, even at our current scale. **APP alignment:** APP 1.2 (practices, procedures and systems for compliance); APP 11.1. - βœ… Policy **Board-approved policy pack** Formal policies cover access, cryptography, incident response, vendors, and change management. The pack is board-approved and held under version control; full content is available under NDA. **APP alignment:** APP 1.2; APP 11.1. - πŸ”§ Policy Technical **Customer SIEM forwarding (e.g. Sentinel)** Security events from Hanah-controlled systems are forwarded into your Sentinel workspace (or equivalent) for joint monitoring where contractually agreed. Configured per institutional customer. **APP alignment:** APP 11.1; supports joint breach assessment under Part IIIC. Due-diligence questionnaires often arrive written against HIPAA, GDPR, ISO/IEC 27001 or SOC 2. In Australia, Hanah is governed by the Privacy Act 1988, so this table starts from each Australian Privacy Principle, lists the nearest provision in each of those frameworks, and names the Hanah control that meets it. Use it to translate a question into the principle that applies here. Equivalences are indicative and not legal advice. | Australian Privacy Principle | HIPAA (US) | GDPR / UK GDPR | NZ Privacy Act 2020 / HIPC 2020 | ISO/IEC 27001:2022 | SOC 2 (TSC 2017) | How Hanah meets it | | --- | --- | --- | --- | --- | --- | --- | | APP 1 β€” Open and transparent management | Β§164.520 notice of privacy practices; Β§164.530(a), (i) privacy official, policies and procedures | Art. 5(2) accountability; Art. 12–14 transparency; Art. 24, 30 | s 201 privacy officer; published privacy statement | Cl. 5.2 policy; A.5.1, A.5.34 | CC1.1–CC1.3; CC2.3; P1.1 | Named accountable executive, risk register, board-approved policy pack, and this Trust Center. | | APP 2 β€” Anonymity and pseudonymity | No direct equivalent; de-identification standard in Β§164.514(a)–(b) | Art. 25 data protection by design; Art. 4(5) pseudonymisation | No direct equivalent | A.8.11 data masking | No direct equivalent | Determined by the clinic, which decides whether a patient can deal with it anonymously or under a pseudonym. | | APP 3 β€” Collection of solicited information (sensitive information needs consent) | Β§164.502(b) minimum necessary | Art. 5(1)(b)–(c) purpose limitation and minimisation; Art. 6, 9 lawful basis for health data | IPP 1, 2, 4; HIPC Rules 1, 2, 4 | A.5.34 | P2.1 choice and consent; P3.1–P3.2 collection | Consent confirmation before every recording; collection limited to the encounter the clinician starts. | | APP 4 β€” Unsolicited information | No direct equivalent | Art. 5(1)(c) minimisation; Art. 5(1)(e) storage limitation | No direct equivalent | A.5.34 | P3.1 | Raw audio is deleted once the transcript is produced; transcripts follow the short default retention window. | | APP 5 β€” Notification of collection | Β§164.520 notice of privacy practices | Art. 13–14 information to be provided | IPP 3; HIPC Rule 3 | A.5.34 | P1.1 notice | In-product consent step; privacy policy names the countries where data is processed. | | APP 6 β€” Use or disclosure | Β§164.502(a), Β§164.506 permitted uses; Β§164.502(e), Β§164.504(e) business associate contracts | Art. 5(1)(b) purpose limitation; Art. 28 processor terms | IPP 10, 11; HIPC Rules 10, 11 | A.5.34; A.5.10 acceptable use | P4.1 use; P6.1 disclosure to third parties | Processing only on the clinic's instructions under the DPA; no secondary use and no model training. | | APP 7 β€” Direct marketing | Β§164.508(a)(3) marketing authorisation | Art. 21(2)–(3) right to object to direct marketing | No direct equivalent (Unsolicited Electronic Messages Act 2007) | No direct equivalent | P2.1 | Patient information is never used for marketing; patients hear from a clinic only when a clinician sends something. | | APP 8 β€” Cross-border disclosure | No geographic restriction; recipients bound through business associate contracts | Chapter V, Art. 44–49 international transfers (UK: IDTA or UK Addendum) | IPP 12; HIPC Rule 12 | A.5.19–A.5.22 supplier relationships | CC9.2 vendor risk; P6.4 | Records stored in Australia. Overseas processing is listed by country under Service providers, with contractual no-training and retention limits. | | APP 9 β€” Government-related identifiers | No direct equivalent | Art. 87 national identification numbers | IPP 13; HIPC Rule 13 unique identifiers | No direct equivalent | No direct equivalent | Hanah does not adopt Medicare numbers or other government identifiers as its own identifiers. | | APP 10 β€” Quality of personal information | Β§164.312(c) integrity | Art. 5(1)(d) accuracy | IPP 8; HIPC Rule 8 | A.5.34 | P7.1 quality | Clinician review before a note is finalised; published accuracy and hallucination measurement. | | APP 11.1 β€” Security of personal information | Security Rule Β§164.308, Β§164.310, Β§164.312 administrative, physical and technical safeguards | Art. 32 security of processing | IPP 5; HIPC Rule 5 | A.5.15, A.8.5 access and authentication; A.8.24 cryptography; A.8.13 backup; A.8.15–A.8.16 logging and monitoring | CC6 logical access; CC7 system operations; CC8 change management | Encryption in transit and at rest, role-based access, MFA for privileged paths, intrusion detection, encrypted backups. | | APP 11.2 β€” Destruction or de-identification | Β§164.310(d)(2)(i) disposal | Art. 5(1)(e) storage limitation; Art. 17 erasure | IPP 9; HIPC Rule 9 | A.8.10 information deletion | C1.2 disposal; P4.3 | Automated deletion of audio and transcripts, recorded in a tamper-evident deletion log. | | APP 12 β€” Access to personal information | Β§164.524 access | Art. 15 access; Art. 20 portability | IPP 6; HIPC Rule 6 | A.5.34 | P5.1 access | Exports in JSON and human-readable formats to support the clinic's response. | | APP 13 β€” Correction of personal information | Β§164.526 amendment | Art. 16 rectification | IPP 7; HIPC Rule 7 | A.5.34 | P5.2 correction | Clinicians edit and re-finalise notes; correction requests follow a documented procedure. | | Part IIIC β€” Notifiable Data Breaches scheme | Breach Notification Rule Β§164.400–414 | Art. 33–34 breach notification | Part 6 notifiable privacy breaches | A.5.24–A.5.27 incident management | CC7.3–CC7.5 incident response | Incident response policy, central security logging, and support for the clinic's 30-day assessment. | These are the categories of service provider that **may process or store Hanah customer data** in our production architecture, what each handles, what it keeps, and where it processes data. Every provider is bound by contract to protect customer data, and none may train models on it. Clinician sign-in uses global identity infrastructure that holds **no patient health information**. The same categories form Annex C of our [Data Processing Agreement](https://hanah.health/dpa/#annex-c). | Service category | Purpose | Data handled | Retention | Processing region | | --- | --- | --- | --- | --- | Operational transparency: a public **status** page (uptime and incidents) sits alongside the production `/healthz` readiness endpoint used by our own monitoring. [Service status](https://hanah.health/au/trust/status/index.html "Per-component health, 90-day uptime, and incident history for the AU deployment.") [Request full security pack under NDA](mailto:security@hanah.health?subject=Trust%20%2F%20security%20pack%20request) [Back to hanah.health](https://hanah.health/index.html) PhysiPal Pty Ltd (trading as Hanah) β€” . This Trust Center is a high-level summary. Contractual commitments, and data processing terms in force at signing supersede this page. Status emoji markers (βœ… πŸ”§) are temporary and will be removed after independent verification of each row.