Slack is huge, showing a massive growth rate since its launch—and it’s a huge ediscovery problem.
Why? Unlike the data within familiar ediscovery formats such as email, the data in Slack is unstructured. This makes it hard to figure out who data custodians are, difficult to set limits on scope, and basically impossible to handle with traditional ediscovery tools.
To make a tough situation tougher, if you do manage to solve the ediscovery problem by retaining Slack messages for legal holds, you create an information governance problem by keeping additional data (most of it irrelevant) past its scheduled deletion date. Or, on the flip side, if you try to maintain record retention schedules and delete older data, you create not just the possibility but also the near certainty that you’ll spoliate relevant data that was subject to a preservation obligation. Hello, rock, I’d like you to meet my friend, hard place.
But, as they say, just because it’s hard doesn’t mean it’s impossible. Indeed, it’s absolutely possible to manage both ediscovery and information governance with Slack data—though you might need a little help.
These three easy steps will get you started.
The first step in managing Slack data is getting clear about what Slack data you care about, which means you’re going to have to think about who your custodians are and what the scope of discovery should include.
Ordinarily, you need to identify custodians for an ediscovery matter—Bob in sales, Cindy in accounting—but you don’t need to define what it means to be a custodian. When you’re putting a legal hold on an email account, the owner of the account is the person who sent or received those messages, thus, of course, the custodian. It seems a bit silly to even have to say it, right?
Slack is different. Aside from direct messages in Slack—which do operate essentially like email in terms of who sees them—most Slack communications occur on public or private “channels.” Slack channels are the bulletin boards of the digital world. Anyone who’s a member of a channel might see any message (or, for that matter, every message) in that channel. They may never contribute to the channel, making them practically invisible, but they can still be there quietly reading. Or not; you can’t tell whether someone has read a message in a Slack channel unless they’ve directly responded to it.
So what Slack messages belong to a particular custodian? If you’re putting a legal hold on the communications from Bob in sales, what Slack messages should you include? In our view, you have to include every channel that Bob belongs to as well as his direct messages. That means you might suddenly be talking about half of your Slack data for just one custodian.
Then there’s the scope of a hold. According to Federal Rule of Civil Procedure 26(b)(1), the scope of discovery encompasses “any nonprivileged matter that is relevant to any party’s claim or defense and proportional to the needs of the case.” So you grab the messages that contain the keywords you’ve identified with opposing counsel, right?
Well, no—or at least, you can’t stop there. Sure, you need the messages with keywords, but most Slack communications are one-liners rather than complete thoughts. The meaning or impact of a given message might take screens of text to unfold. That means your scope can’t be limited to just the messages with keywords; it must encompass all of the surrounding context.
While you’re sorting out these definitions, adopt Slack use policies that will give you at least a modicum of control over what happens on Slack and where it happens. Consider including the following terms in your Slack policy:
Finally, it’s always a good idea to remind employees that all of their Slack messages—like their emails, work-related text messages, and work documents—may be subject to discovery. Slack feels casual and “off the record,” but it’s not. Before writing anything, imagine your words being read aloud to a jury; do they still sound clever and necessary? If not, it might be best to keep that thought to yourself.
Once you’ve defined your custodians and determined how you’ll scope a preservation effort for Slack data, it’s time to plan your legal hold implementation. Where will you preserve Slack messages and how?
Slack has an option for legal holds, allowing users to retain data that’s subject to a hold even if they’ve implemented a record retention schedule. (We’ll return to this in step 3, below.) But there’s an enormous problem with Slack’s legal hold functionality: it’s either on, or it’s off. If you only have one legal hold, that’s probably no big deal. Turn the hold function on when your trigger event occurs; turn it off when the matter has concluded.
But the moment you have multiple, overlapping legal holds, you find yourself in a permanent state of hold. You can’t lift one hold to delete outdated messages without also lifting any current holds, potentially spoliating relevant discoverable data.
That’s why we recommend that all legal holds be maintained outside of Slack rather than keeping all messages within the app. That requires creating a backup of the channels to which your custodians belong, perhaps limited (to some extent) by keywords or relevance filters—but having that external backup allows you to delete messages in your Slack application as they pass your record retention expiration date.
To export data outside of Slack in a meaningful, usable format, you are going to have to make some technology investments. For starters, you can’t get away with the free version of Slack—which only gives you access to your most recent 10,000 messages anyway.
Instead, we recommend that you upgrade to Slack Enterprise Grid, which allows access to Slack’s discovery API (application programming interface). That’s what lets you export Slack data into other ediscovery tools and enables more sophisticated Slack data management.
Okay, you’ve defined your terms, implemented some Slack use policies, and figured out a way to preserve potentially discoverable Slack data outside of the app. Now there’s just one step left—and fortunately, it’s an easy one: establish a record retention schedule and set up your Slack data to self-destruct once it exceeds its expiration date.
Slack has an internal function that allows you to set automatic record retention and deletion schedules. That means you can have messages deleted as soon as they exceed 30 days, 90 days, or whatever period your organization believes best balances the risk of retaining outdated data against the value of that data. And again, having your Slack data on an external legal hold gives you the option to implement this defensible data deletion option within the application itself without risking the loss of any data subject to that legal hold.