DPA Compliance Statement

We have used guidance under the IT Systems Checklist document provided by University central Records Management to form this compliance statement. They state that compliance with the requirements set out in this document will ensure that our School manages fully the data it holds in Theon. It will also ensure that Theon meets the requirements of the Data Protection Act 1998 and the Freedom of Information (Scotland) Act 2002. Each compliance requirement and our explanation of how Theon meets the requirement is detailed below.

The IT system is referred to as Theon below and is considered to encompass the school's central PostgreSQL database and downstream consumers of data held in that database (such as the UI, Portal, Prometheus, etc) that may retain their own copies of data locally mastered in Theon. This statement specifically does not cover the legacy school database nor aspects of Theon using that (as it is due for deprecation and deletion).

Ownership and responsibility

1. Is it clear who the business owner is for all data in the system?

The system collates data from multiple external sources and allows extension with local data. As such there is no one business owner for all the data. The business owners will be those for each external data source (at the University level SAGS and HR) and for locally maintained data added within the School this would be ISS for all student related data and InfHR for all staff related data. Downstream systems will also have distinct business owners where they supplement data from Theon.

2. Do we know what data the system must hold?

Yes. The data the system must hold is defined by the business processes that use the system. We do not believe that we currently hold more than is required by these business processes (as defined by the relevant administrative requirements and staff).

Data retention

3. If the data is about a living, identifiable individual, are arrangements in place to ensure that it is accurate and up-to-date?

Yes. Much of the data is about a living, identifiable individual. The data from upstream is as accurate and up-to-date as held and maintained by those business owners (with a propagation delay of up to normally 24 hours in most cases, one week in a few other cases). Local data is maintained and kept accurate either directly by administrative staff via data entry or indirectly by automated functional processing.

4. If the data is about a living, identifiable individual, are arrangements in place to suspend processing data about a particular individual if they ask us to do so?

Yes mostly. Much of the data is about a living, identifiable individual. We could suspend processing on an individual basis, primarily by putting in a filter at the incoming upstream feed to remove them from that data. That would have a consequential effect of visibly hiding that individual from all business processes (data entry and reporting). This would achieve complete suspension of processing with minimal (although initially manual) effort. Processing of data on individuals where the data is entirely locally maintained (an extremely small proportion) would be harder to suspend in a clean fashion, but a simple hack to their primary record could achieve this if necessary.

5. Do we know how long we will need the data in the system for?

Yes and no. We maintain the data on students for one year beyond their final University programme completion (in order to cover any subsequent assessment changes or investigation). We do not currently have a retention schedule for staff data, given the need to retain some level of alumni record, however the data retained at present would be minimal amounting to name and title/period of last held post. If the University itself has an absolute retention schedule for staff data we would simply aim to comply with that.

6. Does the system have arrangements in place to identify and delete data that is no longer required?

Yes. For upstream data sources which define our entire student and staff data sets we can define purge rules that firstly archive (remove from user visibility) and then delete data automatically based on the retention period defined against each particular data source. We have not actually enabled these rules yet however.

Long-term access

7. Do we know how to ensure that the data remains accessible for as long as it is needed? This applies if the data may be needed for longer than the anticipated life of the system, or is of long-term historical value.

Yes, although we do not currently have a complete solution for our needs. We have, for example, a need to retain statistical aggregated reports of data for trend analysis in various areas, although this data does not need to be tied to individuals. However at the moment all historical data is created live. To meet this requirement fully we would need to develop a snapshot process which could anonymise the relevant base data or provide an integrated archive of the reports that have been generated previously.

8. Can the system export the data in a preservation format and capture the necessary metadata to ensure that the data remains meaningful over time? This applies if the data may be needed for longer than the anticipated life of the system, or is of long-term historical value.

Yes. See 7.

Legal admissibility

9. Might the data in this system be needed in a court of law to support the University’s rights and responsibilities?


Security and back ups

10. If the system contains sensitive data, including data about living, identifiable individuals, is access restricted to those who need to see it to do their job?

Yes. Theon does contain sensitive data, including data about living, identifiable individuals. Access is specifically controlled by robust permissions so that only those that need to see it to carry out the relevant business process can do so.

11. Are measures in place to prevent unauthorised access or changes to the data? This could be by an authorised user or a user who has exceeded their authority.

Yes. Access is under fully managed authentication and authorisation control. All data changes are also audited and held (for up to one year) for the purposes of identifying when changes have been made (and by whom) should an investigation be necessary and retrospective action taken.

12. Are measures in place to limit the risk of accidental changes to the data? For example, staff can be asked to confirm that they meant to make a deletion.

Deletion is a rare process in Theon and the direct ability to do so is generally restricted from normal end user interfaces. Where deletion of records is an appropriate part of the business process then it is usually self contained and of limited consequence. So an additional "deletion only" re-confirmation step is seen as needlessly intrusive. The hourly, daily and monthly backup snapshot regime allows fast reinstatement of data when an accidental deletion of data has been made. Data sourced from upstream is never deleted, merely marked as to be treated as deleted (except when a purge process is initiated based on retention periods).

13. Are measures in place to track who changed the data, when it was changed and what the changes were?

Yes. See 11.

14. Have business procedures have been developed and implemented for changing data?

Yes, the administration team have procedures for managing data.

15. Are measures in place to prevent the loss of the data?

Yes. See 12.

16. Are effective data recovery procedures in place?

Yes. We run a live mirror service which can be promoted to the master instantly if necessary. It is hosted off-site. We have live full database snapshots taken at hourly, daily and monthly intervals and held for at least six months. These snapshots and the live database are mirrored daily to offsite hosts which are also backed up to tape nightly.

-- TimColles - 27 Nov 2018

Topic revision: r1 - 27 Nov 2018 - 14:56:48 - TimColles
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies