This information provides guidelines that should be considered a baseline. Specific requirements in regulations need to also be met to be fully compliant. 

See this page for the tables that describe:

• How to Handle Data by Risk Type
• Risk Levels of Different Kinds of Data
• Harm Level Definitions

Your Role to Protect Cornell’s Data

All Cornell individuals are responsible for complying with university policies 4.12 (Data Stewardship and Custodianship), 5.10 (Information Security) and 4.21 (Research Data Retention). University Policy 4.5, Access to Student Information, may also apply in certain circumstances. 

This guide is intended to support these policies and does not replace them. 

General Data Handling

In the context of Cornell services, “data handling” includes data storage (e.g. Laptop/Desktop computers, Servers, Box, OneDrive, SharePoint, Google Drive, File Shares, etc.), data transfer (e.g. via Outlook, Gmail, or file transfer service) or data processing (e.g. within Cornell IT systems, AI agents, external vendors, etc. 

Consistent with established Cornell policies, the Data Stewards, the Chief Information Officer and Chief Information Security Officer, or their representatives, must approve the collection, storage, transmission, processing, including AI processing, of sensitive administrative data. Handling of sensitive research data such as human subject data or export control data must be approved by Research and Innovation via the Institutional Review Board for Participant Research Office and Export Controls Office respectively.. Several regulated research programs, including Biosafety, Radiation Safety, and Chemical Safety, fall under Environment, Health and Safety and coordinate with Research and Innovation.

Access to data is essential to the mission of the university. Consistent with the Privacy Principles developed by the University Privacy, adhere to these principles when handling sensitive data.

1. Work within the System of Record (Don’t make unnecessary copies)
   When possible, access and work with data in its authoritative system of record (e.g. Workday, PeopleSoft, KFS, etc.) or an approved supporting system (e.g. enterprise data warehouse, document management system, etc.) rather than export, download, or copy it into secondary tools (e.g., spreadsheets, shared drives, email) outside of approved systems where controls and security visibility are weaker. 
   
   Example: A budget analyst runs reports directly in the financial system rather than exporting the full ledger to a spreadsheet that then gets emailed or saved to a personal drive.
2. Minimize and Secure Copies and Derivatives (Storage Limitation)
   Every time sensitive data is copied, extracted, merged into a new report, or fed into another system (including AI tools), it creates a new distribution point that must be independently secured and eventually retired. Fewer copies means less exposure. If data needs to be copied for legitimate reasons, or the derived information is sensitive, then ensure that the system the data is being copied to is approved and secure (e.g. Use a Certified Desktop computer for temporary data storage or movement, enterprise data warehouse, or approved third party). Refer to the Regulated Data Chart or contact the IT Security Office.
   
   Example: Instead of exporting a student roster into three different advisors' personal tracking spreadsheets, advisors pull directly from the shared system each time they need current data. The data is accessed from an approved system and processed on a Certified Desktop computer. A personally owned device, or a personal cloud storage must never be used for sensitive data.
3. Apply Least Privilege (Need-to-Know)
   Limit access to data to those who require it to perform their job function — not granted broadly "just for ease”.
   
    Example: A financial aid dataset with SSNs is accessible only in a system of record such as the Student Information System (SIS) to the specific aid officers processing those applications, not to the entire Financial Aid department. Be intentional with whom you share data and remove access promptly when there’s no longer a need to know.
4. Only use what’s necessary (Data Minimization)
   Collect, retain, and process only the data necessary for the stated purpose — and dispose of it when it's no longer needed.
   
   Example: A campus event registration form asks for name and email, and not date of birth or home address, when those fields serve no purpose for the event itself.
5. Do not reuse data approved for one purpose for an entirely different purpose (Purpose Limitation) 
   Data collected for one purpose shouldn't be repurposed for an unrelated use without appropriate review or consent.
   
   Example: Student health data collected and approved by Cornell Health for treatment purposes isn't then shared without approval with academic advising to assess a student's performance.
6. Accountability, Stewardship & Traceability (Accountability and Stewardship)
   Every dataset should have a clear owner/steward, and access or changes to sensitive data should be logged and auditable.
   
   Example: A Data Steward is designated for the university's HR system, and any bulk export of employee records is approved for a particular purpose, access is limited, logged with who accessed it, when, and why.
7. Delete unneeded files (Storage Limitation)
   It’s a natural habit to keep files “just in case”. In most cases files are no longer needed and the data exists in systems of record. Following federal, state and university retention policies, delete files that are no longer needed. The less you have, the less you have to protect; the more you have the larger the potential scope of data breach.
   
   Example: An automated process is created to download sensitive salary reports from KFS and Workday, then merge them to create a new dataset. The original datasets are not kept indefinitely, instead they’re deleted once the integrity of the new dataset is verified. 
8. Report Suspected Data Incidents Promptly 
   Report suspected or actual loss, unauthorized disclosure, access, or misuse of sensitive data through Cornell’s established incident-reporting process. Do not delay reporting while attempting to determine the severity or resolve the issue yourself; timely reporting allows the appropriate teams to assess the incident, limit potential harm, and determine whether additional notification or response is required. Report incidents to the IT Security Office.
   
   Example: An employee realizes that a spreadsheet containing sensitive student information was emailed to the wrong recipient. Rather than simply asking the recipient to delete it, the employee promptly reports the incident so Cornell can assess the exposure, asks for help on appropriate breach containment measures, and to determine whether further action is required. Another example is a laptop being stolen containing sensitive Cornell information. Similar steps are required.