How to perform tests as an end user for a GDPR compliant hosting/website in three steps

Here are three steps to find out if a website technically complies with today’s European regulations

GDPR – current situation

Almost every Internet user today has heard of the European regulation GDPR. This came into force on 24 May 2016. For the conversion a goodwill time of 2 years was granted and should then be enforced. For some, thankfully, that’s not the case. If you look at the current statistics (, you can see that the majority of all hosters are not yet ready.

What can happen if a site does not comply with these regulations?

For companies which reside in Europe:

There are two tiers of administrative fines that can be levied as penalties for GDPR non-compliance: Up to €10 million, or 2% annual global turnover – whichever is higher; or. Up to €20 million, or 4% annual global turnover – whichever is higher.

For companies which do not reside in Europe and have European customers/clients:

Then sanctions, such as blocking of the website or blocking of the e-mail communication can be enforced and the contact to Europe is lost.


It seems that micro-enterprises are certainly not affected by these high penalties. However, it is advisable to follow these regulations, as we live in an automated time and who knows exactly whether one falls into such a guesser or not.

How do I know if my website is GDPR compliant?

Step 1:
Server communication must be encrypted

The communication for all servers within Europe and to Europe must be encrypted. Communication in plain text will no longer tolerated. For the encryption there are different encryption algorithms. The correct selection of such algorithms is decisive here. It is advisable to choose algorithms that can communicate with any server worldwide, otherwise it is the same as a person is talking in his native language talking to another person in another native language. The international standard PCI DSS (Payment Card Industry Data Security Standard) is best suited for this purpose. PCI DSS is for organizations that handle branded credit cards from the major card schemes. The requirements are even not so high as by others. The choice of algorithms for PCI DSS ensures that the servers can communicate with each other worldwide.

In addition to PCI DSS, there are standards such as HIPAA and NIST, which are also provided in Jaispirit’s hosting:

HIPAA (Health Insurance Portability and Accountability Act of 1996) is United States legislation that provides data privacy and security provisions for safeguarding medical information.

NIST (National Institute of Standards and Technology (NIST) is a metrology laboratory, and a non-regulatory agency of the United States Department of Commerce. Its mission is to promote innovation and industrial competitiveness.

To find out if the used server communicates encrypted and at least complies with the PCI DSS standard, we recommend the SSL Security Test from ImmuniWeb. Here is a direct link to this free test: It is also displayed whether the server meets the HIPAA or NIST encryption standards.

More implemented standards also mean a higher accessibility to communicate securely.

Step 2:
Is the email communication now safe and secure?

In addition to the encryption algorithms, other implementations exist to secure more than just email traffic: STARTTLS, X.509, SPF, DKIM, DMARC, DNSSEC and DANE.

To explain these now here individually would go beyond the scope of this article.

The Joint Research Centre (JRC) of the European Commission has developed an online tool to assess the security of email communication between providers: MECSA. By following a simple procedure, MECSA will allow you to better understand the technical capacity of your email provider to protect the security and privacy of your email communications.

Just go to: MECSA and submit your email address and follow the procedure.

Step 3:
Website communication must be encrypted – not only!

After we could determine the security of the server communication and our email, we take care of our web page, i.e. the web server. Here, too, encryption algorithms are used and standards such as PCI DSS, HIPAA and NIST are applicable. But not only. With the web server different HTTP headers are set, in order to receive a GDPR conform web page.

To explain these now here too individually would go beyond the scope of this article.

We recommend the Website Security Test from ImmuniWeb:

Note: Some of these test results might result in a ‘false positive’ result. Such as the WordPress version or used plugin version, for example. There are other website scanners, such as the WordPress scanner from, to check for false positives.

Cookie consent

Once the server, email and website communications have been secured, it is necessary for the website user to have a choice as to whether or not his website visit can be tracked. This is done with so-called cookies. According to GDPR (EuGH, Judgment in German) no cookies may be used already with the first web page attendance. Excluded from this are so-called essential cookies, which are necessary to execute the website correctly. The website user must explicitly give his consent whether or not he accepts cookies.

What is behind it?

The rejection of cookies is intended to protect the user from any violation of his privacy, in particular against the danger of “hidden identifiers” or similar instruments entering his device.

If the website user agrees to the use of cookies, the website operator can use analysis tools to analyse/track the user’s surfing behaviour. Cookies from third-party providers can also analyse/track the surfing behaviour of the website user. “Hidden identifiers” or similar instruments can enter his device.


If the above mentioned tests have been successful and the cookie-consent has been proper implemented, we see no reason, at least with regard to the technical implementation, to comply with today’s European standards with a clear conscience. On the other hand, we recommend to make up for these technical implementations.

There is the possibility, depending on which hosting you use, to implement them yourself. However, the correct implementation is very extensive and quite difficult, as the statistics show today. If you would like to give these implementations out of your hands, we look forward to seeing you as our future customer (Managed Secure Web Hosting).

Liability disclaimer

The information presented on these pages are not intended to be regarded as legally binding. Since pages published on the internet are often changed, the contents, representations and images/videos must be evaluated as found. Jaispirit Co., Ltd. assumes no liability for any possible damages, loss of earnings or other economic losses incurred as a result of the information, texts or contexts presented on these pages.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply