Table of Contents
Following on the Dutch report slamming Microsoft for potential GDPR violations in how it deals with personal data extracted from Office and Office 365, my thoughts turned to how you can stop some of the data flows.
Lots of Workloads, Lots of Audit Data
No control is possible over the internal telemetry Office 365 apps send back to Microsoft. All we can think about is the switches and controls available in Office 365. One problem that’s immediately apparent is the sheer number of workloads. If you look at the events ingested in the Office 365 audit log, we get:
- Exchange Online.
- SharePoint Online.
- OneDrive for Business.
- Azure Active Directory.
- Power BI.
- Office 365 eDiscovery.
- Dynamics 365.
The wide spectrum of activities encompassed in the list partially explains the 20 to 30 different engineering groups who are interested in the Office events mentioned in the Dutch DPIA report.
Pause the Audit Log
You can stop information flowing into the Office 365 audit log by running the command:
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $False
This pauses ingestion into the audit log. However, my belief is that the pre-ingestion events stay in the generating workload. For example, if Teams generates an audit event when a new channel is added to a team, that event is stored somewhere in the Teams Azure service before the Office 365 audit log ingests it. If ingestion is stopped, the Teams events are still in Teams.
Exchange Mailbox Auditing
There’s no documentation about how to stop audit events accumulating in many of the Office 365 workloads. You can disable mailbox auditing in Exchange Online by running the command:
Set-OrganizationConfig AuditDisabled $True
However, this only controls mailbox auditing and has no effect on administrative auditing.
The documentation for SharePoint Online auditing describes how SharePoint generates data for the Office 365 audit log, but is unclear what might happen if ingestion to that log is paused. It might be that SharePoint reverts to legacy audit data collection, but there’s no certainly on the matter.
A setting in the SharePoint Online Admin Center allows control over the Office Graph (now the Microsoft Graph) by stopping SharePoint capturing information about how people interact with documents. If you turn this off, Office 365 features that depend on the Graph (like Delve) are a lot less effective.
Azure Active Directory is critical to Office 365 and every tenant uses a free instance as its directory service. Azure Active Directory retention policies state that data is held for between 7 and 90 days depending on its type and your licenses.
As for the rest of Azure, a lot of information is logged and there doesn’t seem to be much control at a tenant level over what’s stored and how long storage lasts.
Work to Do
This note only scratches the surface of the work that would need to be done by an Office 365 tenant to understand exactly what data flows due to auditing activities to Microsoft and what that data might hold in terms of personal data under GDPR. And then to decide what to do if they wanted to limit some of those flows.
I’m not advocating that any Office 365 tenant should disable audit logging for any workload. Too much value is to be gained from analyzing the content of the Office 365 audit log to understand what happens in the tenant, how users behave and misbehave, and the course of events that might need to be documented (here’s an example).
Your Data. You Own It
One thing’s for sure. Microsoft has some work to do to deliver the commitment made in the Office 365 Trust Center where they say:
With Office 365, it’s your data. You own it. You control it.
What we need is true control for customers over the information gathered from across Office 365 about user activities and stored in Microsoft databases. It will be interesting to see how Microsoft seeks to assuage the issues raised in the Dutch DPIA over the coming months.
For more information about the Office 365 audit log, read Chapter 21 of the Office 365 for IT Pros eBook.