Highly Sensitive Data (HSD)

Some university processes or departmental business may require working with Highly Sensitive Data (HSD), which is data that:

• Its personal nature can lead to identity theft or exposure of personal health information
• A researcher, funding agency, or other research partner has identified as highly sensitive or otherwise requires a high level of security protection
• The impact of loss of confidentiality, integrity, or availability would have a severe impact on the University's reputation, or the ability to perform its mission

In such cases, authorization is required to ensure this data is used in compliance with university, state, and federal standards and stored properly and securely.

Some examples of HSD include:

• Data classified as secret by the federal government
• Data that is often involved in identity theft (e.g., SSNs)
• Data described in the Health Insurance Portability and Accountability Act (HIPAA) as needing to be secured
• Data that could lead to financial theft (e.g., credit card information)

Managing Access and Rights

The type of access must be restricted to only the rights required to perform work—Read, Write, Delete, Download, Share, Email, and Store on a laptop/workstation. HSD may only be stored on approved systems.

Auditing and Access Review for the HSD Store

The business process owner must have a strategy for initially and periodically evaluating access. An initial justification and schedule to review appropriate staff/business process/data owner regularly must be conducted and documented.

Endpoint Security When Storing HSD Locally

If data will be stored locally on a personal device, these endpoint computers must be managed in MESA, Microsoft Active Directory, or JAMF (Apple devices). An inventory of endpoints approved to store HSD must exist, and additional controls may be applied to the endpoints (i.e., Whole Disk Encryption). The IT Security Office (ITSO) can help assess requirements and processes.

Getting This Service

Access and use of HSD are restricted to those needing access for required business purposes. If you don’t have a hard requirement to store or operate HSD, you should not have access to it. If there is an unnecessary use of HSD in data you currently work with, consider removing these elements. For example, the month and year of birth are not HSD; however, a full birth date is.

When considering all of the controls necessary to protect HSD reasonably, a simple, effective solution that is supportable is always best. Automated technical controls that don’t hinder business processes are ideal. ITSO can help with identifying requirements and translating them into supportable controls. Chief data stewards and ITSO review requests.

You must request approval if you believe you have a legitimate reason to use or store HSD on university-approved applications, including Microsoft Teams (MS Teams).

If you are looking to store HSD on web applications or other server-based applications, see Additional Information.

Policy

All users of HSD must adhere to Policy Number 1114: Data Stewardship.

HSD will almost always have regulatory control requirements described in either university policy, commonwealth, or federal regulation. There may also be requirements stated in a data security standard, data sharing agreement, or grant/other contracts. The Data Owner and Data Custodians must fully understand the requirements for HSD use.

Additional Information

Storing HSD on Web Applications or Other Server-based Applications

Any new request to store HSD on a served web or other application must be evaluated to ensure that the services are controlled appropriately for HSD. This typically requires an Architectural Standards Review Board (ASRB) request.

Any served application like a web application, third-party Software as a Service (SaaS), or system that stores or presents HSD must use the university authentication services, which require Two-Factor Authentication (2FA).