Ontario's new municipal privacy duties, mapped to Microsoft 365 settings

Someone has handed you the compliance file. Maybe you are the clerk. Maybe the records coordinator. Maybe you are the one person who does IT for a township of forty staff and also resets everybody’s password.

The summary you were given says Bill 97 changed MFIPPA, that there are new privacy duties, and that the Information and Privacy Commissioner is involved.

What nobody told you is which of those duties you meet with a policy document, and which ones you meet by changing a setting in Microsoft 365. That is the gap this fills: statutory duties mapped onto tenant settings. It is not legal advice, and you should check the legal reading with your solicitor.

Start with the date, because a lot of what is going round has it wrong.

What changed under MFIPPA, and when

Bill 97, the Plan to Protect Ontario Act (Budget Measures), 2026, got Royal Assent in April 2026. It changes both FIPPA and MFIPPA, and it does it on two separate clocks.

The access-to-information changes came first. Business days instead of calendar days, a longer baseline response period, staged access, fee estimates. Those applied to municipal institutions from July 1, 2026. The privacy duties did not.

So the deadline has not passed. It is January 1, 2027, and you can count the months from wherever you are reading this. And because the provincial side has run under the same duties since 2025, the IPC’s guidance, forms and reporting portal already exist. You are not waiting on anything.

The annual statistics report is the one people miss. Breaches you report during 2027 get summarised and filed with the IPC by March 31, 2028. That only works if you kept a record at the time. It is a records process, not a tenant setting. Write the template now, while nothing is on fire.

Could you reconstruct a breach you had to report?

The reporting bar is a real risk of significant harm. To judge that you have to answer four concrete questions: what was exposed, to whom, when, and for how long.

In a Microsoft 365 tenant those answers live in the unified audit log. How much of it you still have comes down to licensing.

Microsoft Purview Audit (Standard) keeps audit records for 180 days. That has been the default since October 17, 2023. Audit (Premium) adds a policy that keeps Microsoft Entra ID, Exchange, OneDrive and SharePoint records for one year, and lets you write custom policies for everything else.

The catch is that it works per user, not per tenant:

Read that last sentence again with a municipality in mind. Guest accounts are exactly the ones involved in the breach you are most likely to face. Their records are the ones you keep for the shortest time, no matter what you bought.

The Business Premium row is the one worth chasing. Most small Ontario institutions are on Business Premium and assume Audit (Premium) is out of reach. It is not. Microsoft sells a Purview Suite add-on that sits on a Business Premium base licence, and the service description lists Audit (Premium) as included. It caps at 300 seats, which for a municipality of 40 to 300 staff is not a problem. Confirm the exact entitlement with your reseller before you budget for it.

Custom retention lengths are 7 days, 30 days, 6 months, 9 months, 1 year, 3, 5, 7 years, and 10 years with the add-on. You can have up to 50 policies. Before you change anything, find out what you actually have:

Connect-IPPSSession

Get-UnifiedAuditLogRetentionPolicy |
  Sort-Object Priority |
  Format-List Name, RecordTypes, RetentionDuration, Priority

If that comes back empty, do not relax. The command does not return the default policy, only custom ones. Empty means you are running on defaults, and for a non-E5 tenant that means 180 days for everything.

Records made by non-user entities, meaning service principals, system events and application activity, are kept for a fixed one year, and retention policies do not apply to them. Now and then that is the only trace you have left of an app quietly pulling data out.

Is our data in Canada?

Almost certainly yes, for the workload you care about most, and you did not have to buy anything for it.

Canada is one of Microsoft’s Local Region Geographies. For SharePoint and OneDrive, the baseline commitment in the Product Terms applies where the tenant signed up in a Local Region Geography, which a tenant registered in Canada did. Site content, the files in it, and files uploaded to OneDrive sit at rest in that geography.

Check your own position rather than taking my word for it: Microsoft 365 admin center > Settings > Org settings > Organization profile > Data location.

What the Advanced Data Residency add-on buys is breadth, not the country. ADR extends a committed location to Exchange mailbox content, Teams chat and meeting recordings, Microsoft 365 web apps, Defender for Office P1 and EOP data, Copilot interaction content, Viva Connections, and a named list of Purview services. Microsoft notes that Purview list is current as of February 2026, and that other Purview services are not covered.

Two eligibility facts get reported wrongly, and both come from the current Learn page:

• Business Basic, Standard and Premium are on the eligible licence list. So are the enterprise and frontline SKUs. A small municipality on Business Premium is not shut out of ADR the way it is often described.
• You have to cover 100% of eligible paid seats, and that is worked out against purchased seats, not assigned ones. There is no minimum seat count and no partial credit. Buy 95% coverage and you have no commitment at all.

The coverage rule, not the base licence, is what kills the business case for most small institutions. If you have 180 purchased seats with only 140 assigned users behind them, you are buying 180 ADR licences.

So be precise in the PIA about what you are claiming. “SharePoint and OneDrive content is stored at rest in Canada under the Product Terms” holds up today. “All our Microsoft 365 data is in Canada” usually does not.

The one-year rule in O. Reg. 823, as a real retention policy

This one came in long before Bill 97 and gets skipped constantly.

Section 5 of R.R.O. 1990, Reg. 823 under MFIPPA says personal information used by an institution has to be kept for at least one year after use, so the person has a fair chance to ask for access to it. The Ontario government’s own FOI manual lists the narrow exceptions: the person agrees to earlier disposal, the information is credit or debit card payment data, or a municipal by-law sets a different period. That last one is open to municipal institutions only, and if your council has passed a records retention by-law, it wins.

In the tenant this is a Purview retention policy or a retention label. Business Premium includes user rights for both, so you do not need E5.

Plan around two collisions.

The recycle bin is not retention. Files deleted from a site go to the site recycle bin, then the second-stage recycle bin, then they are gone, on a schedule that has nothing to do with a legal minimum. A retention policy holds content in the Preservation Hold Library separately from all of that. If your only answer to “can you still produce it” is the recycle bin, the answer is no.

A policy that deletes is as risky as one that keeps. Set a retention policy to delete personal information after six months because somebody read an article about data minimisation, and you have built a machine that breaks section 5. Put the floor at one year after use, and only use a by-law if you actually have one.

Scope matters more than length here. A tenant-wide “delete after N years” rule is a blunt instrument when one site holds council agendas and another holds employee accommodation files. Label the categories that hold personal information, and put the retention on the label.

Six safeguards you can show someone on request

The safeguards duty is written as administrative, technical and physical measures. Nobody is going to ask you to prove “reasonable” in the abstract. They will ask what you did. These six are one screenshot each.

1. Tenant external sharing level. SharePoint admin center > Policies > Sharing. The four levels are Anyone, New and existing guests, Existing guests, and Only people in your organization. Proves the outer boundary.
2. Per-site sharing, tighter than the tenant. A site can be stricter than the tenant, never looser. Proves the HR site is not run under the same rule as the intranet.
3. Expiry on “Anyone” links. You can make all Anyone links expire within a set number of days and limit them to view only: Set-SPOTenant -RequireAnonymousLinksExpireInDays 30. Proves a link that needs no sign-in cannot live forever.
4. Guest access expiry. Guest access to a site or OneDrive can expire on its own after a set number of days. Proves that access granted in 2022 for one document is not still open.
5. MFA and conditional access on everyone who can reach personal information. Proves the account boundary is more than a password.
6. Sensitivity labels and DLP where they are warranted. Manual labelling and DLP for Exchange, SharePoint and OneDrive are both in Business Premium. Automatic labelling needs E5. DLP activity is written to the audit log by default, the same log your breach report depends on.

Worth knowing for the runbook: Microsoft says that if you restrict or switch off external sharing, guests usually lose access within one hour. That is a real containment tool, and better learned now than under pressure.

The PIA needs an inventory you probably do not have

The written PIA has to name the purpose of collection, the legal authority, what you collect, where it comes from, who can see it, and how it is used and kept. Then the safeguards protecting it, the risks if it leaks, and what you are doing about those risks.

Every one of those except “legal authority” is a question about a specific site. Which makes the PIA unwritable until you have a per-site list. Start here:

Connect-SPOService -Url https://<tenant>-admin.sharepoint.com

Get-SPOSite -Limit All |
  Select-Object Url, Title, Owner, SharingCapability, LastContentModifiedDate,
    @{n='SizeGB';e={[math]::Round($_.StorageUsageCurrent/1024,1)}} |
  Sort-Object SharingCapability, Url |
  Export-Csv .\site-inventory.csv -NoTypeInformation

Then add three columns by hand, because no command can work them out for you: does this site hold personal information, what category, and who is the accountable owner. Accountable owner is the hardest column to fill and the one the IPC will care about.

Start with the sites where SharingCapability is ExternalUserAndGuestSharing and LastContentModifiedDate is two years old. Those are dormant sites that anyone holding an old link can still walk into.

Sharing links are what turns into a breach report

The municipal pattern is predictable. A council package put together in a rush gets shared with an “Anyone” link so the consultant does not need an account. An HR investigation file goes to a personal address because the person was working from home. A committee site from a 2023 project still has four external members and no owner.

None of that is exotic. Every one of them becomes a reportable disclosure the day the wrong person forwards the link.

Fix them in this order:

1. Turn on expiry for Anyone links across the tenant and set the default link type to Specific people. Existing links keep their current expiry if the new setting is longer, and update if it is shorter.
2. Pull the guest list in the Microsoft 365 admin center and check it against the inventory. Anyone not tied to a live site with a live owner comes out.
3. Set guest access expiry so the problem does not rebuild itself.
4. Drop the tenant sharing level to the strictest setting that does not break real work, then grant exceptions per site. Most municipalities can sit at New and existing guests.
5. Take the dormant externally shared sites from the inventory and either give them an owner or archive them.

Steps 1 to 3 are an afternoon. Step 5 takes a month, because it needs a human decision on every site. Our permissions cleanup before migration post covers the ordering, and the sequence is the same whether or not a migration is involved.

Copilot raises the price of every wrong permission

If Copilot is anywhere on your roadmap, do the permissions work first.

Copilot respects existing permissions exactly, and that is the problem. Anything a person could technically have found through search, Copilot now hands them in a sentence. An over-permissioned HR site stops being a risk that might happen and becomes a daily one.

Two posts cover that ground: turn on Copilot without leaking your HR folder for the order to work in, and Restricted Content Discovery for the per-site brake and why using it everywhere backfires.

A 30/60/90 for a small Ontario institution

The duties start January 1, 2027. This plan needs three months, so there is room as long as you start now.

If you do exactly one thing this week, run the audit retention check and write the number down.

Everything else on this page is a project with a budget line and a council report attached. That one takes fifteen minutes, and it tells you how long the only window you will ever have to reconstruct a breach actually is. If the number comes back 180 days, then the incident you find next February happened, at the latest, in August. Anything before that and you will be reporting to the IPC on guesswork.