When your provider talks about protecting your data with in-transit (SSL/TLS) and at-rest encryption, by default this means that they themselves (or their servers) have access to the encryption keys. This means your messages and files are necessarily decrypted and re-encrypted by the service provider, giving them full access to your messages and files.
Not only does this type of encryption give your software vendor access to your data, opening your organization up to significant 3rd party risk, but it also leaves your data vulnerable to insider threats and mass data breaches.
If an attacker hacks into either the server, or can phish/spoof/compromise a single sufficiently privileged user, you run the risk of the devastating "breach of one" equating to a breach of the entire system and all messages/files/data. This is, unfortunately, an all too common occurrence.
It is important to note that the combination of in-transit and at-rest encryption does not equal "end-to-end" encryption (E2EE).
This is an important differentiation because many software vendors misuse the term E2EE (either intentionally, or unknowingly). From both a security and compliance perspective, as numerous compliance frameworks including ITAR can require true E2EE, this misuse of the term is of paramount importance.
With end-to-end encryption, your data moves through HighSide's servers encrypted, and is stored encrypted. HighSide's servers, network and employees never have access to your encryption keys and do not have the ability to decrypt your messages or files.
The system is designed in such a way that an attacker can live inside of HighSide's servers/network perpetually without ever being able to decrypt your data.
HighSide never has access to your messages and files, only you and your explicitly intended recipients have the ability to decrypt your messages/files.