Running a GDPR project –Practical step by step guide
This GDPR project guide will help you plan your GDPR project and understand the order in which things should be done to avoid rework or missing important tasks.
When it comes to GDPR projects, there is a tendency for businesses to focus on areas which seem to be quick wins or they are comfortable with, this is a big mistake on GDPR because there are key dependencies which means the order of task execution is important to the success for the project.
Step 1 -Records of Processing Activities
Start by documenting your Records of Processing activities, they are a key deliverable of GDPR and must be provided to the supervisory authority on request, but they also act as a perfect basis for your planning.
Use the purpose of processing as the basis for the template and everything will grow organically from there. Make sure you don’t have too many purposes of processing, I recommend trying to keep it to under 30 but ideally under 15.
If you are sending templates to business people to complete, then make the templates in advance and use drop downs for most elements . It requires some upfront work but it is beneficial in many ways. It helps because:
- The business will not feel overwhelmed and they will complete it more easily
- You will have consistency in response
- It requires fewer hours/days analysis and you will be able to summarise it more easily
No doubt you will have to be willing to allow the template to develop, but this approach works really well.
Although not part of the Records of Processing requirement, I usually ensure my records of processing template capture an element of high level data flows, volumes of data processed and an assessment of whether there are any high risk elements. This will be removed from the final document issued to the ICO if they request it but it is information that will help assess whether a DPIA is required and also help prioritisation later on. Finally at this point I also capture third party names (rather than just categories) because I will need them later. I don’t capture retention periods now unless I think the business are already exactly where they need to be with this aspect.
When I issue these templates , I usually run workshops or webex to demonstrate how to complete them and work through any concerns. In my view getting this bit right is the most important part of the project if you want it to run smoothly.
Step 2 – Define your lawful bases for processing
Now you have completed a first draft of your records of processing, you will be aware of all your purposes of processing. Assign a lawful basis to each of these, but remember that the lawful basis will differ depending on whether or not you are processing special categories of data or criminal convictions.
Choose your lawful basis wisely, ensuring they are the right ones, each lawful basis will have a different operational impact because they affect which data subject rights can or can’t be fulfilled. For example in the (unlikely) event you are deciding whether to use legitimate interests or performance of a contract as your lawful basis for processing, consider that for legitimate interests you will need the tools to assess and execute objections to processing, but the data would not be in scope for a portability request. If you choose the performance of a contract the data will be in scope for portability, but you won’t need the tools to handle an objection to processing.
If you find you do not have a lawful basis for any of your purposes of processing, you should stop that processing or seek to anonymise it. If it is the special categories which are stopping you from having a lawful basis, consider whether those special categories are imperative. Define any requirements arising from this activity.
Step 2a Legitimate interest assessments
Next ensure you undertake and document Legitimate impact assessments (aka the balancing test) for all purposes you choose to use legitimate interests as a lawful basis for. If you find that your legitimate interests do not outweigh those of the data subject then go back to step 2.
Step 3 – Data Protection Impact assessments
Undertake DPIAs for areas where you identified risks when you did your records of processing – remember DPIAs are only needed where there is a high risk to the rights and freedoms of data subjects, the article 29 working party has issued some helpful guidance on this. Also document your DPIA process (outlining how to assess when it is required and how to do it) and review schedule. On the DPIA itself document a mitigation plan and separate solution requirements for risks identified, including consideration for third country transfers.
Step 4 – Data Subject Rights and Consent Management
Assess which Data Subject rights apply to your business, you can gauge these by looking at which lawful bases for processing you are reliant on and listing which data subject rights align to them. For example, SARs will apply to most organisations but portability only applies to organisations using performance of a contract and consent, so you don’t have to prepare for portability unless you are using a lawful basis affected.
Develop processes for your data subject rights and consent management and where applicable define solution requirements. You will have gauged volumes and risks from the previous steps so you will be able to prioritise accordingly. As part of this activity, don’t forget special consideration for minors, SLAs and the ability to demonstrate compliance – everything the business does should have an audit trail and reporting. Your documentation should also define where you will be reliant on third parties to help fulfil these rights, as well as internal and external training needs.
Step 5 – Breach Framework
Define your breach framework, you need to be able accomodate the tight timeline for reporting a breach, so you must have the right processes to support this, including channels for breaches to be reported, a plan for quick assessment, people responsible for swiftly coordinating the escalation and response, templates for contacting the supervisory authority, just to name a few. I think this framework should look similar to a disaster discover/business continuity plan.
Step 6 – Record Retention
Define your retention periods based on a maximum time you will keep data rather than minimum. The GDPR sets out requirements for data minimisation and storage limitation but does not give you the periods. In order not to make this too complicated it is best to base retention on your purposes of processing, flagging exceptions only if necessary. Don’t dream of defining it by data field. Update your records of processing with the retention periods or logic.
Next define the requirements for a process or tool to erase or anonymise this data at the end of the retention period. You could arguably do this part quite early on without yet having retention periods, but the benefit of waiting is that your solution requirements identified as part of your data subject rights such will be similar to some of the requirements here so it then makes a better case for investing in a solutions.
Step 7 – Fair Processing Notices and Privacy Policies
Prepare your Fair Processing Notices and Privacy policies based on the information you gathered by completing your records processing, lawful basis for of processing and retention records. Decide how you are going to make these available to your data subject at the time you collect their data. Regardless of channel you should opt for layers of information so the data subject can delve to the level of detail that suits them (consent must always be upfront), don’t forget to consider minors. You will also need to document any requirements for third party responsibilities.
Step 8 – Solution options
Now you will have solution requirements gathered from the activities above. You can pass these to your technical team, but first supplement them with any additional requirements from GDPR principles article 5 and privacy by design and default, article 25. IT can start investigating solutions.
Step 9 – Third Parties
In the meantime start serious discussions with Third Party partners ensuring they will fulfil everything you have identified above. It is ok to talk to them before this point but the discussion won’t be meaningful unless you have a good understanding of your needs (the principle outlined in my first top tip blog explains this). Third party discussions will be supplemented by contract changes, so you will need to draw these up, along with data processing agreements. If you rely on third parties applications you would pass on your solution requirements.
Step 10 – Governance Framework
Document your governance framework including roles and responsibilities of the DPO and any support team. Here you may identify resource needs for your future operating model. This step should also include the updating of a company policies and reporting required to assess and evidence compliance in line with the accountability principle.
Step 11 – Solution Implementation
Once you have a clear idea of solutions, work towards implementing them. Where solutions cannot be automated revisit steps 4 and 5 to develop and embed manual processes where possible.
Step 12 – Training
Document your training plans and material based on the information you captured to date, roll out training.
Step 13 – Run a mock breach exercise
As per the title and update the framework if there are issues.
Step -14 – Start again
Not quite, but plan to review all of the above regularly. GDPR is for life, not just for May.
Thank you for reading – Have you ever run a GDPR programme, what do you think? Have I missed anything? Please feel free to comment
