FAQs
Topics on this page:
General
Risk is the likelihood of an occurrence or event happening and its consequences. In simple terms, risk is a combination of the chance that something may happen and the degree of damage or loss that may result.
Within the context of information security, risk refers to the risks when using information, i.e., data security and data privacy risk.
We use various thresholds and scales to predict how impactful an event could be in the context of what solution is being assessed, and the sensitivity of the data at risk.
Some risks are not quantifiable in easily described terms. For example, reputational risks can have far-reaching impacts, such as financial impacts, and these impacts are often not realized until years after an event.
Risk treatment refers to the process of developing strategies and implementing actions to manage identified risks effectively. Risk treatment involves several key steps and should be a continual cycle. Refer to the graphic below to learn about the steps.
1. Identify
Recognising and cataloguing potential risks that could impact your project’s objectives and outcomes.
2. Analyse
Assessing the potential impact and likelihood of each identified risk to prioritize and understand their significance.
3. Mitigate
Developing and implementing strategies to reduce the likelihood or impact of identified risks.
4. Monitor
Continuously overseeing and tracking the identified risks throughout the project’s lifecycle, adapting strategies as needed to ensure timely response and effective risk management.
1. Identify
Recognising and cataloguing potential risks that could impact your project’s objectives and outcomes.
2. Analyse
Developing and implementing strategies to reduce the likelihood or impact of identified risks.
3. Mitigate
Developing and implementing strategies to reduce the likelihood or impact of identified risks.
4. Monitor
Continuously overseeing and tracking the identified risks throughout the profile’s lifecycle, adapting strategies as needed to ensure timely response and effective risk management.
Risk assessment
Risk assessments look at three areas:
- Data security, which looks at the controls that are implemented to keep the data secure
- Data privacy and compliance, which looks at what data is collected and how that data is used, stored and deleted
- Contracts, which define and govern the rules around data handling practices
The University has obligations when we collect, use and store sensitive data. Some of these obligations come from internal policies, and others come from external policies and legislation like the Freedom of Information and Protection of Privacy Act (FIPPA), which is provincial legislation that the University must comply with.
Lack of details surrounding data handling practices may lead to sensitive information being exposed, manipulated or used for malicious purposes. If U of T were to expose sensitive data, there would be impacts for the University and the department(s) that allowed the exposure. Impacts would depend on the sensitivity and volume of the data exposed.
The University must be compliant with FIPPA legislation and the data that FIPPA protects. Noncompliance would have impacts, which could include financial penalties.
Examples of data and documentation needed for data security controls to be examined include, but are not limited to the following:
- Certifications, such as PCI certification for handling financial and payment-based information or an ISO-27001 certification for information management systems
- Documentation that details how security controls are applied, such as a Higher Education Community Vendor Assessment Toolkit (HECVAT) or Consensus Assessments Initiative Questionnaire (CAIQ)
- Audit reports, such as SOC2 type 2 reports that verify that controls are in place and are working as intended
- Vulnerability scan and penetration test reports
Risk assessments should be conducted in the following cases:
- When new applications, systems, platforms or hardware (solutions) are procured or implemented
- When significant change to functionality takes place within an already assessed solution. This is dependent on the solution, but examples are:
- New plugins for a WordPress site
- Integrations to existing environments
- When the data collection, usage or storage is changed
- On a routine basis – depending on the type of solution, new assessments should be done periodically to ensure that controls are still in place
- Every two or three years can be used as a rough timeline, assuming there are no changes to functionality or data collection/usage
Note that updated security documentation from vendor-managed systems should be requested and reviewed annually.
Assessments are meant to be confidential (level 3 data) because they may deal with confidential information and vulnerabilities/weaknesses in solutions that contain sensitive data. Access to assessments should be restricted to those who need to know, such as stakeholders.
Assessments are the property of both the requesting department and Information Security. They are sometimes shared by other University departments on an as-needed basis. Assessments with issues that cross risk thresholds may be escalated within Information Security. Senior management, including the chief information security officer, may be alerted as needed.
Usually, each risk assessment takes anywhere between six to eight weeks (about two months) after providing all documents.
The turnaround time is not time specific and changes depending on current workload.
Assessments take time. Bigger and more complicated solutions will require more time to complete and document.
Typically, when the assessment is complete, a finalized assessment document will be emailed to the requester and the tracking ticket will be closed.
We use a risk matrix that consists of likelihood (the chance that an event will occur) and impact (what happens when that event does occur). Each potential issue is measured by these two factors and rated on a scale. Higher level risks are prioritized for resolution.
For more details, review the risk matrix in the risk register template.
The unit/requestor for the risk assessment is responsible for mitigating the identified risks. If any risk is left untreated, the risk should be continuously tracked and monitored in the unit’s risk register.
Divisions, departments or groups may have their own staff who can assess risks and implement measures to reduce exposure. If internal resources are not available, the Information Security team is available to help.
Vendors
The IRRM process is baked into the procurement process. The procurement team will discuss the IRRM requirements during the process.
It is strongly recommended that the vendor’s security posture be reviewed regularly, especially if there are changes to the data usage. If the vendor has not been assessed in the last two years, it is best to get a re-assessment done. You can always open a ticket and the team can guide you on the best way forward.
Last modified: July 8, 2024