--- title: "Trust Center β€” Hanah (NZ)" description: "Hanah Trust Center (New Zealand): security and privacy controls with Privacy Act 2020 and HIPC 2020 alignment, subprocessors, and live model disclosure for healthcare customers and partners." source: https://hanah.health/nz/trust/ --- # Trust Center Transparency for clinicians, practice owners, and institutional buyers. This page summarises how Hanah handles health information, which subprocessors are in scope for NZ production, and how each security control relates to the **Privacy Act 2020** (Information Privacy Principles) and the **Health Information Privacy Code 2020** (HIPC) where health information is involved. Status markers are a temporary editorial aid and will be removed once every item is production-verified. βœ… Done πŸ”§ Implemented bespoke Overview Controls Subprocessors Resources **Who this is for:** Clinics, health networks, privacy officers, and IT security teams doing due diligence on Hanah. **At a glance:** for New Zealand deployments, patient health information at rest is hosted in **New Zealand** (Catalyst Cloud). Speech and LLM inference use Microsoft Azure and Google Cloud Vertex in **Sydney, Australia**, under enterprise terms that prohibit training on your content. Deeper evidence sits in our Security & Operations Handbook; the **Controls** tab cites how each line aligns with the Privacy Act 2020 (IPPs) and HIPC 2020. ### Security controls Encryption, access control, network segmentation, logging, backup/DR, and AI-specific safeguards β€” with an honest status per line. View controls β†’ ### NZ privacy law on each control Every control row names the relevant **Privacy Act 2020** Information Privacy Principles (IPPs) and **HIPC 2020** rules for health information β€” plain pointers for privacy officers, not legal advice. View controls β†’ ### Subprocessors Who touches data, for what purpose, in which region, and what attestations we rely on. View subprocessors β†’ ### Resources & next steps Service status, how to request full policy packs under NDA, and model disclosure (API). 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/nz/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/nz/trust/transparency/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 how that control supports named items in New Zealand privacy law β€” indicative only, not a substitute for legal advice. **Authorities:** [_Privacy Act 2020_](https://www.legislation.govt.nz/act/public/2020/0031/latest/LMS23223.html) (Information Privacy Principles, Schedule 1) and the [_Health Information Privacy Code 2020_](https://www.privacy.org.nz/privacy-principles/codes-of-practice/hipc2020/) (HIPC), issued under that Act. 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 NZ region, 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 **NZ-hosted production workloads** Primary application servers, databases, object storage, and backups for the NZ deployment are located in New Zealand (Catalyst Cloud). Administrative records describe regions and change approval; technical deployment pins resources to the NZ project. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5 (storage and security), IPP 13 (disclosure outside New Zealand β€” keeping health information in NZ reduces offshore exposure); _HIPC 2020_ β€” Rule 5 (storage and security). - βœ… Technical **Encryption in transit** Public ingress uses modern TLS. Traffic to Microsoft Azure Speech and Google Vertex uses TLS to Sydney regions only as configured. This is a technical control verified in architecture reviews and deployment config. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5 (reasonable security safeguards); _HIPC 2020_ β€” Rule 5. - βœ… Technical Policy **Encryption at rest** Databases, object storage, and backup objects use NZISM\-aligned algorithms (e.g. AES-256-GCM) with keys managed per our cryptography policy. WAL-G backups add client-side encryption before off-site storage. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5; _HIPC 2020_ β€” Rule 5. - βœ… 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. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5; _HIPC 2020_ β€” Rule 5. - βœ… Technical Policy **Intrusion detection** Layered detection: the Catalyst 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. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5; _HIPC 2020_ β€” Rule 5. Supports timely detection and assessment where a serious privacy breach may have occurred. ## 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 Firebase (OIDC/OAuth-style flows); every API path validates identity. Session lifetime and lockout behaviour align with our access-control policy. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5, IPP 12 (unique identifiers); _HIPC 2020_ β€” Rules 5 and 12 (as they apply to health information identifiers). - βœ… 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. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5, IPP 10 (use), IPP 11 (disclosure); _HIPC 2020_ β€” Rules 5, 10, 11. - βœ… 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 Firebase Authentication. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5; _HIPC 2020_ β€” Rule 5. - βœ… 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. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5 (reasonable steps to protect information through the information life cycle); _HIPC 2020_ β€” Rule 5. - βœ… 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. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5; _HIPC 2020_ β€” Rule 5. ## 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. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 9 (retention); _HIPC 2020_ β€” Rule 9 (retention of health information). - βœ… 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)`. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 9, IPP 5 (integrity of safeguards); _HIPC 2020_ β€” Rules 9 and 5. - βœ… Policy Technical **Data subject access and correction** Individuals can request access or correction under the Privacy Act 2020; Hanah documents timelines, formats (JSON + human-readable exports), and escalation paths. Tooling supports export where data lives in Hanah systems. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 6 (access), IPP 7 (correction); _HIPC 2020_ β€” equivalent access and correction rules for health information. - πŸ”§ 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. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5; supports compliance with notifiable privacy breach provisions where a serious breach is suspected. ## 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** Microsoft and Google enterprise agreements prohibit training on customer content; Hanah does not operate an internal training pipeline on your health data. Administrative vendor reviews and technical configuration (region-locked endpoints) support the claim. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 10 (use), IPP 11 (disclosure); _HIPC 2020_ β€” Rules 10 and 11 (permitted use and disclosure of health information). - βœ… 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. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 8 (accuracy before use), IPP 10 (use for purpose); _HIPC 2020_ β€” Rule 10 (clinical and permitted uses). - βœ… 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/nz/trust/wer-methodology/index.html) is published, and [live results](https://hanah.health/nz/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 HNZ). **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 8 (accuracy); _HIPC 2020_ β€” Rule 5 and clinical-quality expectations tied to safe use of health information. - βœ… 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). Vertex and Azure 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. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5, IPP 10; _HIPC 2020_ β€” Rules 5 and 10 (guarding integrity of processing and permitted use). - βœ… 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. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 3 (collection awareness), IPP 4 (manner of collection); _HIPC 2020_ β€” Rule 3 (collection with awareness for health information). ## 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. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5 (agency accountability for reasonable safeguards); _HIPC 2020_ β€” Rule 5. - βœ… 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. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5; _HIPC 2020_ β€” Rule 5. - πŸ”§ 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. **NZ privacy alignment:** _Privacy Act 2020_ β€” IPP 5; supports detection and response where notifiable privacy breaches may arise. Subprocessors listed here are those that **may process or store Hanah customer data** in our New Zealand production architecture. Regions reflect how we configure services for health workloads. Clinician sign-in may use global identity infrastructure where **no patient health information** is stored β€” see the Firebase row and our privacy analysis for the carve-out. Subprocessor Purpose Data categories Region Notes ### Vertex AI / Gemini β€” models in use The rows below are pulled live from Hanah’s public `/api/trust` registry (same contract as audits). Only entries with **vendor Google** and **deployment Vertex** are shown here β€” i.e. LLM inference routed through Google Cloud Vertex AI in the region configured for NZ, not the consumer Gemini API or Google STT. Loading model list… If this fails to load (network or ad blocker), open the raw JSON: [](https://nz.hanah.health/api/trust)β€” region is set via `data-trust-region` on the `` element. 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/nz/trust/status/index.html "Per-component health, 90-day uptime, and incident history for the NZ deployment.") [Full model registry (JSON)](https://nz.hanah.health/api/trust "Full public registry (all vendors / deployments). Vertex Gemini slice is also inlined under Subprocessors.") [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) β€” New Zealand. This Trust Center is a high-level summary. Contractual commitments, data processing terms, and subprocessors in force at signing supersede this page. Status emoji markers (βœ… πŸ”§) are temporary and will be removed after independent verification of each row.