Data Classification: University Data Classification Guide

Overview

This article explains how NEOMED classifies University Data, why classification matters, and what responsibilities Data Users, Data Stewards, and others have when handling data.

Why Data Classification Matters

To protect the security, integrity, and availability of University Data, and to comply with applicable state and federal laws and regulations, all University Data must be appropriately classified.

Data classification ensures that:

  • Sensitive data is protected from unauthorized access or disclosure
  • Legal, regulatory, and contractual obligations are met
  • Data is handled using security controls proportional to its risk
  • NEOMED’s mission, reputation, operations, and financial well‑being are protected

Improper use or disclosure of University Data can cause serious harm, including identity theft and institutional risk.

Who May Access University Data

Access to non-Public University Data is granted only for legitimate university purposes.

Authorization is based on:

  • A person's role and job responsibilities
  • Compliance with university policies and procedures
  • Applicable legal, regulatory, and contractual requirements

All Users are required to comply with:

  • State and federal laws and regulations
  • University policies, standards, and procedures
  • Contractual and grant-based requirements

Data Classification Levels (L1–L4)

All University Data is assigned a classification level based on legal and regulatory requirements, sensitivity, operational use, and risk to individuals and the University.

There are four classification levels, listed below from least to most restrictive.

Public (L1)

Definition

 University Data that is intended for public disclosure and use.

Key Characteristics

  • Approved for public release
  • A breach of confidentiality, integrity, or availability would have little to no adverse impact on the University’s mission, safety, finances, or reputation.
  • No special security controls required beyond standard protections

Academic and Administrative Examples

Click to Expand/Collapse ​​​​​​
  • Course catalogs
  • Published faculty and staff information
  • University publications
  • Published marketing materials
  • Marketing materials
  • Regulatory and legal filings
  • Published annual reports
  • Plans of public university spaces
  • Press releases
  • University-wide policies
  • Released Patents
  • FERPA-defined Student Directory information only when there is legitimate business need1

1 Student Directory Information as defined by FERPA may be disclosed publicly in accordance with the regulation in cases where there is a legitimate university business need. For students with FERPA blocks, their educational record including Student Directory information must be classified and handled as Restricted (L3), at minimum. Seek guidance from the Registrar's Office when needed. 

Research Examples

Click to Expand/Collapse ​​​​​​
  • Published research
  • Deidentified or anonymized data intended for contribution to open-science data repositories
  • Open licensed research products shared in accordance with NIH sharing requirements, or similar, such as software or source code
  • Non-restricted, publicly available data sets (e.g., Behavioral Risk Factor Surveillance System (BRFSS); NHIS: National Health Interview Survey) when the following criteria are met:
    • Research use will NOT involve merging any of the data sets in such a way that individuals might be identified
    • Research use will NOT enhance the public data set with identifiable, or potentially identifiable data

Internal (L2)

Definition

University Data that is used to conduct University business and is not generally available to the public. Internal Data can be shared externally, where appropriate; however, access restrictions should be applied accordingly.

Key Characteristics

  • Default classification for email unless otherwise specified
  • Limited access to university personnel and authorized parties
  • A breach of confidentiality, integrity, or availability could have minimal adverse impact on the University’s mission, safety, finances, or reputation.

Academic and Administrative Examples

Click to Expand/Collapse ​​​​​​
  • Intranet content
  • Student handbooks  
  • Instructional materials intended for general university audience  
  • Emails (excluding Restricted (L3)/Highly Restricted (L4) data)
  • Non-public building plans or layouts (excluding Restricted (L3)/Highly Restricted (L4) data)2
  • Information about physical plant (excluding Restricted (L3)/Highly Restricted (L4) data)2
  • Non-sensitive administrative survey data  
  • Pre-publication findings or similar shared in university seminar, talk, colloquiums, poster sessions, or similar
  • Course syllabi, recordings of presentations and lectures made available to university affiliates
  • FERPA-defined Student Directory information1

1 Student Directory Information as defined by FERPA may be disclosed publicly in accordance with the regulation in cases where there is a legitimate university business need. For students with FERPA blocks, their educational record including Student Directory information must be classified and handled as Restricted (L3), at minimum. Seek guidance from the Registrar's Office when needed.

2 Exclusions may include specific subsets such as toxic gas infrastructure details, substation/switch relay information, and PLC programming/configurations, as these contain sensitive passwords and device codes and should be safeguarded accordingly.

Research Examples

Click to Expand/Collapse ​​​​​​
  • Pre-publication findings or similar shared in university seminar, talk, colloquiums, poster sessions, or similar
  • Course syllabi, recordings of presentations and lectures made broadly available to university affiliates
  • Self-collected de-identified data, anonymized survey data or aggregate statistics
  • Self-collected, de-identified biospecimens or genomic data
  • Self-collected non-sensitive survey data, qualitative data such as interviews, or intervention outcome data
  • Usability data
  • Non-sensitive audio or video recordings
  • Non-sensitive observational notes
  • Other self-collected research data that is identifiable but is not considered sensitive by IRB

Restricted (L3)

Definition

University Data that due to legal, contractual or other requirements, and may not be accessed without specific authorization.

Key Characteristics

  • Access limited to individuals with a legitimate need to know
  • A breach of confidentiality, integrity, or availability could have moderate adverse impact on the University’s mission, safety, finances, or reputation.
  • Requires additional security controls beyond Internal data

Academic and Administrative Examples

Click to Expand/Collapse ​​​​​​
  • Banner IDs
  • Personally identifiable information (PII) not classified as Highly Restricted (L4)  
  • Personnel records not containing Highly Restricted (L4) data2
  • Donor information not classified as Highly Restricted (L4)
  • Non-public legal work and litigation information  
  • Budget/financial transactions information
  • Non-public financial statements  
  • University contracts
  • Research Administration and Compliance records not otherwise classified      
  • Security findings or reports (e.g. SSAE16, vulnerability assessment and penetration test results)  
  • Most NEOMED source code
  • Non-security related technical specifications
  • Library object valuations
  • Sensitive administrative survey data, such as performance reviews or course feedback, especially if free text response is permitted  
  • Course materials not otherwise classified
  • General use technology assets not otherwise classified
  • FERPA defined non-directory education record data not containing Highly Restricted (L4) data1

1 For students with FERPA blocks, their educational record including Student Directory information must be classified and handled as Restricted (L3), at minimum.

2 Employees have the right to discuss terms and conditions of their own employment, including salary and benefits, with each other or with third parties.

Research Examples

Click to Expand/Collapse ​​​​​​
  • Research administration and compliance records not designated CUI or FCI, including research protocols and IRB records
  • Contractual agreements (DUAs, NDAs, Sponsored Research Agreements, etc.) not classified as FCI
  • Active and unpublished sensitive research, including data, metadata, methods, notes, drafts, etc., as well as research products or technology such as software, source code, devices, etc.
  • Sensitive self-collected data not classified as Highly Restricted (L4) 
  • All contractual third-party data1 not specified as Highly Restricted (L4) data

Personally identifiable information (PII) not classified as Highly Restricted (L4), including:

  • Student data subject to FERPA
  • Employment records (including performance)
  • Sensitive self-reported health history (U.S.)
  • Personal or family financial circumstances
  • U.S. criminal conduct details (including prison data), which would not lead to reputational harm or criminal punishment
  • GDPR or PIPL data not reaching level of “extra sensitive” including racial or ethnic origin, political opinions, religious, or philosophical beliefs, trade union membership, sex life or sexual orientation

1 All third-party research data is subject to NEOMED's Data Use Agreement. Data exchanged subject to contractual terms must be classified, handled and shared in accordance with the contract terms throughout the data lifecycle.

Highly Restricted (L4)

Definition

University Data that requires the highest level of protection because inappropriate handling of this data could result in criminal or civil penalties, identity theft, and/or financial loss.

Key Characteristics

  • Extremely sensitive
  • A breach of confidentiality, integrity, or availability could have significant adverse impact on the University’s mission, safety, finances, or reputation.
  • Strict access controls and enhanced security measures required

Academic and Administrative Examples

Click to Expand/Collapse ​​​​​​

Data specified by Ohio Revised Code Section 1349.19, HIPAA, other relevant federal or state laws/regulations, including:

  • Government issued identifiers* (e.g. Social Security Number, Passport number, driver’s license)
  • Individually identifiable financial account information (e.g. bank account, credit or debit card numbers)  
  • Individually identifiable health or medical information1
  • Criminal Justice Information Systems (CJIS) data  
  • Data specified by GDPR or PIPL considered “extra sensitive” – biometric, genetic, or health information
  • System credentials incl Passwords and PINs, encryption keys, etc.  
  • Contractual third-party data data specified as Restricted
  • Trade secrets  
  • Security controls, security system procedures and architectures
  • Information with federal security and compliance requirements such as NIST SP 800-171 (CUI), CMS, CMMC, FISMA, FedRAMP
  • Contracts and other research administration designated as Federal Contract Information (FCI)

* Classification applies to both full or partial Government IDs like SSNs.
1 NEOMED is a HIPAA hybrid entity. Units that qualify as "covered functions" must comply with the HIPAA regulation and related compliance obligations.

Research Examples

Click to Expand/Collapse ​​​​​​

Data specified by Ohio Revised Code Section 1349.19, HIPAA, other relevant federal or state laws/regulations, including:

  • Government issued identifiers* (e.g. Social Security Number, Passport number, driver’s license)
  • Individually identifiable financial account information (e.g., bank account, credit or debit card numbers)
  • Medical records/clinical data, whether directly regulated by HIPAA (US) or not, including “HIPAA limited data sets”, as they contain HIPAA Protected Health Information (PHI)
  • Self-collected information that, if disclosed, could place the subject at risk of significant criminal punishment, or violent reprisals1
  • Individually identifiable genetic information
  • Trade secrets
  • All contractual third-party data2 specified as Highly Restricted (L4) 
  • Data specified by GDPR or PIPL considered “extra sensitive” – biometric, genetic, or health information
  • Information with federal security and compliance requirements such as NIST SP 800-171 (CUI), CMS, CMMC, FISMA, FedRAMP
  • Contractual data with Federal data classifications such as CUI, or with CMS, DFARS 252.204-7012, NIST SP 800-171, CMMC, FISMA, or FEDRAMP requirements, or similar
  • Contracts and other research administration designated as Federal Contract Information (FCI)

* Classification applies to both full or partial Government IDs like SSNs.

1 Investigators must consider the criminal laws applicable to subjects when developing their protocols and identifying necessary study data elements. Collect the minimum necessary, carefully safeguard all data that could place a subject at risk of prosecution or punishment if disclosed. Information about conduct that is punishable by civil or even criminal fines, but not imprisonment, may not merit Highly Restricted (L4) classification. Seek supplemental guidance from the IRB as necessary.

2 All third-party research data is subject to NEOMED's Data Use Agreement. Data exchanged subject to contractual terms must be classified, handled and shared in accordance with the contract terms throughout the data lifecycle.

Handling Mixed Data Classifications

If a dataset or system contains multiple classification levels, the entire set must be handled at the most restrictive level present.

Example: If a system includes both Internal (L2) and Restricted (L3) data, it must be managed as Restricted (L3).

Data may also be classified at a more restrictive level than required if additional protection is warranted. In these cases, the higher classification’s minimum security controls must be applied.

Roles and Responsibilities

Data Stewards

Data Stewards are senior University officials that are responsible for the overall governance, appropriate use, and protection of University Data within their functional areas. Their responsibilities include the following:

  • Serve as members of the Data Governance Council;
  • Appoint and oversee Data Managers;
  • Be accountable for appropriate use of data within their functional areas;
  • Accept and manage institutional risk associated with the use, collection, sharing, retention, and protection of University Data within their domain;
  • Approve access criteria and sharing agreements; and
  • Ensure compliance with law and policy.

Data Managers

Data Managers act on behalf of Data Stewards and are subject matter experts responsible for the operational management, quality, and consistent application of University Data in accordance with approved policies and standards. This is a delegated responsibility and does not confer ownership or final decision‑making authority. Their responsibilities include the following:

  • Maintain University Data classifications;
  • Define and maintain University Data definitions and business rules;
  • Monitor and improve data quality and integrity;
  • Review and process routine data access and use requests in accordance with approved criteria;
  • Maintain metadata, documentation, and data standards;
  • Identify and escalate data issues, risks, or policy conflicts to the Data Steward; and
  • Coordinate with Data Custodians to ensure proper implementation of standards.

Data Custodians

Data Custodians are responsible for the technical management, protection, and operation of systems that store, process, or transmit University Data.. Their responsibilities include the following:

  • Implement appropriate technical security controls for University Data aligned with institutional policy and data classification standards;
  • Ensure access is limited to approved purposes;
  • Provide incident response support;
  • Monitor University Data usage and policy compliance; and
  • Notify Data Managers or Stewards of changes that may affect data integrity or access.

Data Users

Data Users are those who access, use, disclose, generate, administer, or manage University Data. This includes, but is not limited to, faculty, staff, students, contractors, volunteers, visitors, sponsored guests, and affiliated entities acting on behalf of NEOMED.. Their responsibilities include the following:

  • Properly manage and protect University Data as set forth in this policy;
  • Report suspected incidents immediately; and
  • Complete required training annually.

Changing a Data Classification

Requests to modify the classification of University Data elements must:

  1. Be formally submitted
  2. Be reviewed and approved by the Data Governance Council .

Unauthorized reclassification is not permitted.

Summary

  • All University Data must be classified (L1–L4).
  • Higher classifications require stronger security controls.
  • Access is role-based and purpose-driven.
  • Classification changes require formal approval.

If you are unsure how to classify data or how a classification affects your work, contact your Data Steward or itsecurity@neomed.edu for guidance.