Everyone is talking about Data Security and Privacy these days - and rightly so. The fantastic benefits that the Cloud and Chromebooks in particular have brought to education also have their trade-offs, and CIO’s need to be sure that suppliers are taking their responsibilities with your District and Student data seriously.
I thought it would be useful to help schools who are going through this transition by creating a checklist - A list of questions to ask your software supplier to help manage your risk, and ensure the safety, security and privacy of your data.
Remember, under FERPA it is the District’s and School’s responsibility to look after the data - Schools need to satisfy themselves that their data is being treated properly if they entrust a software provider with it.
This sounds complex, but it is pretty easy to understand - we have all learned not to use our credit cards on a website unless we see the padlock icon, and we can see HTTPS at the start of the URL. This means that your Credit Card details are encrypted as they are sent to the website. You should ensure that your ed tech software provider is using HTTPS to encrypt all the data that is transmitted or received from your district. This is to stop a “man in the middle” attack, where a hacker can listen to the data as it passes through the network - if it is encrypted they cannot understand it.
When the data is stored in your provider's database it should also be encrypted. This is for several reasons, but the two most obvious are to prevent unauthorised employees at the provider from accessing the data, and also making the data useless in the event that the server or hard disk is stolen.
If your supplier does not need the data to fulfill the purpose of the software or contract, then it should not collect and store it at all. This is a simple and obvious premise, but is often overlooked. Most SAAS (software as a service) has a privacy policy that lists what personal data the software stores and why they need to have it.
For example, with Read&Write for Google Chrome™ we need to store encrypted individual user IDs so that we can tell if someone is licenced or not. That is the only potentially personally identifiable information we store for that product.
In the old days of Windows or Mac when you installed a piece of software, you basically had to trust it with everything. Software running on Windows could read all the data on your hard drive, and you just had to accept that. Nowadays with Google Chrome Apps and Extensions you can clearly see the permissions that the software is asking for at installation time. Responsible software vendors will do the following:
With assistive technology these permissions often look pretty scary, but when you understand what the AT needs to do, it should appear much more reasonable. Assistive Technology is used to read text aloud from Web Pages and so it needs the scary looking permission “Access your data on all websites”. But every screen reader needs this permission. Google Chrome requires that screen readers and text readers have this permission to enable the AT to access the text and turn it into speech.
A good supplier will have a formal Data Security Policy, possibly audited and approved by an external standards body such as ISO. The data security policy should cover how your data is stored, and what the supplier does to protect it. Some things to look out for in the policy are:
If a company is taking its data security seriously, they will have considered what happens if something goes wrong. Your supplier should have a documented Security Breach Procedure.
If there is a security breach a data security incident plan should be in place that should at the very least:
When possible ALL data should be de-identified. For example, we don’t actually store a user’s Google ID, but rather a one way encryption of it, so even our developers cannot decrypt it.
In the case of some districts, their Data Security Policies classify Meta-Data - e.g. a large picture analysis of student behaviours across a large group of students, as “Student Data”. Because of this the only person at Texthelp who is allowed unrestricted access to User Analytics is the Data Protection Officer. That person uses their knowledge of FERPA, COPPA, and the specific contracts with the districts to control access to the data. This is a documented procedure for us at Texthelp.
With web based software one of the most useful things that software engineers can see is usage analytics. Texthelp tracks this information. It is actually very impersonal - I have included some examples below to give you a flavour of what our development team can see to help them make decisions.
Different Browsers
Most of our users are on Chrome, but we do need to support Safari, MSIE and Firefox
Different Screen Resolutions
This helps us design UI that works for everyone.
Different Operating Systems
Analytics helped us to predict the rapid swing to ChromeOS, and helped us build a product that is great for Chromebooks.
Server Load through the day
We have users in 182 countries, but the USA and Canada keep us pretty busy - we need to track users across geographies and time zones to make sure your speech, and dictionary definitions are served up promptly - even if 50,000 kids are reading different books at the same time.
This is not personal information, but an aggregated picture of use that allows us to improve our service and focus on solving the problems that are impacting the most users.
We have 1 to 2 million students who use our software for free every week. We do not know their user IDs.
What we at Texthelp do know is this:
There is a lot of fear and uncertainty about student data, and student privacy in the marketplace.
The best cure for uncertainty and doubt is information - and hopefully I have given you all some information about what we do with data at Texthelp, and some questions that you can ask your suppliers to get some comfort around how they treat your data.
Any Ed Tech company with good corporate governance will have a similar approach. If you are not sure, just ask them.
If you have any questions or want to start a dialog about this please contact me directly - m.mckay@texthelp.com.