| The University of Toronto Policy on Information Security and the Protection of Digital Assets was adopted as measure to protect the privacy, confidentiality, integrity, and availability of Digital Assets, including information systems that store, process or transmit data. It states that standards set a baseline for Digital Assets protection. |
| Information Technology Systems is developing standards for use within ITS. Others units within the University will be free to use them. Zones being considered are the Security Zone, Governance Zone and Technology Zone. |
| ISEA has worked on standards within the Security zone, as shown in the table below. Controls for each standard are shown under each standard, and are still in discussion. If you would like more information, please contact the director, ISEA. |
** This information is retained on our website for historical purposes. For current Data Classification Standards please visit our Policies & Practices page.
| Identifier | Standard |
| ICP | Information Classification and Protection |
| APS | Application Security |
| IAM | Identity and Access Management |
| OPS | Operational Security |
| IFS | Infrastructure Security |
| CRP | Cryptography |
Within each standard there will be a collection of security controls, each uniquely identified. Each security control is assigned a control rating for each classification of data, illustrating whether the control is appropriate.
It is essential to review each standard in conjunction with the other five to ensure the ITS information security standard requirements are fully understood and met.
Definitions of data classifications being considered are provided in the table below. These classifications are designed to encompass a vast majority of data access – but not all. An information security risk assessment may identify data that requires greater protections than the Restricted category. Also, data classification can include two additional characteristics: integrity and availability which are implicit in the definitions below. A risk assessment may identify either or both of these characteristics for attention.
| Classification | Definition |
| Restricted | Data should be classified as Restricted when the unauthorized disclosure, alteration or destruction of that data could cause a significant level of risk to the University, its stakeholders or its affiliates. In some cases, unauthorized disclosure or loss of this data would require the University to notify the affected individual and provincial authorities. The University would have a contractual, legal, or regulatory obligation to safeguard this data in the most stringent manner.
Examples:
|
| Confidential | Data should be classified as Confidential when the unauthorized disclosure, alteration or destruction of that data could adversely affect individuals, the business of the University or its affiliates. Confidential data includes data protected by provincial or federal privacy regulations, as well as for example data protected by confidentiality agreements.
Examples:
|
| Public | Data should be classified as Public when the data does not require any level of protection from disclosure, as this data is intended to be shared with the public.
Examples:
|
The control ratings being considered are:
| Control Rating | Definition |
| Optional | The security control is optional for the designated classification of data. This does not imply that the control should not be implemented. Business units that would like to go above and beyond baseline requirements are encouraged to evaluate all controls for appropriateness. |
| Recommended | The security control is recommended for the designated classification of data but is not required due to limitations in available technology or because the control could potentially place an undue burden on a business unit to implement. Business units should document their justification for not implementing a ‘Recommended’ security control and whether or not a compensating control has been implemented. |
| Required | The security control is required for the designated classification of data. In situations where a ‘Required’ security control cannot be implemented, the Procedure for Policy Exception Handling should be followed. This process allows for a more formalized tracking and approval of security risks across the University. |
Other definitions are:
| Definition | |
| Sensitive Personal Identifying Information (SPII) | Sensitive Personal Identifying Information (SPII) is defined as information that if lost, compromised, or disclosed could result in substantial harm, embarrassment, inconvenience, or unfairness to an individual Sensitive PII include: * Social security/insurance numbers * Bank account numbers * Passport information * Healthcare related information * Medical insurance information * Student information (Grades) * Credit and debit card numbers * Drivers license and Federal/Provincial ID information In general terms it is any information that could be used by criminals to conduct identity theft, blackmail, stalking, or other crimes against an individual. |
| Personally Identifiable Information | Personally Identifiable Information (PII) is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. PII includes: * Full name (if not common) * Home address * Personal Email address * Digital identity * Date of birth * Birthplace * Telephone number * Login name, screen name, nickname, or handle WARNING: Even anonymized data can become PII, where certain combinations of data can lead to the identification of a specific individual with a high degree of certainty, such as postal code, sex and age/birth year NOTE: Business Contact Information (such as Full Name, Business Address, Business Email Address, Business Telephone and Job Title) is NOT PII. |
| Business Contact Information | Business details such as Full Name, Business Address, Business Email Address, Business Telephone and Job Title. This is not PII. |
The standards reflects a common set of controls that are appropriate across ITS. It is important to note that additional or more specific security controls may be required based on individual business requirements (e.g. contractual and/or regulatory obligations). Many industry business practices and regulatory requirements have been considered in the development of the standards; however, it may not be comprehensive in certain situations. Business units using these standards should consider mapping contractual and/or regulatory obligations to the standards to ensure there are no gaps in their own controls.