This editorial was originally published on Jan 17, 2018. It is being re-published as Steve is at Technorama.

For most of my career, I've felt a tie to the systems I've managed or the code I've written. I've often said that a part of the code was mine, because it was something I'd written. Having some ownership of your work has often meant more pride in ensuring things are well implemented. The same thing goes for administering databases. When an employee feels personally responsible and accountable for  the database and its contents, usually they do a better job.

Most of us know that the systems we manage and the data they contain aren't really "ours", no matter how we might refer to them in conversation. We know that ultimately the data, applications, and hardware belong to our employers. Or, we should know that.

Apparently not everyone does. A contractor just pleaded guilty to stealing classified information from the US National Security Agency, about 50GB worth of data. This isn't a case of spying or malicious intent. Instead, the report is that the employee was a hoarder, just keeping copies of data for some unknown reason. Hopefully that's true.

Many of us will have copies of data that we use for different purposes. We might be building software, or testing queries, or some other task that requires data. We might want to conduct more in depth analysis in our spare time. Those are all positive goals, but none of them mean that we should have copies of data without authorization. We don't own the data, and we should always be sure if we are moving data to other systems, that those systems are secure and someone else has approved the action.

This becomes more important all the time. We have enough issues with data security and keeping our information away from hackers. We make plenty of mistakes with configuration in authorized development and test systems. There's no reason to add to the issues by treating data as our own personal asset, no matter how good your intentions.