© 2018 Capita Business Services Ltd. All rights reserved.
Capita Education Software Solutions is a trading name of Capita Business Services Ltd. Our Registered office is 30 Berners Street, London, W1T 3LR and our registered number is 02299747. Further information about Capita plc can be found in our legal statement.
A detailed set of considerations as to the impact of GDPR on integrators
This update reflects changes from updates to European Union Data Protection Law (and hence UK Law) and extends the interest group above. When we refer to ‘SIMS’ this may reasonably include additional SIMS modules such as FMS and Agora.
The protection of children is paramount and the safeguarding of their data should not be compromised in any way. ESS Ltd continues to promote best practices in Data protection to our Partners in conjunction with Local Authority Teams, MATs and other School Groups.
ESS’s products for education will typically hold:
Data subjects may include, but not be limited to:
On 25th May 2018 the General Data Production Regulation, GDPR, came into EU law for all member states, this provided a focus on the privacy rights for data subjects the export of personal data outside of the EU and EEA. The UK data protection act 2018 provides the specific detail from GDPR where member states are to detail how they provision the articles as defined in GDPR.
ESS Ltd has now provided a list of relevant links for partners which may be found at /node/31
ESS Ltd recommends that Partners consider obtaining legal advice to confirm that the requirements of the DPA 2018 and GDPR are considered for the following:
Where SIMS is used outside of UK / EU jurisdiction, ESS Ltd would recommend that appropriate legal advice is sought with regard to each and every country supplied. EG:
ESS Ltd Partner contracts contain the following section
These clauses are intended to bring to the partner’s attention the need to comply with GDPR / DPA and allow the data controller to assess whether the data processing is legal and appopriate.
GDPR makes significant changes to the level of fines available to enforcement authorities.
ESS Ltd recommend that any queries relating to the UK Data Protection Act 2018 are referred to the Information Commissioner’s Office (ICO) https://ico.org.uk
There is little difference between GDPR requirements of partner products using data on the web vs those using data on premise. The key point is that data is processed as soon as it is pushed or pulled on the web.
Or example is a web-based school music service who only have permission to exchange data for pupils using the service (blue pupils).
The security of the data is the responsibility of the data controller and this includes ensuring that the movement of data complies with their policies and the law.
Data processed within the school’ server or within a cloud system before passing it over the web is low-risk processing. For example, a SQL server would likely process all the pupil records whilst extracting the list of pupils with consent recorded for the School Music Service. (i.e. to the left of the red line above). Once data crosses the line, it is clearly processed and hence data about the red children above should not cross the line.
Web applications need to only demand data for which they have the authority to process.
The school will have a designated data controller. Any data processing that occurs on the MIS data should be with their knowledge and consent. Consent can only be given within the constraints of the Data Protection Act and various Education Acts.
The software / service provider must be transparent in the information it provides on how customer data is processed to allow the data controller to make decisions on the suitability of the software and / or service.
Under GDPR all data controllers must have an appointed and registered Data Protection Officer – this may be a shared resource.
Data Controllers should demand full disclosure on the data extracted, what happens to it, where it is stored and what additional consents, if any, might be required. Data controllers should check with their Local Authority Data Protection Advisor or the Office of the Information Commissioner ( ICO) if they are in any doubt. Data Controllers must challenge any supplier if they are unsure or have concerns about any product, service or how it should be implemented.
A common misconception is that if school A uses a product then it would be automatically legal for school B to use the same product. School B should only use the product if they too meet the requirements of GDPR / DPA 2018 and are required to check that this is the case.
For the purpose of development and to follow best practice, fictitious data must be used for all development work.
DPA 2018 defines a data controller as those who determine the purpose and means for processing personal data. If customer live data is required for development work the development organisation will become the data controller which has to register a lawful basis for processing the data and gaining consent from all data subjects.
State Schools, Academy Trusts (MAT), Independent schools & School Groups / Trusts may choose to write their own bespoke extensions for our products.
In this case there would be absolutely no difference in the requirements for GDPR placed on the school or a commercial organisation. As above training data should be used where at all possible and rather than live data or copies thereof. If the use of real data is being considered, please refer to refer to the ICO for guidance https://ico.org.uk for further advice.
Please note that even relatively trivial developments whereby the school provides a CSV export to a developer internal or external to the school must comply.
This is a matter between the data controller and the partner. Basic guidance should be that the data extracted should be the minimum subset that is reasonably required to complete the task.
Can a catering system extract DOB from SIMS?
> To enable tills to play happy birthday for appropriate students & staff?
> To implement age-based pricing.
It is likely that playing happy birthday would require the explicit consent of data subjects and might lead to bullying.
Age discrimination laws may prevent age dependent pricing.
Schools would need to consider the justification and the catering software provider may need to plan for a school refusing data transfer for the purposes given.
Example #1
A door access management system extracts gender from SIMS; is that reasonable?
Justifications given:
> The import mechanism uses fuzzy matching to assist with linking to existing record.
> Access may be restricted by gender (e.g. Female Locker Room)
Some data such as gender is often extracted as a matter of course and might be used as a part of fuzzy matching with say Surname, Forename & DOB.
The number of matches where gender genuinely differentiates between 2 children born on the same day with the same names is likely to be very small. Hence justification for extracting gender might be weak.
A better justification might be the restriction of access by gender should this be required by the school and appropriate. Arguably if the school did not use that feature then it should be possible to exclude it from processing.
The law is clear and GDPR Principles require that data minimisation is at the heart of ‘legitimate processing’; hence there needs to be clear reasons to extract gender (or any other field).
Example #2
A proposal for a new web based system wants to extract various data about parents and students. Could the system reasonably extract ethnicity and home language?
The answer to the question is purely down to why the provider needs the data and what it does with it and whether any required consent is obtained. Ethnicity and Home Language are deemed special category data under the data protection act. If the system offered billing in the parent’s home language then a case can be made to extract home language. It is less clear how the extraction of ethnicity can be justified. Regardless of the data usage, it may be necessary to get the specific consent of the data subject before the data is exported.
Example #3
A partner system extracts surname and legal surname to ensure that the future proof their system but legal surname won’t be used initially.
GDPR Principles require that data minimisation is at the heart of ‘legitimate processing’; some data can become sensitive when compared with other data items. In this case if legal surnames are different to surnames that may present an opportunity for bullying.
Schools must question the extraction of any data that is not actually required by an external system.
Example #4
A summary report shows the percentage of staff recorded as being pregnant.
1 member of staff is pregnant.
The school asserts that the percentage is special category data (Health).
If the school has 50 female staff then the school might be right, if the school has one female member of staff then they are clearly wrong. The publication of summary data must be checked against the risk of exposing personal data inappropriately
Example #5
All that ESS Ltd can do is to draw partner’s attention to such issues and remind partners to extract the minimum and most appropriate data as agreed with the Data Controller.
Please refer to the ICO GDPR principles for further guidance.
There is a collection of consents that are managed in SIMS for students. This is based on a lookup list which the school can edit to meet their needs. For example:
Partners and schools can make use of consent management but need to note that the consents may be called something different from school to school and that a consent called ‘photo’ may mean different things in different schools.
Partners using SIMS consents must ask schools to define the name of the consent to be used for each feature of their application requiring consent.
In order to extract data from SIMS, the partner will require a bona fide SIMS user to log in to SIMS (in some sense) and the user’s access rights will dictate what data can be extracted.
Partners have access to https://support.capitasoftware.com If partners search for 'permissions spreadsheet' then they should find a link to the latest permissions spreadsheet. There are 2 ways in which partner applications can request that schools manage access to their systems.
The main difference being that a real user may have additional access rights, a bespoke user must only have the lowest access levels required to extract the required data.
It is possible to grant rights to just about all the data in SIMS, however, this would provide a user who can log in to SIMS and see the data that the user’s rights allow.
SIMS provides a set of pre-defined access permission groups for the convenience of customers. System Manager also allows customers to create their own bespoke permission groups if they deem the default groups to be insufficient for their needs.
A common request from partners is access to sensitive fields for staff members such as staff telephone numbers and emails that require the grant of ‘Personnel Officer’ rights to access this data, based on the default permission groups in SIMS. Within SIMS, there is no differentiation on which emails or phone numbers are suitable for wider disclosure.
It is possible to create user defined permission groups which could for example have read only access to staff communication information which includes phone numbers and email addresses and hence allow a more granular control of access. If this is required then the school may choose to create specific access right groups and use them for partner products in addition to or as a replacement for the default access groups provided.
A common response when a Partner demands that the school grants Personnel Officer Access rights to say ‘partnerUser’ is to either question the need with the partner and/or decline the request.
The reasons why a data controller may say ‘No’ are discussed below.
WARNING
Partners are recommended to consider their response if the school says no to any part of their data extraction.
Whilst partners may ask schools to create a user for them with an indicative name e.g.’ <Partner Product>User’, it is essential that the school retains these credentials and does not share these with any third party.
Partner Systems will need to extract / exchange data using a User Name and Password for on premise applications. Our web based products may require other forms of identity and are usually based on SIMS ID which is an OAuth2 provider.
In all cases, the school will grant to a user or application a set of rights in line with the needs of the application or service.
For on premise applications, It is always best practice to ask a member if the school staff to enter the password and to keep the password secret and wholly within the school. This avoids the risk that the data is compromised by access external to school staff. Whilst this may be best practice, there may be instances where this may not be possible for example the provision of Local Support Units account but additional safeguards should be sought where these access rights are granted.
Web based products may well have a distributed security model but it is essential that all credentials and secrets are kept secret except to those that absolutely need them.
Data held within the school’s network needs to be secured or securable to an appropriate standard. Where the data is taken out of the school’s network then added security requirements will apply but essentially the paradigms are the same. Only those people who should have access to the data should be allowed access to the data. Additionally data in transit must be secured to a demonstrable international standard. The data protection act is specific as to where data can be transported to see http://www.ico.gov.uk/ for details.
Only those things that are agreed by the data controller which comply with all relevant UK or appropriate government laws! Care should be taken if a supplier is subject to jurisdiction outside of the EU and schools are advised to confirm their legal position with their LA or legal advisors before engaging.
A supplier provides a routine that extracts a basic set of data and stores it in say a SQL database housed in the school and uses it to say generate network folders and accounts for all of the students within the school’s network.
Risk should be low because:
In addition, if the partner never sees real school data then they may not need to invest in data protection registration and DBS checks for staff.
Example #6
A partner extracts data including data within the ‘Special Data Category’ from SIMS, stores it on their own corporate network, and uses this to provide say a support service for SEND children at home.
Risks, in this case, are obviously higher and need to be correctly managed:
> Clear contracts need to be in place with the provider defining what data is taken and how it will be used and protected.
> Sign off needs to be from the senior management team perhaps supported by the LA / Trust /
Managing Group.
> Legal advice may be needed.
> All appropriate registrations/staff clearances must be obtained.
Example #7
A product provided by a commercial entity uses the school data to email parents about exciting offers for their children such as theme park deals and holiday clubs.
Example #8
It is the prerogative of the data controller to say no. That said, it is unlikely that the data controller would say no to an ‘Appropriate Request’. An ‘Appropriate Request’ being one that enables and enhances the operation of the school without compromising their data or granting access to any unnecessary data and meets the requirements of GDPR / DPA 2018 with regards to the way in which data is processed
It is quite plausible that a partner could provide a system that can take say staff and student emails and use these to inform them of school closure. If the school / LA have provided staff and students with ‘corporate’ email addresses then it is doubtful if the staff could object to such a disclosure. However, the staff or their trade unions may object to a private email being transferred to the partner system without the explicit consent of the staff member. If an objection occurs then the partner will need to accept that this is the case and provide some work around for example the provision of a web page that allows a member of staff to register their email address for use.
None whatsoever!
ESS Ltd cannot dictate or seek to dictate what data a partner extracts and what they do with it!
ESS Ltd has and can have no opinion as to whether the extraction of any given data by a partner is correct or reasonable.
We believe that as part of our duty of care it is correct and appropriate for us to raise the profile of these issues with customers and partners with the aim of promoting debate. This may in turn cause partners to have to justify to the data controller what they are doing and why.
Schools must have a data protection policy, this is often provided by the Data Protection Officer at a local authority, trust, or managing group. ESS Ltd recommends that the data controller should at least ask partners the questions below before agreeing to any data extraction by a partner.
We would suggest that the school’s data controller had the discussion directly with the partner and then draw their own conclusion. If they have access to a Data Protection Officer at their LA then any remaining questions should be referred to them.
Data controllers are advised to seek and retain written / printed answers to the questions above to ensure that they can answer any questions raised about the use of the additional software/services.
Partners must make this information available to their customers and the information provided must be:
ESS Ltd also has to comply with these requirements; for example a document is available for our Partnership Exchange Customers detailing the data exchanged between partnership schools.
ESS Ltd Partners will be provided with a utility called ‘Report Manager’. This allows them to change the ‘Supplier Name’ for reports. ESS Ltd requires all partners to use this utility to ‘brand’ any report that they distribute with some form of traceable name linked to their Company. For example ESS Ltd Reports might be branded as:
In all cases, the report ‘brand’ must be sufficient to identify the supplier and MUST NOT refer to ESS Ltd, ‘Green Abbey School, SIMS or derivatives thereof, unless ESS Ltd has agreed to this in writing.
Partners may consider referring customers to their report definitions as one mechanism for confirming the data extracted from SIMS. An example is given below.
ESS Ltd would expect partners to provide a statement that details what data is extracted for each facility that they provide. Partners are asked to note that it is possible to be granted the right to extract data for one purpose but that may not give them the right to use it for another purpose even though they hold the data. For example, it would be reasonable to extract data for school use to enable say exam certificates to be sent directly home to students, but it would not be reasonable without further consent to use the same data to advertise vacancies for A level mathematicians at a university
BustIt and FixIt PLC
The data extracted from SIMS is as follows:
Report1: Student Base for Bustit and Fixit PLC
Focus: Students
Filter: Students on roll as of the specified date
Order: Default (Surname, Forename)
Columns: Preferred Surname
Preferred Forename
Middle Names
Admission Number (To aid identification)
Year (To aid identification)
Reg (To aid identification)
Gender (For analysis purposes)
Ethnicity (For analysis purposes)
Exam Results (All)
Exam (For analysis purposes)
Result (For analysis purposes)
Points (For analysis purposes)
Subject (For analysis purposes)
Purpose of Extraction
This application extracts student data and produces a graph of exams results broken down by gender, grade, subject and ethnicity.
Location of extracted data
Extracted data is posted via PPK encryption over http to our data centre located in Hanoi, Vietnam. We have EU standard reciprocal agreements in place for data security and protection. Our parent company Free and Easy Marketing PLC are subject to Zimbabwean Law.
Access to extracted data
Data access is restricted to senior staff. School access is restricted to staff with a login to www.bustitfast.com/yourschool. School staff may request a login on that site simply by providing the school name and your email address. Schools may request a list of access holders by emailing service@bustit.com.zw
Example #9
The statement above contains all the information that was required by ESS Ltd . ESS Ltd are not in a position to judge whether this is acceptable. In the above case, the data controller at the school should reject the software because it contains sensitive personal information with insufficient access control to meet a reasonable expectation of control.
The fact that data will be going outside of the EU may also mean that the data controller could not agree to the transfer. At the very least they would need to refer this to their legal service for advice; that said each case is judged on the standards deemed to operate in that country.
(Please do not ask ESS Ltd to adjudicate on such matters)
ESS Ltd will always recommend that schools use accredited partner products to augment their SIMS systems. The accreditation process requires that partners provided public URLs for:
Whilst ESS Ltd cannot warrant these statements/links we may be able to advise if we have concerns upon the links. A typical concern is that partners occasionally provide a link to their own web site DPIA rather than one that covers the school’s data held by them and surfaced within their applications.
If a partner ever has possession of personal data then they have a legal requirement to register under the data protection act. ESS Ltd cannot advise them as to the content of that registration but will require that partners provide a link to their data protection policy and will refer joint customers or other interested parties to the data protection registration documentation on request. This forms part of ESS Ltd ’s Due Diligence requirements. Where data is stored in the cloud appropriate registration should be sought.
CRB is now renamed to the Disclosure and Barring Service (DBS).
https://www.gov.uk/disclosure-barring-service-check/overview
At ESS Ltd:
The basis for the enhanced check is the inability to guarantee that ESS Ltd staff in schools would be chaperoned throughout their visit and the obvious need to ensure the safety of school children.
Please that any disclosures would be individually considered prior to or during employment and may not debar them from employment.
Partners are likely to engage in similar activities to ESS Ltd and should give due consideration to checking their staff, especially those who visit schools.
One of the key requirements for all data processors in the event of a potential breach is that they help the data controller in a timely and transparent way to evaluate the potential breach to decide whether:
Time scales are short in which to make decisions which makes it essential that data controllers get appropriate and timely support with their investigations. The ICO publishes helpful guidance but the 72 hour deadline means that prior planning must be complete and documented processes in place prior to any potential breach if statutory deadlines are to be met.
ESS Ltd provides various mechanisms to enable interoperability between SIMS and other systems. The act of extracting data from the SIMS system(s) must always be under the protection of SIMS security system (i.e. not by direct access to the database) as a bona fide SIMS user. That data extracted is then solely the responsibility of the system extracting it to protect it thereafter under the prevailing law. Once extracted, ESS Ltd ESS is unable to take any responsibility for the data extracted.
Any similarity between examples provided above and actual partner product is co-incidental.