Over the last couple of years anyone involved in business, especially in Europe, will have heard of the EU General Data Protection Regulation (known as GDPR). This is designed to protect the data of individuals with a compliance date of 25 May 2018.
The regulation has a number of aims all designed to increase and standardise the protection of individuals including:
- data portability
- the right to be forgotten
- the right to prevent profiling
- the right to object to processing
- the right to rectification and erasure
- subject access requests
The implications for not complying can be serious with the possibility of fines of 4% of turnover or $20 million. However, it is important to remember that the outcome being sort by the European Commission is for organisations to embrace improved data controls, not a mechanism to raise revenue. Therefore, this may mean that there is a period of time where organisations will be guided on how to comply where there are gaps as opposed to being fined the maximum on day 1 (although they might).
At the time of writing this post, the alleged use of Facebook data by Cambridge Analytica without consent of up to 50 million Facebook users to aid the US elections, is all over the news. Mark Zuckerberg, CEO of Facebook, has been called to testify to US Congress where it is highly likely he will face intense questioning on how Facebook controls and uses the private data of individuals. On the back of this alone billions were wiped from the Facebook share price.
More importantly, it has placed acute scrutiny on the large tech companies. Many individuals are now realising just how much information is being held about them and, how this can be used. Given this backdrop, I can see that the regulators across Europe will be looking to maximise the use of GDPR to demonstrate to the public that they are serious about data protection.
Before exploring the implications on project management, I want to spend a moment providing the definition of 2 important roles, Controller and Processor as I will reference this later in the article.
Controller and Processor
GDPR outlines 2 important roles in the management and protection of data.
Controller: an entity that decides the purpose and manner that data is or will be used
Processor: the person or group that processes the data on behalf of the controller. Processing is obtaining, recording, adapting or holding personal data
With all this in mind, I want to turn to what this might mean to project management. Please note I am not a legal expert so this is my thoughts and you should seek advice from an appropriate legal expert.
What is personal data?
Another important point is to understand what constitutes personal data. This is any data that can be used to identify a person. For example name, identification number, address, etc. It also includes more sensitive data such as religion, political preference, etc. However, this can mean a simple combination of Name and email, mobile telephone number or IP address in many European countries.
This in theory means that where ever you record information and use information that identifies an individual, it is subject to GDPR. This is an interesting thought when you consider the information used as part of a project.
Governance Artefacts
There are many governance artefacts that should be used by a project to aid delivery.
Governance forums like steering committees should have terms of reference. This will include the name and role of the members. This could be identifiable personal data.
A Microsoft or Clarity project plan. This will contain tasks and activities that could have individuals assigned to them. This could be considered identifiable personal data. If the versions of project planning software is enterprise level, this means that the software will contain what is deemed personal data as any user who creates a plan will have the option to select the resource from a drop down list.
Carrying on with the project plan theme. What if the plan includes 3rd party resources from another organisation? Perhaps a software vendor. In theory, an individual from the 3rd party could make a Subject Access Request (SAR) to ask what data is being collected and how it is being used. Then what if they ask for the right to be forgotten? What then is used against the tasks in the plan?
Project Artefacts
Similar to governance artefacts, many project documents such as business requirements can contain information that identifies individuals, both internal and external. I have been trying to research the implications under GDPR and have not found a clear answer.
However, if the personal information is captured electronically i.e. wordprocessor document, then technically GDPR applies. This means that the organisation and the project team will need to be able to search the project documentation if and when they receive a SAR. This could be very challenging and relies on all project documentation to be stored in the correct location i.e. not on their local hard drive, removable media, etc.
Software Solutions
Many projects have the objective of implementing or enhancing software. Part of the development cycle is the testing of software. This can mean using test data to ensure that the system works as required.
Where testing involves using production data where it contains personal data, again, this will be captured under GDPR meaning the individual has the rights mentioned at the start of this article.
It is good practice for testing that data should be anonymised and encrypted. In fact it is considered that this removes much of the burden of GDPR as the person(s) could not be identified in event of a data breach. This means that the there would not be a requirement to notify the individuals of the breach.
Many organisations already adopt / mandate this approach. In fact if an organisation had a way to use this methods more generally across their organisation, it would greatly reduce the burden of GDPR. However, the cost of the solution would be high.
SaaS Providers
GDPR is a challenge for SaaS providers. Many organisations have embraced the use of cloud technology and use SaaS solutions for project management. The new regulation makes the Processor (the SaaS provider) jointly liable for compliance (unlike today where it is purely with the Controller (the organisation).
The SaaS provider will be operating as the Processor for the different organisations who are the Controllers of the data. They need to ensure that they have the robust controls in place to manage the data. That it is only used for the purpose stated by the Controller (i.e. not used beyond this). That they can respond to SAR when a request is received from the Controller.
The landscape for SaaS, especially in Europe has become a lot more challenging. This increased burden of compliance may result in higher prices being passed to end users. It also means a lot more diligence for an organisation ensuring that a SaaS provider has all of the necessary controls. Potentially meaning some of the benefit is lost such as the attraction of an agile, quick to market approach being lost.
Conclusion
This is a very wide reaching topic and very difficult to cover in a single article. I know I have only touched a couple of the many considerations.
The aim was to consider some of the areas of consideration that may directly impact project management. Some may be correct, others may not be an issue. I imagine that, like with most things, it is only when the regulation comes into full force and the practicalities are tested, that we will really know.
While the regulation does cover all internal and external people, I sense the real focus for the regulators is the protection of individuals, the business to client relationship (B2C) as opposed the business to business (B2B). Likewise, internal people (employees) are typically covered under the legitimate need to hold and process the data.
I am hoping that this will mean that there is a level of sensibility when it comes to the management of personal data required to manage a project. Of course, it is very important to protect the data and only capture / store what is needed. However, having a name against an activity in a project plan is very different to holding data in respect of bank accounts.
It is important that you operate robust controls. You should also conduct an audit of all of your project artefacts and processors so that you have a clear understanding of what data is captured, how it is used and how it is stored. If there is personal data you are capturing that is not required, stop.
Many large organisations will have a GDPR project. It is worthwhile engaging with them to understand what is being implemented for your organisation and, what you need to do to comply.
