GDPR's Accountability and Governance Obligations
In my last blog post I discussed GDPR's 6 legal bases for processing data, its 6 data processing principles and the 8 individual rights that EU citizens have vis a vis the processing of their personal data in the EU. In this blog I am going to discuss the 12 provisions in the GDPR that promote accountability and governance for organizations that control and process personal data. Historically many organizations have followed best practices for accountability and governance within the context of IT security and privacy, but with the GDPR these provisions are legally required, i.e. must do "obligations" vs. nice-to-do "recommendations" and/or "guidance" and/or "best practices."
The end goal of these obligations is to minimize the risk of breaches and to protect data subject's personal data and to avoid an administrative fine. This will certainly require a significant amount of policies and procedures for organizations that control and process personal data, and also cause a "re-think" on how one builds systems and apps that process personal data, and how one interacts with data subjects whose personal data you process. While they may seem initially daunting to implement, these are, in the long run, well worth the effort to not only avoid GDPR fines but also the corresponding brand damage if a breach were to occur with your organization. And frankly, given how consumers feel about data privacy, the more you invest in this area, the happier your customers will be with your business.
But first, what is the definition of accountability and governance vis a vis GDPR? Accountability is about answering for actions and decisions taken regarding data protection, while governance is about the process and program of controlling and directing data protection, so obviously they go hand-in-hand. Many refer to the two combined together as the "Accountability Principle" vis a vis GDPR (note that specific term is never defined in the actual GDPR regulation). The European Data Protection Supervisor (EDPS) defines this principle as "as a principle which requires that organisations put in place appropriate technical and organisational measures and be able to demonstrate what they did and its effectiveness when requested" and "embodies that organisations live up to expectations for instance in the delivery of their products and their behaviour towards those they interact with."
Per the EDPS, these "technical and organisational measures" include: "adequate documentation on what personal data are processed, how, to what purpose, how long; documented processes and procedures aiming at tackling data protection issues at an early state when building information systems or responding to a data breach; the presence of a Data Protection Officer that be integrated in the organisation planning and operations etc."
What I am going to do in this blog post is expand on that list and go through the GDPR recitals and try to clearly enumerate what I see are the 12 Accountability and Governance Obligations found in the GDPR that must be met by Controllers. [Note: Controllers is defined in the GDPR as the organizations that determine the purposes and means of the processing of personal data]. [Another Note: References to “(#)” below refers to the preamble recital number.]
#1 Implement Privacy Notices and Information Rights in Transparent Manner.
A controller must be public and upfront and transparent to "natural persons that personal data concerning them are collected, used, consulted or otherwise processed and to what extent the personal data are or will be processed." (39) Furthermore, "the principle of transparency requires that any information and communication relating to the processing of those personal data be easily accessible and easy to understand, and that clear and plain language be used." And it should be clearly documented in these notices that the natural persons have rights with regard to their personal data that is being processed by the controller. In addition, "where processing is based on the data subject's consent, the controller should be able to demonstrate that the data subject has given consent to the processing operation." (42)
#2 Internally Implement Data Protection by Design and Default.
While #1 is about what they publicly articulate about data protection to data subjects, this one is about what controllers must do internally. The GDPR states that "the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default." (78). Policies could include "staff training, internal audits of processing activities and reviews of internal HR policies." Measures would include making sure that an organization has a lawful basis for processing personal data (i.e. one of the 6 legal bases for processing personal data — with most organizations' basis typically being either users' consent or a contractual relationship).
Note the word "Accountability" is actually only mentioned twice in the GDPR. The second and final reference to the word "accountability" in the GDPR is in Article 5.2, which states "The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’)" and paragraph 1 lists out the 6 data processing principles (lawfulness, fairness and transparency; purpose limitation; data minimization; accuracy; storage limitation; and integrity and confidentiality). So the measures must also include baking into the design of systems and apps that process personal data the 6 data processing principles (e.g. minimization aka collect only what you need for the purpose at hand).
Adhering to approved codes of conduct and/or certification mechanism may be used to demonstrate compliance (more on that later).
#3 Enter into Written Contracts with Processors
The reality is that controllers will probably not do all the processing of personal data, e.g. CRM data may be stored in a cloud provider. The GDPR calls these third parties "processors." The GDPR wants to make sure that GDPR's obligations regarding data protection are adhered to by these third parties. As such, controllers should only use processors that provide "sufficient guarantees" (81), meet an "approved code of conduct or approved certification mechanism," and the relationship "should be governed by a contract or legal act" under EU or member country state law that "binds" the processor to the controller with the commitment to be GDPR compliant.
#4 Maintain Records of Processing Activities
In order to demonstrate compliance, GDPR requires controllers and processors to "maintain records of processing activities under its responsibility." (82) The UK's ICO has some good templates to help document internal data processing. Article 30 lists what is required documentation-wise.
#5 Cooperate and Consult with their Supervisory Authority
Controllers and processors should also "be obliged to cooperate with the supervisory authority and make those records, on request, available to it." (#82). Supervisory authorities are the member states data protection authorities, e.g. the Information Commissioner Office (ICO) in the UK (well, maybe a bad example given Brexit ...).
#6 Respond to Rights Requests
I initially overlooked this one, but besides having to publicly post privacy notices and interface with the appropriate supervisory authority, a controller must respond to rights requests from data subjects: "The controller should be obliged to respond to requests from the data subject without undue delay and at the latest within one month and to give reasons where the controller does not intend to comply with any such requests." (52) This ties back into #1 above, which is not only about providing clear and transparent notice of what you will collect, clearly communicating the rights available to data subjects, and tracking consent requests, but also the ongoing fulfillment of any rights requests that come in. It also dovetails with #5 above, which is to cooperate with supervisory authorities if a complaint come through them via a data subject or if you have to notify data subjects and the supervisory authority of a data breach (#8 below). In other words, responding to rights requests become a lifecyle of interfacing with data subjects about their data that you process.
#2-5 above are considered by the GDPR as "general obligations" for controllers, but I would add #1 and #6 as inferred general obligations as well.
#7 Implement Appropriate Security Measures
Organizations should "ensure an appropriate level of security, including confidentiality" and also implement measures to mitigate risks, such as the use of encryption. (#83) No surprise here given we are talking about personal data. Note GDPR does not get into too many specifics of what security to implement (with exception of encryption and pseudonymization), and is focused more on the highlevel definition of security being preserving confidentiality, integrity and availability.
#8 Notify both Supervisory Authority and Users of Data Breaches
As recital #85 notes, a personal data breach may "result in physical, material or non-material damage to natural persons such as loss of control over their personal data or limitation of their rights, discrimination, identity theft or fraud, financial loss, unauthorised reversal of pseudonymisation, damage to reputation, loss of confidentiality of personal data protected by professional secrecy or any other significant economic or social disadvantage to the natural person concerned."
So, as soon as the controller becomes aware of the breach of personal data, the controller "should notify the personal data breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it unless the controller is able to demonstrate ... that the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons." The controller must also notify to the impacted data subjects (#86).
The last two are considered by the GDPR as "security of personal data" obligations.
#9 Conduct Data Protection Impact Assessments
Whenever a new app or program that uses personal data, or a new technology is introduced that involves the processing of personal data, the controller should "be responsible for the carrying-out of a data protection impact assessment (DPIA) to evaluate, in particular, the origin, nature, particularity and severity of that risk." (84) The outcomes of the DPIA will determine if the processing complies with GDPR. Furthermore, the controller should consult with the supervisory authority if the "processing operations involve a high risk which the controller cannot mitigate by appropriate measures in terms of available technology and costs of implementation."
#10 Appoint a Data Protection Officer
For organizations the process large amounts of personal data, the controller must appoint a Data Protection Officer who is "a person with expert knowledge of data protection law and practices" and who will "assist the controller or processor to monitor internal compliance with this Regulation." (97) They should be in a position to "perform their duties and tasks in an independent manner." They should act as the main point of contact with the supervisory authority.
#11 Adhere to Relevant Codes of Conduct and Certifications
The GDPR encourages associations to draw up codes of conduct as to "facilitate the effect application" of the GDPR. (98) Furthermore the establishment of certifications and data protection seals are also encouraged. As noted previously, "the adherence of the processor to an approved code of conduct or an approved certification mechanism may be used as an element to demonstrate compliance with the obligations of the controller." (81). Furthermore, "adherence to a code of conduct" would be factored in when a supervisory authority looks at a potential administrative fine against an organization.
#12 Adhere to the Rules of Cross-Border Data Transfers
That's awesome that GDPR enforces great data protection, but the reality is that the "flows of personal data to and from countries outside the Union and international organisations are necessary for the expansion of international trade and international cooperation." (101) And the reality is that many countries do not have the same high standard of data protection that the EU has. So a controller needs to be careful here, namely "transfers to third countries and international organisations may only be carried out in full compliance."
So what's an organization to do? Well if the data is being transferred to a country that the European Commission has deemed as having sufficient data protection laws that are enforced (known as an "adequacy decision"), then the controller can transfer the data. If not, "the controller or processor should take measures to compensate for the lack of data protection in a third country by way of appropriate safeguards for the data subject" including "making use of binding corporate rules" and/or "standard data protection clauses" that are blessed by the Commission or supervisory authority. (108)
Binding corporate rules are internal rules that adopted by multinational groups of companies engaged in a joint economic activity that must require approval from the supervisory authority. Alternatively, a standard data protection clause is akin to the EU-US Privacy Shield law, which was approved by the European Commission, and companies in the US self-certify that they will adhere to GDPR rules when it comes to data transfers.
....
OK! I think over the last two blogs I have hit the main meat of the GDPR and boiled it down to (a) 6 lawful bases for processing personal data; (b) 6 data processing principles; (c) 8 individual rights and (d) 12 accountability and governance obligations for controllers. Will dig even further into GDPR in my next blog post.