Announcement

December 4, 2018

The European Union’s General Data Protection Regulation (GDPR) has affected NYU in many ways, including aspects of various University policies. Among these are NYU’s data-centric policies, especially the Data Classification Table and the Reference for Data and System Classification.

As a result, these two documents were reviewed extensively by committees and representatives of the University community, including members from the Office of General Counsel (OGC) and the Office of Information Security (OIS), the GDPR Data Protection Officer (DPO), the NYU IT Chief Data Architect, various data stewards and compliance personnel, and others.

It was determined that the Table and Reference contained much of the same information, were unwieldy, and that a single policy would provide essential and increased information while incorporating necessary data-centric information about the GDPR. As a result, for convenience and clarification, information in the Table and Reference was updated, combined into one document, and re-issued as the below Electronic Data and System Risk Classification Policy.

Note that the changes reflected in the Electronic Data and System Risk Classification Policy below require modifications in other currently posted policies, especially the security policies. Those changes are underway; NYU community members are encouraged to check the Information Technology Policies and Guidelines website periodically for updates.

Statement of Policy

New York University is committed to safeguarding the privacy of its students, alumni, faculty, and staff, as well as protecting the confidentiality, integrity, and availability of information and systems that are important to the University’s mission. This policy is the authoritative source of information on data and systems risk classification at NYU.

Purpose of this Policy

This policy provides a framework for safeguarding NYU’s information assets, i.e., its information technology systems and the data in its possession. NYU has classified its information assets into risk-based categories for the purpose of determining who is allowed to access and use those assets and what security precautions must be taken to safeguard those assets against unauthorized access. Risk is considered loss of confidentiality, integrity, or availability. This policy should be read in conjunction with the Data and System Security Measures policy, which sets forth the specific security measures that apply to each data and system classification.

This policy establishes the following risk classifications for NYU data: Low Risk, Moderate Risk, and High Risk; and the following criticality classifications for NYU systems: Low Criticality, Moderate Criticality, and High Criticality. The classifications help to identify the level of safeguarding required for any specific type of data or system. While all data and systems must be safeguarded, more stringent measures are required as the level of risk or criticality increases.

Scope of this Policy

The data and systems referred to in this policy must be properly safeguarded regardless of the location of the specific data and the systems on which they can be found. This risk classification, therefore, is applicable to a wide variety of IT resources which are connected to NYU-NET or are used for any NYU business purpose, including personally owned devices. A “system” is defined as any IT resource to which security safeguards may be applied.

Examples of systems include, but are not limited to:

  1. Desktop, laptop, or server computers running general purpose operating systems such as Windows, Mac OS, Unix/Linux, and mobile applications
  2. Network server applications, such as an SFTP-server application
  3. Applications and web applications, such as student information systems, HR systems, learning management systems, websites, CMS, and wikis among others
  4. Databases, Data Warehouse, APIs, and other data exchange systems
  5. Mobile devices, such as tablets, smartphones, and IoT devices where data can be stored
  6. Authentication and authorization systems such as SSO, Active Directory, and LDAP, among others

All of the above systems may perform their own authentication and authorization, logging and auditing, and have their own configurations which must be managed, and each of them is considered a compliance object to be safeguarded.

A system may be classified at a higher criticality than is required by the classification below. If so, the system must meet the security measures for that higher criticality level.

To Whom this Policy Applies

Those responsible for classifying data and system risk may be individual system owners, system administrators, project managers, or data stewards/trustees. The entire NYU community (faculty, staff, students, contractors/consultants, alumni, vendors, and guests) who access University data and systems must consider how they are protecting University data and systems. Therefore, all must be aware of the sensitivity of the data they access and the resultant risk if that data is not properly safeguarded.

Procedures for Implementation

Data Risk Classification

Three levels of data risk classification are outlined below which are based on the impact of an unauthorized access, disclosure or alteration of the data in question to individual community members and/or to NYU as an institution.

Risk classification of data takes into account the:

  • inherent attributes of the data,
  • source of the data,
  • regulation or policy governing the data, and
  • relationship of the data to previously disclosed data.

The classification of specific data is subject to change as the attributes of that data change (e.g., its elements, content, uses, importance, method of transmission, or regulatory context).

The data classifications are listed below with examples provided in the following section. The following rules should be applied when classifying data:

  • When a data element falls into more than one category, it should be classified in the highest applicable risk category. For example, if a data element meets the definition for both Moderate Risk and High Risk data, it should be classified as High Risk.
  • When a data set includes more than one data element, the data set should be classified based on the highest applicable risk category. For example, if a database contains both Low Risk and Moderate Risk data, the database should be classified as Moderate Risk.
  • Data may be classified at a higher risk than is required by the classifications below; if that is the case, the data element must meet the security measures for the higher classification level.
Low Risk Moderate Risk High Risk

Data is classified as Low Risk if either of the following conditions apply:

  1. The data is generally available to the public, or
  2. The unauthorized use, access, or alteration of the data would not have an adverse impact on NYU or an individual community member.

Data is classified as Moderate Risk if any of the following conditions apply:

  1.  The data is governed by laws or regulations that restrict the use or disclosure of such data , or
  2. The data is subject to contractual restrictions that restrict the use or disclosure of such data, or
  3. The unauthorized use, access, or alteration of the data could have an adverse impact on NYU or an individual community member.

Data is classified as High Risk if either of the following conditions apply:

  1. The data is governed by laws or regulations that require NYU to report to the government and/or provide notice to individuals if the data is breached, or
  2. The unauthorized use, access, or alteration of the data could have a significant adverse impact on NYU or an individual community member

An “adverse impact” means (i) with respect to an individual, that the security or privacy of the data has been compromised with a probable increase in risk, and (ii) with respect to NYU, that the financial, legal, operational, and/or reputational risk is increased up to and including severe repercussions.

Data Risk Examples

The following examples are intended to assist with determining which risk classification is appropriate for a particular type of data and are not meant to be an exclusive list of data that falls into each classification.

Note regarding Research Data: (1) Protected Data Related to Research - Research data which is guided by federal regulation or sponsor requirements:  Depending on the subject matter and the data accessed, generated, and/or shared, there may be more stringent requirements, from the sponsor, the U.S. federal government, foreign governments, e.g., EU GDPR. Therefore, the data owner is advised to check with the OSP or the IRB (for human subject research). (2) Except for regulated data such as Protected Health Information (PHI), Social Security Numbers (SSNs), Controlled Unclassified Information (CUI), financial account numbers, and other protected data related to research and systems serving as repositories for these data types, research data predominately falls into the Low Risk classification. Review the classification definitions and examples below to determine the appropriate risk level to apply.

Low Risk Moderate Risk High Risk

Data is classified as Low Risk if any of the following conditions apply:

  1. NetIDs
  2. Information authorized to be available on or through NYU’S websites without NetID authentication
  3. Policy and procedure manuals designated by the owner as public
  4. Job postings
  5. University contact information not designated by the individual as "private" in the NYU Directory
  6. Publicly available campus maps
  7. Research data (at data owner's discretion)

Data is classified as Moderate Risk if any of the following conditions apply:

  1. University and employee ID numbers (e.g., N-number)
  2. Personal Data under the GDPR (except for Special Categories of Personal Data)
  3. Unpublished institutional research data, including unpublished research data (at owner’s discretion)
  4. NYU intellectual property licensed from a third party or that is contractually restricted
  5. Student records and admission applications (includes FERPA-covered information)
  6. Human Resources data (e.g., faculty/staff employment applications, personnel files, benefits information, salary, birth date, personal contact information)
  7. Non-public contracts
  8. NYU official internal memos and email, non-public reports and policies, budgets, plans
  9. Engineering, design, and operational information regarding NYU infrastructure
  10. University financial data (i.e., financial data at the system of record, where modification of that data would impact University processes; does not include representation of that data elsewhere)

Data is classified as High Risk if any of the following conditions apply:

  1. Social Security Numbers and national identification numbers
  2. Driver’s license numbers
  3. Passport and visa numbers
  4. Operating system passwords, application passwords, and API keys
  5. Central authentication credentials
  6. Special Categories of Personal Data under the GDPR (See Appendix for examples)
  7. Personally identifiable health information about patients, including Protected Health Information (PHI) under HIPAA
  8. Unpublished research data that is personally identifiable or identified: Unpublished institutional research data, including unpublished research data that is subject to sponsor, federal, or foreign government protected data requirements, including data originating with human subjects or data which are proprietary, confidential, sensitive or designated as controlled unclassified information (CUI).
  9. Health Insurance policy ID numbers
  10. Credit/Debit card numbers and other cardholder data under the PCI-DSS
  11. Bank/Financial account numbers
  12. Export controlled information
  13. Donor contact information and non-public gift information

System Criticality Classification

System Criticality is determined according to the following classifications. The following rules should be taken into account when classifying systems:

  • When a system falls into more than one category, it should be classified in the highest applicable criticality category.  For example, if an application meets the definition for both Moderate Criticality and High Criticality, it should be classified as High Criticality.
  • When a system includes more than one resource, the system should be classified based on the highest applicable criticality category. For example, if a system includes both Low Criticality and Moderate Criticality applications, it should be classified as a Moderate Criticality system.
Low Criticality Moderate Criticality
High Criticality

A system should be classified as Low Criticality when it meets the following criterion:

  1. Stores, transmits, or provides access to low Risk Data only

A system should be classified as Moderate Criticality when it meets either of the following criteria:

  1. Stores, transmits, or provides access to Moderate Risk Data
  2. Loss of access could have a significant impact on a large number of users or multiple business units and the overall institutional risk from downtime is moderate

A system should be classified as High Criticality when it meets either of the following criteria:

  1. Stores, transmits, or provides access to High Risk Data
  2. Loss of access could have a significant impact on NYU as a whole [and the overall institution risk from downtime is high]

 

System Criticality Examples

The following examples are intended to assist with determining which classification is appropriate for a particular type of system and are not meant to be an exclusive list of systems falling into each classification.

Low Criticality Moderate Criticality
High Criticality

A system should be classified as Low Criticality if any of the following conditions apply:

  1. Applications handling Low Risk Data
  2. Online maps
  3. University online catalog displaying academic course descriptions
  4. Bus schedules
  5. Public directory containing phone numbers, email addresses, and titles 

A system should be classified as Moderate Criticality if any of the following conditions apply:

  1. Applications handling Moderate Risk Data
  2. Human Resources application that stores salary information
  3. University application that distributes incident information in the event of a campus emergency
  4. System that collects information for potential students to apply
  5. System that contains information related to employment applications

A system should be classified as High Criticality if any of the following conditions apply: 

  1. Applications handling High Risk Data
  2. Human Resources application that stores employee SSNs
  3. Application that stores campus network node information
  4. Application collecting personal information of donors, alumni, or other individuals
  5. Application that processes credit card payments

Depending on the Classification Levels determined for Data and Systems, procedures for securing systems are outlined in:

Appendix: Special Data Types

  • Credit Card numbers and other cardholder information are subject to specific industry standards and additional controls and, thus, must be handled appropriately. See NYU’s Payment Card Industry Data Security Standard.
  • Other data covered by Export Controls are subject to additional rules on distribution, in particular sharing with non-U.S. persons. See NYU’s Export Control Regulation information.
  • FERPA refers to the Family Educational Rights and Privacy Act of 1974 enacted, among other purposes, to protect the privacy of students' education records. The “education records” are defined as those records, files, documents, and other materials that contain information directly related to a student and that are maintained by the University or by a third party acting for the university. The form in which the information is maintained by the University does not matter.  For example, computerized or electronic files, audio or video tape, photographic images, film, with such information are "education records". This includes communications and documents distributed or received by email, or other similar University systems, which are retained in these systems, either by the sending or receiving party. See NYU’s FERPA guidelines.
  • GDPR refers to The EU General Data Protection Regulation (Regulation (EU) 2016/679). See NYU’s GDPR website.
    • Personal Data (GDPR) – This includes any information relating to an identified or identifiable natural (i.e., living) person who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number (e.g., tax ID, NYU NetID and University/N number), location data, an online identifier, or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of such natural person.
    • Sensitive Personal Data (GDPR) – This means the following categories of Personal Data that are subject to heightened protection under GDPR: (a) revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership; (b) relating to the inherited or acquired genetic characteristics of a natural person which gives unique information about the physiology or health of such person and which results, in particular, from an analysis of a biological sample from the person in question ("Genetic Data"); (c) resulting from specific technical processing relating to the physical, physiological or behavioral characteristics of a natural person, which allows or confirms the unique identification of such person, such as facial images or fingerprint data ("Biometric Data"); (d) relating to the physical or mental health of a natural person (including the provision of health care services) which reveals information about such person's health status; (e) concerning a natural person's sex life or sexual orientation; (f) consisting of or revealing identification numbers or other information specially protected by Applicable Data Protection Requirements (e.g., national identification numbers); and (g) relating to criminal convictions and offences.
  • GLBA refers to the Gramm-Leach-Bliley Act, short form for the Financial Modernization Act of 1999, an act of Congress. Its main purpose is to promote financial integration and develop a regulatory framework for financial institutions which deal with non-public financial information, such as financial aid, Bursar activities, faculty housing finances, and donations to the university. This financial information can be provided by the consumer, initiated by NYU, or received from another financial institution. See NYU’s GLBA Information Security Program.
  • HIPAA refers to the Health Insurance Portability and Accountability Act, complex legislation and various Rules signed into law in 1996 and updated over the years requiring safeguarding individual identifiable healthcare information, especially for privacy and security. EPHI is Electronic Protected Health Information that NYU creates, receives, maintains, and/or transmits electronically. It can exist outside a computer, such as on clinical equipment, storage media, tapes, DVDs, and many other peripheral devices. See NYU’s HIPAA Security Policies.

Notes
top
  1. Dates of official enactment and amendments: Nov 6, 2018
  2. History: Additional dates of amendments: Data Classification Table: Issued 06/19/07. Data Classification Table: Officially Enacted 02/10/12. Data Classification Table reviewed and updated. The Table and the Reference for Data and System Classification were integrated and expanded into the Electronic Data and System Risk Classification. Policy: 11/06/18. The original Data Classification Table was created by NYU ITS Technology Security and adopted by the Data Protection Risk Analysis Project Team. For questions or comments, including from global locations, regarding the contents of this policy, please contact security@nyu.edu. Last Review: November 6, 2018. Last Revision: N/A.
  3. Cross References: N/A