Comms groups inevitably become access groups

IT teams create two types of groups that seem logical in theory: communication groups and access groups. "Comms groups" are meant for project updates and discussions, and so are easier to join. "Access groups" are meant for actual system permissions and are much more tightly controlled — managed by IT, and with approval requirements set by security.

The theory sounds reasonable: keep the friction low for people who just need to stay informed, but maintain strict controls for actual access.

This doesn't work in practice. Comms groups always become access groups. It's not a matter of if, but when.

How groups actually get used

This happens because in many platforms, the same group management systems that handle communication also control access. In GCP, your Google Groups directly become your IAM groups. In Slack, when you share a document with a channel, you're granting access to everyone in that channel. A comms group for an offsite ends up being used for access to a new tool built during the event. A social activities group for the Boston office becomes the access control for the newly installed bike racks. IT teams try to prevent this — usually by creating naming conventions like “Project-X-COMMS-ONLY”. Just like your file naming convention — you know, the one where “Filename_FINAL_v3” gets superseded by “Filename_FINAL_v4_ACTUALLY_FINAL” — it's a beautiful lie that doesn't work.

Users will follow the path of least resistance. When you need to grant access to a system, and everyone who needs access is already right there in that group, you use it… even if it just happens to be the COMMS-ONLY group. (It’s rare that the reverse happens.)

Why is the comms group often a better fit for access? Comms groups map to how people actually work, and often, access groups don't (but they should). Access groups tend to be tightly managed to meet specific compliance or security requirements. As users often need to request access to these, they become bureaucratic obstacles that get in the way of actual work.

Comms groups, on the other hand, naturally follow project and team lines — they contain the people you need input from or need to keep informed. IT teams typically want these groups to be easy to join since they enable business operations and seem low-risk (even when the conversations themselves involve highly sensitive information). Our access controls end up mirroring our communication patterns, whether we plan for it or not.

The gap between groups and permissions

Part of the reason IT teams try to create this separation is that we fundamentally lack visibility into what we're actually granting when we add someone to a group. The system managing groups (often your IdP) isn’t the same system where your permissions live (often an application).

This is where security breaks down: when you add a user to a group, you're making an access decision blind to the actual access being granted. You can't see what downstream permissions a group membership grants — access to customer data, financial data, or other sensitive resources. (Look at Google Groups’ newly added security groups, which perpetuate this naming separation while offering only limited restrictions. It's too little, too late — and too confusing to solve the real problem.)

IT teams try to separate comms and access groups to reduce what they need to manage, control, and audit, but sensitive access inevitably creeps into places it doesn't belong.

Design for reality

So what can you do? Well, stop fighting this pattern, and accept the inevitable. Instead of pretending comms and access groups will remain separate, create unified project- or team-based groups from the beginning. Make it explicit that joining the project group means both receiving comms and getting relevant access.

The goal isn't to make it even harder for users to get access — they already find it plenty frustrating. Acknowledge that comms and access groups are one and the same, and design proper controls from the beginning.