This may be a taboo take on systems like Slack and I know this will not be popular given the number of developers here, but I had to explain this to HR and it w

This may be a taboo take on systems like Slack and I know this will not be popular given the number of developers here, but I had to explain this to HR and it was not easy to convey these concepts in plain terms. Slack itself is just a chat system. Ok, what's the risk? By design, people (the user base, or admins, up to each company) can integrate third party applications. The permissions system allows chat data to flow to these third parties without any logging or visibility by the Slack business customer. So in effect, each employee (depending on perms) may on behalf of their company, relay all chat messages to third parties that their company does not have a legally binding agreement and NDA with. This is the actual risk with Slack (the product, not the company). So by design, employees can leak all the chats for all of the #public channels they are a member of and they won't even see it happening. Some companies choose to have admins review the third party applications and integration. "But they are #public, right?". People in a company don't assume that the public channels are really public in the sense that third parties outside of their company can see these messages. Employees may discuss very sensitive topics about their own customers that may not be appropriate to relay to extended parties that their company does not have mutually binding agreements and NDA's with. When you run your own servers such as IRC, Mattermost, etc.., the chat admins know what third party servers (if any) they are linking to. This does not preclude an employee from relaying their own data through their workstation, but that can be addressed by edge DLP devices for monitoring or mitigation. Even then, the employee knows exactly what they are relaying. When the chat system itself is a third party, and that third party allows relaying of user data, chat data to fourth parties, then by design, the system will always leak data. Slack does not alert members in a channel which bots are reading their messages real time and where that data is being stored and who is reading it and for what purpose. This also becomes a problem for data retention policies. The parties external to Slack may retain and use the data for as long as they wish, even if Slack purge data from a channel after a period of time. I see this as a legal quagmire. In terms of leaking private messages, those are also stored so that an admin in a company may review them by request. This is only an issue if Slack's servers were compromised. That risk applies to both self hosted and third party chat servers, though Slack becomes a much more juicy target by having the private chats of many companies. This is similar to the risk of routing non-static content through Akamai. Akamai had employees caught selling sensitive data to other nations which highlights the risk of aggregating private data through one transit provider that can decrypt your data or see your data in plain text. This risk could be mitigated by having short data retention policies, however that is the opposite of what users expect. They expect their messages to be around forever.