This article is opinion only, and is no substitute for personalised, professional legal advice.
Our solution - it's in the detail
We must also be clear that this article references our specific solution for blocking EU web traffic, for which we have taken extreme care to remain compliant at every stage. It would be very easy for a less well-informed, less well-skilled or less compliance conscious developer to create an EU traffic blocking tool that failed to achieve compliance in many areas.
Personal Data in scope
The only personal data used by our EU Visitor Blocker (and any similar, honestly written solution) is a visitors IP address.
Storage of Personal Data
Our EU Visitor Blocker tool looks at a user’s IP address when a request is received, and uses this address to look up the country of origin. We do not have access to any more granular physical location data than the country, from which it would be impossible to identify a natural person. Once we know the country of origin, we discard the IP address data, and our servers are specially configured not to store IP addresses in any of the logs, meaning this data is purged permanently.
All of this happens in the first instances of a request being made, leaving us only with country of origin for a request – which means no personal data is stored anywhere.
Automated decision making and profiling
This is where many commentators believe the approach of blocking EU website traffic may fall foul of GDPR.
When inspecting article 22 however, we see the following:
- The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.
- Paragraph 1 shall not apply if the decision:
- is necessary for entering into, or performance of, a contract between the data subject and a data controller;
Section 2.a gives provision for overriding Section 1. On a website, your Terms and Conditions act as the initial contract between website owner and visitor. If your website Terms and Conditions of use states that your website is not for use by visitors from within the European Union, then blocking access to your site for said visitors may simply be an enforcement of the contract outlined in your Terms and Conditions.
Also, it could be argued (in most cases) that being unable to access a website will not produce legal effects on a data subject, or anything of a similarly significant severity. Lack of access to a website is, in most cases, likely to be simply an inconvenience.
What we do suggest, and make provision for in our EU traffic blocking product, is that you provide a contact email on your ‘blocked’ page – allowing any data subject with genuine concerns of legal or significant impacts, the freedom to engage with you to deal with these concerns.
The above suggestion is backed up by Section 3. of the same article:
- In the cases referred to in points (a) and (c) of paragraph 2, the data controller shall implement suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests, at least the right to obtain human intervention on the part of the controller, to express his or her point of view and to contest the decision.
Furthermore, given it is impossible to rule out inaccuracies in location determination (believed to be around 99.8%) after accounting for edge cases such as VPN or TOR network use, the provision of an option to contest the decision (e.g. our “I am not in the EU” button) allows the automated decision to be corrected if required, thereby giving the user ultimate control over the decision, placing control back in their hands.
Capturing data before the block occurs
In your HTML
One consideration when blocking EU website traffic is that care must be taken to ensure that the solution takes action before user data is logged.
This means that if you’re going to block an EU visitor from accessing your site, this decision and consequent action must take place before any of your Google Anayltics code, remarketing tags, Ad networks or other trackers / cookies have been able to fire.
We achieve this by providing a JavaScript snippet that acts as a blocking code, which when inserted correctly (right after your <head> tags in your HTML) will take the appropriate action before any other page content loads / fires.
Other similar providers have not accounted for this and care must be taken when choosing how to block EU traffic.
On your server
To complete the above approach, it would be best practice to modify your server logs not to collect IP addresses. If you don’t know how to access your logs, then you could argue that you don’t realistically have access to that data, but for us this is currently a grey area. We suggest speaking to your hosting provider if you’re not sure about any of this.
Data you’ve already captured
It has been correctly pointed out by several commentators that simply blocking access to your website will not achieve compliance, as you may have already collected personal data from the EU.
This is obviously, logically true, however we don’t believe it’s a reason that this approach won’t work.
By offering user a means of contacting you to make a Data Rights Request from your ‘blocked access’ page, users are still able to exercise their rights under Chapter 3. You must of course, be prepared to take action as requested within 30 days.
There is a serious consideration here however, if you suffer a data breach and EU user data is compromised, you have 72 hours to notify the data subjects and if, in the aftermath, you’re found to have been non-compliant, then there would be little you could say or do to defend yourself from penalties. Full compliance is the only genuine protection from this scenario.
You can start to protect yourself by trying to figure out what data you have, and where it is – then take steps to protect it, or get rid of data you no longer need.
Additional Information
Principles relating to processing of personal data.
Article 5 of the GDPR makes a number of clear points about how data may be processed. We believe the following apply when considering blocking EU web traffic:
- processed lawfully, fairly and in a transparent manner in relation to the data subject (‘lawfulness, fairness and transparency’);
Processing a user’s IP could be considered lawful under the need to enforce the Terms and Conditions of your website. It should be fair, as every user is subject to the same checks, and it is transparent, as the user isirected straight to a page that clearly explains what has happened. - collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’);
Data is collected for a clear, legitimate purpose (website functionality and/or enforcement of Terms and Conditions contract and/or legitimate business interest and/or other reasons), and is discarded immediately after initial inspection with no further processing taking place. - adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’);
Data collection could not be any more minimal in this instance. - accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’);
Data (IP) is as accurate as current technology permits, and is discarded almost instantly, leaving nothing for which to maintain accuracy. - kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; […]
Data is not kept at all in our solution. - processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).
Data is processed ‘on-the-fly’ and is not stored thereafter, mitigating the possibility of loss.