GDPR implementation part 3: Mapping our “world”

This is the third post in our series on Runbox’ GDPR implementation.

After having structured our GDPR project, the next piece of necessary groundwork was to map out status on relevant facts about important areas of our business. The reason is that it’s impossible to establish and maintain good security and privacy – and to determine GDPR compliancy — if the “territory” is not clearly described.

The “territory”

The “territory” in question was foremost and first of all,

  • The email service delivery system, that is the Webmail and backend systems and files – the development platform that is used, the components of which the system is built, the dependencies between the components, description of access points etc. – while being well aware of that the GDPR compliancy also includes Privacy of Design requirements.

Other realms that are necessary to describe were for example:

  • The economic system in which the company operates; i.e. mapping out the network of organizations with which our company is involved – including partners, associates, suppliers, financial institutions, government agencies, and so on – in order to serve our customers.
  • Server infrastructure with all physical links and channels, and not the least: All software components.
  • Data networks, including how and where our serves are connected to the Internet, but also the Local Area Network at our premises.
  • Data catalogue, including of course all personal data, that is, what kind of data are registered on customers and also employees and partners/associates as well.
  • Applications of all sorts necessary to run the company – applications that are managerial of nature.

Level of description

One problem encountered is how detailed the descriptions should be. Too many details will make the job unnecessarily big in the first place, followed by a lot of maintenance to keep the documentation current.

We chose to start with a “helicopter view”, to obtain an overview of the different realms with the intention to fine-grain the documentation depending on the requirements of the ultimate goal: To identify areas where privacy and security is of concern, ticking off issues that are well taken care of in light of the GDPR, or followed up with measures to improve the situation to achieve GDPR compliancy.

Of course, the GDPR Implementation Project is not a sequential one, as development projects seldom are. Therefore, from time to time we had to go back and adjust our planning tools when needs arose.

The next blog post in this series will concern our Information Security Policy.

print

Leave a Reply

Your email address will not be published. Required fields are marked *