Assessment Process
Last updated on March 14, 2024“Security Threat and Risk Assessment” (STRA) is the process of assessing security risk for a system at a point in time. The artifact which comes out of this process is the “Statement of Acceptable Risks” (SoAR).
A STRA MUST be conducted for all new information systems and be kept updated throughout an information system’s lifecycle. The STRA for an existing information system MUST be reviewed and updated whenever there are any significant or material change(s) and: previously identified risks reassessed and updated; and, new risks that are identified, documented. A review schedule MUST be maintained to ensure that STRAs are reviewed and re-evaluated throughout the life of an information system. The frequency of the STRA review MUST be based on maintaining the target risk level for the information system.
When a STRA is conducted, it MUST be based on the criticality of the information system and the information security classification of information stored and handled by the system. Service delivery units MUST engage, communicate, and consult with their respective Ministry Information Security Officer when an STRA is required. The scope of potential impact MUST be documented (e.g. impact to business unit, ministry only, parts of government or all of government, citizens, or other stakeholders). Information security risks MUST be assessed based on: how likely a threat will leverage an exposed security weakness (a.k.a vulnerability) or gap; and, the potential impact to the organization if the risk is realized.
Risk findings from the STRA activity MUST be recorded via an OCIO-approved tool. For each risk that is identified, a planned treatment or acceptance MUST be documented. Risks which require treatment after the completion of the risk assessment MUST be tracked in a risk register and managed. Ministries MUST not accept risks which are likely to have a corporate or government-wide impact. Such risks MUST be documented with a note indicating that the risk is corporate in nature and will be communicated to OCIO via the approved tool. At minimum, a STRA activity MUST result in a Statement of Acceptable Risks (SoAR) artifact that has been reviewed and signed by an accountable individual. All completed and signed SoARs MUST be submitted to the OCIO’s Cybersecurity and Digital Trust Branch. This constitutes the closure of an STRA.
The above process is articulated in the STRA Standard and further elaborated-on in the STRA Specifications. All government organizations (ministries, public agencies, boards, and commissions), service providers, and any other entity managing the Government of British Columbia’s information which is subject to Core Policy & Procedures Manual, Information Security Policy, and Information Security Standard, are also bound to comply with the STRA Standard.
At a high level, the STRA process is as follows:
A detailed flow chart can be used to guide the implementation of the STRA process within an organization. See here:
Security teams within Government of B.C. organizations may choose to augment with additional process and tools; however, these must not contradict or replace the OCIO-approved process and tools and must follow policy and standards. Care should be taken, as significant addition of process or tools can result in unnecessary inefficiencies and STRA backlogs which are not defensible. It is recommended to keep STRAs right sized to what is actually required and avoid complicating the activity so that it is possible to get through the completion of STRAs within reasonable timeframes.
For questions please contact: InfoSecAdvisoryServices@gov.bc.ca