Data Access Agreement Guidelines

NOTE: The Information Security Office is currently updating UC Berkeley's Data Classification Standard and Protection Profiles for the Campus. Our intention is to first make changes to the DPL numbering system without modifying the associated controls or requirements. These number changes are reflected on this page.

--------------------

UC Berkeley security policy mandates compliance with Minimum Security Standard for Electronic Information for devices handling covered data.  The recommendations below are provided as optional guidance to assist with achieving requirement 15.4, Data Access Agreement.

Requirement

Resource Proprietors must establish Data Access Agreements that define appropriate use and access to covered data, as well as procedures for obtaining approval for deviation from restrictions.

Description of Risk

Incomplete and inconsistent formal agreements to terms and conditions may lead to negligence by employees and contractors in the handling and distribution of sensitive data. 

Recommendation

The purpose of the Data Access Agreement is to specify the terms under which users are provided access to the specified data, and to obtain explicit acceptance of those terms by a user prior to granting him or her access to the data.

Essential components of a Data Access Agreement:

  • Definition of service offered*
  • Definition of user roles in the context of provided service*
  • Description of covered data being used (stored, transferred and processed) by provided service
  • Classification of data based on the Berkeley Data Classification Standard, and associated confidentiality requirements, with reference to campus data privacy principles.
  • Restrict sharing data with third parties, including individuals, campus departments and external parties who have not accepted the terms of the Data Access Agreement.
  • Description of additional laws and policies governing covered data.
  • Notification to users of MSSEI security requirements for individual devices:

    UC Protection
    Level(s):

    Former UCB
    Protection Level(s)
    respectively

    1.1 Removal of non-required covered data  UC P2/P3, UC P4 UCB PL1, UCB PL2
    3.1 Secure configuration UC P2/P3, UC P4 UCB PL2
    5.1 Device physical security UC P4 UCB PL2
    8.1 Privacy and Security Training UC P4 UCB PL2
    9.1 Unique passphrase  UC P2/P3, UC P4 UCB PL1, UCB PL2
    9.2 Separation of accounts UC P2/P3, UC P4 UCB PL1, UCB PL2
    13.1 Controlled access based on need to know  UC P2/P3, UC P4 UCB PL1, UCB PL2
    14.1 Account monitoring and management  UC P4 UCB PL2
    15.1 Encryption in transit UC P2/P3, UC P4 UCB PL1, UCB PL2
    15.2 Encryption on mobile devices and removable media  UC P4 UCB PL2
    15.3 Secure deletion upon decommission  UC P2/P3, UC P4 UCB PL1, UCB PL2
    16.3 Incident Response Training UC P2/P3, UC P4 UCB PL1, UCB PL2
* A Data Access Agreement can be a standalone document or a section within a broader Service Agreement that defines a service to be provided.  If the Data Access Agreement is part of a broader Service Agreement, the starred items are only necessary if not already defined in other areas of the Service Agreement.

Supplemental Guidance

In addition to the above recommendations, where resources permit, the following controls should also be considered to enhance the effectiveness of data access agreements.

User Acceptance Tracking

Terms defined on a separate page (not part of the login process) are unlikely to be read, and therefore, relying solely on links to terms and conditions is not a recommended solution. Instead, implement a solution to electronically keep track of user acceptance of the data access agreement. 
  • Electronic tracking may entail displaying a summary of terms on the sign-in screen, as well as an easily accessible place within the system, and requiring active acceptance of the terms, e.g., button click. (e.g., bearbuy.is.berkeley.edu)
  • Users can also be required to select the radio button(s) that correctly summarize to the stated terms. (e.g.,https://ibg.colorado.edu/cadd_wiki/tutorial/intro.htm)

Sample Template

Provided below is a template for a stand-alone Data Access Agreement.  The template and sample text is provided as a guide, and should be adapted to fit the specifics of each system/data set.

1.    Parties to the Agreement

Clearly identify the Data Proprietor (by name and/or role) and identify the data to be accessed.  Also capture or provide (based on login) the user's name and their position and responsibility that requires access to the data set.

Between

Data Proprietor:     
for Data Set Name:

and

User Name: 
in the role of:

2.    Definitions

3.    References

Links to other relevant documentation, e.g.,
Minimum Security Standard for Electronic Information (MSSEI)
Minimum Security Standard for Networked Devices (MSSND)
Berkeley Data Classification Standard
Data Protection Profiles

4.    Purpose of Access

Intended and allowable uses of the data.

I agree to use [system name] only for legitimate business purposes, restricting my usage to my designated professional responsibilities.

5.    Confidentiality

Designation of sensitivity of the data.

The [data set name] data in [system name] is classified as UC P1-4 (formerly UCB PL0-3) and data protections have been established accordingly.

I agree to preserve the quality and integrity of the information I access, and to protect the privacy of any individual's personal information that I access.

(Example for a UC P2/3 (formerly UCB PL1) system where users enter/edit records:)
I recognize that UC Berkeley is required to have strict access control over personal information that contains an individual's name or initials combined with:

  • a Social Security Number, or
  • credit card number, or
  • driver's license or state identification card number, or
  • any type of medical or medical insurance information, or
  • any personal financial account number

and will not enter any such data, or any other Protection Level 2 data into the [system name] system.

6.    Data Protection

All devices used to access this data must, at a minimum, meet the Protection Profile specified for individual devices for UC P2/3 (formerly UCB PL1). This includes:
 
6.1 Secure Coding Training
9.1 Unique passphrase
9.2 Separation of accounts
13.1 Controlled access based on need to know
15.1 Encryption in transit
16.3 Incident Response Training
17.1 MSSND Compliance
 
Devices accessing UC P4 (formerly UCB PL2) data must meet the following MSSEI requirements for individual devices, in addition to protection profile for UC P2/3 (formerly UCB PL1) devices listed above:
 
1.1 Removal of non-required covered data
3.1 Secure configuration
8.1 Privacy and Security Training
14.1 Account monitoring and management
15.2 Encryption on mobile devices and removable media
15.3 Secure deletion upon decommission
 
Please refer to MSSEI guidelines for specific guidance on how to comply with security requirements.  
 
Devices used to access administrative accounts must also meet Privileged Access Device security requirements for UC P1-4 (formerly UCB PL0-3) data.

7.    Access and Governance

I will obtain approval from the Data Proprietor before transferring data from [system name] to any individual who has not accepted the terms of this Data Access Agreement.

Protection of data in this system is governed by the following law, policy and regulation:
-
-
-

8.    Data reuse

Secondary storage/systems may not be created from the [system name] data without prior approval of the Data Proprietor and registration and approval of the secondary storage/system with the Office of the CIO.

9.    Termination of Access

If my employment with the University ends, or my professional responsibilities no longer require access to the data, or the scope of required access changes, I have a joint responsibility with the Data Proprietor to ensure my system access is revoked or changed appropriately.  If my access is not changed in a timely manner, I will notify the Data Proprietor. 

I agree to the terms of this Data Access Agreement.

Signature of user or "I accept" button.