Resources from the SSD Divisional Security Officer

The purpose of the Divisional Security Officer is to accelerate and facilitate data security compliance with project agreements held by the University of Chicago by helping faculty, researchers, and staff streamline these details into their research processes.

The Divisional Security Officer is a resource available at the University of Chicago for departments and research centers under the Social Science Division to guide faculty and researchers with data security requirements associated with their research projects.

The Divisional Security Officer serves as a liaison among the University Administrative offices, the SSD Dean’s Office, the University’s Secure Research Computing Oversight Committee, faculty, and vendors on topics related to data security, data privacy, and the implementation of data security policies and their technological tools.

If you need help related to data governance, data management plans, data resources, you can contact the Divisional Security Officer. In addition, if you would like to leave feedback regarding this webpage, foreseeable needs, general data security questions, you can contact the Divisional Security Officer at

Obtain a CNET
As a University of Chicago member-student, researcher, staff, faculty—a CNET will provide access to university resources and authentication.

Always keep your cnet password secure and confidential-never share your cnet password.

End User Device Security
Standard security measures for end user’s computing device include password log-in, single user account on the computer, screen saver timeout screen, anti-virus updates and protection, and operating system updates.

If you do not have a university issued computer, contact ITS in their service portal to set-up your personal computer for the standard ITS security measures.

If you are a member of the Social Sciences Division, and rely on Social Sciences Computing Services resources, contact desktop support at or use the SSCS ticketing system to make a request.

Training Related to Data Security
Depending on your involvement in a project, the below are common request for data security training:

Office/Physical Security Concerns
Know who can access your workspace and how building access is maintained since most data security plans will inquire into this information.

University of Chicago Administrative Offices
Within the SSD, SSCS closely connects with the Dean’s Office, Information Technology Services, Identity Management, SBS-IRB, URA, Secure Data Enclave, and the Social Sciences Research Council. These offices may request or reference the same agreements for different or similar information for your research projects.

For training on the AURA platform and its application submission processes, see AURAs Training Webpage

Commonly requested Information

  • AURA Identification Numbers– applies to all agreements and services (Aura Grants, Agreements, IRB, COIs)
  • Staff and Researchers who are working with you for the specific project and project access
  • Dataset description and its level of sensitivity

Applications to Download prior to accessing SSCS Resources
The University of Chicago requires two factor authentication.

  • On your mobile smart-phone, download the DUO application.
  • Then, register the DUO app to your cnet, by going to the University’s 2FactorAuthentication page

Off-Campus Network Access
Download Cisco AnyConnect Client and connect to the cVPN. This is necessary for when you want to access SSCS server off-campus.

Accessing SSCS Server Computational Spaces
For accessing server computational spaces, download the easy-VNC which allows you to log-into athens, cronus, and acropolis once your department has requested access for your account.

For a comprehensive overview of logging on from cnet to server access, see SSCS’ Logging On webpage

Summary of Data Security Terminology and their Tools
No matter the source and category of your data, it is always good practice to keep it secure and organized. At any given time, it is important to document where your data are located, who is accessing your data, and how it is being kept secure.

The University offers multiple resources for data management, storage, transmission, collection, collaboration, and publishing.

Data Management Practices
The University of Chicago Libraries has many helpful research resources and guidelines for data management, see UChicago Library’s Research Data Management.

Supplemental Information on Data Management Practices can be found on MIT Libraries Data Management site.

Data Storage Options
The terms of the data’s agreement and the type of data you are collecting will determine the location of your data storage. Options for securely storing data include:

UChicago Box 
Secure Data Enclave
SSD Storage and Computational Systems:

SSCS Athens

Accessing the Athens Server

Instructions for Windows

Instructions for Mac

Please note the instructions where your login requires adlocal/ in front of your CNet ID

SSCS Cronus

Accessing the Cronus Server

Instructions for Windows

Instructions for Mac

Please note the instructions where your login requires adlocal/ in front of your CNet ID

Additional Information can be found in the SSCS FAQ

SSDLab Virtual Desktop

(For a comprehensive overview of logging on from cnet to server access, see SSCS’ Logging On webpage)

Research Computing Center

Location of Data Analysis
Depending on your project, the location where you store your raw data files may or may not be the same location where you analyze your files. This is important to track for project organization, replication of findings, and data security.

Moving data and copying data files from their secure location must always be pre-approved in writing in order to comply with the terms of the agreements—IRB, grants, data use, and data provider agreements.

Data Transmission
When receiving or sending data, you want to make sure that the connection is secure and that the data can be transmitted as permitted by any agreement in place. It is recommended to not send data files over email since you can quickly lose track of who is accessing the data.

UChicago Box (A copy of BSD step by step for securing files on UChicago Box can be found here)
Secure Data Enclave
WinScP for windows

Project Collaboration & Sharing Data
Prior to sharing data, always review any existing agreement terms, even if the data is considered ‘free’ or if you own the data.

For data housed and owned at the University of Chicago, see Data Collaborator Agreements.

Data Collection
University offers several resources for collecting data. It is always best to default to university resources since they require secure authentication when downloading and using the software. Using these tools for data collection becomes even more important when conducting research.

Qualitative Resources

University of Chicago Agencies

Existing University Software
ITS Software for Departments
ITS Software for Students
ITS Communication and Collaboration

External Agencies
If hiring external agencies, contact the University Research Administration to develop the appropriate research agreement for your project.

Data Collection Practices in your Field of Research
For project specific questions, you can reach out to Divisional Security Officer to help solidify the data security details for your project at

Supplemental Information of Data Collection and Storage can be found on the Social and Behavioral Sciences Institutional Review Board webpage under SBS-IRB Investigator Guidance, including tab Data Security and Storage.

The University of Chicago Libraries has subject specialists related to your field of research, including a Social Sciences Data Librarian as available resources.

Data Publishing/Curation
When data is ready to be shared with the larger research community, the University of Chicago Libraries can provide guidance with storing and sharing your data in a data repository.

Prior to releasing and publishing data and or their results, always check the data provider’s expectations, agreement terms, consent forms, and required acknowledgements.

Caution with Mobile Apps and Social Media Platforms
If using an external app or developing an app to collect data, it is important to work with ITS, SDE, or SSCS to determine security standards that are appropriate for the app, prior to funding, creating, or using the app.

To note, social media platforms and apps typically do not keep data confidential. If using an app that does not meet SSCS or ITS university security policy, this information must be disclosed and documented to participants prior to participants’ use of the app. The risks conveyed should provide and summarize the apps security policy, what information the app collects (in addition to the research data you are collecting), what information it stores, what information cannot be deleted, and what information is shared, and what unknowns are present.

SSCS Data Security Introduction for Faculty
This section is a soft introduction summarizing the requirements you will encounter as you work with your projects and its data at the University of Chicago. These details may arise in discussions in project development, data applications, procurement, agreements, and grants. The introduction will help you understand the data’s security requirements. Whether you are collecting your own data or accessing data from a secondary source, there are always data protection and data security measures accompanying the data. Even if you own the data or if the data is considered free of purchase, the type of data and University policy will require data security measures.

Data Categories as related to Data Security
The below categories are not exclusive of each other and are categories that are commonly mentioned in a university setting in regard to data security.

Data Categories According to Sensitivity of Information Security :

Public data tends to be more quickly accessible, and is usually accompanied with a user required acknowledgement to protect the integrity and expected use of the data, prior to access.

Restricted Data is typically protected by a contractual agreement or an application prior to access. The agreements are legally binding and can be used to enforce local, state, and federal laws, convey how the respondents’ data is protected by confidentiality agreements, and convey the data’s explicit security standards and use.

Sensitive Data is data that was disclosed, willingly released, or provided by a participant with the understanding that it had a specific and limited use, while ensuring confidentiality and security of the data. The term, sensitive data, is predominantly used as the overarching general term that can encompass PII, de-identified, and/or restricted data.

Personally Identifiable Information (PII) refers to any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means (NIST definition).

De-identified data is data that has removed the personally identifiable information from dataset, this can include deletion of the PII or recorded in a way that does not protects and maintain the respondent’s confidentiality of information in the dataset, such as recoding PIIs with identification numbers that do not derive back to the participant

Comprehensive and official information on data classification can be found on the University of Chicago ITS Data Classification Guide

Bringing your data over from another University
Agreements in relation to data are usually institution specific meaning that the data are bound under the university’s responsibility.

If you have data obtained through agreements, you may need to update the agreements to be under your current institution. For example, if you’re bringing data into the University of Chicago, you will need to route the agreements through the University Research Administration to obtain institutional signature. This will help transfer the agreements under your current institution-University of Chicago.

If your previous institution owns the data, and you want to maintain access through your previous institution and their resources, you can enter into an agreement with your previous institution and ask them to update your institutional affiliation in their agreements as well.

If you own your project data, make sure you have copies of your agreements, grants, IRB applications, and any related documents. If the location of the data will change, update the appropriate documents where needed. If you need help knowing where to start, you reach out to SSCS Divisional Security Officer.

For the type of agreements available at the University, see the University Research Administration contracts page

For supplemental Information on the DUA process, the Secure Data Enclave offers a summary of information on the process: Navigating the DUA

UChicago Faculty with Collaborators at other Institutions
If you are working on a University of Chicago project and want collaborators accessing your project data  who are not formally affiliated with the University of Chicago, the collaborator can enter into an agreement with the University of Chicago. The expectations of the collaboration and agreements behind the data will determine what type of agreement(s) and other documentation the collaborator will need to enter with the University of Chicago.

For the type of agreements available at the University, see the University Research Administration contracts page

A few examples of what documentation will need to be updated are:
Updating an existing Data Use Agreement
Reviewing Grant Documentation
Updating appropriate IRB(s)
Submitting a Data Collaborator Agreement
Submitting an Outgoing Data Use Agreement 
Submitting an Outgoing Research Services

Agreement Terms that Apply to Faculty
The below are commonly listed terns that may appear in your agreement(s). While the language may vary, the goal is for both parties to understand the terms of collaboration. Any questions about the agreements, revising agreements, and negotiating agreements terms can be coordinated between faculty and URA.

Research Purpose—what the Principal Investigator intends to do with the data, the data is being released under these expectations described in the research purpose

Data Ownership–who own the data during analysis and after the project is complete

Terms for Raw Data and Derivate Data—how are the data defined

Project Duration and Project renewal—how long is the project expected to take, are renewals possible and if they are, how do they occur

Annual Updates or Annual Reports—providing updates to the data provider or funding source as to project milestones in addressing the research purpose

Collaborators—can non-UChicago collaborators access the data and if so, how are they allowed to access the data and if not, important not to share or allow access

Acknowledgements and Citations—note specific language or expectation for citing the project, data, or other sources

Publication embargos—is the data provider requesting for review of any output from the project, has the process and expectations been discussed; the goal is avoid releasing findings that have not been approved in writing by the data provider

Data Sharing—during project (e.g. collaborations within and outside the University) and post project e.g. publishing the data releasing the data)

Merging—specify if the data is expected to be merged with other data (regardless if public or restricted)

PII—specify what Personal Identifying Information will be requested

Data Categories as specified by the data provider—the data provider usually splits their data into waves, subsets, years, restricted, etc. so when requesting the data make can justify and request the data as described by the data provider

Security details—expectations and procedures for project access and researcher responsibilities, data and output storage, data copies, and data and output transfer, computer and office security

Audits—data providers usually request audits to verify that the terms of the agreement are being carried out I.e. that the data is being used and secured as specified

Helpful details to track and archive for audits and administrative records
For audits and administrative records, the below details are helpful to track or archive when a quick review is required.

Keep a current list of all project file locations–this applies to both whether files are centralized or split across locations. Keep note of each folder’s purpose so easier to communicate this information across research team (e.g. raw data, PII data, data folders as they relate to each component of the research process, documentation, articles, publications, background/research goals, administrative).

The raw data folder holds the original receipt of each file received and collected without any alterations.

Data folders can include notes on software output, software sources, reminders on how to access and share among the team, notes on the structure or reasoning for the data files.

Documentation folder can hold copies of the codebooks and accompanying manuals for the data.

The research goal folder can include details on the project’s history, motivation, and background, project goals, research expectations, internal workflows.

The administrative folder can include copies of contracts, agreements, data obtainment processes that are accessible to the research team (do not save files with researchers’ PII, delete those pages or redact the information prior to making it accessible to internal team members).

This folder can also include current user list for each project, such as confirmations when users were added and removed from project. It can be helpful to keep a summary of what is required to add on users prior to granting access to the projects folders such as storing commonly requested information from the data provider, to note who to contact for details, what documents to review.

For a comprehensive overview of data management, visit the University of Chicago’s Library Research Data Management website.

Data Management Plans, Data Sharing Plans, Data Security Plans

University of Chicago Library Data Management Plan Resources
The University of Chicago Library offers online access to the DMP Tool which provides sample data management plans and can help guide you through funder specific questions. To access the DMP Tool and to obtain an introduction to Data Management Plans, visit the University of Chicago’s Library Research Data Management website.

Supplemental Information on the University of Chicago Library Site:
For a Data Management Plan checklist see Edinburgh Digital Curation DMP Checklist 2013

Information on NSF and NIH Data Management Plans 

NSF DMP Goal: National Science Foundation expects the DMP to address research issues related to data and metadata format and content, policies for access, sharing, reuse, and redistribution, and plans for archiving and preservation 

The National Science Foundation provides the requirements of their NSF Data Management Plan by field of research. On the NSF DMP website, see the section requirements by directorate, office, division, program, or other NSF Unit to obtain the latest DMP requirements for the Social, Behavioral and Economic Sciences Directorate (SBE) or your relevant field.

Subcomponents of the NSF DMP:
Preview the NSF DMP overview SBE template here

NIH DMS Goal: National Institute of Health expects that data be made as widely and freely available as possible while safeguarding the privacy of participants and protecting confidential and proprietary data. Sharing is particularly important for unique data that cannot be readily replicated.

The National Institute of Health Data Management and Sharing (DMS) policy can be found on their website. NIH provides information on the DMS policy expectations, the applicability of the policy, how to prepare a Data Management and Sharing Plan, and considerations for sharing data responsibly. Annual compliance of the DMS will be requested in NIHs Research Performance Progress Reports (RPPRs).

Subcomponents of the NIH DMS:
Preview the upcoming NIH DMS template page here
Writing Data Management and Sharing Plans
Format Requirements   (usually 2 pages or less) page will be updated by NIH Fall 2022
Implementation Details for the NIH DMSP

Note on Consent Form Development: In order to share data as specified in your plans, make sure the consent forms and agreements address and match the intent to share that data as expressed in the plans. In regards to data sharing, the consent form should include intent to share, what data you will release, what sensitive information will be released, who you will share the data with (during and post) project.

SSCS Data Security Templates
Depending on where the agreements and documentation allow the data to be stored, the below language can be incorporated into your larger framework for the data and security plans. Therefore, if you will be using SSCS servers for your project data, below are template language specific to SSCS at the University of Chicago.

Recommended Grant Sections to Insert Language:

In NSF DMP—Data storage and preservation of access
The DMP should describe physical and cyber resources and facilities that will be used for the effective preservation and storage of research data.

In NSF DMP—Additional possible data management requirements
More stringent data management requirements may be specified in NSF solicitations or result from local policies and best practices at the PI’s home institution. Additional requirements will be specified in the program solicitation and award conditions. Principal Investigators to be supported by such programs must discuss how they will meet these additional requirements in their Data Management Plans.

In NIH DMS Plan—Element 3 Standards
Standards State what common data standards will be applied to the scientific data and associated metadata to enable interoperability of datasets and resources, and provide the name(s) of the data standards that will be applied and describe how these data standards will be applied to the scientific data generated by the research proposed in this project. If applicable, indicate that no consensus standards exist.

see SSD-DSO-SSCS Templates

SSCS Data Security Plan Template

Acropolis, Athens, Cronos
see SSD-DSO-SSCS Templates

IRB Data Management Security Questions

  • These questions can vary by IRB submission
    The document holds sample questions so you can preview how details in the DMP can be carried over and expanded upon in the IRB
    see SSD-DSO-SSCS Templates

SSCS Facilities and Resources

For an overview on the SSCS Facilities and Resources, visit the Box folder in the link below or preview on the SSCS homepage
see SSD-DSO-SSCS Templates

Server Storage of Personally Identifiable Information (PII)
The SSCS servers can hold low sensitive, de-identified information. PII and sensitive can at times be stored on the SSCS servers, but the project must always be reviewed by the SSCS Director and the Divisional Security Officer.

Data from government entities (local, state, and federal) are directed towards the Secure Data Enclave which can hold highly sensitive information, including identified and de-identified data.

To note, URA assigns the final security level to incoming and outgoing data.

University Policies Relating to Technology and Data Security

The guidelines for gathering, transmitting, storing, sharing, and publishing data must be consistent with The University of Chicago IT Policies, including the Research Data Protection Policy and the End User Device Policy.

The University Information Technology Services has a ITS Data Classification Guide which addresses data usage guidelines in order to mitigate risk of data breaches, including research data.

The University Data Stewardship Council has a the UChicago Sensitive Data Usage Guide that is intended to assist members of the University community to make informed decisions about where and how to store and share sensitive University data in a secure and safe way. The University Data Usage Guide helps summarize the type of data and their appropriate transmission and storage tools. (You will need your cnet to login.)