This checklist is to be completed by the responsible Business Owner or Project Manager. This must be done as early as possible in the planning process, for:

1. All new IT systems or key business processes

2. Any changes to IT systems or key business processes.

Note, for the purposes of this assessment, personal information is any information that relates to an identifiable individual. It does not have to include their name or contact details to be personal information.

If you do not believe that the change you are assessing involves or impacts on any personal information, then please provide your rationale for this in the summary of change section below.

Directorate: Strategy and Design

Sponsor: Ian Lee

Date Completed

Summary of Change

Provide a summary of the change being assessed. You should provide enough information to enable the reviewer to understand what the change involves, why TEC is doing it and what it is intended to achieve

In here talk about the platform and its purpose in relation to ItF. This is where you tell the story of the thing you are proposing to do.

What personal information will be involved?

Existing information

Provide a summary of any personal information TEC already holds that will be used in the change. This could be about customers, staff, stakeholders or other individuals.

Confirm the original purpose that this information was collected for.

New information

Provide a summary of any new personal information we will be collecting about individuals as a result of the change.

Provide reasons why we need this new information for this change.

In this case the information will largely be a new collection so we want to understand what we are proposing to collect. Be quite specific if you can be. If you aren’t sure whether we will collect something but it’s an option then note in brackets beside that thing (under consideration).

Voluntarily provides the following functions for people

Anonymous visitors

· Read web pages.

· Browse information about provider organisations and registered schools

· Browse and search opportunity listings

· View small picture and name of people providing opportunities.

Registered and signed in people

· Register and sign in using username, password, social media or enterprise credentials.

· Maintain a personal profile page

· Browse opportunity listings

· Express interest in, be invited to, and commit to opportunity listings.

· Access contact details (email, phone) of person organizing the opportunity to which they are invited.

· Complete activities and training and receive microcredentials (badges) for same.

· View the personal profiles of other volunteers including their listed skills and badges.

· Follow or join organisations.

Activity Providers

· Create and edit activity listings.

· Link and attach resources required for activity listings

· Define assessment requirements and issue badges to people meeting specified criteria.

Opportunity Providers

· Create and edit opportunity listings

· Link and attach resources required for opportunity listings

· Review profile, skills and badges of people expressing interest in an opportunity

· Accept and invite people to commit to the opportunity

· Access contact details – email and phone number of interested parties.

Organisation Adminisators

· Edit organisation profile

· Access listings and contact details of followers and members (email only)

· Create and issue badges

Personal Information

Anonymous users

· IP address and other platform information collected in the course of providing the web service. Retained by Google Analytics and system logs.

Logged in users

· Personal Profile information entered by user (* required)

Field

Description

Use

Required

Name *

full name - longform

in formal communications

required

Email *

validated email address

for validation as a human and communications

required

nickname

short form name how person would like to be addressed

general use on the site e.g 'nickname' is interested in this opportunity

optional

about

Anything the person wants to tell others about themselves. formatted text

Informing others, used to select recommended volunteering opportunities

optional

location

region or city

used to recommend opportunities by location

optional

phone

Contact phone number

made available to organisers when person is committed to an event

optional

pronoun

how to address someone appropriately - subject, object and posessive forms : them/they/their

to ensure communications are rendered using appropriate terms

optional

language

preferred language code (en, mi, fr etc)

to provide appropriate translations

optional

imgUrl

URL of image representing the person

Represents the person in various listings pages

optional

website

personal website URL

social network

optional

facebook

Facebook link

Allows share to Facebook function when participating in an activity

optional

twitter

twitter handle

Allows share to twitter function when participating in an activity

optional

status

active, inactive or on hold

inactive and hold people are not available on the site for opportunities

optional

dateAdded

when person first joined the site

administrative tracking

optional

tags

list of words describing skills, interests etc.

matching people to appropriate opportunities

optional

· Interest and Attendance

We record the relationship of a person with an opportunity through a lifecycle of being interested, invited, committed and finally having attended or not attended the event.

Before the event only the organisor ( and admins) is able to see the list of interested people. At any time the person can withdraw interest or commitment to an event.

After an event actual attendance is recorded for downstream reporting and to improve the effectiveness of the platform. This information is available to people on their personal history page.

· Badges Issued to Person

Each badge represents an award recognizing that the person has met specific criteria. Badges are illustrated with a small icon and a link to the badge description which may include the purpose of the badge, when issued, and a citation regarding the achievement or evidence provided to receive the badge.

Badges are portable and may be imported and exported from the platform to other systems including learning management systems, and social media sites.

Badges are intended to be made public and shared. However, badge receivers will be able to suppress the fact that they have a badge if they wish.

Badges fall into the following categories:

· System administration.

· Requirements and Skills

· Achievements and accomplishments

System Administration

Badges are used instead of status flags to indicate that a person has a certain status on the platform. These include:

· Email validation – confirmation that the person has reply access to the email address they have provided.

· Completion of personal profile – this indicates that a person has provided information on skills and interests etc. so that an organizer can assess their suitability for an activity. Note website and social media links are not required for profile completion.

· Identity validation – this indicates that the person has been validated as a ‘real person’ through various mechanisms that may include ‘RealMe’, viewing of passport or drivers licence. Note: identity validation is a pre-requisite for being able to request a Police vetting process.

· School Ready – this indicates that a person has completed preparatory training for volunteering in a school and has a passed police vetting. Opportunity and Activity providers may require volunteers to have the school ready badge prior to attending an event or working with children.

Note that absence of the badge does not reveal whether a person has failed a police vet as other steps such as email & identity validation, training etc. are also required.

Requirements and Skills

These badges are used to indicate that a person meets specific requirements for an activity or has been assessed to have specific skills. Providers may require at least one person attending to meet these requirements.

These may include:

· First Aider – person has a current first aid certificate

· Organisation specific training – such as TEC or OMGTech onboarding

· Language skills – competency in Te Reo Maori, NZSL, Chinese etc.

· Specific Technical or educational competency

Achievements and accomplishments

These badges are used to encourage participation and reputation in volunteering by recognizing attendance, special effort, key capabilities etc.

These may include:

· First time school volunteer

· Regular volunteer

· Going the extra mile – for volunteering further from home

· Volunteering where its most needed.

Is any of the information likely to be sensitive?

Provide details of any information involved in the change that is likely to be viewed as sensitive by the individuals that it relates to.

Most of the information stored in the system is both non sensitive and under the control of the person in question as to how much the share about themselves.

In the personal profile the telephone number and social media links are probably the most sensitive. Telephone number is not made publicly available and is only shared with people attending an event as a necessary communications tool. Social media links are shown on a person’s profile but are optional.

For Badges the most sensitive information would be whether the person has completed and failed police vetting. This specific information is not stored but is a requirement for a school ready badge that includes other steps.

In obtaining police vetting a more specific set of personal identity information is required. E.g full address, date of birth etc. This is collected as part of the vetting process through a form on the platform which collects data that is not stored in the platform. Instead it is transmitted to an API which results in a formal police vetting request. Once the information has been submitted it is not retained. Once the process has completed the badge is issued.

Where did we get the information from?

Individual

What information are we collecting directly from the individual involved?

For this information, how have we made sure that the individual understands what we are collecting and the purpose that we are collecting it for?

Most information is collected from the individual concerned and is available to them to be updated, removed or corrected.

Profile page forms give details on the purpose of each piece of information requested with further details in associated help.

TEO

What information is TEC collecting from a TEO about individuals? Outline why it is being collected from the TEO and what consent / authorisation we have to do so.

None at this time.

If TEOs are able to provide OB2 compliant microcredentials then we may allow people using the platform to import badges from such systems.

Other third party

What information is TEC collecting from other third party sources? List the source(s) and outline why it is being collected from the source and what consent / authorisation we have to do so.

· A teacher on the system may enter their teacher ID and we may autofill some information that can be obtained from this ID

· When an organisation, acting as a volunteer provider, has integrated into our authentication system so that their staff can sign in directly using their enterprise credentials, we will obtain initial values for Full Name, Nickname, Image and potentially role and skills from the enterprise source. People are then prompted to correct this information on their profile.

· When a person signs into the platform using a social media account such as Facebook, Twitter, GitHub etc. we will obtain initial values for Full Name, Nickname, Image and potentially role and skills from the social media source. People are then prompted to correct this information on their profile.

· If permitted by the person we may obtain initial values for skills and interests from sources such as LinkedIn.

· If permitted by the person we may import badges and credentials from alternative sources such as a learning management system.

· Some organisations may choose to bulk register their members by uploading a table of information. This will contain only basic account information (name, email, role, image)

Where are we storing the information?

Provide details of the system / location where information will be stored, including whether it will be hosted in the cloud. If the information will be stored outside the TEC environment, provide details of where and what contractual arrangements are in place.

This is where we need to talk about voluntarily, their security processes and what contractual arrangements are in place around this.

The voluntarily platform is realized through the following components

1. Source code

2. Integration and deployment tools

3. Cloud service accounts and configuration

4. Secrets

5. Run time instances

6. Databases associated with the run time instances.

Source code

Voluntarily is an Open Source platform under the Mozilla Public Licence (https://opensource.org/licenses/MPL-2.0)

This means that all source code including management and deployment scripts are available for public inspection.

Voluntarily source code is currently stored on Github.com at: https://github.com/voluntarily/vly2

The platform is based on the following key technologies:

· Node – javascript runtime library

· Express – Web service library

· React – Web UI framework

· MongoDB – document management database

Integration and deployment tools

Voluntarily platform makes use of the following integration and deployment tools (CI/CD)

· Cirrus CI https://cirrus-ci.com/ - This tool runs automated test coverage

· Docker https://www.docker.com/ - container platform

·

Cloud service accounts and configuration

Voluntarily platforms are currently hosted on Amazon Web Services (AWS) using the following services

· Elastic Container Service (ECS) – Fargate

· Elastic Container Repository (ECR)

· Load balancer

· CloudWatch – status monitoring and logging

· Certificate management

· CloudFormation – scripts to build the deployed instances and services.

· Simple Email Service (SES)

· Simple Storage Service (S3) – used to hold uploaded images and attachments.

It is a possibility that the production deployment may move to Microsoft Azure. There it will use a similar set of container and repository services.

Auth0

For identity management, user registration, sign in, social sign in, and enterprise sign in we use the identity services provided by Auth0.com.

Auth0 Data Privacy statement https://auth0.com/docs/compliance

The personal data stored in Auth0 is used only for the purposes of providing its services, namely authenticating users

Secrets

Secrets are maintained for the following:

· AWS account credentials used for site construction and deployment.

· AWS account credentials used to access run time services such as email (SES).

· AWS account credentials used for account management and billing

· Atlas Cloud account credentials used to access the MongoDB database.

Primary values for these secrets are held in a LastPass password manager.

Run time values for these secrets are stored as encrypted strings in the build scripts and then injected into the docker containers during construction by the CI system.

Run time instances

Voluntarily will maintain and operate the following run time instances of the platform

· Alpha.voluntarily.nz – used as a staging and test site for changes

· Beta.voluntarily.nz – used for field trials and beta testing

· Gamma.voluntarily.nz – used for performance and load testing

· Voluntarily.nz – NZ production site.

The above instances are hosted in Sydney with the exception of alpha which is hosted in Singapore (will move to Sydney eventually)

Databases associated with the run time instances.

All information used on the platform not in the source code, or secrets, is placed in the database. This is a mongoDB database hosted at https://cloud.mongodb.com/

The databases are currently hosted in Singapore.

Atlas Cloud Privacy Policy https://www.atlascloud.co.uk/privacy-policy/

How are we keeping the information safe?

Provide details of security controls that are in place to protect the information. If a security risk assessment or penetration testing has been completed, provide a summary of the outcomes here.

Security controls exist at the following levels

1. Access to Open source code.

2. Access to platforms

3. Access to Database contents

4. API Services

Access to Open source code

The source code is readable by anyone. Changes to the source code are subject to the following controls:

· To commit code people must have a github account and be added to a voluntarily members team to get the ability to create a branch, commit to a branch and issue pull requests. To get this access contributors must demonstrate basic capability in using the system and must communicate directly with the team to request access.

· Deployments are made only from the master branch. To commit to the master branch contributors must issue a Pull Request (PR). A restricted group of staff members have permission to accept a PR into the master branch, and the request must pass a suite of unit, function, end to end and coverage checks plus personal code review.

· Code base and libraries used are monitored by GitHub for known vulnerabilities.

Access to platforms

Access to platform for deployment is granted to staff via an AWS IAM account. Access is tracked. Deployed systems run as web services within docker containers and do not have shell access.

Website is Https only so all information transmitted is secured in transit. Information at rest is stored only in the AltasCloud database or in S3 buckets in the case of uploaded images. Both these storage locations are encrypted.

Access to Database contents

Direct access to the database through the atlas cloud service is limited to key administrative staff of voluntarily. (Currently only (Andrew and Walter). Code level access requires a secret which is not stored in the open source code base except in an encrypted form.

API Services

All information in and out of the database is provided by Server side APIs. These allow clients with appropriate credentials to make create, read, update, and delete requests on entities in the database which include people, activities, opportunities, organisations etc.

The API is secured via the CASL library https://github.com/stalniy/casl

This provides fine grained controls on

· Who can have access

· What requests they are able to make

· What data fields can be accessed or sent in requests.

For example, this allows us to provide general access to a personal profile while restricting access to edit the profile to the owner and not giving out phone numbers unless the requestor has the required status.

Security Risk Assessment

· Not yet carried out

Penetration Test

· Not yet carried out

How will people be able to access and correct their information?

Provide details of how individuals will be able to access and correct their information. Will it be through standard TEC processes or will additional steps need to be put in place?

All personal information held on the platform will be able to be edited and maintained by the person themselves through their personal profile.

With the following exceptions:

· If badges are issued in error they will need to be rescinded by the badge issuer

· If people are marked as either attending or not attending an event in error, then the organizer of the event will need to correct the error.

In both above cases the error can also be corrected by making a help desk request (through the site) and an admin will be able to correct the data.

How do we know personal information is accurate before we use it?

Provide a summary of any validation / accuracy controls that are being put in place to check personal information is accurate before it is used or disclosed.

If collection is from source then we would know.

Other than the person maintaining their profile information directly we perform the following

1. Email validation.

2. Real person validation as part of police vetting

3.

How will the information be used?

Provide a summary of how personal information will be used in the change. For example, if we are using information to assess an individual’s eligibility for a service and then delivering it, outline what information is being used for assessing the eligibility and what is required to deliver the service.

This is where we need to talk about who would be making decisions on things like the police check.

Activity and Opportunity providers are able to define the requirements for volunteers participating in an event. This is done by listing the badges required. Badge requirements may be either mandatory or optional. When assessing volunteers organisers have visibility of whether the volunteer has the necessary mandatory badges and how well they match the overall optional requirements.

Policy on whether a particular badge is required is therefore set by the organisation creating the request. In the case where an opportunity is generated from an activity both sets of requirements will be used.

Hence either a school, activity provider (such as ITF) or the voluntarily platform itself may set a policy.

Will there be any areas where we use algorithms or automated decision making?

Voluntarily will use algorithms to make recommendations to volunteers as to which opportunities they should consider e.g. by locality, skills matching, interests etc. Similar algorithms may be used to identify potential candidates for helping with an opportunity (shoulder tap).

Presence of absence of specific badges will be involved in automated decision making e.g. excluding non police vetted people from attending events that require it.

If the information is being used for research / analysis, will individuals be identifiable during the analysis or in the outputs?

In general no. However should we make available a complete set of volunteer activity data for analysis, even without personal identity information it may be able to identify people from other correlations such as social media postings about attending events etc.

Do we have the right permission / basis to use it for this

Do we have consent / authority or a legal basis to use the information in this way? If so, provide the details here.

We should probably add a consent statement into the platform as part of the build.

Yes, There will be a privacy section in the terms and conditions. A consent check box is required at the point of first expressing interest in an activity and thus wishing to be considered for invitation.

How have we communicated to individuals how we will be using their information?

We will need to write a statement to sit on voluntarily that talks about why we collect what we collect and what we will do with it, storage etc etc.

We can rewrite this document.

Are we going to be sharing the information with anyone else?

If so, list all parties who will have access to information, what information they will have access to and why they need to have it?

There will need to be detailed information in here on how the platform can/will lock down information. It will need to assess access controls.

Each Organisation registered on the platform will have access to the following information:

· Name and email address of followers

· Name and email address of members

· List of all people expressing interest, invited, committed, attended or not attended an opportunity they have organized.

· List of all opportunities, activities, events created on the system by the organisation or their members.

Volunteer provider organisations will have access to

· List of their staff members who have attended/not attended volunteering events, which events and how frequently.

· Reporting dashboard showing overall statistics.

·

Activity provider organisations will have access to

· List of opportunities created based on their activities including school, requestor and attendance list.

· Reporting dashboard showing overall statistics on the use and popularity of their activities.

OrgAdmin

Access to organisation reporting and data features is restricted to a member of the organisation designated OrgAdmin. Organisations may assign one or more Org Admin.

Do we have consent / authority or a legal basis to share the information in this way? If so, provide the details here.

Build initial consent on the platform.

As an Activity provider ITF will have access to information about schools that take up their activities.

How have we communicated to individuals how we will be sharing their information and who we will be sharing it with?

Privacy statement?

Provide details on what safeguards have been put in place to provide TEC with assurance that the information will be protected by the people / organisations we are sharing it with.

Again this is will relate to what Voluntarily have in place.

What will we do when we don’t need the information any longer?

Do we know how long we will need to retain the information for? Why is it for this period?

We plan to retain information about opportunities and the interested attendees indefinitely. When an event is completed then a subset of information about the event is moved to an archive collection along with feedback comments and attendance information. Transitory information such as questions asked, emails or chat discussions, invites sent or withdrawn etc will be discarded.

If a person decides to leave the site their personal information will be discarded. In order to maintain database integrity their account id will be retained and their profile details replaced with anonymized default values. E.g. name: volunteer ABCED.

How will the information be disposed of when it is no longer required?

Any non required records in the database will be deleted. In order to maintain database integrity some keys and non identifying information may be retained.

Are we using unique identifiers?

Are we using any specific unique identifiers for individuals as a part of this change (i.e. NSN, Driver Licence)? If so, provide details of what and why we are using them.

Probably not relevant but we should check that no unique identifiers will be created.

Personal email address is used as the unique identifier for a person in the system. However this may be changed along with name and nickname.

A database key is also used internally to identify the person. This is a non sequential, randomized string e.g 5d957d1094bcb300124d3d4f

This key cannot be used to identify the person in any other system.

Passport and Driver license information may be collected as part of the Police Vetting process. This is not stored in the personal data and not retained once the process has been completed.