Student data: five things to demand from your software provider

An educational institution holds sensitive information on thousands of people: identity, address, parents' phone numbers, marks, financial status, sometimes health details. When it entrusts that data to an online platform, it remains responsible for what happens to it. The provider is only accountable for what the contract actually says.

Here are the five points to get in black and white. We hold ourselves to them too.

1. Know where the data is hosted

The first question, and often the most awkward one for the provider: in which country, in which building, with whom? "In the cloud" is not an answer. You need to know:

• the country and city where the servers are located;
• the company operating those servers, if it is not the provider itself;
• the law that applies to the stored data;
• the procedure for retrieving all of your data if you change provider, with a deadline and a format.

That last point, reversibility, is too often forgotten. A contract with no exit clause leaves you locked in.

2. Role-based access, not shared accounts

In many institutions, a single login is passed around three or four people in the registry. The day a mark is changed, nobody knows who did it.

Insist that every user has their own account, and that each account only gives access to what that person needs:

• lecturers enter marks for their own courses, not anyone else's;
• cashiers see payments, not deliberations;
• faculty secretaries manage their faculty, not the whole university;
• the provider's system administrator has no reason to read the content of student files.

Ask, too, how accounts are disabled when someone leaves. It is a classic gap: the former employee whose login still works six months later.

3. An activity log

Everything that matters should leave a trace: who changed which mark, when and from which computer; who approved a payment; who exported the student list. The institution must be able to consult this log, and ordinary users must not be able to erase it.

The log is not only there to catch wrongdoing. It lets you answer a student who disputes a mark calmly, trace the source of an error, and it deters anyone tempted to "adjust" a result.

4. Backups, and proof that they work

Ask the provider:

• how often the data is backed up;
• where the copies are kept, and whether one of them is off site;
• when the last restore test took place, and what the outcome was.

"We back up every day" is not enough. A backup that has never been restored is an assumption, not a guarantee. We cover this in detail in a separate article on the 3-2-1 rule.

5. Two-factor authentication for sensitive accounts

Passwords get stolen, guessed or written on a note stuck to the screen. For accounts that can change marks, approve payments or administer the platform, require a second factor: a code sent by text message, generated by an app on the phone, or a physical key.

Text messages have their limits, but they work on any phone, including the most basic, and they are far better than no second factor at all. For administrators, an authenticator app is preferable.

Questions to ask in the meeting

Before signing, ask these questions and make sure the answers end up in the contract:

1. Where is our data physically located, and under which law?
2. Who on your side can access it, and is that access logged?
3. Can we create roles that fit our organisation?
4. Can we consult the activity log ourselves?
5. When did you last test a restore?
6. Is two-factor authentication available, and can we make it mandatory?
7. How do we get our data back if we leave?

A serious provider answers these questions in writing, without evasion.

For our part, access to the servers we run in Kinshasa is restricted to named administrators, that access is logged, and reversibility is written into the contract: you receive a complete archive of your data and configuration within fifteen days, free of charge. Details are on our hosting offer page. To review your current set-up, write to us.