AI Scribe Data Security Checklist for Australian Practices
Reviewed: 30 July 2026
An AI scribe can touch more patient information than its finished note suggests. Live audio, transcripts, prompts, metadata, logs and backups may pass through several services. For Australian practices, a privacy badge or promise of local hosting is too thin for procurement. This checklist gives practice owners, clinical leaders and security teams a practical way to map those flows, require written evidence, set contract terms and keep the controls working after rollout.
Start with the complete data flow
An ambient AI scribe usually captures speech on a clinician's device, streams it to a transcription service, sends text and instructions to a model, returns a draft, then transfers an approved note to the patient record. Extra copies can arise in application logs, error monitoring, support tickets, feedback tools, analytics and backups.
The assessment therefore needs to cover every data type:
- consultation audio and any temporary audio file
- transcript, draft note and approved note
- patient identifiers and clinical context drawn from the record
- prompts, templates, clinician edits and feedback
- consent records, timestamps and user activity
- diagnostic logs, support records, analytics and backups
For each one, record its purpose, every processor, country of processing, access rules, encryption, retention period and deletion event. A statement that data is "hosted in Australia" answers only one part of that map. Offshore model processing, support access or telemetry may still create a cross-border disclosure.
Australian requirements set the baseline
The Privacy Act 1988 and Australian Privacy Principles (APPs) govern the handling of personal information. For an AI scribe, the most relevant duties include transparent management under APP 1, collection under APPs 3 and 5, use and disclosure under APP 6, cross-border disclosure under APP 8, accuracy under APP 10, and security and deletion under APP 11. The current APP guidelines explain how these duties apply.
The Office of the Australian Information Commissioner (OAIC) says privacy obligations apply to personal information entered into an AI system and personal information generated by it. Its commercial AI guidance calls for product due diligence, a privacy impact assessment, human oversight, staff training and regular review across the product lifecycle.
Federal privacy guidance is a baseline rather than an exhaustive account. State and territory health-privacy, health-records and surveillance or recording laws can add requirements, and public health services may apply stricter approved-technology policies. The Australian Commission's ambient scribe safety scenario flags these jurisdictional layers.
Clinical accountability also belongs in the security decision. The Therapeutic Goods Administration (TGA) distinguishes documentation-only scribes from products that analyse a conversation or create new diagnoses or treatment recommendations. It also directs clinicians to review software changes, privacy safeguards and ongoing performance. The TGA digital scribe guidance requires informed consent and clinician responsibility for the accuracy of information entered into the record. Ahpra's AI guidance likewise keeps responsibility for safe care and human judgement with the practitioner.
AI scribe data security checklist
Use three outcomes for each item: Pass, Remediate before use, or Stop. A pass needs written evidence that matches the contract and the live workflow. A sales answer on its own does not qualify.
Data handling and privacy
| Requirement | Question for the vendor | Evidence for a pass | Red flags |
|---|---|---|---|
| 1. Intended use | Does the product only draft documentation, or does it add clinical interpretation, diagnosis, triage or treatment advice? | A precise intended-use statement and inclusion in the Australian Register of Therapeutic Goods where the functionality has a therapeutic purpose. | Vague "clinical assistant" language or therapeutic features without ARTG inclusion. |
| 2. End-to-end data flow | Which systems receive audio, text, identifiers, prompts, edits, feedback and logs? | A current architecture diagram naming each processor, system, data type and transfer. | A hosting-region answer with no model, logging, support or integration path. |
| 3. Collection and purpose | Which data is necessary to produce the draft, and which fields are optional? | A field-level purpose list, data minimisation by default and a way to disable unnecessary collection. | Whole-record access by default or undefined collection "to improve the service". |
| 4. Processing location | In which country is each data type processed, stored, backed up and accessed for support? | A country-by-country answer for the primary service and every subprocessor, plus the vendor's documented APP 8 position. | "Australian hosted" with undisclosed offshore processing, support or telemetry. |
| 5. Retention and deletion | How long does each copy survive, including audio, transcripts, drafts, logs, support data and backups? | A retention schedule with automatic deletion, backup expiry, exception handling and deletion records. | "Deleted promptly", indefinite logs, manual-only deletion or no backup timetable. |
| 6. Training and secondary use | Can customer data be used for training, fine-tuning, evaluation, benchmarking, research, analytics or sale? | Contract terms that prohibit unwanted uses and bind subprocessors to the same rule. Any permitted derived data is narrowly defined and protected against re-identification. | Broad rights to "develop" or "improve" products, a policy-only promise, opt-out training, or sale rights. |
| 7. Subprocessors | Which third parties handle data, for what purpose, and how will changes be communicated? | A maintained register with service, data, location and advance notice of material changes. | Refusal to name processors or unrestricted changes without notice. |
Technical security, auditability and contracts
| Requirement | Question for the vendor | Evidence for a pass | Red flags |
|---|---|---|---|
| 8. Identity and access | How are clinician, administrator, vendor-support and machine access controlled? | Individual accounts, multi-factor authentication, role-based access, prompt account removal during offboarding and time-limited support access with approval. | Shared accounts, optional MFA or standing employee access to clinical data. |
| 9. Encryption and keys | How is data protected in transit and at rest, and who controls the keys? | Documented encryption, key storage and rotation, secrets management, and separation between production customers. | "Bank-grade encryption" without architecture or key-management detail. |
| 10. Audit trail | Can the practice reconstruct capture, consent, generation, editing, approval, export, deletion and administrative access? | Exportable logs with user, timestamp, action, template and model version, protected from alteration and retained for a defined period. | Missing approval or support-access events, unexportable logs, or no link to the model version used. |
| 11. Independent assurance | Which controls have an independent party assessed, and what was in scope? | A current ISO/IEC 27001 certificate and scope, plus a recent penetration-test summary and remediation status. ISO/IEC 27001 covers an information security management system, so certificate scope matters. | An expired badge, a scope that excludes the scribe service, or no independent security testing. |
| 12. Incident response | When and how will the practice learn of suspected unauthorised access, loss or disclosure? | A contractual notification period, named contacts, containment and forensic support, affected-data detail, evidence preservation and cooperation with notifications. | Notice only after the vendor decides a breach is legally reportable, or no response time. |
| 13. Contract exit | What can the practice export, and what is deleted when the service ends? | Usable exports, dated deletion from primary systems and subprocessors, backup expiry, a deletion attestation and a defined legal-hold exception. | Data lock-in, ongoing broad use rights or retention "as necessary" without a schedule. |
| 14. Resilience | What happens during transcription failure, internet loss, ransomware or vendor outage? | Tested recovery arrangements, backup controls and a practice workflow that does not depend on the scribe being available. | No outage mode, silent data loss or no route to retrieve approved records. |
The Australian Signals Directorate's Essential Eight is a useful baseline for MFA, restricted administrative privileges, patching and backups. It applies to the practice environment as well as the vendor.
Consent, clinician review and change control
| Requirement | Question for the vendor and practice | Evidence for a pass | Red flags |
|---|---|---|---|
| 15. Patient notice and consent | What does the patient learn, how is consent recorded, and how is refusal handled? | Plain-language information, consent before capture, a per-consult record, pause and stop controls, and an ordinary documentation alternative. Our AI scribe consent guide provides a practical workflow. | A reception sign as the only notice, bundled consent, or care affected by refusal. |
| 16. Clinician review | Can any draft reach the patient record or another recipient without clinician action? | Draft status is clear. The clinician can edit, discard and approve before write-back, with the action attributed in the audit trail. | Automatic finalisation, hidden edits or unchecked letters and referrals. |
| 17. Product and model changes | How are material changes assessed, released and linked to past outputs? | Release notes, notice of changes affecting data use or clinical behaviour, version-linked records, pre-release evaluation and rollback. | Silent model replacement or a new recommendation feature enabled by default. |
| 18. Staff readiness and monitoring | Who may use the scribe, who owns risk, and how is performance reviewed? | An approved-tool policy, role-based training, named clinical and privacy owners, incident reporting, and recurring review of access, consent and note quality. | Personal AI accounts, unmanaged shadow use or no post-rollout owner. |
Six procurement stop signs
A practice should pause procurement when any of these remains unresolved:
- The vendor will not provide a complete data-flow diagram or subprocessor register.
- Contract terms allow patient information to train or benchmark models, or grant broad product-improvement rights without a narrow definition.
- Australian data residency is claimed, yet offshore processing, support access and backups are not addressed.
- Individual accounts, MFA, access logs or a clinician approval step are missing.
- Incident notification and deletion after contract exit have no enforceable timetable.
- A compliance badge is offered in place of its certificate, scope and supporting evidence.
A HIPAA claim does not resolve these points. HIPAA is a United States framework and does not establish compliance with the Australian Privacy Act, applicable state or territory rules, or local professional obligations.
Turn the checklist into an operating control
Security work continues after a contract is signed. The OAIC specifically warns against a set-and-forget approach to commercial AI.
- Create an evidence pack. Keep the data-flow map, privacy impact assessment, contract, subprocessor register, retention schedule, security assurance, incident contacts and decision record together.
- Set non-negotiable gates. Data use, access control, clinician review, incident notice and exit deletion should have an owner and an accepted position before patient information enters the system.
- Stage the rollout. Begin with synthetic data, then a small approved clinical cohort with the consent workflow, MFA, audit logs and fallback documentation in place.
- Train for the actual workflow. Staff need to know which tool is approved, how to obtain consent, when to pause capture, how to review drafts, and how to report a privacy or quality concern.
- Review outputs and access. Sample notes for omission, unsupported content and contradiction. Review accounts, consent records, incidents and vendor changes. Our broader ambient documentation vendor checklist adds quality and implementation criteria.
- Trigger a new assessment after change. A new model, subprocessor, retention rule, integration or recommendation feature can alter the original risk decision. The TGA also expects ongoing attention to software updates and intended use.
If an incident occurs, the contract needs to give the practice enough information to contain it and assess notification duties. The OAIC's health service data breach plan organises the response into containment, evaluation, notification and review.
How we currently handle these controls at Lyrebird
Our current terms and privacy policies distinguish the temporary data needed to produce and deliver a draft from the clinician-approved note held in the practice's clinical record:
- Consultation audio: Audio is deleted after successful transcription in normal operation. If the real-time transcription service has a technical problem or outage, the current terms allow encrypted audio to be held for a maximum of two days. It is deleted after successful transcription or at the two-day limit, whichever comes first, and the practice can opt out of this outage buffer. Terms of Service
- Platform notes and the clinical record: Notes saved in Lyrebird are deleted after seven days by default, with a configurable retention period of up to six months. The detailed policy also sets a six-month maximum for transcripts and clinical notes and says they are typically deleted once delivered to the electronic health record. These are vendor-held, transient copies. The clinician-approved note stored in the practice's record system is the clinical record and remains under the practice's retention and security controls. Privacy & Security FAQ, detailed Australian Privacy Policy, Terms of Service
- Processing locations and providers: Application databases, transcripts, authentication data, speech processing and encrypted backups remain in Australia in the AWS Sydney region. The detailed policy separately discloses overseas handling of payment metadata, pseudonymised monitoring logs, non-health website usage data and de-identified health information used for language processing by Azure OpenAI in the European Union, with region pinning where available. Detailed Australian Privacy Policy
- Model training and statistical data: The terms prohibit using "Your Data" to train, fine-tune, benchmark or otherwise develop an AI or machine-learning model, and require third-party service providers to accept the same restriction. A separate clause permits us to create and use anonymised statistical data from customer data and service usage, including for service improvement, new offerings and business trends, with a restriction against publishing samples small enough to expose underlying data. Terms of Service
- Clinician review: Lyrebird generates clinical documentation drafts for clinician review and approval. The clinician remains responsible for editing the draft as needed and for the final version placed in the practice's record system. AI Scribe usage policy, Terms of Service
- Security safeguards: The detailed policy documents encryption for storage and transmission, role-based access, security testing, monitoring and threat detection. These controls do not imply customer-visible access to every audit event described in the procurement checklist above. Detailed Australian Privacy Policy
This handling reduces avoidable vendor-side retention while keeping the clinician responsible for the final record and patient care.
See the workflow, consent controls and review step in practice. Book a demo.
