Data Access Agreement Guidelines

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.


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. 


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.
  • Notification to users of MSSEI security requirements for individual devices:
    • 1.1 Removal of non-required covered data (PL1, PL2)
    • 3.1 Secure configuration (PL1, PL2)
    • 5.1 Device physical security (PL2)
    • 8.1 Privacy and Security Training (PL2)
    • 9.1 Unique passphrase (PL1, PL2)
    • 9.2 Separation of accounts (PL1, PL2)
    • 13.1 Controlled access based on need to know (PL1, PL2)
    • 14.1 Account monitoring and management (PL2)
    • 15.1 Encryption in transit (PL1, PL2)
    • 15.2 Encryption on mobile devices and removable media (PL2)
    • 15.3 Secure deletion upon decommission (PL2)
    • 16.3 Incident Response Training (PL1, PL2)
  • Description of additional laws and policies governing covered data.
    * 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 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 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.,
  • Users can also be required to select the radio button(s) that correctly summarize to the stated terms. (e.g.,

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.


Data Proprietor:     
for Data Set Name:


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 Protection Level [0-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 Protection level 1 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 Protection Level 1 (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 Protection Level 2 (PL2) data must meet the following MSSEI requirements for individual devices, in addition to protection profile for 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 Protection Level [0-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.