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

Someone handed you the compliance file. Maybe you’re the clerk, maybe the records coordinator, maybe the one person who does IT for a township of forty staff and also resets everyone’s password. The summary you were given says Bill 97 changed MFIPPA, that there are new privacy obligations, and that they involve the Information and Privacy Commissioner.

What nobody told you is which of those obligations you satisfy with a policy document and which ones you satisfy by changing a setting in Microsoft 365. That’s the gap below: a mapping of statutory duties onto tenant configuration, not legal advice, and the statutory reading should be confirmed with your solicitor.

Start with the date, because most of what’s circulating has it wrong.

What actually changed under MFIPPA, and when

Bill 97, the Plan to Protect Ontario Act (Budget Measures), 2026, received Royal Assent in April 2026. It amends both FIPPA and MFIPPA, and it does so on two separate clocks. The access-to-information changes (business days instead of calendar days, a longer baseline response period, staged access, fee estimates) applied to municipal institutions from July 1, 2026. The privacy duties did not.

So you have roughly five months, not a passed deadline. And because the provincial side has run under identical duties since 2025, the IPC’s guidance, forms and reporting portal already exist. You aren’t waiting on anything.

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

Can you reconstruct a breach you’d have to report?

The reporting threshold is a real risk of significant harm. Assessing that means answering, concretely: what was exposed, to whom, when, and for how long. In a Microsoft 365 tenant that answer lives in the unified audit log, and how much of it you still have depends on licensing.

Microsoft Purview Audit (Standard) retains audit records for 180 days, 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 per user, not per tenant:

Guest users are exactly the accounts involved in the breach scenario a municipality is most likely to face, and their records are the ones you keep for the shortest time regardless of 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 isn’t. Microsoft sells a Purview Suite add-on that takes a Business Premium base licence, and the service description lists Audit (Premium) as included. It is capped at 300 seats total, which for a municipality of 40 to 300 staff is not a constraint. Confirm the exact entitlement with your reseller before you budget it.

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

Connect-IPPSSession

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

If that returns nothing, don’t relax. The cmdlet doesn’t return the default policy, only custom ones. An empty result means you are running on defaults, which for a non-E5 tenant means 180 days for everything.

Records generated by non-user entities, meaning service principals, system events and application activity, are kept a fixed one year, and retention policies don’t apply to them. Occasionally that’s the only trace of an app-based exfiltration you’ll have left.

Is our data in Canada?

Almost certainly yes, for the workload you care about most, and you didn’t 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’s sign-up country sits in a Local Region Geography, which a tenant registered in Canada does. Site content, the files in it, and files uploaded to OneDrive sit at rest in that geography. Confirm 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 aren’t covered.

Two eligibility facts that get misreported, both 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’s often described.
• You must cover 100% of eligible paid seats, and coverage is calculated against purchased seats, not assigned ones. There is no minimum seat count and no partial credit. Buy 95% coverage and you have no durable 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 sitting behind 140 assigned users, you are buying 180 ADR licences.

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

The one-year rule in O. Reg. 823, as an actual retention policy

This one predates Bill 97 and gets skipped constantly. Section 5 of R.R.O. 1990, Reg. 823 under MFIPPA requires that personal information used by an institution be retained at least one year after use, so the individual has a reasonable opportunity to request access to it. The Ontario government’s own FOI manual sets out the narrow exceptions: the individual consents to earlier disposal, the information is credit or debit card payment data, or a municipal by-law sets a different retention period. The by-law exception is open to municipal institutions only, and if your council has passed a records retention by-law, it governs.

The tenant expression is a Purview retention policy or a retention label. Business Premium carries user rights for both, so this does not require 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’re gone on a schedule that has nothing to do with a statutory minimum. A retention policy preserves content in the Preservation Hold Library independently of all 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 much a risk as one that keeps. Set a retention policy to delete personal information after six months because someone read a data-minimization article, and you have built a machine that breaks section 5. Set the floor at one year after use, and use a by-law only if you actually have one.

Scope matters more than duration here. A tenant-wide “delete after N years” rule is a blunt instrument in an organization where 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 will 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 more restrictive than the tenant, never more permissive. Proves the HR site isn’t governed by the same rule as the intranet.
3. Expiry on “Anyone” links. You can require all Anyone links to expire within a set number of days and restrict them to view only: Set-SPOTenant -RequireAnonymousLinksExpireInDays 30. Proves an unauthenticated link cannot live forever.
4. Guest access expiry. Guest access to a site or OneDrive can expire automatically after a set number of days. Proves that access granted in 2022 for one document isn’t still live.
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’re 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 states that if you restrict or turn off external sharing, guests typically 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 don’t have

The written PIA has to name the purpose of collection, the legal authority, what is collected, from where, who can access it, and how it is used and retained. Then the safeguards protecting it, the risks if it is lost or disclosed, and what you’re 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 catalogue. 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 cmdlet can infer them: 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.

Sites with SharingCapability set to ExternalUserAndGuestSharing and a LastContentModifiedDate two years old are where you start. Those are dormant sites that anyone with an old link can still reach.

Sharing links are what becomes a breach report

The municipal pattern is predictable. A council package assembled under time pressure gets shared with an “Anyone” link so the consultant doesn’t 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, and every one of them becomes a reportable disclosure the day the wrong person forwards the link.

The remediation sequence, in order:

1. Turn on expiry for Anyone links tenant-wide 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’s shorter.
2. Pull the guest list in the Microsoft 365 admin center and reconcile it against the inventory. Anyone not mapped to a live site with a live owner comes out.
3. Set guest access expiry so this doesn’t rebuild itself.
4. Drop the tenant sharing level to the most restrictive setting that doesn’t 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 assign an owner or archive them.

Steps 1 through 3 are an afternoon. Step 5 takes a month, because it needs a human decision per site. Our permissions cleanup before migration post covers the ordering; 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 user could technically have found through search, Copilot now hands them in a sentence. An over-permissioned HR site stops being a latent risk and becomes a daily one.

Two posts cover that ground: turn on Copilot without leaking your HR folder for the sequence, and Restricted Content Discovery for the per-site brake and why blanket-applying it backfires.

A 30/60/90 for a small Ontario institution

Five months to January 1. This fits inside three of them.

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 is fifteen minutes, and it tells you the length of the only window you’ll ever have to reconstruct a breach. If the number comes back 180 days, then the incident you discover next February happened, at the latest, in August. Anything earlier than that, you will be reporting to the IPC on inference.