In previous blogs, we talked about few key requirements of the GDPR. We explored the terms GDPR, controller, processor, personal data, legitimate interests, consent, and privacy rights.
I personally got confused and amused by a term ‘Data Subject’ used in the regulation. Data Subject is an EU resident whose personal information is being collected or processed. I personally did not like this term as it is very impersonal. It is expected by the regulation that the language used in the ‘privacy notice’, ‘consent forms’ and many other instruments for communicating with the EU citizens should be very simple and easy to understand. I felt the language used by the regulation should have been simple and easy to understand for the people for whom it is meant and for the organizations which plan to comply. After all regulatory laws are meant to be like that. So, Data Subject is an entity, which is a living person in EU.
Naturally on first thought, we need to identify who we are and what are our activities. Does the GDPR apply to us? To ascertain this we need to prepare a list of processing activities we perform in our organization. Complete an inventory of functions and projects dealing with the personal information and also take a note of the type of processing we engage in. This could be done using an Excel spreadsheet to record list of processing activities in Marketing, Sales, HR, Projects/Delivery.
Once this list is generated, start looking for a lawful base to process the data and record them. These reasons have been identified in my previous blogs. It will be useful if you identify and record responsibility for collecting/processing the data, label the category of data and identify storage locations of this data in the same inventory list. There is a possibility of this data being transferred to internal functions or to an outside vendor for further processing. Recording it will therefore help. Location where data is getting processed must be recorded. If it is outside EU, data protection clauses must be agreed, contracted and adhered to. Special care must be taken for sensitive personal information like medical records, insurance policies, etc.
Also it is important to add retention period for the data that is being collected and processed. Justification for extending this retention duration must be backed by statutory and regulatory requirements. It will be highly desirable to record, how this data will be disposed of once retention period is over.
Additional columns mentioning links to various policies and security controls, in the same list, will reduce your time to search for appropriate documentation in your organization.
Expect several abbreviations to be thrown around as you prepare to review the regulation. I would like to unveil some of them for you here.
Data Protection Officer (DPO) - Though regulation says, there is no need of a DPO for an organization having less than 150 employees, it depends on how much and what kind of personal information you deal with. The DPO is a central authority and point of contact for all GDPR related matters. ‘Data Subjects’ can access DPO for all their queries and Data Protection Authority (DPA) will get in touch with DPO, in case of complaints related to data breach and violation of GDPR.
Data Protection Authority (DPA) - These are country specific public authorities ensuring application of data protection regulations. They are experts and provide advice on issues of data protection. In EU they handle GDPR and country specific law violation complaints. I searched for DPA in India and could not find anyone appointed as of yet.
Data Subject Access Request (DSAR) - Individuals or their legal representatives can make a request to the organization, which is controlling and/or processing their personal data. As the name suggests this request is for accessing their data to ensure it is processed as per the privacy policy declared and consent provided. These requests can come through various channels including via email, letter, corporate website, fax etc. In Germany even verbal requests are considered. These requests can be for modifications, deletion, porting data to different organization, verification of processing etc. This request must be fulfilled within 30 calendar days. Organizations can charge reasonable fee if addressing these requests require sizable efforts or if the requestor is repeatedly submitting those requests or for requests that are beyond the scope of GDPR or the organization. Organizations can decline this request in case a law prevents disclosure of the information. DPO is responsible to analyze all these requests and take necessary actions.
Data Protection Impact Assessment (DPIA) - Functions handling personal information must perform this activity with the help of DPO. I think asset management classification done on the basis of ‘CIA’ (Confidentiality, Integrity and Availability) for ISO 27001 will be helpful over here. Treat privacy information as an asset and not liability; classify it, and identify vulnerabilities and threats in the system responsible for data breach. Those are the risks, which need to be addressed. Take mitigation actions by placing appropriate controls. DPIA will help organizations take preventive steps rather than doing firefighting at the end of data breach. Our planning will convince DPA that our organization has the intent to protect the privacy information. Capturing learnings from incidences and updating the risk register on an ongoing basis will help meet GDPR requirements.
Do it for all functions and processes once you build the inventory list of processing activities. Do it again if there is any change in the privacy information. Do it again when risks are updated based on learning from incidence closures. Revisit for review at regular frequencies. This discipline needs to be inculcated in the organization’s culture.
Privacy by Design - It is said prevention is better than cure. If setting up the right kind of policies incorporates privacy in the organizational DNA and procedures and people are trained and retrained on them, then chances of mistakes reduce to great extent. If your organization handles errors at the early stage a great deal of the firefighting gets reduced. As an example, do not start defining a template for notification of data breach to DPA and Data subjects after the breach has happened. If those templates are ready you can focus on correction and corrective actions. In my opinion that is ‘Privacy by Design’.
Data Breach - All of us are aware of this term, which refers to the intentional or unintentional disclosure of personal data. Placing appropriate controls and training people will help prevent the breach. However, when it happens, your ability to respond and contain it, and take long-term actions to prevent it in future, will drive systems to perfection. In case of GDPR notifications to data subjects and DPA, based on severity of breach is a must. If analysis says that the data breach is not going to affect lives of data subjects, then internal recording will suffice. If data breach is to be notified, remember you have SLA of 72 hours from the time it was brought to your notice.
Hope I have covered most of the key terms. I want to start explaining few scenarios that could happen to an organization in the context of GDPR in my next post.
