SQLServerCentral Editorial

The Road to Better Data Handling

,

Recently I was on an internal communication thread with multiple people at Redgate Software. We have various ways to keep our (semi-) distributed teams in touch with one another and handle issues. While email works, I think many people like Slack better for quick discussions. I appreciate that as a remote worker since I'm not around to hear a conversation around a desk. To be fair, with a busy staff, others often aren't as well, so a thread in Slack often saves details others can see later.

In any case, we had some issue. I don't know if this was a product issue with a customer or a communication item for our marketing group. No matter what it was, we had someone mention they could help if the first poster would provide details. The next message that I saw was great. It said something along the lines of

"Please do not post email details in Slack."

A gentle reminder, but one that was needed. It's great that we want to help others and work through problems, but in many companies we've played far too fast and loose with data. Not necessarily technical people, but often our customers have. Many of them will put sensitive information in "notes" fields in our databases. It's a hassle when we want to work with data that hasn't been put in a normalized space and must extract it somehow.

It's also a source of data leakage. While we might appreciate saving a quick note, these aren't secured communications, and more importantly, they provide yet another attack vector for problems if we lost control of the backups, archives, etc. Even worse, we could have gotten a request to remove emails and we now have another security risk with the email email searchable in old Slack messages.

This is likely a bit of an extreme example, but still a place where data handling should be better. We have secure systems for tickets or issues where we can store data. Or we can reference their information in another way. I've started doing this in GitHub, where we often log issues for SQLServerCentral users. Rather than putting in an email, I'll put a user ID or other identifier. If the user wants to delete their account, I don't want their email floating around anywhere it isn't required.

While it might be a bit more hassle to be careful with personal information, I think it's much better than treating it as unimportant and potentially having it disclosed in some security incident. Whether it's my email, tax ID number, or credit card, I'd want my own data handled carefully and am trying to do the same for others.

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating