GDPR Guidance

Data retention over the history of schools’ management information systems

The author joined SIMS from teaching almost 30 years ago when he taught maths to pupils aged 11 to 18 from an inner-city school with a challenging set of pupils many of who would be classified as having additional educational needs by today’s standards.

If we roll back to when SIMS was first released over 30 years ago, such recommendations were made without much regard to the practicalities of keeping the data even in printed form!  The standard option was a ‘Dot Matrix’ printer which was relatively fast using sprocket fed paper. The downside was that the ink faded to become practically invisible within months! More expensive and ‘permanent’ golf ball & daisy wheel printers were usually much slower to use and materials were prohibitively expensive.

Over many years there has been a plethora of guidance notes from local authorities and other bodies with regards to how long data should be retained in Schools. In extremis some papers recommended retention until a pupil had reached the age of 45 for some children with special needs. By extension the data about a special needs pupil extends to those linked to them such as teachers and potentially other students.

Join these together and the school would potentially have a requirement to keep the author’s data for a further 4 years to ensure that all those with additional needs that he taught had reached the age of 45!

GDPR simply demands that such policies are reviewed but would not of itself prevent the school from retaining the author’s data!

Who controls retention policy for data?

This is purely a matter for the schools and their governing organisations. There are clear laws on retention of finance data but GDPR simply requires the personal data is stored for no longer than it is needed, hence the ambiguity above.

The consequence of GDPR is that MIS systems will have to allow the deletion of personal data and to put the control of deletion in the hands of the schools using the software. 

Challenge to the Schools

Even though the extended retention policy now sounds wrong under GDPR, it was put there for a reason which we assume was to protect the interests of the pupils with additional needs.  It would be incumbent on school’s changing the retention policy to ensure that the interests of all parties are appropriately considered.  Once the policy is agreed, it would then fall to the school to remove any personal data that was no longer required under their updated policy.

Recent versions of SIMS have made it much easier for SIMS users to delete people and their related data within the product.  A number of bulk deletion routines have been provided to customers with deliberately relaxed rules as to when they can be used in compliance with the act.

Challenge for Partner’s Applications

This is really in 2 parts:

1. The expectation that data will simply be no longer sent to the partner’s application. 
2. A corresponding requirement to comply with the intent of the deletion

Partner applications typically lift and shift data in to their application before presenting it in some way to a user. A simple example might be a squash ladder and court booking system which holds the name, email and phone numbers of the students and staff both past and present from SIMS. 

Data No longer sent to a partner’s application.

The first challenge is to deal with missing people from the update. 

Partner’s must now ensure that their system will correctly deal with deleted records.  For example, if a former student ‘Bob Smith’ was deleted with the rest of his year group and so will not being included in any future data exchange. 

Technically there is no change here because SIMS has always allowed deletions of students. The key change is that GDPR has made it more likely that deletion will occur more often and in bulk.

What should a partner system do when a record is deleted?

There are two possibilities. 

• If ‘Bob Smith’ has not used the system for months then it is likely that the squash management system should also remove Bob. 
• The same may however not be true if Bob was the current leader of the squash ladder.

The key advice is that partners must consider and code for the expected deletions of records exported from SIMS. 

Partners who update data in SIMS should also consider the potential the removal of records in SIMS prior to write back! The most ironic example being that of trying to attach an e-copy of the request to delete that individual’s record!

Change Tracking

Change tracking APIs do record the external ID of deleted records and a date/time of deletion.  Please do note that these are only retained for the period of time set within the configuration screen and so do not offer a complete historic record of deletions.

Partners using change tracking would not be impacted by the new delete routines in SIMS except for the expectation that there will be more examples of deletions