Data and IT Resource Classification Guideline

The UC Berkeley Data and IT Resource Classification Standard is a framework for assessing the adverse impact that loss of confidentiality, integrity or availability of Institutional Information and IT Resources would have upon the Campus. The Minimum Security Standard for Electronic Information (MSSEI) identifies required security protections based on the Data and IT Resource Classification Standard.

The information below is provided as additional guidance on classifying information and IT Resources under the Data and IT Resource Classification Standard.

Steps for determining Protection Level classification
Steps for determining Availability Level classification
Information Security Policy Glossary (links to separate page)
Note: There is no step-by-step guide for Recovery Level classification. RL classification is determined in partnership by the IT Resource Proprietor(s) and the Service Provider, and is based on the functional requirements of the service. Please reach out to the Campus IT Recovery Implementation Team for guidance: itdrhelp@berkeley.edu

Steps for determining Protection Level classification

The following steps provide guidance for the considerations necessary to determine data classification Protection Level. The most sensitive data element generally determines the Protection Level of a set of data. Combining sets of lower level data can also result in a higher level classification, particularly where the combined data can potentially identify an individual or group.

This table addresses the most common questions the Information Security Office (ISO) receives about Protection Level classification; it does not cover all circumstances. For additional assistance determining Protection Level, please contact the ISO at security@berkeley.edu.

Step 1

Identify the specific data elements you’re working with.

Check the Protection Levels table. If you can find them there, use the classifications from the table, and you’re done! Otherwise, continue to Step 2.

Step 2

Are you working with any of the following?

research data involving a data use agreement (DUA)
confidentiality or nondisclosure agreements with security clauses
HIPAA data
federal Controlled Unclassified Information (CUI)

If not, continue to Step 3.

If so, please contact the Information Security Office (ISO) at security@berkeley.edu.

If you are a researcher, please contact Research IT at research-it@berkeley.edu.

Step 3

Does the data include any of the following?

Social Security numbers (SSN)
driver's license, passport, or other government issued ID numbers
financial account numbers
personal medical information
personal health insurance information
credit card numbers
passwords, PINs, passphrases, or security questions and answers
individually identifiable human subject research data containing P4 data elements, or that the Institutional Review Board (IRB) or Campus Privacy Office has determined is high risk
genetic data as defined by California AB-825 (effective 1/1/2022)
human genomic data subject to GDPR or HIPAA (regardless of de-identification status)
biometric data used for authentication purposes, including facial recognition

If not, continue to Step 4.

If so, it’s P4.

Additional Considerations:

Notice-Triggering data components

Individual components of Notice-Triggering Information (other than name) merit Protection Level 4 (P4) classification, regardless of the actual data breach notification requirement. For example, breach notification law requires notice if Social Security number (SSN) AND name are breached. However, UC Berkeley treats SSNs as P4 even if name is not included. Please contact the ISO at security@berkeley.edu if you have questions about this practice.

Partial SSNs

Partial SSNs in certain contexts are considered Notice-Triggering Information. If you are using partial SSNs, please contact the ISO at security@berkeley.edu to help determine the protection level of your data.

3. Passwords, PINs, passphrases, and security questions and answers

When properly encrypted or hashed, these elements are not considered P4 data. However, the encryption keys are classified as P4. Systems that manage credentials that provide access to P4 data or resources, and encryption keys, are also P4.

Step 4

Are you dealing with industrial control systems affecting life and safety?

If not, continue to Step 5.

If so, it’s P4.

Step 5

Does the data include personal information of

European Union (EU) or European Economic Area (EEA) residents?
People residing in the People's Republic of China (PRC)?

If not, continue to Step 6.

If so, the European Union General Data Protection Regulation (GDPR) or China’s Personal Information Protection Law (PIPL) probably applies.

For EU or EAA residents' data, does the information fall into any of the special categories of personal data outlined in Article 9 of the GDPR?

If so, it’s P4
If not, or if it's PRC residents' data, it’s P3

For questions regarding the GDPR or PIPL, contact the Campus Privacy Office.

Step 6

Does the data include student information protected by FERPA?

If not, continue to Step 7.

If so, it’s probably P3.

Exceptions:

a) Personally Identifiable information about loans (including student loans), federally funded student financial aid, and any other financial aid that requires repayment is P4.

b) Public Directory Information for students who have NOT requested a FERPA block would generally be P2. However, directory information for students who have exercised their right under FERPA to request that information about them not be released as public information is still classified as P3.

Step 7

Does the data include staff and academic Personnel Records?

If not, continue to Step 8.

If so, it’s probably P3.

The exceptions would be Public Directory Information for faculty and staff, and UCPath Employee ID. These would be P2.

Step 8

Does the data include individually identifiable human subject research data not containing P4 data elements and that the IRB or Campus Privacy Office have not determined is high risk?

If not, continue to Step 9.

If so, it’s probably P3.

This includes human genomic data if standard identifiers are not removed; or if the data can be re-identified using publicly available data.

If you're not sure about the risk level, contact the Institutional Review Board (IRB) or Campus Privacy Office for assistance.

Step 9

Does the data include IT security-related information which, if obtained by attackers, would significantly increase the effectiveness of their attacks?

If not, continue to Step 10.

If so, it’s probably P3.

Examples that would be classified as P3 include vulnerability scan and penetration test results, information security exception requests, information about a system’s security configuration or known vulnerabilities, administrator/user account names, non-public database names/schema, audit findings, firewall rules, and other security-related information of a similar level of sensitivity. This category would not typically include general system configuration information. Contact security@berkeley.edu if unsure.

Step 10

Does the data involve de-identified human subject research or de-identified human genomic data?

If not, continue to Step 11.

If yes,

Is the data entirely de-identified or anonymized, with a negligible re-identification risk, and no Notice-Triggering data elements? If so, it's probably P2.
Consult with the Campus Privacy Office to confirm that the data is fully de-identified/anonymized under applicable laws, regulations, and protocols.
De-identified human genomic data is a special case due to evolving laws and technological advances. Please consult with the Campus Privacy Office even for genomic data sets that appear to be fully de-identified.

Step 11

Is the data public (no sharing restriction)?

If you don’t know, continue to Step 12.

If it’s public, it’s probably P1 unless unauthorized modification of the data would be an issue. Departmental websites are a good example of this: The information is public, but the accuracy (integrity) of the information is important. In situations like this, the need for data integrity drives the Protection Level.

P1: Public data, and unauthorized modification has a minimal impact
P2: Public data, and unauthorized modification has a low impact
P3: Public data, and unauthorized modification has a moderate impact
P4: Public data, and unauthorized modification has a high impact

Step 12

Are you are still uncertain of the classification?

If the Protection Level is still not clear after completing steps 1-10 and consulting the Protection Levels table, please contact security@berkeley.edu for assistance.

Steps for determining Availability Level classification

The following steps provide guidance for the considerations necessary to determine Availability Level classification.

Step 1	Identify the specific IT Resources and/or data you’re working with.	Check the Availability Levels table. If you can find them there, use the classifications from the table, and you’re done! For the Availability Level of Campus services not listed in the table, contact the IT Resource Proprietor of the specific service. If the classification in the table seems incorrect, please contact the Resource Proprietor for a determination." If none of the above apply, continue to Step 2.
Step 2	Are the resources/data Critical IT Infrastructure? -or- Do the resources/data support life/safety? If not, continue to Step 3.	If so, it’s A4.
Step 3	Are there contractual service level agreements (SLAs) or regulations requiring high availability of the resource/data? For example, the following all have varying requirements to be up and running: The emergency 911 system The Campus data center Campus power generation If not, continue to Step 4.	If so, it’s probably A4.
Step 4	Consider the impact and implications if the resource/data became unavailable. For example, if the data were lost or destroyed, what would be the impact? If there were loss of use or loss of access, what would be the impact? Could you/Campus live without it? If you don’t know, continue to Step 5.	Would there be a risk of harm to individuals? Would there be a business impact to the Campus, a Campus Unit, and/or essential services? Would it cause financial losses? Would it jeopardize critical research? Would it damage the reputation of the Campus or a Campus Unit? If you answered yes to any of the above, would the impact be: High? If so, then it’s A4. Moderate? If so, then it’s A3. Low? If so, then it’s A2. Minimal or none? If so, then it’s A1.
Step 5	Are you are still uncertain of the classification?	If the Availability Level is still not clear after completing steps 1-4 and consulting the Availability Levels table, please contact the IT Resource Proprietor or Institutional Information Proprietor for assistance. If it’s not clear who this would be, talk to your Department Head.