Even after ensuring that you’ve covered all of the data subjects’ rights, GDPR has additional obligations for both controllers and processors. Here’s a short overview of the most important obligations under GDPR.
GDPR Art. 5: GDPR states that you (as the controller) are also responsible for demonstrating that you are actually following the rules of GDPR.
In the event of a data breach or another personal data related problem, being able to demonstrate GDPR compliance in your company should presumably lessen the wrath of your local data protection authority. However, we will see how exactly this plays out after May 25th.
Choosing data processors
GDPR Art. 28: You may only use the services of data processors who also follow the rules of GDPR. Furthermore, you will need a written contract between you and the processor. The processor has to help you to comply with GDPR as well as demonstrate compliance on their part.
Technical and organizational measures to support following data protection rules
GDPR Art. 24: GDPR states that you must implement “appropriate technical and organizational measures” to ensure compliance. This is a requirement that is meant to be open to interpretation, as every company is different and it does not make sense nor is it possible to define strict rules that apply to everyone. You should analyze the data processing activities in your company and figure out appropriate measures by yourself or with legal assistance.
Examples of technical measures include opt-in functionality (as opposed to “enabled by default”), anonymization, pseudonymization, etc.
Examples of organizational measures include: informing yourself and employees of GDPR rules, clear guidance how to react to requests connected to personal data etc.
Privacy by design
GDPR Art. 25: While developing or renewing your services or products, data protection rules should be taken into consideration from the start. By default privacy protection should be integrated to your services.
Records of processing activities
This is a tough one.
GDPR Art. 30 states that you need to keep records of all the activities performed with personal data. Creating and keeping this registry up to date is certainly not an easy task. Art. 30(5) sets an exemption to organization with less than 250 employees allowing them to not maintain a registry, UNLESS:
the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects,
the processing is not occasional, or
the processing includes special categories of data (i.e. sensitive data).
Unfortunately, the exception in Art. 30(5) should be interpreted restrictively. As processing is almost always intentional and not occasional, it would mean that pretty much ALL organizations need to maintain the registry.
The registry of processing activities should consist of two parts – a static registry and a dynamic registry.
The static registry should list all different processing activities performed. For each processing activity, it needs to describe the details of processing, categories of data, the purpose of processing, if there are any transfers outside the European Economic Area, descriptions of appropriate technical and organizational measures and data retention periods.
The dynamic registry is a log of all the activities which should include a timestamp and the person responsible for processing. There’s a free WordPress plugin that logs all administrative actions, which should theoretically cover most of the dynamic registry requirements: WP Stream.
Yes, this is a lot. No, there currently doesn’t seem to be a good way around it.
Cooperation with supervisory authorities
GDPR Art. 31: You are obliged to cooperate with data protection authorities. Failing to do so may lead to an administrative fine.
GDPR Art. 32: You and all your data processors have to ensure the safety and security of any personal data.
As mentioned before, you must implement “appropriate technical and organizational measures” to do so.
Examples of these measures would be conducting a security audit on your website, pseudonymizing or encrypting personal data or deleting data once you no longer need to store it.
GDPR Art. 33 and Art. 34: In case of a data breach (data leakage, unauthorized access, loss etc) you must inform your supervisory authority within 72 hours from the time you became aware of the breach. There’s a whole set of guidelines on how to document the data breach and how to inform your supervisory authority (which we will not cover in this post). You must also inform all data subjects whose data was breached if there is a high risk to their rights or freedoms due to the breach.
If you’re wondering what “high risk” means:
As explained above, notification of a breach is required unless it is unlikely to result in a risk to the rights and freedoms of individuals, and the key trigger requiring communication of a breach to data subjects is where it is likely to result in a high risk to the rights and freedoms of individuals. This risk exists when the breach may lead to physical, material or non-material damage for the individuals whose data have been breached. Examples of such damage are discrimination, identity theft or fraud, financial loss and damage to reputation. When the breach involves personal data that reveals racial or ethnic origin, political opinion, religion or philosophical beliefs, or trade union membership, or includes genetic data, data concerning health or data concerning sex life, or criminal convictions and offenses or related security measures, such damage should be considered likely to occur.
– Guidelines on Personal data breach notification under Regulation 2016/679 by the WP29 Working Party
So unless you are completely sure that the risk doesn’t qualify as “high,” we recommend informing your data subjects of a breach. Note that you still need to inform your local supervisory authority either way.
GDPR Art. 35 and Art. 36: If your processing activities might influence or pose a high risk to the data subject’s rights and freedoms, you must conduct an assessment of these processing activities and find a way to mitigate risks. In the context of a DIPA, “high risk” is explained in detail in these guidelines published by WP29.
GDPR Art. 8: You must try to verify either the age of your data subjects or authorization by their parent if they are underage. You probably don’t need to worry unless are offering a product or service aimed towards children. Read more about it here.
If you are a company, all of these rules apply to your employees as well. GDPR regulates the processing of everyone’s personal data, whether they are a customer or an employee.
How we help?
Most of these requirements are something that a WordPress plugin cannot solve. Depending on the size and scope of your business, they might require significant effort to ensure compliance to GDPR. However, if you need help with any of these items, we offer consultation and both technical and legal assistance – get in touch!