Ignacio Orts (EVERIS)
When creating a website, privacy and security should be taken into account. Both dimensions are highly connected and it is important to bear them in mind when an individual (in this case, a Researcher) or an organization (e.g. universities, private organizations, etc.) is going to create a website.
For this section, it is going to be assumed that the researcher does not have any knowledge of development, privacy, or security. Therefore, this section is going to be written attending to two different situations:
- The website is developed by a web designer; or
- Using a CMS (Content Management System, e.g. WordPress)
In both cases, privacy and security are difficult to implement when third parties are involved. For this reason, the researcher must acquire knowledge in both dimensions in order to avoid infringing data protection Laws.
The main objective of this section will be to provide enough awareness about the main topics related to privacy and security at the moment of creating a website.
Data protection: what to take into account at the time of creating a website
The Regulation which is going to guide this section is the REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (hereinafter, GDPR) together with DIRECTIVE 2002/58/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector (hereinafter, e-Privacy Directive)
e-Privacy Directive affects to a website, mainly, in to aspects:
- Marketing communications: here it is important, now, to follow GDPR requirements for consent; nevertheless e-Privacy Directive has its own local Regulation. It is important to review local requirements and assess when or when not marketing communications can be sent with or without consent.
- Cookies: for this topic, please read (include section of the guidelines referred to cookies within the new template) and follow the recommendations on how cookies have to be managed to comply with GDPR and e-Privacy Directive requirements.
Going back to the website, the process starts when the Researcher decides to create one, which represents the first milestone, namely “design phase”. In line with the GDPR, we can say that this design phase is where we must ensure compliance, which is not a recommendation but an obligation of Article 25 of GDPR: Data Protection by Design and by Default.
This concept was a bit confusing when the GDPR came into force on 25th May, 2018, but Data Protection Authorities (hereinafter, DPA) have been enlightening organizations in relation to what this obligation entails.
In short, Data Protection by design and by default consists in this case in applying the necessary guarantees from an initial phase (design of the website) if personal data are going to be processed. These guarantees pervade all GDPR principles. In this case, it is the controller (when applicable, researcher/university/other organizations where the researcher works) who has the obligation to comply with this Article and ensure compliance with all GDPR principles. We have a very good example with the Spanish DPA, who has developed a guideline.
Each principle derives in specific measures which we are going to be analyzed in this section.
Lawfulness, fairness and transparency principle
Within this principle we can differentiate two parts: Lawfulness and fairness on the one hand, and transparency on the other.
Lawfulness and fairness:
This principle implies that personal data can be processed if at least one of the legal bases identified in Article 6 of the GDPR applies. In the case of websites, normally, these requirements mean that it is necessary to obtain consent from the data subject.
If consent is required, the next website areas, among others, are normally the ones that require implementing an action in order to comply with the Regulation:
- Contact section: where the end user can contact the researcher in order to ask any question. The purpose of this processing activity is to use personal data of the end user in order to answer the question.
- Subscribe to newsletter: the purpose of this activity is to process personal data to send data subjects news regarding, for example, new research activities carried out during the last month.
- Career area: the purpose of this processing activity is to process personal data from candidates in order to perform the hiring process.
Consent requires an affirmative and positive action from the data subject (for example, clicking a checkbox accepting to share personal data with the researcher) but also requires being informed (developed later on here) and giving it freely. Freely given means that the options given to the data subject cannot be remarked, highlighted or in another way where benefits the process of these data.
As a requirement of the GDPR (Art. 7), the Researcher will need to keep a record of the consents gathered on this website, but also demonstrate compliance with the other requirements: informed, freely given, and unambiguous (Recital 32 together with Art. 7).
Consent must be proportional to the purpose for which the activity is carried out; it has to be specific. Giving consent to different purposes that bear no relation to one another fails to comply with GDPR requirements.
In the event that the research activity involves children, it is important to bear in mind that the GDPR establishes digital consent as the requirement for children when they are at least 16 years old (Art. 8). This Article can be modified by each Member State of the European Economic Area (hereinafter, EEA), so the Researcher must take into consideration local Data Protection Laws for this situation.
Anyway, when personal data are collected from children who are below the minimum digital age to consent to processing of personal data, parents or legal guardians must give consent on their behalf.
The GDPR establishes strong requirements about the information that must be given when personal data are gathered and processed. These requirements are stated in Art. 13 and 14 when personal data comes from public sources, which can be an important source for Researchers to obtain personal data for their activities. Nevertheless, for the case of gathering personal data through a website, Art. 13 will be the one applicable.
Going back to the transparency principle, which is closely linked to the duty to inform, it is important for the Researcher to understand that the information must be given in a way that is easy to understand; this means that an average user must be able to clearly understand what is going to be done with their data. Using user-friendly language helps to reach this requirement, together with graphics or pictures, even videos.
In addition, information must be easily accessible for data subjects. If the information is “hidden” or the data subject has to click on several sections to reach this information, the website will not be transparent about what is being done with personal data at the time they are processed.
Based on the different actions named in previous section 4.2.1, the following purposes can be identified:
- To answer questions from users of the website (contact section);
- To send the newsletter (subscribe newsletter); and
- To manage job positions.
These purposes will be applied to one or more processing activities. A processing activity is any operation or set of operations which is performed on personal data or on sets of personal data; therefore, we can group the aforementioned purposes in one processing activity: website management. This name is an example and the Researcher can name the processing activity as desired.
Data minimization requires not processing more personal data than necessary to fulfil the different purposes of the processing activity or activities identified.
As guidance to comply with the data minimization principle, three questions can be asked to help Researchers to perform a brief assessment:
- Can we fulfil the purposes already identified with fewer personal data?
- Does this reduced amount of personal data suffice to properly fulfil the purposes?
- Do we have enough personal data to properly fulfil the purposes?
By answering these questions, the Researcher will solely see if the minimization requirement is fulfilled or not; if the above questions are answered affirmatively, the Researcher must ultimately find out which personal data are strictly needed to fulfil the purposes identified.
In addition to this, the most common source where data minimization could be not fulfilled is at open fields: for example, from the contact section, anyone can send as many personal data as they want to the Researcher. This entails a risk, because these personal data will also be stored and maintained during the processing activity and once it’s ended. The recommendation here is to avoid as much as possible open fields and only use closed fields to gather personal data.
This principle states that when personal data are collected they have to be accurate and, where necessary, kept up to date. In practice, ensuring compliance with this principle seems a difficult task.
Data quality can be preserved using technology (e.g. data analytics), requiring extensive efforts in order to achieve compliance with this principle. For this reason, the Researcher should also bear in mind that this principle applies only when data are going to be processed (accuracy does not have to be ensured all the time), and to make this happen, there are two recommendations:
- The first one is to add a checkbox as a statement from the data subject side, indicating that they assure the accuracy of the personal data given. This should be mandatory for the data subjects.
- On the other hand, it would be highly advisable to include a section within the profile area on the website, giving the possibility for the data subjects to modify and update their personal data if there is any change during the activity to be developed.
These two tips will give the Researcher an easy way to comply with this principle.
The storage limitation principle requires that personal data not be stored longer than needed to fulfil the purposes of the processing activities identified. In addition to this, the Researcher can store personal data longer than needed if they are processed for archiving activities of public interest, purposes of scientific and historical research or statistical purposes.
Also, different Regulations can affect the storage of personal data, such as tax obligations or criminal laws. If none of these legal obligations or other exemptions to these principles operate, the Researcher will need to define a retention period for personal data in line with the proportionality of the purposes pursued.
For the common purposes and processing activities already identified in this section (website management), the recommendation will be to not store personal data for longer periods; besides, this information should be deleted once the purpose is fulfilled. In case that personal data is used for research activities, the recommendation is to transform personal data to aggregated data (using de-identification protocols such as anonymization) where the GDPR does not apply, since aggregated data are not personal data.
Lastly, the Researcher must be aware that, if personal data are shared with third parties, they have the obligation to delete the data once the professional relationship ends. Additionally, backup policies from different solutions such as Microsoft OneDrive should be reviewed in order to ensure that data are deleted. Backups may store these data without the knowledge of the Researcher.
Secure the information: minimum tips to ensure information security when creating a website.
In this section, we define some cybersecurity recommendations to bear in mind at the time of creating a website.
First, it is necessary to differentiate between cybersecurity and information security, which is a common mistake. Information Security deals with the processes and methodologies designed to protect any information, regardless of its format. Cybersecurity, on the other hand, is concerned with protecting digital assets; everything encompassing network hardware, software and information that is processed, stored within systems or transported by internetworked information environments.
About the aforementioned terms, we can say that information security is part of a broad concept of cybersecurity. In this sense, we also need to safeguard cybersecurity in order to protect all the assets involved during the processing of personal data and grant a secure environment. Nevertheless, in the world of information security and cybersecurity, we cannot affirm that we are completely safe or that the risk of materialization of a threat or event that may harm our assets is 0.
In terms of the compliance side of security, the GDPR indicates that security of processing is an obligation (Art. 32), and forces all persons and organizations to implement a high level of security in order to grant the confidentiality, integrity and availability of personal data. Integrity and confidentiality of data processing is also a GDPR principle (art. 5.1 f). However, the GDPR does not specify which measures should be implemented to grant these security dimensions further than encryption and anonymization. In fact, the controller and the processors are the ones responsible for defining these measures. Without any guidance and understanding of what is necessary to comply with the Regulation, this is a rather difficult task.
Our main goal is to offer guidance on the most important aspects to bear in mind for cybersecurity and information security, considering the most common types of attacks on websites.
The first thing to think about is providers. As already mentioned in the introduction, the most common option to create a website are:
- By means of a CMS (e.g. WordPress)
- A web designer
In both situations, we will be externalizing the service and sharing personal data with third parties. The CMS and the web designer would be a processor according to the GDPR, which entails an obligation to normalise this relationship with a contract, stipulating all the requirements set forth in Art. 28.
Big solution providers such as CMS have already addressed this issue. Thus, they offer their customers some solutions to comply with Article 28 requirements.
In the scenario of hiring a web designer, the Researcher may face two situations that may change the management of the contract:
- The web designer works for a company; or
- The web designer is a freelancer.
In the first case, the company may send a template to the researcher. This is because companies are used to working with other companies or customers, where processing personal data and signing a Data Processor Agreement is a common task.
Then, if the company sends a template, it is important for the Researcher to carefully review the contract and see if all the requirements of the GDPR are met. To be able to do this, the best option is to compare a standard Data Processor Agreement already approved by a National Data Protection Authority (example given in the last page: Danish Data Protection Authority).
On the other hand, when hiring freelance web designers, it may be necessary to send them a template, as they are not so used to dealing directly with legal compliance. It is also important to raise the freelancer’s awareness about the duties arising from the contract, in addition to those corresponding to the Researcher, in order to ensure compliance throughout the whole professional relationship.
Information Security is an important part of the contract derived from an obligation of the GDPR. To ensure the confidentiality, availability, and integrity of personal data together with the rest of the legal obligations contained in the Regulation, the Researcher must only hire and work with those processors which offer a high level of security.
To reach this goal, the common practice is to include a “Compliance Checklist” as an addendum to the contract to be fulfilled by the processor. The recommendation here is to hire those processors which fulfil the entire checklist, meaning that they offer a high level of compliance. This checklist also includes some organizational measures derived from International Standards such as ISO asking for security.
Also, when hiring a web designer or choosing a CMS for your website, it should not be forgotten that the Researcher entails a controller position, regarding data protection roles defined in the GDPR. The controller holds a dominant position over the processor, then, regarding processing activities of personal data, the processor must hear and follow the instructions of the controller.
Deeping into cybersecurity: CMS security tips
Once we have legally regulated the relationship between the Researcher and the processor (in this case, a CMS), we should say that these tools are not secure by default even though there are security measures in place based on the best standards in the market.
Nevertheless, there are a few tips that will improve the security of your CMS:
- Make sure to update your CMS!
Technology is constantly changing. This has positive consequences but also negative ones in terms of cybersecurity; hackers can take advantage of old systems (as well-known as legacy systems) to discover vulnerabilities in the code which may allow a potential attack. Companies are normally aware of this, and they make updates to patch these vulnerabilities and keep the environment safe. Within your CMS management dashboard, you will have to regularly check out the update section and install those which improve security.
- Passwords are one of the first steps towards cybersecurity!
It may seem to be a very basic topic, but people still use default or easy passwords (e.g. 1234/admin/password, etc.) to access the environment where their sensitive information is stored and processed. Within the FAQ section, you can learn how to build a robust password and avoid hacker attacks.
- Roles and responsibilities: do not grant access with high privileges if not needed!
You may fall under the situation of working with a team, consisting of people who need to work in this environment and make changes or management of the web site. Make sure to manage within your control dashboard these privileges following the concept.
- Use backups to ensure availability of information!
In the event of losing information, receiving an attack, or any other situation that may lead to the unavailability of the information of the website, backups are the solution to maintain this dimension untouched.
- If you have the chance, carefully choose your host!
The best option is that your host be located in Europe. If you choose, or for any other reason it is by default located outside of the European Economic Area, you will be making international transfer of personal data, which requires taking specific measures into account (not legal and technical). You will have to make sure that your host uses a valid certificate for your website (SSL/TLS certificates, further explained in section 4.3.3).
As already mentioned, within the cybersecurity world, we cannot talk about 0 risks. All these tips to be aware of while building a CMS for the web site might be not enough to completely secure your website.
The recommendation here is to have support, if possible, from cybersecurity professionals who are always up to date regarding new vulnerabilities and security improvements, and also to have the necessary tools to improve security on your website.
If not possible, the five tips above should give a minimum of security for your website.
Web design: basic tips to develop a secure website
In the event that the Researcher prefers to hire a company or a freelancer specialized in web design and development, it is a common mistake to think about a web designer as a developer.
A web designer may have knowledge on development but focuses on front-end design. Front-end design refers to the work done on the website interface, not anything related to the back-end or connections to the database, etc. This is done by a back-end developer, who focuses on writing all the code that manages the relationship between the website and all systems that work to make it run.
That said, some tips can be provided to the developers during the web creation project:
- If the website allows the submission of comments or any other interaction with the user, it is important to implement captcha systems. These systems prevent a machine from acting as a user to facilitate the usage of malicious or marketing spam.
- If the Researcher includes the possibility of downloading any kind of material (e.g. brochures), it is important to use software in order to delete metadata that these documents store, because it can contain information that a hacker can use to exploit such as user names, directories, etc.a
- Follow the instructions already given in the CMS section for robust passwords.
- Be able to store logs in order to facilitate them to authorities for investigation in the event of an attack.
- Back up all critical elements that allow the website to run, and do not forget the database used for it. These backups must be stored in a different place from the original data, regularly verifying that these backups are made correctly. If the website is managed by a third party (which could be the situation for the Researcher), the obligation to make backups must be stipulated within the contract.
- If the Researcher is going to use a complex web environment within a project, it is important to differentiate between the pre-production environment, where tests are performed in order to verify the further changes or features that are to be implemented, and the production environment. This will make it possible to apply patches (pre-production environment) if vulnerabilities are detected, and to verify the modifications and features changed before making them visible to users.
- For the back-end developers, it is important to follow a Secure Software Development Lifecycle and Secure coding routine. By using these methodologies, the Researcher will make sure to meet basic security requirements.
- Control the connections made by the website. Connections external to our website must be administered and controlled by a firewall with a proper policy configuration. This applies regardless of who manages the website (Researcher or a third party);
- If possible, perform technical audits to search for vulnerabilities. This is normally performed through a pen testing, where specialized professionals (ethical hackers) search for vulnerabilities to be corrected in order to avoid attacks.
Encryption: the importance of the SSL/TLS certificate
As already mentioned, the GDPR only refers to two security measures as a basis to ensure the integrity and confidentiality of personal data: encryption and anonymization.
Encryption is a broad concept that can be applied to different assets in several ways. Focusing on website encryption, what we need to be aware of is the connection between the website and the database.
Using SSL/TLS (Secure Sockets Layer/Transport Layer Security) protocols allows ensuring security by encrypting data traffic between a web browser (e.g. Firefox) and a web server (where all the elements of the website are stored). Basically, these protocols protect the data processed within the website using two keys (public and private), making it unlikely for third parties to access data without the proper rights.
When the protocol is implemented, the website will earn the status of HTTPS (HyperText Protocol Secure) meaning that this site is protected by an SSL/TLS certification.
SSL/TLS protocols do not only transport data securely (converting plain text to ciphered text) but also acts as an authentication between the receiver and the sender, allowing client-server applications to communicate in a way designed to prevent eavesdropping (interception of communication between two parties) and tampering (modifying data through unauthorised channels), among other things.
SSL/TLS encryption protocols are the most commonly used in the context of Internet connections. Nevertheless, it should be noted that SSL 2.0 and 3.0 are no longer valid due to the detection of huge vulnerabilities; it is recommended to only use TLS protocols for encryption.
1For further information, please visit https://www.aepd.es/sites/default/files/2019-12/guia-privacidad-desde-diseno_en.pdf ↑
2By legal basis we mean the legal justification that allows us to use personal data. Theses legal bases are the following: consent, the performance of a contract, for compliance with a legal obligation¸ to protect vital interests, or for the performance of a task in the public interest or in the exercise of official authority vested in the controller; this legal basis can be found at Article 6 of GDPR ↑
3As already mentioned, other legal bases can be identified as the grounds to process personal data, which may not require the same actions as consent. Consent is the only legal basis which requires a positive and affirmative action from the data subject. ↑
4Also, these consent requirements are complimented by specific guidelines from the European Data Protection Board. For further information, please visit the following link: https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en ↑
6Following art. 28.8, the Danish Data Protection Authority has published standard clauses for the relationship between controllers and processors. It is the only Data Protection Authority that has proceeded to publish these clauses in Europe. For the Researcher’s guidance, it may be useful to have this material, which can be consulted at: https://edpb.europa.eu/sites/edpb/files/files/file2/dk_sa_standard_contractual_clauses_january_2020_en.pdf ↑
7To this end, the Information Commissioner Office of the UK Data Protection Authority offers two resources: one to assess processors’ compliance (https://ico.org.uk/for-organisations/data-protection-self-assessment/processors-checklist/) and another for information security (https://ico.org.uk/for-organisations/data-protection-self-assessment/information-security-checklist-report/); these two checklists can offer guidance for Researchers on what has to be sent to processors. ↑
8Please, for further information on storing your data properly, please read (include reference to section II.3. Storing your data within the new template) ↑
9Databases are also a critical asset where personal data is stored. Therefore, is important to consider specific issued while creating a data base. Please, follow section III.3 “Creating a database” recommendations. class=”references”↑
10https://owasp.org/www-pdf-arc class=”references”hive/OWASP_SCP_Quick_Reference_Guide_v2.pdf ↑
11Please read Security and Cybersecurity FAQs to understand how encryption works, the different types, and also the applications. ↑