Official documentation checked October 14, 2026.
An Australian organisation using Microsoft 365 Copilot must assess its own privacy obligations and the circumstances of any disclosure. A Copilot output containing personal information is not automatically a notifiable breach, and a Microsoft security feature does not certify compliance with Australian law.
This guide concerns organisational use and incident planning. Have your privacy, security, and legal leads determine the applicable obligations, controls, and response for your entity and information.
How Copilot Interacts with Personal Information Under the Privacy Act
First check coverage. The OAIC’s NDB quick reference guide lists covered agencies, larger businesses, and certain smaller entities, including health service providers and tax file number recipients. Do not assume every Australian business has identical obligations or that a small-business exemption covers every information type.
The OAIC describes personal information as information or an opinion about an identified or reasonably identifiable individual. Its scope includes more than a list of obvious identifiers, and sensitive information needs particular care.
Microsoft’s enterprise data protection documentation says Copilot respects the user’s access permissions and applicable organisational controls. Broad existing permissions can therefore create a governance risk even when the service follows those permissions. Technical ability to open a file does not establish that every proposed use or disclosure is lawful.
The OAIC’s commercial AI guidance recommends evaluating privacy before adoption. Check intended purposes, notices, data accuracy, provider arrangements, overseas disclosures, and protection of information. It recommends avoiding personal, particularly sensitive, information in publicly available generative AI tools. Do not assume a personal-account Copilot session has your organisation’s enterprise arrangement.
What Constitutes a Notifiable Data Breach With Copilot
The OAIC’s reporting guidance requires assessing unauthorised access or disclosure, or loss of personal information, likely serious harm to individuals, and whether remedial action prevents that likely harm. Loss also needs assessment where unauthorised access or disclosure is likely. A file type, a tax file number, or the word “Copilot” does not determine notification by itself.
Steps to Prevent and Respond to Copilot-Related Data Breaches
- Inventory the deployment and permissions. Identify the app, account type, connectors, information sources, and approved purposes. Have resource owners review broad sharing links and unnecessary mailbox or site access. Preserve legitimate access and document each proposed restriction.
- Choose a supported protection for the actual data path. Microsoft’s Copilot DLP documentation distinguishes blocking chosen labelled files/emails from processing, restricting prompts containing sensitive information types, and blocking web search. Prompt restriction is described as a preview rollout; confirm availability and licensing. That location does not scan files uploaded directly into prompts. It is not a blanket filter guaranteeing that every response lacks personal information.
- Configure and test through the approved change process. In the Microsoft Purview portal, review the relevant DLP policy, location, condition, action, and assigned users. Test with synthetic data, including an allowed case and a restricted case. Record the specific result. Do not treat a label name or “sensitive” marking alone as proof of encryption or access denial.
- Preserve useful evidence. The Copilot audit guide describes
CopilotInteractionrecords and resource/message references. Use authorised Audit access to narrow the user, time, and workload. A CSV activity export alone should not be assumed to contain the full offending answer. Microsoft’s eDiscovery documentation provides a route to locate supported stored prompts and responses. Follow preservation procedures; do not run deletion steps during evidence gathering. - Contain and evaluate the incident promptly. Engage the incident team, limit the actual exposure, identify recipients and affected people, and document remedial action. Resetting a password or removing a license does not recall an answer already copied or sent. Preserve a timeline, exact output where lawfully available, source permissions, and subsequent sharing evidence.
The OAIC’s NDB scheme guidance distinguishes assessment from notification. An entity suspecting an eligible breach must assess it expeditiously and take all reasonable steps to finish within 30 calendar days after the day it became aware of the grounds for suspicion. Once there are reasonable grounds to believe an eligible breach occurred, notify the OAIC and the relevant individuals as soon as practicable, subject to applicable exceptions. Thirty days is not a general permission to delay notification.
Common Compliance Gaps and How to Fix Them
Over-broad mailbox, file, or chat access
Review the actual permission and supported Copilot experience with the resource owner. Restrict unnecessary access through the relevant service. Do not rely on an invented Copilot “Data sources” checkbox for excluding every mailbox, OneDrive folder, or Teams chat. Sharing a generated answer externally is also a separate event from generating it internally.
Using retention as an access control
A retention policy manages the information lifecycle. It is not a universal Copilot privacy switch. Do not impose “retain for 30 days then delete” on Teams history merely to reduce AI exposure. Information may be subject to records obligations, legal holds, or an investigation. Microsoft documents retention, preservation, and other controls in its Purview AI protection overview; choose them with the records and privacy teams.
Assuming Microsoft compliance statements settle local duties
Document the organisation’s own assessment and response. Include people, processes, sharing practices, vendor arrangements, and the effects of remedial action. An incident can warrant internal action even if the NDB notification threshold is not met.
Assessing Copilot Incidents Under the NDB Scheme
| Situation | Questions to investigate | Next step |
|---|---|---|
| A TFN or health record reaches an unintended person | Who accessed it, what protections applied, what harm is likely, and did containment prevent that harm? | Prompt incident assessment; do not assume the 30-day period is a notification deadline |
| A generated answer is sent externally | Was the disclosure authorised, who received it, and what personal information was involved? | Preserve the answer and sharing evidence; assess notification requirements |
| The disclosed material contains no personal information | Are other confidentiality, contractual, or security duties affected? | Address those duties separately; NDB concerns personal information |
Record the decision, supporting facts, remedial actions, and responsible owner. Recheck the controls after changes or new Copilot capabilities rather than treating one configuration as permanent proof of compliance.