For a good portion of my career I was responsible for the payroll data of hundreds of customers. In the beginning it seemed a very solemn responsibility, but I quickly got involved in the day to day and payroll data was just data. We kept it safe and made sure only the right people had access, but this is true of all of our data, right? Our main application was from a third-party vendor and it was a locally installed application that used SQL Server as the back end. About 1 in 4 new clients would ask the same question when we would set them up with the payroll software.
How do I keep the IT department/DBA from seeing the payroll data?
My answer was always the same, “You can’t.” I would try to temper this based on exactly how paranoid the CEO or Office Manager sounded, but I wanted them to understand that I had just spent a day or two working with their IT people to get the application installed and their own people would be the first line of technical support for SQL Server issues. If they wanted to have that support available to them they needed to trust their DBA (sometimes now a new accidental DBA with their first SQL Server install). Most people accepted this, but their were some times when you could tell the management really didn’t trust their IT person. I can’t remember ever backing out of a new client install for this reason, but I am sure that sales were lost earlier in the process when this question came up. There was of course a web-based version of the application where no one at their company needed to be responsible for the database, but it was not as feature rich and typically the people who were nervous about trusting their own IT had issues about putting their data “out on the internet.”
It was easy to sympathize with our clients because we were a small company ourselves and the owners had to trust a very shady character with our internal payroll data, me. We used our own software, but we kept it in a contained environment so that only myself, the owners and the CFO had access to the data. I would occasionally access the data through the application if I needed to help set something up or troubleshoot, but for the most part I never touched it after setting up the SQL database and a maintenance plan. I am very proud to say that I worked at that company for eight years and I have no idea how much people were getting paid (unless I hired them).
One of the items Chris listed to discuss was the idea of an Ethics Statement for DBAs. I like the idea of a written, formal statement of ethics – in theory. The biggest reason for having something like this would be to make the upper levels of a company sleep easier at night and give them something to point to for outside parties. “Our DBAs are beyond reproach. They have signed the DBA code of ethics.” Coincidentally, this week we are going through our annual Ethics course at my current job. Once a year every employee in the company takes an online ethics course and has to pass a quick quiz after they are done. Taking the course today I realized that the problem with a formal code of DBA ethics is the same as this annual class. If you need an ethics class or a signed code of ethics to help shape your behavior it is probably not going to change how you behave.
However, I have to admit as a symbolic gesture I still kind of like it. I could see PASS adopting something that you have to agree to before becoming a member. While it wouldn’t really be enforceable it would add meaning to the term “Professional” in Professional Association for SQL Server. The SQL community is a pretty close knit group if there was a member who violated the code of DBA ethics (written or unwritten) it would probably halt their career. Of course the great part about the SQLFamily is that I can’t envision anyone doing anything like this.