One of the main objectives for the European Union (EU) when they developed the replacement for the Data Protection Directive 95/46 (from 1995), was to expand individual control over the use of personal data.

This can be seen in a broader view as an implementation of the right to one’s private life, as laid down in the European Convention on Human Rights (Article 8). The right to respect for one’s private and family life is also stated in the EU Treaty on Fundamental Rights (Article 7).

Norway has signed both of these agreements, and the Constitution of Norway implements these rights in Article 100 and 102 of the Constitution and in the Norwegian Human Rights Act.

Already in GDPR¹ Article 1 we see the connection between the GDPR and especially the Treaty on Fundamental Rights:

This Regulation protects fundamental rights and freedoms of natural persons and in particular their right to the protection of personal data

Article 1-2 of the GDPR

Observe the expression “rights and freedoms of natural persons“, which is very important throughout the Regulation and is used 31 times in all.

Before we go further into the subject of this post, it is important to state that Norway’s legislation on the processing of personal data was already compliant with the GDPR before the latter was declared as the new framework for the legislation in Norway. The Norwegian Personal Data Act (PDA²), as compliant with the GDPR, tok effect 20 July 2018.

First and foremost, the GDPR states that no processing of personal data shall be done unless the data subject has given consent (Article 6-1, a). Runbox obtains consent to registration of our users’ personal data when they sign up for an account and accept our Terms of Service.

The GDPR (Article 6-1, ff.) allows a controller – that is Runbox in our context – to process personal data when there is a legitimate reason for doing so, i.e. something that is necessary to use our services.

It is an important objective for the GDPR to secure one’s control of one’s own personal data. In this respect, the GDPR has given the data subjects eight fundamental rights (Article 15—17).

When implementing these rights in Runbox, we found that most of those were already there. However, the introduction of the GDPR provided us with a checklist and the opportunity to analyze our status, and to improve our services in this respect.

Our Privacy Policy provides exhaustive information about how we process personal data, but here is an overview of the data subject’s rights, and our implementation of them:

• The right to access (Article 15): Since Runbox does not collect other types of information than what the users register by themselves, they can easily check which personal data is processed. The data processing is only done in order to process your emails, and optionally your web site and domain name.
• The right to rectification (Article 16): You may at any time log in to your email account and change your personal information.
• The right to erasure (‘right to be forgotten’) (Article 17): You may terminate your subscription any time, and your account contents will subsequently be deleted after 6 months. Your personal details data will be deleted after 5 years in accordance with Norwegian accounting regulations. However, you may send a request to dataprotectionofficer@nullrunbox.com for immediate erasure of your account contents.
• The right to restriction of processing (Article 18): Runbox will never use your personal information for purposes other than providing our services to you, so restrictions are not necessary in our context.
• The right to be informed (Article 19): Runbox uses your personal information only in order to provide our services to you..
• The right to data portability (Article 20): In case that you wish to move to another email service provider and export your data, you will find information on how to do this through our services and documentation.
• The right to object (Article 21): Since we never will use your personal data for other purposes than to deliver the services you have agreed to, this right is implicitly fulfilled.
• The right to individual decision-making (Article 22): This article is intended to protect data subjects against automated data-processing that might involve profiling them based on personally identifiable information, which is something Runbox doesn’t do.

Regarding questions or concerns about our implementation of the GDPR, customers may use the email address dataprotectionofficer@nullrunbox.com as a direct channel to our appointed Data Protection Officer.

Some final remarks about consent: Runbox uses cookies in order to provide our services, and new users must give express consent to this on our signup page. On this page, and on the Account page once logged in, you may also give/revoke consent to future news and offers from Runbox.

In our next post in this series, we will consider our contractual situation regarding GDPR requirements. Stay tuned.

Footnotes

1. The GDPR means Regulation EU 2016/679 of 27 April 2016 on the protection of individuals with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46 / EC General Data Protection, General Data Processing Regulation. Article refers to Article in the GDPR, unless stated otherwise.

2. The Personal Data Act (the PDA) means the regulations that are currently in force in Norway for the protection of individuals in connection with the processing of personal data, which includes the implementation of GDPR in Norway (2018-07-20).

Continue Reading →

In part 3 of this blog series we described how we mapped the “world” of our operations, including the following components:

• Server infrastructure, including all servers and other hardware as well as the links between these.
• Software components that comprise our application stack from the operating system level to the front-end application level.
• Data networks, including how and where our serves are connected to the Internet, but also the Local Area Network at our premises.
• Data inventory, i.e. all personal data including customer and employee data, financial records, information about partners/associates, etc.
• Applications necessary to run the company itself, meaning software that is managerial in nature.

Access control concerns permissions attached to system-related objects. Within each of the components listed above, there may be several sub-objects — servers, software modules, data files, catalogues etc., to which restricted access should be implemented.

Creating an Access Control Table

These objects then form one axis of an Access Control matrix or table (ACT). The other axis of the table include organizational units, broken down into person-related objects, for instance segments or groups, but also individuals, for each unit.

After breaking these objects down to an appropriate level, we attached roles to each of these components. In terms of the GDPR, data processor and data controller are examples of roles to use in this context.

To each of the defined roles, we attached categories of tasks, for instance sysadmin, developer, and support staff tasks.

For our email service systems we found it convenient to structure the system-related objects in 3 main categories:

• General software.
• Application software.
• Personal data.

Within each of these categories there are various numbers of objects, to which access permissions are attached, comprising the Access Control Table for the realm in question. For other realms of our “world” we used a similar approach, resulting in a number of ACTs that implement a principle of least privilege.

With this the groundwork was laid for establishing various mechanisms for implementing the access control regime, in order to secure our most precious pieces of hardware, software, and data.

In our next blog post in this series we will look at Information and Tools for Implementation of Users’ Rights.

Continue Reading →

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.

Continue Reading →