Team collaboration security: the parts worth your attention

A collaboration product becomes a records system about six weeks after it is installed, and nobody ever decides that it should. Contracts get negotiated in it. Passwords get pasted into it. Somebody photographs a document and drops it into a channel because that was faster than filing it.

The security work here is therefore mostly not about attackers. It is about knowing what is in there, who can reach it, and how long it stays.

What to take away

Start with an inventory, not a policy

Four lists, each of which takes under an hour and none of which most organizations have.

Do these before writing a policy. A policy written without the lists is written about an imaginary estate, and the first thing it will do is prohibit something forty people are already doing.

The guest problem, precisely

Outside access is the whole point of these products for anyone who works with clients, so removing it is not the answer. Bounding it is.

Three questions decide how bad your exposure is: what can a guest see beyond the invited channel, such as the member directory, other channel names, and file search?

Does an invitation expire on its own, or only when a human remembers? When a guest is removed, what happens to the files they uploaded and the messages they posted?

Set a review interval, put it in a calendar, and give it an owner. Quarterly is enough for most teams, monthly if client work turns over quickly.

Access should be the narrowest that still lets the work happen, and it should be re-earned rather than assumed. That argument runs through the guidance on identity and access management published by the national cyber security body.

Connected applications are the quiet one

Most collaboration products let an ordinary user add an application, and that application often asks for permission to read messages in every channel the user can see. The consent dialog is three lines long and appears when somebody is trying to do something else.

The default is permissive in Slack, Microsoft Teams and Google Workspace: a member can usually install an app, and the approval step is off until an administrator turns it on.

Pick one of three positions and configure it instead of leaving the default because nobody looked. Either any user may install anything, a choice that should be deliberate.

Or users may request and an administrator approves, where most organizations end up. Or only administrators install, which is safest and draws the most complaints.

Whichever you pick, keep the list from the inventory above and review it on the same schedule as the guest list. An application whose vendor has gone quiet is a credential sitting in someone else's system with a permanent read on your conversations.

Retention: the periods to set

The defaults are permissive and most teams never change them. Slack keeps everything on paid plans and 90 days of history on its free plan.

Google Workspace keeps user data until the account or the data is deleted, unless a Vault retention rule says otherwise. In Microsoft 365, Teams messages and files stay until a Purview retention policy removes them.

Long retention means every future incident reaches further back, while short retention means a compromised account yields a few weeks of content instead of six years.

The tension is that some content genuinely must be kept. The resolution is to decide by class rather than by convenience: which channels carry material with an obligation attached, and which are chatter.

The usual answers are 30, 90 or 365 days. Put every space in one of those three buckets and leave the argument there.

Two practical notes. Retention settings usually apply per channel or per space, so the useful work is deciding which spaces are which, not choosing a global number. And deleted rarely means gone immediately: content sits in a recovery window and then in backups, so ask what the real elapsed time is before you describe your position to anyone.

Recovery windows differ. Microsoft 365 keeps a deleted file in the SharePoint or OneDrive recycle bin for 93 days, and Google Workspace keeps items in a user's trash for 30 days.

What the audit trail will and will not tell you

At some point somebody will ask who saw a particular message. Find out now whether you can answer, because the answer differs sharply by product and by tier.

It is worth knowing before a manager asks you to look at one. Log retention is the part people set once and forget, and the reasoning for treating it as its own decision is set out well in the guide to security log management from the standards body.

The defaults are shorter than most administrators expect. Microsoft 365 keeps the unified audit log for 180 days, extended to one year on an E5 licence and to ten years with a paid add-on. Google Workspace keeps admin and login audit events for six months.

Slack exposes audit logs through an API on Business+ and Enterprise Grid, so what you can query depends on the plan you bought.

Tell people plainly what is visible to administrators. A workforce that assumes private messages are private, and is wrong, is a problem waiting for a bad week.

When somebody leaves

The offboarding step everyone gets right is disabling the account. The steps that get missed:

Write those five into the leaver checklist that already exists for mail and payroll. The administration layer is where four of the five are actually enforced, and doing it there rather than product by product is the difference between a checklist that works and one that gets skipped.

Where this fits with the rest

Storage and messaging leak into each other, since most of what gets posted in a channel is really a file. The storage category overview is worth reading alongside this. If a move is coming, the migration notes cover what happens to history and holds.

If cost is the pressure, most of the controls above sit above the entry tier, which the cost model covers. If the whole thing is under review, the selection method is where these questions belong in the process.

Common questions

Is it reasonable to ban links to external documents in channels?

Rarely, because people will send them anyway by another route. The more useful move is to make the sanctioned path easier and to make sure external sharing from your own storage is limited, so that a pasted link fails safely for anyone who should not have it.

Should we turn off direct messages?

Almost nobody does, and the ones who do find that conversation moves to personal phones, where you have no visibility at all. Better to be clear about what direct messages are not for, and to keep retention on them the same as everything else.

How do we handle a request to read someone's messages?

Decide the process before the first request, in writing, with whoever owns employment matters. Who may ask, who approves, what is recorded, and whether the person is told. Deciding this during an incident produces a decision you will not want to defend later.

We are small. Is any of this proportionate?

The inventory is, and it takes an afternoon. The guest list and the application list are where small organizations find their real exposure, and both can be reviewed by one person over coffee. Skip the policy document until you have read the lists.