In our previous blog post, GDPR - The 5 Ws and How to Get Compliant, we covered the What, Why, When, Where and Who of the upcoming EU General Data Protection Regulation (GDPR) and described the steps required to become and remain compliant with this major change to privacy regulation before the looming 25 May deadline.
In this post, we are going to expand on the How part by using the analogy of a three-course meal.
So, what do we have on the menu?
Starter
A sharing platter of documentation
Main Course
Accountability and governance
Accompanied by robust and scalable handling of data subject requests
Dessert
Data breach handling
First, like all good meals, we need to start with high quality, value for money ingredients. Fortunately these may be ones that you may already have in your software store cupboard: Atlassian's Jira Service Desk and Confluence.
A sharing platter of documentation
Like a good stock is the foundation of a great soup, documentation is a fundamental ingredient of IT projects. Implementing GDPR is no exception.
In fact, the regulations themselves require certain documentation to be held and kept up to date by data controllers and processors about processing purposes, data sharing and retention. The regulations build on the requirements of previous data protection legislation, for example the Data Protection Act 1998.
The documentation must be kept in writing in electronic format, and organisations may be required to make the records available on request to the appropriate supervisory authority. See Article 30 of the GDPR regulations.
There are some additional requirements if you process special category or criminal conviction and offence data. See Schedule 1 of the Data Protection Bill (PDF, page labelled 112).
It may also be necessary for you to document all of your data processing activities. This is a new requirement introduced as part of GDPR. Small to medium-sized organisations (fewer than 250 employees) may have a limited exception from this requirement but it is good practice to record this information. See Who needs to document their processing activities?
In the UK the supervisory authority is the Information Commissioner's Office (ICO). They have published some very valuable guides to the requirements of GDPR and they have produced one specifically about Documentation and also some basic templates for controllers and processors.
In this guide, ICO sets out what needs to be documented under Article 30:
It also outlines some items to consider documenting as part of recording processing activities:
BDQ would also add to this list a recommendation to take copies of the relevant legislation documents themselves (e.g. GDPR, the Data Protection Bill, the Data Protection Act, etc.) and import them into Confluence. As these documents are very long, it is a good idea to split them up into separate pages covering individual topics or sections. This will make it easier to link and comment on these individual sections of the document and therefore make collaboration on understanding and implementing the requirements of the legislation easier.
The regulations require that the documentation is kept in writing and up to date but make no suggestions as to the way to store this information. ICO provide the basic templates in Excel and describe the requirements as "we document our processing activities in electronic form so we can add, remove and amend information easily".
BDQ believe that using Atlassian's Confluence to hold this information makes sense for the following reasons:
Having digested our substantial starter, we turn to the main course.
A central part of GDPR is promoting accountability and governance. You are expected to put in place comprehensive technical and organisational measures to minimise the risk of data breaches and ensure that personal data is protected appropriately. See Article 5 and Recital 78.
In many respects these are extensions to good practices and some of the requirements from earlier legislation. GDPR provides the opportunity to reassess how you approach these challenges. You must also consider how you will be able to demonstrate how your organisation complies with these requirements to the statutory authority, e.g. ICO.
You should review our existing privacy policies and, as mentioned earlier, the collaboration facilities in Confluence are a very useful way to handle this process. Once completed, you can make this content available to your colleagues and it becomes a "one stop shop" for your privacy policy documentation.
You need to then ensure that you train your staff members on any changes made to the policies and ensure that new hires are made of aware of their individual responsibilities regarding personal information.
The Atlassian Marketplace has several Learning Management System apps that can be added to Confluence to provide training for users and in some cases track completion, for example Learndot Pathways Pro by ServiceRocket or Quizzes for Confluence by SiltSoft.
Privacy is often an afterthought when designing systems. You must be able to demonstrate that you have considered and integrated data protection into your projects, processes, products or systems from the outset.
Although not specifically relating to the requirements of GDPR, ICO has published some guidance about how to consider Privacy by Design. A core part of this guidance relates to conducting Privacy Impact Assessments (PIAs). PIAs are a useful tool to identify and reduce privacy risks of your projects and can reduce the risks to individuals through misuse of their personal information.
BDQ recommend creating a Confluence template based on the annexes from the ICO document (.docx) and running through these assessments as early as possible during each development project you start.
Another useful resource regarding Privacy by Design is the guide produced by Information and Privacy Commissioner of Ontario.
Accompanying our main course of "Accountability and Governance" is a requirement for handling data subjects' requests in a robust and scalable way.
GDPR gives data subjects improved rights in respect to the personal data that organisations hold about them. Data subjects can make a number of requests of the organisation holding the data (see Individual rights). The regulations require that these requests are responded to within one month of receipt and usually without being able to charge the data subject.
The regulations do include a best practice recommendation that, where possible, organisations should be able to provide a secure self-service system, ideally to the data itself but failing that to make raise a request (see Recital 63). You cannot require data subjects to make requests exclusively via an online system. The legislation requires that you are able to handle requests by letter, phone, fax, or even social media - whichever is the preferred method of the data subject.
BDQ offer a solution to data subject request handling using Jira Service Desk. We see the benefits of this solution as follows:
Secure public portal – Jira Service Desk provides a secure, mobile-friendly portal for users to make their requests.
Queues for agents – The internal view of the requests shows the currently outstanding requests, how much time is left before the deadline and who is currently responsible for each request.
Workflows and Automation – Jira Service Desk has a fully customisable workflow behind the requests, which BDQ have used to create a standard data subject request handling process. This can be fully customised and through automation we can add additional functionality, e.g. generating issues in Jira in response to a validated request and assigning them to individual system owners.
SLAs and Dashboards – A critical aspect is ensuring that you respond within the timescales set out in the legislation. SLAs and Dashboards within Jira Service Desk allow managers to get actionable information about how you are handling requests.
Data breach handling
Remember to leave room for dessert - the final part of the set menu of GDPR regulations.
In the event of a notifiable data breach being discovered, you have only 72 hours to report to the relevant supervisory authority. Time is very short and the fines for non-compliance can be high, up to a maximum of 20 million euros or 4 percent of global turnover (whichever is greater). Therefore, it is important that you have the processes in place and documented to handle any breach as soon as possible after discovery.
BDQ recommends the following:
So, after that we might want a coffee, perhaps even a double espresso.
Atlassian's Confluence, Jira and Jira Service Desk can provide a robust and scalable solution to some of the issues around GDPR compliance.
Are you hungry for more? BDQ offers a comprehensive GDPR implementation service using Atlassian's products. Contact us and let us talk about what you need.