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 

Project Info

Project
Privacy Impact Assessment Tool (GDPR Requirement)
Code
STU257
Programme
Student Services (STU)
Management Office
ISG PMO
Project Manager
Andrew Stewart
Project Sponsor
Renate Gertz
Current Stage
Close
Status
Closed
Project Classification
Run
Start Date
07-Aug-2017
Planning Date
06-Oct-2017
Delivery Date
03-Jul-2019
Close Date
12-Dec-2019
Programme Priority
2
Overall Priority
Normal
Category
Compliance

Documentation

Close