Resources from the SSD Divisional Security Officer
The Divisional Security Officer is a resource for departments and research centers under the Social Science Division. The purpose of the DSO is to accelerate and facilitate data security compliance with project agreements held by the University of Chicago. The DSO seeks to help faculty, researchers, and staff streamline data security details into their research processes.
The DSO 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 alongside 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 email@example.com or submit a ticket via our portal.
SSCS Data Security Introduction for Faculty
This section is a soft introduction on the data security requirements you may encounter as you develop your project’s design and workflows at the University of Chicago. These details may arise during project development, data applications, procurement, agreements, and grants. 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. 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 are usually accompanied with a user required acknowledgement to protect the integrity and expected use of the data, prior to access.
Restricted Data are protected by a contractual agreement or an application prior to access. The agreement or application 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 are data that were conditionally released by a participant with the strict understanding that the data have specific and limited use while being assured confidentiality of the data. The classification of sensitive data, 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 recoded 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. (For an example on how to de-identify data see J-PAL Guide or contact the University of Chicago Library for more information.)
Comprehensive information on data classification can be found on the University of Chicago ITS Data Classification Guide.
Agreement Terms that Apply to Faculty
The below are commonly listed terms 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—the expectations and project goals under which the data are released
Terms for Data and Derivative Data—how the data are defined and is there a need for distinction of the data at different project stages (e.g.) collection, analysis, output
Data Ownership—entities or individuals who own the data
Project Duration—time and length project is expected to take
Project Renewals—are renewals possible and if they are, what are the requirements
Annual Updates or Annual Reports—providing updates to the data provider or funding source as to project milestones in addressing the research purpose
Collaborators—non-UChicago researchers who require access to the data and with UChicago following appropriate steps for access
Acknowledgements and Citations—note specific language or expectations for citing the project, data, or other sources
Publication Embargos or Review of Output—data providers may request review of output from the project
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 are 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
Also see URAs What Should Be Addressed in a Data-Sharing Agreement?
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.
NSF and NIH Data Management Plans
University of Chicago URA
URA has provided a guidelines and FAQs for the new NIH DMP
see URAs NIH 2023 Data Management and Sharing Policy (DMS Policy)
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
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
Important 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
If you will be using SSCS servers for your project data, below are template language specific to SSCS at the University of Chicago. The SSCS language helps address storage space. Please note that this is only one subset of the DMPs requirement. Please reach out to firstname.lastname@example.org for review or guidance on your data management plan.
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.
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