Why it is important for schools to consider security#

Security has always been important in developing software to keep the data it holds protected. The increasing adoption of Software as a Service (SaaS) systems means that data is held online, so there is a greater reliance on providers to maintain aspects of security.

When purchasing new software, it is easy to focus on the great functionality and how it will make our jobs easier. Before choosing or using software, it is also important to understand the cyber risks associated with using new systems by considering the security of the software.

These systems often hold sensitive and important information about staff, students, their families and your school or kura. Therefore, it is important for schools to conduct due diligence on new software and ensure it is securely configured.

Security considerations when selecting new software and providers#

If you did not consider privacy and security risks when selecting your software, it’s a good idea to review the software you already maintain. You can then apply any recommendations to your new software settings to tighten the privacy.

Evaluating security and privacy risk#

Safer Technologies for Schools (ST4S) is an initiative set up to provide a catalogue of assurance reports on software commonly used by schools across Australia and New Zealand. This resource has information on school software that has been assessed against a set of security and privacy standards. It will help your school understand the level of risk attached to products. This resource should be referred to in the early stages of selecting new software.

Your school should use ST4S resources to make informed decisions when selecting digital products.

Access the following guidance to learn more about ST4S and how to access it.

Safer Technologies for Schools (ST4S)

Check if the software you use has an ST4S badge.

Verify a badge – Safer Technologies 4 Schools

Due diligence questions#

If the software your school is considering using is not included in the ST4S catalogue or you want to conduct further due diligence, here are some questions for your school to think about.

Software provider – due diligence considerations#

Your school should consider asking if the software provider holds any privacy and security certifications or compliance standards.

This information will usually be on the provider’s website if they do. Sometimes you will have to request this information from the provider.

Common examples are: 

• ISO/IEC 27001
• SOC 2
• CSA Star
• NIST CSF. 

If they hold any of these, this means they have information security practices in place to protect data and systems.

You should also ask:

• Where is the provider located?
• What support can the software provider give to our school during onboarding and on an ongoing basis?
• What aspects of the software is the provider responsible for maintaining?
• What aspects of the software is our school or kura responsible for maintaining?
• Is the software provider contractually required to notify us of any incidents?
• Can information security requirements be incorporated into the contract?

Software – due diligence considerations#

The following security considerations about the software, should be discussed with the software provider.

Software security

Your school should consider key security features of the software. You should ask:

• Are these enabled by default or do we have to configure it ourselves?
• What key privacy features does the software have – are these enabled by default or do we have to configure it ourselves?
• Is the software compatible with our school devices and operation systems?
• Does the software provider conduct regular security testing to identify weaknesses and vulnerabilities?

Data

You school should ask:

• Can the software provider’s staff access our data?
• Where is our data stored?
• Is the server where our data is stored, regularly updated and maintained?
• If our data is stored overseas, are there any legal implications with this?

Your school’s data should be fine being stored in AWS or Microsoft data centres, as they conduct information security assurance on their data centres.

Outages

Your school should ask:

• What is the guaranteed uptime for the software – can this be outlined in the contract?
• Is there any redundancy built into the software?
• Will backups be conducted for our data, and where are the backups stored?
• What type of logs are available and how long are they available for?

Configuring new software#

The software provider will most likely be responsible for maintaining the backend of the software, such as the underlying infrastructure and platform, which your school will not have visibility into. Your school will most likely be responsible for the configurations and managing access for your users.

Before the software is used, your school should make sure the following configurations are applied to new software:

• Configure single sign-on where possible.
• Set up 1 or 2 backup administrator or ‘break glass’ accounts.
• Make sure 2-factor authentication is turned on for all users.
• Set up a password policy within the system that aligns with your school’s password guidelines, if possible.
• Set up user accounts and permissions and use role-based templates or groups where possible.
• Make sure the right levels of access are applied.
• Disable any settings or features that are not required.
• Review what logging is available.

Using 2-factor authentication at school

Creating a password policy for your school

How to implement least privilege

If you install the software on your devices, you should make sure the software is regularly updated and backed up.

Do not be afraid to reach out to the software provider if you have questions about configuring any of the above.

Providers may have help guides, training material or resources available.

Other considerations#

In addition to configuring software, your school should also consider the following:

• Defining roles and responsibilities for the system – who will be responsible for maintaining the system?
• Ongoing user access reviews are completed – have staff left, any accounts that should not be there, do people have the right levels of access?
• Reviewing security reporting from the software provider periodically.
• Training for administrators and users.
• Updating the asset register to include the software.
• Tracking licences for the software.
• Updating any documentation to record users who have access to the new system for off-boarding purposes.