Data Classification Table

Level Definition Explanation and examples
Level 4

Protected

Non-public data that the University has designated as Protected. Protected data requires substantially greater protection measures than Confidential data. Some non-public data is highly sensitive such that its disclosure poses substantially greater risk of harm to the University than Confidential data, and it is possible to manage this risk by storing and using the data so that extra protections are always in place. This category is for data of particular sensitivity that should not normally reside on general-purpose computer systems, or be handled in the same way as ordinary office paperwork.

Examples (not exhaustive):

  • personal health records as defined by PHIPA
  • customer Payment Card Information when University is in a merchant capacity
Level 3

Confidential

Non-public data that contains personal information (as defined by FIPPA for which appropriate permission to disclose has not been received) and other data that the University has designated as being Confidential. Much administrative data, including general-purpose email and business paperwork in a typical university office, would fall into this category, given that the administration of the University’s teaching generally involves the handling of personal information about students, and sometimes (HR) about staff and faculty. FIPPA imposes additional privacy obligations on the University, so in addition to risks for levels one and two, FIPPA risks also apply.

Examples (not exhaustive):

  • student numbers, names, marks, student records,
  • employee records,
  • video surveillance security footage,
  • research data involving identified living human subjects,
  • research data classified as confidential by funding agencies / research ethics board
Level 2

Internal

Data the University has not chosen to make public, but has not been designated by the University as being in another level. This is the default category. In addition to risks for level 1, this data should not be disclosed to the public in general, or to people other than those the data owner or steward wishes, until/unless the data owner/steward decides to make it public.

Examples (not exhaustive):

  • UofT Advanced Directory for faculty/staff
  • most unpublished research
  • most course materials
  • building floor plans
  • unpublished  software source code
Level 1

Public

Data available for broad or general open view This category is for data that the University has designated as being generally accessible, e.g. to the public. Privacy and confidentiality of this data is not an issue, the issue is authenticity/integrity of the data (no unauthorized additions/modifications/deletions).

Examples (not exhaustive):

  • UofT Directory
  • press releases
  • news articles
  • published annual reports
  • faculty and staff directory
  • published research
  • external job postings, distributed
  • open source software source code

Draft FAQ.

Q: Why not only two levels: Public and Non-Public?

A: The risks to the University of the exposure of non-Public data varies widely, from very little (e.g. unpublished research soon to be published) to extreme (e.g. the University’s master encryption keys). It’s prohibitively expensive and impractical to protect all non-public data with the highest possible degree of protection.  But for certain data of great risk, it may well be prudent to use very high degrees of protection. Moreover, specific laws obligate the University to protect certain kinds of data to a high degree, a degree of protection that would be prohibitively expensive and cumbersome to impose on all non-public data.

Q: Why not only three levels: Public, “Ordinary” Non-Public, and “Risky” Non-Public?

A: Ontario’s Freedom of Information and Protection of Privacy Act (FIPPA) and Personal Health Information Protection Act (PHIPA) impose legal obligations on the University to protect certain kinds of data in certain ways. FIPPA imposes moderate protection obligations on personal information, but defines personal information broadly, such that much if not most of the University’s administrative data falls into this category. PHIPA does not apply to most of the university’s data, but it imposes very significant protection obligations on personal health information (such as medical records). Some of the University’s data (e.g. some medical research data) falls into this category. It would be expensive and impractical to apply the significant and expensive protections required for e.g. medical records to most if not all of the University’s administrative functions.

Q: Why not treat all non-public data with at least the protections required for personal information (as defined by FIPPA)?

A: FIPPA’s protection requirements for personal information are not extreme but neither are they negligible. The University uses data of various forms in its teaching and research. Most of this is not personal information as defined by FIPPA. It would be a significant hindrance to the university’s teaching and research to insist that all teaching and research systems must meet the requirements necessary to protect personal information, when most of them do not handle such information.

Q: Why not four levels: Public, non-public, FIPPA and PHIPA?

A: A risk inherent to general-purpose computer networks is that they may contain (undiscovered) flaws that could potentially be exploited to disclose data. Because new flaws are frequently being discovered, and these cannot always be patched immediately, security breaches over computer networks cannot be completely prevented. Computer networks are too useful to avoid for most data, even highly sensitive data such as medical records. But there is some data in use at the University that is so sensitive that the inherent risk of access over general-purpose computer networks is too high. A classification for this sort of data, not to be attached to general-purpose networks, is also needed.

Q: Will everyone at the University need to figure out what level each piece of data is in? With five levels to choose from, won’t this be difficult and error-prone?

A: Most people at the university will not need to figure out what level their data is in. Level four and five data is rare: not many people at the University deal regularly with e.g. medical records or the University’s master encryption keys. So only three levels will be typically seen. Personal information is so widespread in the University’s administration that it is probably inevitable that most general-purpose administrative systems (e.g. the University’s email systems, administrative PCs) will need to meet suitable protection requirements for personal information. For teaching and research, in most instances, research data and course materials are not personal information, and so less restrictive protections for systems intended for this data will normally be acceptable. Most often, people would need to consider data level only when moving data from e.g. an administrative system to a system designed for research data or teaching materials only, such as a classroom podium PC.

Q: If some mechanism were to be available to classify individual documents by data type, would that be useful?

A: If documents could be classified by type (e.g. student marks, employee records, research, etc.), and some form of protection automatically assigned based on that type’s security classification (e.g. student marks are personal information, thus Confidential), that could potentially be useful, so long as the work required to assign types and maintain them correctly is not too onerous.

A provisional approach would be to classify by system: for example, an administrative desktop can be used for data up to Confidential (level 3), while a classroom podium PC only for data up to Internal (level 2). Rather than pre-classify every document, a document’s security level could be considered when needed, such as when copying it from an administrative system to a less protected teaching or research system.

Because of the significant protections required, we would expect there to be relatively few systems that can hold Protected data, and even more so for Off-Line data. Highly sensitive data such as medical records would need to be handled only on systems that are designed with the necessary protections. A mechanism here that makes it more difficult to move Protected data to an unsuitable system might be helpful.