Administrative Procedure

AP-328 — Risk Management Framework

Section Three: General School Administration

Effective Date: May 26, 2026 Last Reviewed: —

Background

This Administrative Procedure establishes the Division's risk management framework. It provides a common methodology for identifying, scoring, and treating risks so that the Division's decisions are consistent, defensible, and proportionate to its resources.

Risk management applies across all six domains identified in Policy 102 – Risk Management: information security and privacy, operational, financial, reputational, legal and compliance, and strategic. Whether the risk involves a data breach, a facility safety concern, a vendor contract, or a reputational issue, the same methodology applies.

Scope

This procedure applies to all risk assessments conducted within Grasslands Public Schools across the domains identified in Policy 102. It defines the standard risk scoring methodology (likelihood multiplied by impact, using 1 to 5 scales), the governance requirements for the risk registry, and the approval authorities for risk acceptance and compensating controls.

The operational procedures for conducting risk assessments (threat identification techniques, scoring walkthroughs, worksheets, and templates) are in IM-012 – Risk Assessment Guidance. This procedure establishes when assessments are required and who authorizes the results.

Definitions

Terms not defined in this procedure have the meanings assigned in Policy 310 – Information Security Charter and Policy 311 – Privacy and Access to Information.

Algorithm Impact Assessment (AIA): A structured evaluation of the risks associated with an automated decision-making system or a system that uses personal information to generate content, decisions, recommendations, or predictions. An AIA is required under POPA when a Privacy Impact Assessment is being prepared for a project that involves an automated system. Methodology is described in IM-012.

Automated system: A system that uses personal information to generate content or to make decisions, recommendations, or predictions about an individual. Includes generative AI tools, automated decision systems, and recommendation engines. The determination of whether a system is an automated system is operational, not definitional: if personal information is used in the manner described, the system is an automated system regardless of the underlying technology.

Compensating control: An alternative security measure implemented when a primary control cannot be applied. Compensating controls must provide equivalent or near-equivalent risk reduction and require documented justification. See §5 for examples.

Common system: As defined in A.P. 312, a system used across multiple schools or departments that supports standard operational needs.

Core system: As defined in A.P. 312, a system essential to Division-wide operations where failure would significantly disrupt educational delivery or administrative functions.

Cross-cutting infrastructure: Shared technology systems, platforms, and services that support multiple Division functions and are not assigned to a single System Owner (for example, network infrastructure, the Microsoft 365 tenant, the identity and access management environment, shared backup systems, endpoint management platforms). Where a specific application built on shared infrastructure has an assigned System Owner, the System Owner is responsible for that application's risk assessment; the Director of Technology is responsible for the underlying platform.

High-sensitivity personal information: As defined in the Protection of Privacy (Ministerial) Regulation, Alta Reg 143/2025, s.1: biometric information about an individual, financial information about an individual, or personal information respecting a minor, senior, or vulnerable individual. The list is not exhaustive; other categories may be high-sensitivity in context. Determination that a project involves high-sensitivity personal information triggers the enhanced requirements under M-Reg 143/2025 s.6(2) and a higher bar for accepting residual risk.

Impact: The magnitude of harm that would result if a threat were to exploit a vulnerability, scored on a 1 to 5 scale as defined in IM-012.

Inherent risk: The level of risk present before any controls are applied.

Innovative system: As defined in A.P. 312, a system being piloted or evaluated, typically at limited scale, before a decision on broader adoption.

Likelihood: The probability that a threat will exploit a vulnerability within a defined time period, scored on a 1 to 5 scale as defined in IM-012.

Residual risk: The level of risk remaining after controls have been applied.

Risk: The potential for loss or harm resulting from a threat exploiting a vulnerability, expressed as the product of likelihood and impact.

Risk acceptance: A documented decision to accept a residual risk without further mitigation, made by an authorized individual based on the risk score and the Division's risk tolerance.

Risk owner: The individual accountable for monitoring and managing a specific risk, typically the System Owner, or the Director of Technology for cross-cutting infrastructure risks.

Risk treatment: The process of selecting and implementing measures to modify risk. Treatment options are mitigate, transfer, avoid, or accept.

System: Any organized method (technology-based, paper-based, or a combination) used to collect, create, store, use, or disclose information in support of Division operations. This includes software applications, databases, spreadsheets, shared drives, paper filing systems, and manual processes. Where this procedure or its supporting documents refer to a system, the term carries this broad meaning unless the context clearly indicates otherwise.

Responsibilities

Superintendent

• Accountable for the Division's risk management framework and the risk registry.
• Delegates day-to-day registry maintenance to the Director of Technology.

System Owner

• Conducts risk assessments for systems, programs, or practices under their ownership.
• Documents risks at source and is accountable for the accuracy of the assessment.
• Proposes compensating controls when required controls cannot be implemented.

Director of Technology

• Provides training and methodology support.
• Reviews completed assessments for consistency.
• Conducts assessments for cross-cutting infrastructure.
• Maintains the risk registry on behalf of the Superintendent.
• Presents the risk registry summary to Senior Administration as required.

Access and Privacy Coordinator

• Reviews risk assessments involving personal information and advises on privacy-related threats, POPA obligations, and the interaction between risk assessments and Privacy Impact Assessments.
• Reviews and signs off on any Algorithm Impact Assessment conducted under this procedure before it is finalized.

Procedures

1. When risk assessments are required

1. A risk assessment shall be conducted when any of the following occur:
   1. A new Core or Common system, program, or practice is proposed under A.P. 312 – Technology Acquisition and Use. The risk assessment informs the acquisition approval and, where applicable, the Privacy Impact Assessment under IM-008.
   2. A Privacy Impact Assessment is being conducted for any system, program, or practice that processes personal information about minors or other high-sensitivity personal information as defined by Alta Reg 143/2025. Because Grasslands is a school division, virtually all student-facing systems (regardless of whether they are digital or paper-based) meet this threshold. The risk assessment is completed using the Risk Assessment Tool (IM-012A) and follows the methodology in IM-012. For PIAs that will be submitted to the Office of the Information and Privacy Commissioner, the risk assessment uses the OIPC-prescribed risk list (POPA PIA Template Section H and its appendices) as the starter set.
   3. A material change occurs to an existing system's architecture, data handling, vendor arrangements, or user population that could alter the system's risk profile.
   4. A security or privacy incident reveals previously unidentified threats or vulnerabilities. Post-incident risk reassessment is conducted as part of the post-incident review process under A.P. 321 – Information Security Incident Response.
   5. A vendor assessment or reassessment is conducted under A.P. 322 – Third-Party and Vendor Risk Management, using the scoring methodology established in this procedure.
   6. A periodic review cycle triggers reassessment. Core systems shall be reassessed at minimum every two years; Common systems every three years, aligned with the vendor reassessment cycle under A.P. 322.
   7. A significant change to the external threat landscape, applicable legislation, or organizational structure warrants reassessment, as determined by the Director of Technology.
   8. Senior Administration, the Board of Education, or the Access and Privacy Coordinator directs a risk assessment based on emerging concerns or audit findings.
   9. A project proposes to use an automated system that will process personal information to generate content or make decisions, recommendations, or predictions. In addition to the standard risk assessment and any applicable PIA, an Algorithm Impact Assessment is required, conducted using the methodology in IM-012. The AIA is a companion artefact to the PIA and is submitted with the PIA where OIPC submission is required.

2. Risk scoring and tolerance

2. The Division uses a 5-by-5 likelihood-by-impact matrix. Likelihood and impact are each scored from 1 to 5; the risk score is their product (1 to 25). The detailed scoring scales, worked examples, and assessment worksheets are defined in IM-012 – Risk Assessment Guidance.

3. The goal of risk treatment is to reduce residual risk to Moderate or below. Where residual risk remains High or Critical after treatment, the risk must be formally accepted at the appropriate approval level.
4. For risks involving high-sensitivity personal information (as defined in this procedure), the Division applies a more conservative tolerance. Acceptance of Moderate residual risk in this category may warrant Senior Administration sign-off at the Director of Technology's discretion.

3. Risk treatment options

5. Risk treatment shall select one or a combination of the following four options based on the residual risk score, the cost and feasibility of treatment, and the Division's tolerance for risk in the relevant domain:
   1. Mitigate: Reduce the likelihood or impact of the risk through additional controls. Mitigation is the default treatment for High and Critical risks and includes both primary controls (those required by Division policy or vendor standards) and compensating controls where primary controls are not feasible. Compensating controls are governed by §6.
   2. Transfer: Shift some or all of the financial consequences of the risk to a third party, typically through insurance or contractual provisions. The Division's cyber insurance policy with Marsh provides transfer for many information security and privacy risks; vendor contracts under A.P. 322 may include indemnification, liability caps, or breach notification obligations that transfer specific risks. Transfer does not eliminate the operational consequences of risk realization (for example, reputational harm, service disruption, or POPA compliance obligations); the Division retains accountability for these regardless of insurance coverage.
   3. Avoid: Choose not to undertake the activity, or discontinue an existing activity, that creates the risk. Avoidance is appropriate when residual risk after other treatment options remains Critical and acceptance is not warranted, or when the activity is not essential to Division operations. Examples include declining to acquire a system that cannot meet security or privacy requirements, retiring a system with unresolvable vulnerabilities, or restructuring a process to remove the high-risk component.
   4. Accept: Acknowledge the residual risk without further treatment. Acceptance is governed by §4 and requires authorization at the level appropriate to the residual risk score and system classification.
6. Risk treatment commonly combines multiple options. For example, a risk involving personal information may be partially mitigated through technical controls, partially transferred through cyber insurance, with the residual risk formally accepted at the appropriate authority level.
7. The selection of treatment options shall be documented in the risk assessment along with the rationale. Where treatment includes transfer, the specific instrument (insurance policy clause, vendor contract provision) shall be identified. Where treatment is avoidance, the alternative path (alternative system, alternative process, decision not to proceed) shall be documented.

4. Risk acceptance and authorization

8. Risk acceptance authority is determined by the residual risk level and the system classification:

9. Acceptance decisions shall be documented in the risk registry, including the rationale, the authorized individual, and the date of acceptance.

5. Risk registry

10. The Superintendent is accountable for the Division's risk registry. The Director of Technology maintains the registry on the Superintendent's behalf.
11. Risks scored as High (10 to 16) or Critical (17 to 25) shall be elevated to the risk registry during the acceptance process. Low and Moderate risks are managed by the System Owner within the source document and do not require elevation.
12. The registry schema (required fields, risk ID format, and entry procedures) is defined in IM-021 – Information Security Risk Registry.
13. The Director of Technology shall present a risk registry summary to Senior Administration annually. The summary shall include the total number of High and Critical risks, trends since the previous report, and risks with overdue treatment actions.
14. The risk registry is classified as Restricted under A.P. 313 – Data Classification.

6. Compensating controls

15. Where a required security or privacy control cannot be implemented due to technical, operational, or financial constraints, the System Owner may propose a compensating control as an alternative. Compensating controls must provide equivalent or near-equivalent risk reduction and are not permanent exceptions. The System Owner shall evaluate whether the original control becomes feasible at each annual review.
16. Compensating control approval authority is determined by system classification:

17. All approved compensating controls shall be recorded in the risk registry and reviewed at minimum annually.

Example. A.P. 326 – Technical Security Controls requires data loss prevention (DLP) controls on electronic messaging systems to prevent unauthorized transmission of Restricted or Confidential information. The Division's current email platform does not support native DLP policies. Rather than accept the risk without mitigation, the Director of Technology documents a compensating control: staff training on data classification and handling (per A.P. 313), combined with transport-layer encryption for all outbound email and restricted external sharing settings on the collaboration platform. The compensating control is recorded in the risk registry with a note that the original DLP requirement will be re-evaluated when the Division's messaging platform changes or gains DLP capability.

7. Risk monitoring and follow-up

18. The risk registry is a living document. Risks recorded in the registry shall be monitored throughout their lifecycle by the Risk Owner, with periodic review by the Director of Technology.
19. The Risk Owner shall:
    1. Monitor the risk as part of normal system or program operations.
    2. Notify the Director of Technology when the risk profile changes materially (likelihood or impact change, new threats identified, controls deteriorate, or environmental changes affect the risk).
    3. Track committed treatment actions to completion and report progress at least semi-annually to the Director of Technology.
    4. Initiate a formal reassessment when the periodic review cycle under §1 is reached or when a material change occurs.
20. The Director of Technology shall conduct a periodic review of all High and Critical risks in the registry at minimum every six months. The review shall:
    1. Assess whether the risk score remains accurate.
    2. Confirm that committed treatment actions are on track or identify reasons for delay.
    3. Identify risks eligible for de-escalation (where treatment has reduced the risk to Moderate or below).
    4. Identify risks where the original treatment plan has not been effective and re-treatment is warranted.
21. A risk shall be de-escalated from the registry when residual risk has been reduced to Moderate or below through completed treatment actions, verified by the Risk Owner and confirmed by the Director of Technology. De-escalation does not delete the risk record; it transitions the risk to the source document for ongoing management and retains the historical record in the registry.
22. Where a committed treatment action is overdue, the Director of Technology shall escalate to the original approval authority with a status update and either a revised timeline or a recommendation to revise the acceptance decision. Overdue treatment actions shall be reflected in the annual risk registry summary to Senior Administration.
23. Lessons learned from security and privacy incidents (per A.P. 321) and from operational incidents in other Policy 102 risk domains shall be reviewed against the risk registry to identify whether registered risks should be re-scored, whether new risks should be added, or whether treatment plans need revision. The lessons-learned feedback loop is operationalized through IM-019 – Security Improvement and Lessons Learned.

Review

This procedure shall be reviewed every three years by the Director of Technology, or earlier if triggered by:

• Significant changes to the Division's risk environment
• Changes to applicable legislation (POPA, ATIA, M-Reg 143/2025) or OIPC guidance
• Audit findings or incident lessons learned that warrant methodology adjustments
• Changes to Policy 102 or related Board policies
• Direction from Senior Administration or the Board of Education

Cross reference

• Policy 102 – Risk Management
• Policy 310 – Information Security Charter
• Policy 311 – Privacy and Access to Information
• A.P. 312 – Technology Acquisition and Use
• A.P. 313 – Data Classification
• A.P. 314 – IT Asset Management
• A.P. 320 – Information Access Control
• A.P. 321 – Information Security Incident Response
• A.P. 322 – Third-Party and Vendor Risk Management
• A.P. 323 – Privacy Management
• A.P. 324 – Access to Information
• A.P. 325 – Chain of Custody
• A.P. 326 – Technical Security Controls
• A.P. 327 – Security Awareness and Training
• A.P. 505 – Electronic Surveillance
• CG-002 – Privacy Management Program Overview
• CG-003 – Delegation of Authority Under POPA
• FM-001 – Server and Network Physical Security and Environmental Controls
• IM-008 – Privacy Impact Assessment Procedures
• IM-012 – Risk Assessment Guidance
• IM-013 – Vulnerability and Patch Management
• IM-019 – Security Improvement and Lessons Learned
• IM-021 – Information Security Risk Registry

Legal references

• Education Act, SA 2012, c E-0.3
• Protection of Privacy Act, SA 2024, c P-28.5
• Protection of Privacy (Ministerial) Regulation, Alta Reg 143/2025
• Access to Information Act, SA 2024, c A-1.4