Closure Report
Background
Privacy Impact assessments (PIAs) can be used to identify and reduce the privacy risks of projects. A PIA can reduce the risks of harm to individuals through the misuse of their personal information. It can also help to design more efficient and effective processes for handling personal data.
The introduction of a Privacy Impact Assessment tool is a core part of the University’s strategy to meet the requirements of the General Data Protection Regulation (GDPR). (Strategy paper approved by the Central Management Group on 19 January 2016). As the onus has changed to the burden of proof now being on the University to provide proof of compliance rather than the previous ( the burden of proof being on the disputer). It will become compulsory for staff across the University to routinely carry these out when using personal data, for example when:
- building new IT systems for storing or accessing personal data;
- developing legislation, policy or strategies that have privacy implications;
- embarking on a data sharing initiative; or
- using data for new purposes.
The concept of data protection by design and default is core to the GDPR. It requires organisations to play an active role in ensuring privacy. From project/policy/process inception to data deletion, the University will be expected to systematise measures to ensure the accuracy, confidentiality and security of the personal data it holds. Privacy Impact Assessments (PIAs) are an integral part of a privacy by design approach.
The Privacy Impact Assessment will be a core part of the University’s evidence that an appropriate assessment of privacy risks has been made in the event of complaints or investigations by the Information Commissioner’s Office.
The current relevant Information Commissioner Officer’s guidance is available through the following link: https://ico.org.uk/for-organisations/guide-to-data-protection/privacy-by-design/
Scope
The scope of this proposal relates to the IS Apps effort to support procuring or developing a tool or the definition of process / guidelines using existing technologies that can walk staff through the process of conducting a privacy assessment and generate meaningful results. This is likely to take the format of a customised survey.
The aim is that the privacy impact assessment process is:
- Meaningful
- User friendly
- Uses language staff understand (i.e. not specialised data protection language)
- Allows them to identify action points to ensure their system is compliant
In considering the scope of the project the following should be taken into account
- As the requirements for Privacy Impact Assessment (PIA) grow
- It is expected some industry standard tools will continue to be developed to meet this need. This looks to be the case already as there are already some free tools already available and should be evaluated
- The project will look to deliver a fit for purpose solution to meet the legal obligations, whilst acknowledging that the solution could be further developed at a later date to take advantage of new industry standard applications
- Where options are possible, the path of lowest cost should be taken to fulfil the compliance requirements
Project Summary
In successfully implementing a SaaS workflow based solution to manage the creation of Data Protection Impact Assessments (DPIA) and their subsequent maintenance through the lifetime of the service, the project has produced
- a detailed business analysis incorporating process flows and user roles
- a detailed document detailing the implemented work flow question set
- a completed and approved Data Protection Impact Assessment for the service itself
- a published Equalities Impact Assessment (EqIA)
- a user guide for system users
The delivered solution has been well received by both the Data Protection Office and the user base in general with some positive comments being fed back and a higher than anticipated level of DPIAs being requested and completed.
The outline project strategy was changed to both procure and implement a market-place solution, after the initial analysis of developing an in-house solution within the given budget of 50 days was deemed to be neither feasible nor sustainable (as detailed in piccl item 1).
During the procurement process
- market research was undertaken on a number of potential solution which resulted in concerns being expressed by the Procurement department that the whole life cost of the solution could breach OJEU threshold
- the ITT was compiled and published encompassing both the functional and technical requirements
- the scoring process was completed using a three-phased approach
- response to the written responses
- supplier presentation with regards the functional scenarios outlined in the ITT
- a hands-on experience on a sandbox environment for each of the proposed systems
- the contract was successfully negotiated and resulted in the UoE ITT requirements being incorporated into the contract (after the legal teams involvement)
During the Implementation period
- user training was carried out
- the system was successfully configured through the creation of two predefined DPIA templates; one for the University staff and one for Research teams. A template was also developed for legitimate interest assessments, a different type of assessment also used to demonstrate GDPR compliance.
- user acceptance was successfully completed
- a number of user workshops were held to ascertain feedback to the user experience - from which changes were noted and subsequently implemented. Feedback was received from
- a workshop for the data champions, whilst limited to 20 was over subscribed in bookings
- two workshops with representatives from SCE IT department, working through the creation of a system generated DPIA from scratch
- communication of the system roll out was led by the Data Protection office team through the Data Champions and through guidance on the GDPR pages on the university Website
- arrangements were made for the system to be supported initially by the IT HelpDesk, routing all calls to Service Management, who will manage the service in conjunction with the Data Protection Office
During the Roll-Out
- a soft roll-out was initiated in July and the system usage has continued to grow during which time a total of 108 DPIA's have now been requested with a total of 53 completed
- the matter of email routing has been resolved whereby all system generated emails are delivered from the functional account DPIA
- the matter of enabling Single Sign On has been has been resolved after a considerable effort involving the technical teams from Development Technology, ITI and the supplier
- the Operations Level Agreement (OLA) has been completed
With regards the technical configuration
Difficulties have been experienced in configuring email relays and Single Sign-On (SSO) during the project due to a number of reasons as noted below. With additional technical resource being assigned to the project from Dev Tech in mid-August, both the email relay matter has been resolved along with SSO after the hands-on involvement of ITI personnel.
- resource difficulties within Development Technology
- issues with certificates supplied by the supplier
- difficulties in understanding how SSO was working with the application
Subsequent to the soft roll-out, SSO was successfully implemented into the Live environment on 19th November
Access to the application is via Data Protection Impact Analysis
In closing, the project manger would like to recognise the significant contribution of the project team in the delivering the system during the various project phases.
Objectives
| Phase | Achieved |
| O1. Determine the approach to generating Privacy Impact Assessments that matches the needs of the University | Yes |
| O2. Implement preferred solution | Yes |
| O3. Ensure long term sustainability of the solution | Yes |
Deliverables
| Phase | Priority | Achieved |
| D1.1. Document the business requirements required for a Privacy Impact Assessment | Must | Yes |
| D1.2 Determine preferred business solution and whether approach should be build or buy | Must | Yes |
| D2.1 Design technical solution or implementation needs for procured solution | Must | Yes |
| D2.2 Build / Implement Technical Solution | Must | Yes |
| D3.1 Establish service documentation and support arrangements including service funding | Must | Yes |
| D3.2 Roll-out service to University including communications plan | Must | Yes |
Analysis of Resource Usage:
Staff Usage Estimate: 146 days
Staff Usage Actual: 184 days
Staff Usage Variance: 126 %
Other Resource Estimate: £xxx
Other Resource Actual: £xxx
Other Resource Variance: xx%
Breakdown by Project Phase / Team (to be completed)
| Project Phase | Project Services | Development Technology | Software Development | Applications Management | Service Management | Total |
| Project Management / Governance | 35 | 1 | 36 | |||
| Planning | 17 | 1 | 18 | |||
| Business Analysis | 22 | 22 | ||||
| Procurement | 70 | 4 | 5 | 2 | 81 | |
| Design | 2 | 2 | ||||
| Build | 2 | 10 | 5 | 17 | ||
| Acceptance | 1 | 1 | ||||
| Deployment | 3 | 1 | 2 | 6 | ||
| Closure | 1 | 1 | ||||
| Total | 152 | 16 | 7 | 9 | 184 |
Explanation for variance
The project timelines were extended on a number of occasions;
- When the project strategy was directed to the market-place to procure via a local ITQ (piccl 1) there was the requirement to re-plan the project. This required further re-planning on account of the decision to both procure and implement a solution along with the requirement to further extend the procurement process, as the early market engagement had suggested the OJEU threshold could be breached (piccl item 4)
- Due to diary conflicts within the project team, there was the requirement to extend the project timelines by a further five weeks to complete the product scoring evaluation (piccl item 5)
- Having selected the preferred supplier in mid November 2018 , there was an unexpected delays in signing the contract whilst
- Agreement was reached regarding the terms and conditions. This resulted in the use of UoE terms and conditions, including the insertion of the scored ITT components, UoE technical specification along with the agreed supplier adjustments. To achieve this there was the requirement to involve legal representatives from both parties (piccl item 6). The contract signatures were finally concluded w/c 11th February 2019
- The purchase order was processed - unexpected delays encountered whilst the supplier completed the appropriate documentation and the requirement to increase authorised spending limits (piccl item 7). The purchase order was forwarded w/c 11th March 2019
- Resulting from post procurement delays, the project was re-planned to commence user training in mid April, with a s scheduled deployment set for mid June (ref piccl item 10)
- Due the the requirement to allow further time to reconfigure the DPIA templates, the soft launch was achieved early July 2019 (ref piccl item 11), whilst noting that it had not been possible to complete the configuration for the email relay (subsequently resolved on 29th August) and SSO (successfully tested on Test on 20th September 2019)
The project budget was increased due to
- Change of scope resulted in the budget being increased from 50 days to 146 days (re piccl item 2)
- Due to elongated project activity during the post procurement phase, there was teh requirement to increase the budget by a further 25 days to 171 days (ref piccl 10)
Key Learning Points
- During the procurement process,
- The business functional requirements were detailed within 10 scenarios and supplemented with a suggested process flow and user roles and responsibilities matrix which assisted in reducing the question set
- the functional evaluation process recommended by the Procurement Lead was found to be extremely beneficial and encompassed
- scoring of the original tender responses
- product demonstration based on the scenarios outlined in the tender documentation
- hands-on via a sandbox environment
- During the elongated discussions regarding terms and conditions, the project manager in hindsight should have sought the involvement of the legal team earlier
- Requirement to ensure that the individual creating the purchase order has the appropriate authorisation limit
- When incorporating SSO within an externally supplied application, the project manager should have directly involved a representative from ITI at the start of the Implementation period
- The good working relationship established between the Data Protection Office and the Data Champions proved to be very beneficial whereby
- Good feedback was received to the early drafts of the new system workflows and associated questions
- The roll out of the new system and processes were able to be communicated locally
- The involvement of the Service Management lead during the UAT was invaluable and has enabled
- a greater focus on service related requirements from an early stage
- the working relationship with the business has been quickly established and greatly developed
- the handover from a project to an on-going service has been seamless
Recommendations
- Utilisation of the supplier Ideas website should continue to be utilised with regards to
- logging of new business requirements
- influencing the product development by voting for already logged business requirements
- As the supplier has a world-wide user base, consideration could be given to joining the UK based suppler group (Chapter) to focus on UK based requirements
Outstanding Issues
There are no outstanding project related issues
