Personal Identity Information (PII) Training

Background | Definitions | Responsibilities for Protecting PII | Contact Information |


California State Law requires that Personal Identity Information (PII) is appropriately protected and that affected individuals must be notified of any reasonable suspicion of a compromise of that protection. The University is responsible for complying with these legal requirements and for providing employees with information about requirements and responsibilities relating to PII.

The UCSC PII Inventory and Security Breach Procedures, provides campus procedures regarding PII, and is referenced throughout this page.


Personal Identity Information (PII): Personal Identity Information, or PII, is a specific category of restricted data defined as,

Unencrypted electronic information that includes an individual’s first name or initial, and last name, in combination with any one or more of the following:

  1. Social Security number (SSN)
  2. Drivers license number or State-issued Identification Card number
  3. Financial account number, credit card number*, or debit card number in combination with any required security code, access code, or password such as expiration date or mother’s maiden name that could permit access to an individual’s financial account
  4. Medical information: any information regarding an individual’s medical history, mental or physical condition, or medical treatment or diagnosis by a health care professional
  5. Health insurance information: an individual’s health insurance policy number or subscriber identification number, any unique identifier used by a health insurer to identify the individual, or any information in an individual’s application and claims history, including any appeals records

*Special note about credit card information:
Credit card number in conjunction with name is a form of PII. Credit card information is also regulated by the Payment Card Industry (PCI) Data Security Standard.

Additional Definitions:


Identify PII

  • Identify, to the best of your ability, any PII that resides on your individual devices. This includes portable devices such as flash drives, phones, tablets, CDs/DVDs, external hard drives, old disks, etc., as well as old and archival data and backups.
  • Inform your Manager of all PII contained in and accessed by your systems.

Remove all unnecessary PII from all systems and electronic media

The best way to protect PII is not to have it in the first place.
  • Work with ITS to securely delete PII when there is no longer a business need for its retention.
  • Work with ITS to completely and securely remove all PII from electronic media before disposal or re-use. Always shred or otherwise destroy restricted data before disposing of it.
  • Additional responsibilities of Managers: Managers should implement and document procedures that govern the receipt and removal of hardware and electronic media containing PII, including equipment reassignment, and final disposition of equipment. 

Protect all PII that you must keep

 - All members of the University community are responsible for appropriate access, use and protection of PII to which they have access or over which they have jurisdiction or control. This includes storage and distribution of PII. Individuals are responsible for working in partnership with Service Providers to ensure appropriate awareness and protection of PII. 

 - System Stewards
 are responsible for ensuring appropriate measures and checks are in place for protection of PII under their control, including any downloading or transmission of such information. If there is any question about the adequacy of current controls, a review by UCSC IT Security or UCSC Internal Audit staff should be requested.

 - Service Providers are responsible for providing appropriate protection of PII on supported systems.

 - UCSC has developed general guidelines for the protection of all restricted data, including PII. See Practices for Protecting Electronic Restricted Data, a quick-reference for non-technical employees. 

Incident Response Procedures for Suspected Data Breaches

UCSC's PII Inventory and Security Breach Procedures outline campus incident response procedures for suspected and confirmed breaches of PII, as summarized below. These procedures also address security breaches or suspected security breaches involving other types of restricted data, including electronic protected health information (ePHI or "HIPAA data"), and credit card information (PCI), though notification procedures may differ.

System Stewards are responsible for ensuring that these procedures are followed for all breaches of electronic restricted data, or systems containing electronic restricted data, under their management.


  • Report Suspected Data Breaches. Any suspected breach of a system containing restricted data, or any suspected inappropriate disclosure of restricted data must be reported to the ITS Support Center, 459-4357, or, regardless of how the suspicion arose. The Support Center will notify UCSC IT Security.
  • Employees are also to report suspected incidents to their supervisor in addition to the ITS Support Center.
  • Service Providers, System Stewards, Unit/Departmental Managers, and ITS staff are also to report suspected incidents to affected Unit/Departmental Managers and System Stewards.

Report suspected theft of UCSC-related computing equipment to the police in addition to notifying the ITS Support Center and your supervisor:

  • On-campus theft: Contact the UCSC Police Department at 831-459-2231.
  • Off-campus theft: Contact local police.
  • Be sure to tell the ITS Support Center if the missing equipment contains PII or other restricted data.

Incident Response Process
(Summary only. See PII Inventory and Security Breach Procedures for full process.)

The incident response process is initiated with a suspected security breach of unencrypted electronic restricted data or a significant or high-visibility incident.

  • The System Steward or designee must complete an Initial Incident Report (UCSC PII Inventory and Security Breach Procedures, Appendix A), and submit this to IT Security or IT Policy as soon as possible, but no later than 24 hours after becoming aware of the suspected breach. The System Steward or designee should file a police report with the UCSC Police Department if criminal activity is suspected.
  • The VC IT will forward the Initial Incident Report to the Campus Incident Response Team (CIRT).
  • IT Security and the Service Provider work together to disable unauthorized access to electronic restricted data where applicable and restore the service and integrity of the system with appropriate documentation and preservation of evidence.
  • IT Security in partnership with the Service Provider will confirm the security breach.
  • If IT Security determines that there is a possibility of unauthorized access, the VC IT will convene the CIRT to determine whether criteria for notification have been met (see Notification Procedures, below). The CIRT will complete the CIRT Checklist (UCSC PII Inventory and Security Breach Procedures, Appendix C) for all incidents for which they are convened.
  • Upon resolution of the breach, IT Security and IT Policy will coordinate to ensure completion of the Campus Incident Response Team Report (UCSC PII Inventory and Security Breach Procedures, Appendix B), and submit this to the VC IT as soon as possible.
  • The VC IT or designee will submit a final incident report to the Associate Vice President for Information Resources and Communications at UCOP via the UC EthicsPoint reporting tool as soon as the incident is closed, or if any problem is encountered during the notification process (see below).

Note: If a suspected security breach potentially involves electronic protected health information (ePHI/HIPAA data), UC's HIPAA Breach Response Policy shall apply. The Campus HIPAA Privacy Official shall be the designated Privacy Official under this policy, and the response will include the use of the UC Privacy and Data Security Incident Response Plan referenced therein.

Notification Procedures
(Summary only. See PII Inventory and Security Breach Procedures for complete procedures.)

If unencrypted electronic restricted data is reasonably believed to have been acquired by an unauthorized person, state law or industry regulation may require notification to affected subjects. The CIRT may also determine that notification is appropriate in situations involving other types of restricted data, or in the case of a significant or high-visibility incident. The CIRT must consult UC’s “Information Breach Decision Tree for California State Law” and/or “Information Breach Decision Checklist for HIPAA” (available from UC HIPAA Officers or Health Lawyers) as necessary.

If the criteria for notification has been met, the VC IT along with the Campus Incident Response Team determines the notification plan, including the means and text of notification. The VC IT will work with the System Steward or designee and Service Provider to determine the availability of contact information for notification. Upon approval of the notification plan by Campus Counsel, the VC IT works with the Public Information Office (PIO) to deliver the notification. The VC IT will work with the System Steward or designee and Service Provider as required for additional advice or assistance to affected subjects.

Release of Information

Requests for information regarding a security incident from University employees without a clearly defined business need to know, or from any individuals or entities outside the University must be directed to the Chief Privacy Officer in the Office of Campus Counsel.

Note: Written correspondence, such as email, created during the discovery or investigation phase of a security incident may be considered a public record subject to release under the California Public Records Act and/or Information Practices Act. Therefore, information that is not appropriate for release based on the protection of privacy interests or security considerations (e.g., names of individuals or other identifying information or technical information that could enable another breach) should not be included in this correspondence. This is especially important to take into consideration where notification may be required.

Contact Information

For questions or feedback about the information in this training, contact:

Rev. Sept 2015