Closure Report

Project Summary 

The key objective of this project was to create two new GDPR request type categories within Request Handling Monitor of the FOI database. 

The project was initiated in order to upgrade the existing Freedom of Information database with the necessary GDPR categories that would allow the Records Management Team to respond to subject access requests (GDPR SAR) for personal information and GDPR Right to correct/erase/object/restrict data that is held by the University of Edinburgh holds, pertaining to them.


This project addressed the need to implement changes to the Freedom of Information(FOI) Publication Scheme Database to ensure compliance of GDPR. The element of change pertains to the Request Handling Monitor functionality in relation to how this information is requested, logged, monitored and managed.

In order to accommodate GDPR Subject (subject can be described as anyone, either internal to the organisation, a previous student or anyone who believes that Edinburgh University have any personal information about them) Access Requests, and GDPR Right to request/correct/erase/object/restrict data requests, the changes involved the creation of two new request types and the redundancy of two existing request types within the Request Handling Monitor.

This project was  initiated to upgrade the FOI database to accommodate the GDPR legislation.


The scope of this project was to: 

  • Introduction of two request type categories for GDPR by 25th May 2018
  • Facility to maintain existing categories and new categories for a two week period during 'cutover' to accommodate 'delayed' requests, until 8th June
  • Redundancy of two of the existing request type categories 8th June 2018
  • 'Search request ONLY 'functionality for the two categories that GDPR will replace, for historical and auditory purposes
  • Some guidance to Record Management team in support of their UAT for each deliverable.

Objectives, Deliverables

No Description



O1 To ensure compliance of GDPR Subject Access Requests and 'GDPR right to correct/erase/object/restrict data, within Freedom of Information(FOI) Publication Scheme Database, for the Records management team by 25th May2018. Must  
O1D1 Add New GDPR Subject access requests type Option, within Freedom of Information(FOI) Publication Scheme Database, allowing for calendar days and working days. Must  YES
O1D2 Add NEW GDPR functionality request type - GDPR right to correct/erase/object/restrict data, within Freedom of Information(FOI) Publication Scheme Database. Must  YES
O1D3 To provide the administrative option to control whether the period is calendar or working days.    
O1D4 Support Records management team with UAT that will incorporate the new functionality and phases. Must  YES
O2 To ensure pre-GDPR categories can be searched and reported on enable for redundant requests in support of management Reporting and auditory purposes. Must  

To Provide facility to search and report facility on non GDPR categories.

Must  YES


 ADDITIONAL DELIVERABLES - investigations  in case existing reports did not work with new categories:  not required in the end

   Set up new categories on the BI  Must  N/A
   Set up new calculations for the new categories  Must  N/A



The changes to the Freedom of Information Database went LIVE on 26th April, without issues.



The planned benefits from this project were all achieved:

  • Compliance with the General Data Protection Regulation (GDPR) (Regulation (EU) 2016/679) wrt to recording of new request types
  • Edinburgh University remaining as a GDPR compliant organisation.
  • The Records management team   able to demonstrate  compliance to the requesting subjects and regulator bodies.

Additional Benefits

  • Project team and business testers successful use of Testrail in a project environment, enabling this technology to be used for further projects
  • Business Analyst gained considerable insight into work of the records management tea, which is knowledge already proving useful for new projects ( eg STU263)

Success Criteria

The planned success criteria for this project were all achieved,

  • The Records management team can respond to the subject's GDPR requests.
  • Add New GDPR Subject access requests within Freedom of Information(FOI) Publication Scheme Database, for the Records management team, with option for Business to select option for response times in calendar days or working days.
  • All categories can be selected as active or inactive, are searchable and can be reported by the Records management Team.

Analysis of Resource Usage:

Staff Usage Estimate: 30 days  Additional days approved by STU programme and WIS, increased to 59 days

Staff Usage Actual: 50 days

Staff Usage Variance: 67%


Explanation for variance

  • The original project plan approved at the planning stage anticipated for the project to be closed by the 18th May 2018 however due to an increase within project scope to cover reporting, and delays due to the need to clarify of the GDPR calculation (that had to be redressed with the  ICO), the budget was increased to 59 days.
  • During planning it was not clear how the request-type target date would be calculated. The business was not in a position to confirm how the target date ought to be calculated as this required  guidance from an external party (Information Commissioner's Office) . 

  • In order to ensure that a solution was available by 25th May, the approach agreed was to provide an additional  ‘calendar days’  option in addition to the ‘working days’ option that already existed in the system.  The project team and business accepted the risk that the project might carry out development which would not ultimately be required. However when firm guidance was eventually provided to the business,  it was that the target date was to be based on   ‘calendar month’  rather than 'calendar days.  At that point the relevant sections of the BRD were updated and the design adjusted to reflect this.

  • The business considered that the project team did not understand that they were not in a position to confirm the target-date requirement: however from the planning stage the project team  attempted to ensure delivery by 25th May by ensuring that more than one means of calculating the target date could be selected by the business after delivery. This is because the business was unable to say when the target-date requirement would be confirmed and the project team considered it was  too risky to wait until the target-date requirement was confirmed, in case this was not delivered until too late or when resources were not  available.

  • Delays due to Industrial Strike action increased project costs

  • The project team and the business testers were all new to Testrail therefore additional effort was required to understand how to use this for testing.
  • As  the Records Management Section is a small team, the project team carried out more testing in-house than had been anticipated. 
  • The project manager noted that the Business Analyst took a crucial leadership role in  gathering requirements and in planning and directing testing.
  • The BI reporting element changes were not as significant as had been anticipated, so fewer days were required than had been estimated in the change of scope
  •  17 days  days were subsequently returned to STU Programme.


Key Learning Points


  • Great communications between the Records Management Section, the development resource and business analyst proved to be successful in the upgrade to the FOI database.
  • Early planning of UAT and scripting with the Records Management resource and BA, allowing the Records Management Section to understand their role and the tools such as JIRA and Testrail in signing-off the UAT
  • The project team found that Testrail was a useful tool in monitoring testing progress.
  • The Business also found that Testrail was easy to use and noted that the Business Analyst planned  and managed the testing process very well.
  • Where an existing spreadsheet of tests exists, it would likely save effort to upload this into testrail - a template for uploading into Testrail would be useful.
  • RISK management ensured control throughout the Project.
  • The JIRA board was not set up in time for this integration testing,  therefore it was not used to record any of the bugs identified in integration testing.
  • The partnership between a project manager new to IS and a very experienced Business Analyst  worked very well, as the BA was able to provide a great deal of support and information ot the PM.

Outstanding Issues



Project Info

Freedom of Information GDPR Updates
Student Services (STU)
Management Office
Project Manager
Morna Findlay
Project Sponsor
Sara Cranston
Current Stage
Start Date
Planning Date
Delivery Date
Close Date
Programme Priority
Overall Priority