Microsoft 365 Security for Australian Healthcare Organisations
Healthcare organisations have legal obligations around health information that go beyond general cyber security best practice. Under the Privacy Act 1988 and the My Health Records Act 2012, health information requires specific protections. Microsoft 365 can be configured to meet these requirements - but the default configuration does not get you there. This guide covers the controls that matter and the gaps most commonly found in healthcare tenants.
The legal context: what healthcare organisations are required to do
The Privacy Act 1988 classifies health information as sensitive information, which attracts a higher standard of protection. The Australian Privacy Principles (APPs) require organisations to take reasonable steps to protect personal information from misuse, interference, loss, and unauthorised access or disclosure.
The Notifiable Data Breaches (NDB) scheme, which applies to organisations covered by the Privacy Act, requires notification to the Office of the Australian Information Commissioner (OAIC) and affected individuals when a data breach is likely to result in serious harm. Unauthorised access to health information is among the most commonly notified breach types.
For organisations that participate in the My Health Records system, additional obligations apply under the My Health Records Act 2012, including strict limitations on permitted uses of health information and specific security requirements.
This does not mean you need a separate compliance programme for Microsoft 365. It means the security controls you implement need to be documented, verifiable, and defensible - not just in place but demonstrable.
Identity and access: the highest-priority controls
Compromised credentials are the primary vector for healthcare data breaches. The 2022 Medibank incident, the 2023 HWL Ebsworth breach, and numerous smaller incidents consistently trace back to inadequate identity controls. The following controls are non-negotiable for any healthcare organisation on Microsoft 365:
- Multi-factor authentication for all users without exception - including clinical staff, reception, and administrative roles. No exemptions for convenience.
- Legacy authentication blocked via Conditional Access - legacy protocols bypass MFA entirely and are the most common credential theft vector in healthcare environments
- Privileged access review - clinical IT coordinators, practice managers with admin access, and any MSP-held admin accounts should be inventoried and reviewed quarterly
- Entra ID sign-in risk policies - Microsoft Defender for Identity and Entra ID Protection can detect high-risk sign-ins and require step-up MFA or block access automatically
- Break-glass accounts documented and tested - if your MFA or Conditional Access misconfigures, you need a recovery path that does not require calling your MSP at 11pm
Data classification and sensitivity labels for health information
Health information in Microsoft 365 typically lives across SharePoint document libraries, Teams channels, OneDrive, and Exchange. Without sensitivity labels, there is no systematic way to identify where health information is, restrict who can access it, or prevent it from being shared inappropriately.
A minimum sensitivity label configuration for a healthcare organisation should include at minimum three labels:
- General - for non-sensitive internal content
- Confidential - for personal information that requires restricted access (patient records, staff HR files, financial data)
- Health Information - for documents containing patient health information specifically, with encryption and Copilot access restrictions applied
Sensitivity labels in Microsoft Purview can be configured to encrypt documents, restrict who can open them, prevent copying or forwarding, and block Microsoft Copilot from including their contents in AI-generated responses. For patient-identifiable information, encryption at rest is appropriate - a sensitivity label is the mechanism for applying it in Microsoft 365.
External sharing: the clinical collaboration problem
Healthcare organisations have legitimate reasons to share information with external parties - referrals to specialists, sharing results with patients, collaboration with allied health providers. This creates tension with external sharing controls.
The default Microsoft 365 external sharing settings are too permissive for healthcare. The recommended approach is to restrict the default sharing setting to 'Existing guests only' or 'Only people in your organisation', and to create an approved process for requesting external sharing in specific cases - for example, a shared Teams channel with a partner organisation that has been reviewed and approved.
Anonymous sharing links - 'anyone with the link' - should be disabled for healthcare organisations. There is no appropriate clinical or administrative use case where a document containing patient information should be accessible without authentication.
Microsoft 365 Copilot in healthcare environments
Copilot introduces specific risk in healthcare environments because it queries content based on user permissions, not content classification. If a clinician has access to a SharePoint library containing patient records - even a library they never interact with directly - Copilot can surface that content in response to a query.
Before deploying Copilot in a healthcare environment, you need to complete a permissions review, deploy sensitivity labels with Copilot access restrictions on health information, and establish a governance policy for Copilot Studio agent creation. This is not optional - a Copilot deployment into an unreviewed healthcare environment is a material data breach risk.
Healthcare-specific control priorities
| Control area | Why it matters for healthcare | Implementation |
|---|---|---|
| MFA for all users | Compromised credentials are the primary breach vector in healthcare | Conditional Access - Require MFA for all users policy |
| Legacy auth blocked | Bypasses MFA; commonly exploited in healthcare credential attacks | Conditional Access - Block legacy authentication policy |
| Sensitivity labels for health info | Required to restrict Copilot access and apply encryption to patient data | Microsoft Purview - sensitivity labels with encryption |
| External sharing restrictions | Prevents accidental disclosure of patient information via anonymous links | SharePoint admin - restrict to existing guests or specific people |
| DLP policies for health data | Detects and prevents transmission of Medicare numbers, health identifiers, and clinical data | Microsoft Purview - DLP policy with Australian health data classifiers |
| Audit logging enabled | Required to demonstrate compliance and investigate incidents under NDB scheme | Microsoft Purview - audit log retention, minimum 12 months |
| Offboarding process for clinical staff | Clinicians with access to patient systems change roles and organisations frequently | Entra ID - account disabling, session revocation, access review on departure |
Notifiable data breach preparation
Under the NDB scheme, you have 30 days from becoming aware of a potential eligible data breach to assess whether notification is required. In practice, the assessment requires you to know what data was accessed, by whom, and for how long.
Microsoft 365 audit logging provides the evidence trail for this assessment - but only if it was enabled before the incident. Audit log retention in Microsoft 365 defaults to 90 days on most licences. For organisations with Microsoft 365 Business Premium, audit log retention can be extended to 180 days. For extended retention of one year or more, Microsoft Purview Audit (Premium) is required.
Enable audit logging now, not after an incident. Review the retention period against your incident investigation requirements. Document what constitutes a reportable breach for your organisation under the NDB scheme.
The question for a healthcare organisation is not whether you are a target. Healthcare data is consistently among the most valuable on dark web markets. The question is whether your Microsoft 365 environment is configured to detect, contain and respond to an incident - or whether you would find out about it from a patient.
Accuracy
Last reviewed: 9 October 2026 · Microsoft product capabilities, licensing and configuration options change regularly. Verify current details at learn.microsoft.com.
Next step
Microsoft 365 Security & Governance Baseline
An independent Microsoft 365 security assessment for healthcare organisations - covering identity, Conditional Access, sensitivity label deployment, audit logging, external sharing and Copilot readiness. Written findings report and remediation recommendations. From $2,500.
Learn more