Company Culture: Data Security

The Case: Processes Are More Important Than Results

In my first job as an IT professional, I had a good idea where data security was an important part of the proposition. So, I went with my idea to a senior colleague who was responsible for the security of servers and databases. His answer was simple and still holds true today:

“If you want to protect a database with information, you should store as little data as possible, only allow uninteresting data, and not allow users.”

Here is a good example from the GGD, a few weeks ago.

There are now quite a few possibilities to make user access fairly secure. Fortunately, because without users, our software is not very useful. At Payt, we talk weekly about new functionalities that provide a lot of user convenience but require a concession to data protection. Our data is (unfortunately) also interesting enough to have a lot of value, so we are ISO27001 certified. This means that we comply with the international standard for Information Security Management System (ISMS). I would like to describe an example of what this can lead to within the company.

We were only 20 employees when we obtained the certificate. We had prepared a lot and written a well-thought-out security policy. Within a year, someone at Payt thought that this policy document should not only be known to the policymakers but also to all other employees. And the best way to do that was to have everyone sign it. For this, we found that a general text about confidentiality in the employment contract sufficed. Not long after, there was an extensive list of all hardware, software, and processes for every new employee that had to be completed (an intake list). For a year now, one person has been responsible for having all access visible. The intake list has been replaced by an extensive authorization matrix. To make the process of access where security is involved a bit easier, we have an access_request channel in Slack. Sounds good, right?

For a new colleague, I requested access in the access_request channel. I wanted to impress her with our speed of action so she could get off to a flying start. After a week, there was still no access. Inquiry taught me that a developer had decided not to grant this access because the new colleague had not yet signed the security policy. And shortly after, I received a reprimand that I had also not filled in the authorization matrix.

It is much harder to work result-oriented than process-oriented. You can simply follow a written process. And if you follow it well, you are never at fault.