Information Security Policy Guide for Units

This is a working document last updated July 3, 2023

I. Introduction

The UC system wide policy UC Electronic Information Security Policy BFB-IS-3 (IS-3) establishes that Units are responsible for the appropriate protection of Institutional Information and IT Resources within the Unit. IS-3 identifies specific information security-related requirements and responsibilities for Units. Units are also responsible for implementing and complying with Campus information security policy requirements. Unit Heads are ultimately accountable and responsible for compliance. 

II. Purpose

The purpose of this guide is to help create a “one stop shop” of Unit responsibilities at UC Berkeley with respect to the security and protection of Institutional Information and IT Resources. It consolidates responsibilities from existing Campus policies and from IS-3 for this reference.

III. Scope

This guide applies to all Units at UC Berkeley, as defined below.

IV. Key Definitions

  1. Unit: In the context of information security, a Unit is a Campus academic or administrative entity led by a Campus appointed Unit Head with budgetary authority and resources of a level sufficient to accept and manage the organization’s information security risk. Units are the point of accountability and responsibility for Institutional Information and IT Resources. At UC Berkeley, the organizational level of a Unit in this context is at the Dean, VC, or AVC level. Delegation is allowed if the delegation is explicit and includes budget and resources necessary to fully accept and manage information security risk at the delegated level, including covering an adverse information security event such as a data breach or system compromise.
  2. Definitions of other Key Terms (capitalized and italicized) used in this guide are included in UC Berkeley’s Information Security Policy Glossary

V. Policy Exceptions:

Units are responsible for requesting an exception through the Information Security Policy Exception Process if they are unable to meet UC Berkeley information security policy requirements.

VI. Essential Responsibilities for All Units 

A. Unit Information Security Lead(s)

The Unit Head must designate one or more Unit Information Security Lead(s) (UISLs) to be responsible for ensuring implementation of information security requirements within the Unit. Resources for UISLs include:

  1. “Unit Heads and Security Leads” informational page
  2. UISL “Job Description”: full version | 1-pager
  3. mailing list, to communicate with and get help from the UISL community
  4. email to request assistance from the Information Security Office (creates a ServiceNow ticket)

B. Information Security Contact(s)

Every Unit must establish a Security Contact, as outlined in the Campus Departmental Information Security Contact Policy, in order to ensure that Units can be contacted in the event of a security incident. In some Units the UISL and the Security Contact(s) are the same person. If you are the UISL for a large Unit, you may have multiple security contacts.

C. Security Plan

The Unit must maintain a security plan documenting how it manages information security risk. UC Berkeley’s "Unit-Level Information Security Management Program Template" can be used to meet this requirement. Other formats are also allowed.

  1. The security plan must be reviewed and updated annually. 
  2. Unit Head acceptance of the security plan is required.
  3. Units and Service Providers must use and demonstrate an evidence-based approach to compliance with security requirements.

D. Inventory

The Unit is responsible for identifying and inventorying Institutional Information and IT Resources that the Unit uses and is responsible for, including classification of Protection Level and Availability Level as determined by or in conjunction with the Proprietor

  1. All Institutional Devices and Services classified at Protection Level P3 or P4, or Availability Level A4, must be registered in Socreg. P4 Individual Devices should be registered in Socreg as compinents of a Protected Data Application.
    1. The most sensitive data element generally determines the Protection Level of a set of data.
  2. Units must review classifications when major changes occur. For example, changes in the kind of data a group in your Unit is collecting or storing, changes in a service or software that a group uses, or moving or upgrading hardware and software that host services storing Protected Data, etc.
  3. Record retention is another aspect of inventory -- ensuring that record retention and secure disposal/deletion processes are in place.

E. Compliance with MSSND, MSSEI, and UC Minimum Security Standards

  1. Units must ensure that all devices and services under their area of responsibility comply with UC Berkeley’s MSSND, MSSEI, and the UC Minimum Security Standard. (This will eventually translate to complying with the MSSND & updated MSSEI.)
  2. Units managing or handling certificates or private keys must follow the UC Encryption Key and Certificate Management Standard.

F. Risk Assessment and Risk Treatment Plans

A current risk assessment or risk treatment plan is required for all P3 and P4 assets and services. UC Berkeley’s MSSEI System Security Plan (SSP) meets this requirement. An SSP reviewed by the Information Security Office is required for P4 assets and services.

G. Security-Related Training 

Units must ensure appropriate information security training throughout the Unit, according to each person’s role. This includes:

  1. Security awareness training -- at a minimum the annual required UC systemwide cybersecurity training.
  2. Procedures for reporting suspected or confirmed security incidents or concerns (See Section H, below).
  3. Ensuring that those with IT responsibilities have appropriate security skills and qualifications; and are educated on a regular basis, or receive training related to the security job requirements, policies, procedures, and best practices in order to maintain minimum standards of information security.

H. Incident Response and Reporting

Units must:

  1. Establish and train on Unit procedures for individuals to report suspected or confirmed security incidents or concerns.
  2. Report suspected or confirmed information security incidents, and non-compliance with legal and contractual requirements related to information security, to the Information Security Office (ISO).
  3. Promptly respond to security incident reports and notices from the ISO.
  4. Additionally, Service Providers must develop and review at least annually a system-level incident response plan for Institutional Devices that handle data classified at Protection Level P2 or above. A template is also available.

I. Managing Service Providers (internal) and Suppliers (external) 

  1. Units using Suppliers must comply with IS-3 Part III, Section 15 “Supplier Relationships”. This includes working with the Unit’s Buyer or Campus Procurement to ensure necessary contract language is in place, and fulfilling the Unit responsibilities listed in IS-3 Part III, Section 15.2. You can verify your Unit's Buyer here:
  2. A Vendor Security Assessment is required for Suppliers with access to institutional Information or IT Resources classified at Protection Level P3 or P4.
  3. Units should maintain a list or repository of their Unit’s Suppliers and the services that they provide. This list should be reviewed at least annually for changes in Protection Level, Availability Level, and business need.
  4. Units using Service Providers must not exceed the established Protection Level or Availability Level of the service. Units must also confirm with the Service Provider which required security controls are provided by the Service and which are the responsibility of the Unit.
  5. Units that are also Service Providers must meet all Service Provider responsibilities. See UC Berkeley’s Roles and Responsibilities Policy for details.

J. Security Planning and Review 

  1. Unit Heads must factor information security risk management into budgetary decisions and allocations.  
  2. Units must ensure that new devices and services are able to meet security requirements before purchasing, contracting, or implementing them. 
    1. Note: If a Unit procures and/or installs a system that creates, processes, stores or transmits Institutional Information, it must assign a named Workforce Member (or role) to act as the Proprietor for the resource. UISLs are responsible for ensuring this assignment.
  3. Units must plan for:
    1. Future capacity requirements.
    2. Replacing or retiring unsupported IT Resources.
    3. Institutional Information retention and disposal requirements.
    4. Secure decommissioning of IT Resources.
  4. Units must perform periodic reviews of information security practices, make corresponding adjustments to the application of Campus policy, and update applicable Risk Assessments/Risk Treatment Plans.

K. Provisioning and Managing Access Rights Within the Unit

  1. Units are responsible for reviewing access rights at least annually and removing access that is no longer needed. This includes privileged and administrator-level access.
  2. Units must notify appropriate Units and contacts in a timely manner when someone’s job responsibilities change in a way that affects their access to Institutional Information and IT Resources.
  3. As a general rule, Campus and UC Minimum Security Standards and Acceptable Use Policies apply to everyone who uses or accesses UC IT Resources or Institutional Information. Units granting guest or other access to networks and network services not otherwise covered under Campus policy must:
    1. Establish terms of use or acceptable use.
    2. Set minimum security requirements.
    3. Scope access and security requirements based on operational need and risk.

L. Facilities

Units maintaining information processing facilities must ensure correct and secure operations of those facilities (based on IS-3 section 12.1).

M. Software Development

Software developed in-house that stores, processes or transmits Institutional Information classified at Protection Level P2 or higher must be developed in compliance with the MSSND, MSSEI, and UC Secure Software Development Standard. (IS-3 section 14.1)

  1. Information security must be designed and implemented within the entire development lifecycle of information systems. Units must maintain documentation showing security planning and requirements during all phases of development or acquisition, from initiation through implementation, and ongoing maintenance phases. (IS-3 section 14.2)

N. Separation of Duties

Workforce Managers must consider the principle of Separation of Duties when designing and defining job duties. This includes:

  1. Implementing methods and controls that, to the extent feasible and appropriate, separate duties among Workforce Members so that the roles of requestor, approver, and implementer are independent.
  2. Establishing effective oversight of activities and transactions.
  3. When functions cannot be separated, ensuring adequate administrative oversight or other compensating controls are in place to mitigate any identified risks.

O. HR Responsibilities

IS-3 Part III, Section 7 identifies specific Human Resource security responsibilities for before, during, and after employment. Units are responsible for ensuring that these responsibilities are met for their Workforce Members, even if another Unit is responsible for the actual tasks. 

While UISLs may not oversee HR policies for their Unit, they are still responsible for ensuring their Unit works with their HR resources to ensure that the Unit has consistent processes and procedures in place that address these areas.

A summary follows. Please refer to IS-3 (link above) for the complete list.

  1. Prior to Employment: 
    1. Establish security-related duties of the position and include them in the job description. Perform required background checks and verify identity prior to providing access to Institutional Information or IT Resources.
  2. During Employment:
    1. Include information security-related requirements, training, and procedures in the onboarding process.
    2. Update the information security elements of job descriptions and training requirements when job duties change.
    3. Promptly address reported, suspected, or actual policy violations.
  3. Separation and Change of Employment:
    1. Perform required background checks when a Workforce Member moves into a critical position, or is granted access to Institutional Information or IT Resources classified at Protection Level P3 or higher as part of a job change or reclassification.
    2. Ensure physical and electronic access to Institutional Information and IT Resources is modified, added, or removed as needed in response to separation or job change.
    3. Collect UC property, IT Resources and physical access keys/cards as applicable.
    4. Ensure the return and/or secure deletion of Institutional Information (including copies), token encryption keys, and UC-licensed software and tools in the individual’s possession.
    5. Ensure continued availability of Institutional Information required for business continuity.

P. Audits 

IS-3 Part III, Section 12.7 establishes requirements for Units in the event of audits. These are:

  1. Units must support UC Internal Audit reviews, investigations, audits and other approved reviews, including those performed by Suppliers
  2. Units must plan and control audits to minimize adverse effects on production systems and business processes.
  3. Units must ensure that audit tests do not alter audit logs or production Institutional Information.
  4. Units must ensure that audit activities do not reduce security controls below what is appropriate for the applicable Protection or Availability Level.
  5. Units must log and record auditor access to Institutional Information classified at Protection Level P3 or higher.

VII. Related Documents and Policies 

UC Berkeley

UC Systemwide