Microsoft Teams pulled off a quiet trick: it became the room where work happens — the decisions in chat, the files shared mid-meeting, the recordings, the client channels — while storing almost none of that data in Teams. It’s a front-end wearing four back-ends, and that architecture is why protecting Teams confuses everyone: you can’t secure or back up “Teams” as a thing; you protect the places it actually keeps your data. Here’s the map, then the protections.

The map: one app, four storage locations

  • Channel files → the SharePoint site every Team silently owns. Protecting them is protecting SharePoint — permissions, versioning, backup, all of it applies here.
  • Files shared in chats (not channels) → the sender’s OneDrive, in a “Microsoft Teams Chat Files” folder, shared to recipients. Which means the file the whole project relied on lives in one person’s OneDrive — and inherits that person’s departure countdown.
  • Chat and channel messages → Exchange-adjacent storage, discoverable and retention-policy governed, but not a mailbox you can casually open — message recovery is compliance machinery, not a recycle bin.
  • Meeting recordings → OneDrive (for ad-hoc meetings, the organizer’s) or SharePoint (channel meetings), with their own default expiration timers that quietly delete recordings after a set period unless configured otherwise — a surprise that has claimed many a “we recorded that decision” moment.

Read that map once and the confusion resolves into a checklist: Teams protection is SharePoint protection plus OneDrive protection plus message retention plus a few Teams-specific settings.

What the map means in practice

Backup follows the map. A third-party M365 backup that covers Exchange, OneDrive, and SharePoint captures most of Teams by construction — but “most” earns scrutiny: verify your tool explicitly supports Teams structures (channel/team reconstruction, chat capture where offered), because restoring raw SharePoint files is not the same as restoring a functioning Team, and vendors differ honestly here. Ask the pointed question and test the answer: “delete a test Team, restore it — what comes back?”

Deletion is harsher than people expect. Deleting a Team deletes its SharePoint site, its channels, its mailbox components — recoverable within the soft-delete window (roughly 30 days), then gone as a unit. Combine with the site-lifecycle reality — bored owners “cleaning up” old Teams — and the case for backup plus a light governance layer on who can delete what makes itself.

Departures hit Teams sideways. The chat-files-live-in-OneDrive detail means offboarding’s preserve-first rule protects more than the person’s own work — it protects every chat-shared file the rest of the company still links to. One more line on the checklist, worth its ink.

Guests are members too. External guests invited into Teams get real access to channel files (SharePoint access, by the map) — appropriate during the project, forgotten after it. Guest access deserves the same expiration-and-review treatment as any vendor access: periodic review of which guests remain in which Teams, and removal when the engagement ends.

Compliance needs deliberate settings. For regulated businesses, Teams messages are business communications — retention configured on purpose, and policy clarity on what belongs in chat versus channels versus email, because “the decision is in some chat thread” is a discovery request nobody enjoys. Recording expiration timers get set consciously for the same reason.

The bottom line

Teams isn’t a data store — it’s a beautiful lid over four of them. Protect the four (SharePoint and OneDrive with their full treatments, messages via retention, recordings via deliberate settings), verify your backup reassembles Teams rather than just files, and staple the chat-files quirk to offboarding and the guest question to vendor reviews. Once the map is on the wall, the app everyone works in stops being the data nobody can account for.