Cookies on this website

We use cookies to ensure that we give you the best experience on our website. If you click 'Accept all cookies' we'll assume that you are happy to receive all cookies and you won't see this message again. If you click 'Reject all non-essential cookies' only necessary cookies providing core functionality such as security, network management, and accessibility will be enabled. Click 'Find out more' for information on how to change your cookie settings.

On-line, cloud-based software includes common services like SurveyMonkey, Google docs, Zoom as well as more specialised software - Qualtrics, Simitive. These have the technical term of Software as a Service (SAAS).

SAAS is hosted in the cloud and so the data you add or generate in the system is stored in the cloud.  SAAS is often incredibly efficient, quick to set up (as you only need your web browser to access it) and inexpensive or even free. However, to use it for University purposes there are several steps to go through in order to commission a system. 

You can undertake the steps concurrently but you must be aware that each one could take at least two weeks (often longer) to obtain sign-off. 

For purchasing over £25,000 you will need to undertake due diligence in a tendering process. In that case, think about setting out and prioritising your requirements (see the specifications section).

The financial regulations require the use of the University’s SAAS Terms & Conditions. If that isn’t possible, you may need further assistance from Purchasing and/or Legal Services.  

There are two elements you will need along with the T&Cs - a Security Schedule (see Security) and, if relevant, a Data Processor Agreement (see Data Privacy). 

You will need to initiate a Third Party Security Assessment (TPSA). This should result in a risk profile for the supplier to inform your decision making, and the security schedule for the T&Cs. You can find out whether a TPSA has already been undertaken, but be aware that the assessment might be for a different process or different level of confidentiality. 

Part of the TPSA addresses the level of confidentiality of the information you are likely to process through the system and whether this involves identified or identifiable personal data, if this is the case, then you will also need to consider data privacy.

If you are planning on processing personal data, you may need to undertake a DPIA 

 A screening process helps you decide if you need the full DPIA. If not, a DPA is recommended. It feels like a burden but encourages you to think about the risks involved and address the niggling bits and pieces you might otherwise put to the back of your mind - like back-up, deletion, retention. All of which will usually highlight the importance of appointing a service owner and defining a checklist for them.  

You also need to be aware that your software provider takes on a formal role of data processor under the GDPR/DPA18 (UK GDPR). So you will need a data processor agreement. This is usually incorporated into the University's SAAS Terms and Conditions.

 Make sure you are aware of where your data will be processed and stored. At the time of writing, within the EU/EAA is acceptable, but standard contractual clauses must be used for most of the rest of the world including the US (please be aware that the Privacy Shield we used to rely on for the US is no longer valid). You should find the clauses incorporated into the University agreements. 

 Don’t forget the schedule with data protection particulars, usually lurking at the bottom of the agreement.  

 

 

There is no formal requirement for a Service Owner, but it is worth giving responsibility and ownership to someone, bearing in mind the following: 

  • Does the system will require specific configuration or special training of users as part of the mitigation of security or data privacy risks?  
  • TPSAs need to be revisited every few years 
  • DPAs/DPIAs should be revisited if the system changes or your use of the system changes 
  • You should review access and log ins every year to ensure that accounts haven’t been abandoned or people who have left still need access 
  • Are your back-up, retention and deletion schedules working appropriately? 

This role might overlap with that of Information Asset Administrator. 

Specifications?

Do you have a list of requirements and have you thought through the processes you want to model with the system? 

Two useful (and simple) techniques for creating a list of requirements and prioritising them are User Stories and MoSCoW prioritisation.  

Already in Use?

Is the University already using the system you’re interested in and have they done due diligence? 

The system might show up in Information Security TPSA List or in the IT Services Application Catalogue. In that case you could contact purchasing to see if they have negotiated terms or a framework agreement. 

Alternatives? 

Is there an alternative already in use in the University? 

This is a tricky question as the possibilities are endless - the current application catalogue only includes software in use in central services, not the MSD. It doesn't guarantee that the software has been through the entire assurance process.  

The links above can help, and requirements and prioritisation can help with defining the problem. If you are processing research data then consult the Research Data Management Service for advice.