GDPR - Serving up a solution with Jira Service Desk and Confluence

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.

GDPR - The 5 W's and How to Get Compliant →

In this post, we are going to expand on the How part by using the analogy of a three-course meal.

Menu

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

Ingredients

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.

Starter

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:

• The name and contact details of your organisation (and where applicable, of other controllers, your representative and your data protection officer).
• The purposes of your processing.
• A description of the categories of individuals and categories of personal data.
• The categories of recipients of personal data.
• Details of your transfers to third countries including documenting the transfer mechanism safeguards in place.
• Retention schedules.
• A description of your technical and organisational security measures.

It also outlines some items to consider documenting as part of recording processing activities:

• Information required for privacy notices, such as:
  • The lawful basis for the processing
  • The legitimate interests for the processing
  • Individuals' rights
  • The existence of automated decision-making, including profiling
  • The source of the personal data;
• Records of consent;
• Controller-processor contracts;
• The location of personal data;
• Data Protection Impact Assessment reports;
• Records of personal data breaches;
• Information required for processing special category data or criminal conviction and offence data under the Data Protection Bill, covering:
  • The condition for processing in the Data Protection Bill
  • The lawful basis for the processing in the GDPR
  • Your retention and erasure policy document.

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.

Confluence

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:

• Security - Confluence is secure but easy to access and use by authorised users.
• Update history - Each page has a detailed update history that shows the changes made between versions and which user has changed the content.
• Collaboration - Many different parts of the organisation need to come together to create and amend the documentation required. Confluence's collaboration features shine through with inline, page and file commenting on any page. In addition, groups of users can simultaneously edit a page together in real time and see changes as they happen – very useful when documenting processing activities.
• Templates – Capturing the required information in a consistent way helps ensure that you are not missing important information. Confluence provides user templates and, for complex requirements, custom Blueprints can be created.
• Powerful search – Confluence's simple but powerful search functionality ensures that you can always find what you are looking for. For more complex searches, for example to find documentation that has not been updated within a certain limited, it is possible to run advanced queries using the Confluence Query Language (CQL).

Main course

Having digested our substantial starter, we turn to the main course.

Accountability and governance

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.

Data privacy policies

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.

Data protection by design and default

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.

Data subject requests

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.

Dessert

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:

• Have a Jira Service Desk security incident request set up for employees and make them aware of this mechanism to report their concerns if they become aware of a potential breach. Optionally, consider making a similar facility available for external parties to report their concerns, similar to a Bug Bounty program.
• Allocate responsibility to a dedicated person or team to investigate these concerns and ensure that the security incident requests are handled immediately.
• Develop a response plan and document it in Confluence. This plan should reference the following information:
  • Guidelines about which types of breach are notifiable and which should only be recorded internally.
  • Who is the relevant supervisory authority for our processing activities?
  • What information do you need to provide as part of the breach notification?
  • Steps required to safeguard personal information and up to date contact information for the individuals who will authorise these actions, e.g. for an ongoing data breach, who can authorise shutting down the eCommerce website?
  • Templates for notifications to the individuals concerned. The copy for these emails or letters need to be written, reviewed and authorised in advance.
• Use a Jira Service Desk SLA to track response time in comparison with the 72-hour deadline. Make this visible to management via a Dashboard within the product.

So, after that we might want a coffee, perhaps even a double espresso.

Conclusion

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.