Security Threat and Risk Assessment


What are Security Threat and Risk Assessments (STRA)?

STRAs are a type of assessment used by the BC public service to assess digital risks. This is a key supporting enabler for responsible digital government. STRAs are a snap-shot in time and raise the awareness of system security risks in an organization to a level at which risk-based decisions can occur effectively. STRAs are key to empowering management to make informed risk based decisions about information assets that are directly or indirectly under their control as part of their responsibilities and accountabilities. An STRA also documents risk ratings and planned treatments.

How are risks assessed in an STRA?

STRAs are accomplished by identifying how likely threats are to act on vulnerabilities (weaknesses) and what the potential impacts could mean to the business.

When should an STRA be conducted?

An STRA should be completed for each new system, or significant change to a system. 

How are STRAs iterated on as a system develops?

The workflow lifecycle of STRA iterations prior to the launch of a new system or significant changes into production includes the following stages:

  1. Initiation stage: STRA completed at the conceptual level
  2. Requirements stage: STRA update completed considering known requirements
  3. Design stage: STRA update completed considering system design
  4. Build stage: STRA update completed considering the system build as it will actually be implemented once in production
  5. Operational review stage: STRA update completed at minimum annually to address minor incremental changes which cumulatively could be significant

What is required for an STRA to be considered complete?

A signed Statement of Acceptable Risk (SOAR) constitutes the completion of an STRA. The SOAR documents all risks identified in the STRA, their ratings and planned treatment action, and that appropriate reviews and acceptance has occurred. SOAR guidelines are documented here.

What is the scope of an STRA?

STRA supporting activities should be scoped commensurate to the criticality and complexity of the system which is being assessed. The level of effort, diligence, and time spent on an STRA increases the more critical and complex a system is.

  • A qualitative and “lite” approach is acceptable for systems which are not critical. In this case, completing just a SOAR is acceptable provided it is evident that risks have been reasonably assessed and there are no noticeable gaps in the assessment.
  • It is recommended that a quantitative approach be taken for critical systems; there should be a body of evidence to support how risks were assessed and treatments were identified, and a “return on security investment” (ROSI) for each risk as part of this.

An STRA should consider and explain the likelihood and potential impact of risks, provide risk ratings, and identify planned treatments.

Treatment types can include:

  • Accepting risk as is
  • Remediating the risk (fix)
  • Mitigating the risk (reducing the risk)
  • Transferring the risk (e.g. insurance)
  • Avoiding the risk (make a change so the risk no longer applies)

STRAs can focus on applications (e.g. web, desktop, mobile), cloud services, operating systems, systems hardware, mobile devices (e.g. smartphone, tablet), and other digital technologies.

How long does it take to complete an STRA?

The time it takes to complete an STRA can vary; however, it is often achievable to complete an STRA in a short amount of time. The amount of time and effort spent on an STRA should be reasonably commensurate to what is being assessed.   

Is there a corporate process for completing STRAs?

Yes. An STRA assessment process has been published to support the collection of information which can then be an input to successfully complete a SOAR. BC public sector organizations are free to adapt their STRA supporting activities to meet their unique business needs.  Some organizations prefer to start the process by taking a threat modeling approach, while other organizations prefer to identify threats by working through pre-defined control sets.  Either approach is valid and acceptable.  At the end of the process ministries must be able to successfully complete a SOAR in the format provided by OCIO Enterprise Services.

Do contractors, vendors, and partners of core government need to complete STRAs?

Security requirements for contractors, vendors, and partners to core government are articulated by provisions in contract security schedules.

Do greater public sector entities in British Columbia, external to core government, need to complete STRAs?

It is a strongly recommended practice. Legislation and regulation does not specifically require STRAs, however, they do help to demonstrate “reasonable security” which is a requirement outlined in FOIPPA, Section 30. Greater public sector entities outside of core government may determine their own needs, requirements, and processes related to conducting STRAs from end-to-end. The Government of BC’s approach to STRAs can act as a good guide for greater public sector entities to model around. The Information Security Branch with OCIO Enterprise Services Division is happy to consult and provide recommendations and guidance.

What compels core government to complete STRAs?

Core government is mandated to complete STRAs as required by the Information Security Branch with the Office of the Chief Information Officer (OCIO), Information Security Policy (ISP), and Core Policy.  The practice of STRAs is also consistent with applicable legislation (e.g. FOIPPA) and risk management requirements set forth by the Risk Management Branch.

I am a Government of B.C. employee. Where can I find more information on STRAs?

Government of BC employees can learn more about STRAs on the intranet page for Security Threat and Risk Assessments.