SIFA Data Privacy Charter

Data Privacy Team Charter

Version	Date	Reason	Author(s)
0.1	3/12/2014	Initial Draft	R Kleinman
0.2	4/08/2014	Adjusted to reflect initial reviewer feedback	R. Kleinman
0.3	4/15/2014	Adjusted to reflect initial SIG meeting feedback	R. Kleinman
0.4	4/23/2014	Adjusted to reflect international (AU) feedback	R. Kleinman
1.0	5/08/2014	Approved by ITB and Co-leads identified	R. Kleinman

Team Name:	Data Privacy Work Group
Date Submitted to TB leads:	TBD
Type of Charter:	Work Group ___X___
Work Group Sponsor Needed:	Core group of participants identified
Staff Liaison:	Name of Staff Liaison (or “unassigned”) ________Ron Kleinman____________
PT Leads: (Must be from different SIF member organizations)	Leslie Zimmerscheid, Wyoming SEA Graham Reed, SchoolsICT, UK
PT Members	Over 20

Need/Rationale for Formation:

Threats to student data privacy have received considerable attention recently, and it is generally recognized that while data security and data privacy issues overlap to some degree, there are enough differences that data privacy concerns can effectively be treated separately. Educational solutions at the school and district levels are increasingly deployed in the cloud, and that introduces a set of new concerns about who might be granted (or otherwise obtain) access to student health records, discipline actions or identification (ex: name, address and phone) information. At the 2014 SIF Annual Meeting at a session called “Who owns the data?” the consensus of attendees was to form a SIF Work Group focused exclusively on privacy issues surrounding access to and use of sensitive student related data.

Mission Statement:

This Work Group will concentrate on end user (District and State) issues relating to ensuring data privacy primarily for student data, but encompassing staff and possibly parental data privacy as well.  It will create: Checklist of Data Privacy “Recommendations”:  These suggest important SEA / LEA constraints be placed upon the privacy policies of Cloud Service providers, enabling EAs to meet or exceed FERPA and local data privacy mandates. Where such guidelines are not agreed to before sensitive student data is turned over to a Cloud Service vendor, data privacy can be fatally compromised with no recourse from the District or State.  Problematic examples have been posted on the Group SharePoint page and will be maintained and updated. Data Privacy Use Cases:  Identifies the major solution components (ex: District SIS, State Data Warehouse) and what sort of (student) data they each should be allowed access to in a particular process (and whether for all students or a subset): Ex A: Work Study Application (UK use case –only students in the work study program and only their identification and grades) Ex B: State level Data Warehouse (Student Data without identification elements like name, addresses, phone numbers) Object Data Privacy “Profiles”:  Each profile will correspond to one or more use cases, and will identify a unique collection of data elements which are to be excluded in objects conforming to that profile.  For example the Anonymous Student profile might contain an encoded unique index (UUID) but no identifying student data elements (name, addresses, phone numbers, etc.).  Other standardized profiles might exclude discipline or health related student elements or any combination of all 3. SIF administrative Data Privacy “Best Practices”:  These will specify exactly how SIF-compliant solutions can be administrated to enforce selected Object Data Privacy Profiles in a real world solution.  For example, once the Anonymous Student profile is selected, the multi-zone SIF Data Confederacy architecture allows local administrators to directly apply that profile to all student data exchanges in a separate Anonymous Student SIF Zone.  The set of applications assigned to that Zone (whether cloud based or not) never see the restricted information ... not because it is stripped out by routing middleware or just before message delivery, but because it is never made available to them.

Activity Overview
Projected Data Privacy Meetings For Version 3.0:	Virtual meetings:  24 (bi-monthly) Group meetings: 2 (SIF Annual Meeting and SIF Developer Camp) Minutes to be provided for each meeting:   ____X__
PST Time Frame for Version 3.0	Proposed Start Date:  3/25/2014 Estimated End Date:  12/16/2014
Tech Board Approval of Charter	Date Tech Board Approved  5/1/2014

Proposed Deliverables	Description	Est. Due Date	Dependencies & Assumptions	Status
Assemble Initial Team	·         Complete first draft of  Data Privacy Work Group Charter ·         Recruit additional members, ·         Hold first meeting, ·         Elect team leaders.	April-May 2014	Complete initial recruitment of members who are concerned with data privacy issues.	Completed
Scoping Document / Finalized Work Group Charter	Gain consensus on the scope of team activities and the set of initial “artifacts” team will attempt to produce. Publish final draft of the Work Group charter.	April-May 2014		Completed
Data Privacy SIG transformed into Data Privacy Work Group	Get ITB and Association Executive Board Approval of charter. Elect co-leads and start meeting as a Work Group	May 2014	Charter approved as submitted.	Completed
Activities
Identify critical end user Data Privacy concerns / questions and generate an associated Data Privacy  “Glossary of Terms”	Questions like: ·         Who “owns” the data? ·         Who “has” the data? ·         Who can access the data? ·         Who determines who can access the data? ·         Who can change the data? ·         Who defines “rules of ownership”? ·         Who enforces these rules? ·         Who verifies these rules are enforced? ·         Are there any special requirements when data is stored in 3rd party cloud?	June 2014	Initial list taken from the “Who owns the data” session notes at the Annual Meeting	In Progress
Define a list of cloud service provider recommendations which if adhered to would provide an “adequate” level of student data privacy	Potential examples include: ·         Cloud Servers must be located in US ·         No access given to product marketers ·         All data is owned solely by the district. ·         The district is the only entity that can specifically approve others to access its data ... no matter where the data actually resides.		Existing privacy policies of educational Cloud vendors will be examined and potential “weaknesses” identified and addressed
Define RFP wording to be used when a district solicits Cloud Service Provider proposals	Example: The student data belongs solely to the district and may never be considered an asset of the cloud service provider.  If a cloud service vendor is acquired or its assets sold, any new host organization must be explicitly approved by district or all student data must be downloaded to a district approved location and scrubbed from the cloud servers.		Providing this level of detail proves useful to Districts and States, and does not duplicate information available elsewhere.
Create Student Data Privacy “Profiles”	These apply data privacy concerns to the SIF Data Model, and define “subsets” of Student data that may be made accessible to a class of applications (ex: State level applications to District data)		Example might be AnonymousStudent profile with no identifying elements
Map data privacy requirements to a set of SIF solution best practices which can be implemented and enforced	Example: If multiple applications from an external source are to be given access to only part of a Student record (ex: no health, or no discipline or no identifying information) as defined in a Data Privacy Profile, consider creating a separate Zone for them in which the Student object events and responses simply do not contain the restricted information.		Providers supporting defined Data Privacy Profiles may be required to post multiple Events for a given change.