case study for risk assessment

What Is a Case Study?

When you’re performing research as part of your job or for a school assignment, you’ll probably come across case studies that help you to learn more about the topic at hand. But what is a case study and why are they helpful? Read on to learn all about case studies.

At face value, a case study is a deep dive into a topic. Case studies can be found in many fields, particularly across the social sciences and medicine. When you conduct a case study, you create a body of research based on an inquiry and related data from analysis of a group, individual or controlled research environment.

As a researcher, you can benefit from the analysis of case studies similar to inquiries you’re currently studying. Researchers often rely on case studies to answer questions that basic information and standard diagnostics cannot address.

Study a Pattern

One of the main objectives of a case study is to find a pattern that answers whatever the initial inquiry seeks to find. This might be a question about why college students are prone to certain eating habits or what mental health problems afflict house fire survivors. The researcher then collects data, either through observation or data research, and starts connecting the dots to find underlying behaviors or impacts of the sample group’s behavior.

Gather Evidence

During the study period, the researcher gathers evidence to back the observed patterns and future claims that’ll be derived from the data. Since case studies are usually presented in the professional environment, it’s not enough to simply have a theory and observational notes to back up a claim. Instead, the researcher must provide evidence to support the body of study and the resulting conclusions.

Present Findings

As the study progresses, the researcher develops a solid case to present to peers or a governing body. Case study presentation is important because it legitimizes the body of research and opens the findings to a broader analysis that may end up drawing a conclusion that’s more true to the data than what one or two researchers might establish. The presentation might be formal or casual, depending on the case study itself.

Draw Conclusions

Once the body of research is established, it’s time to draw conclusions from the case study. As with all social sciences studies, conclusions from one researcher shouldn’t necessarily be taken as gospel, but they’re helpful for advancing the body of knowledge in a given field. For that purpose, they’re an invaluable way of gathering new material and presenting ideas that others in the field can learn from and expand upon.

• Privacy Policy
• Terms of Service
• © 2023 Ask Media Group, LLC

You are using an outdated browser. Please upgrade your browser to improve your experience.

Risk Assessment Case Studies | Machine Safety Specialists

Case studies.

Live Event: Open Enrollment for Machine Safety Specialists (MSS) Virtual Machine Safety and Risk Assessment Training Class. Click Here to enroll today!

What are “Unbiased Risk Assessments”?

Unbiased  Risk Assessments are guided by safety experts that have your best interests in mind.  Product companies, integrators, and solution providers may steer you toward expensive, overly-complex technical solutions.   Machine Safety Specialists provides unbiased Risk Assessments.   See examples below.

Biased  risk assessments can happen when a safety products company, integrator, or solution provider participates in the risk assessment. The participant has a conflict of interest and may steer you towards overly expensive or complex solutions that they want to sell you.  Some safety product companies will do anything to get involved in the risk assessment, knowing they will “make up for it” by selling you overly expensive solutions.  Safety product companies have sales targets and you could be one of them.

Machine Safety Specialists are experts in OSHA, ANSI, NFPA, RIA and ISO/EN safety standards. We can solve your machine safety compliance issues, provide  unbiased  Risk Assessments, or help you develop your corporate Machine Safety and Risk Assessment program.

Case Study: Machine Safety Verification and Validation

A multi-national food processing company had a problem.  A recent amputation at a U.S. food processing plant generated negative publicity, earned another OSHA citation, and caused significant financial losses due to lost production.  Another amputation, if it occurred, would likely result in more lost production, an OSHA crackdown, and, if posted on social media, irreparable damage to the company’s brand.

After multiple injuries and OSHA citations, the company contacted MSS for help.  First, the company needed to know if the existing machine safeguarding systems provided “effective alternative protective measures” as required by OSHA.  MSS was contracted through the company’s legal counsel to audit three (3) plants with various type of machines and deliver detailed Machine Safety compliance reports for each machine to the client under Attorney Client Privilege.  A summary in our safeguarding audit reports for one plant was as follows:

For the 19 high risk and 8 medium risk (poorly guarded) machines, action by applying risk reduction measures through the use of the hierarchy of controls was required.  MSS provided a Machine Safeguarding specification for the machines and worked with our client to select qualified local fabricators and integrators that performed the work in an aggressive schedule.  MSS provided specifications and consulting services, and our client contracted the fabrication and integration contractors directly, under the guidance of MSS.

During the design phase of the Machine Safeguarding implementation, MSS provided safety  verification services  and detailed design reviews.  Due to the stringent legal requirements and the need for global compliance, the safety design verification included  SISTEMA analysis  of the functional safety systems.  MSS provided a detailed compliance report with written compliance statements covering OSHA compliance, hazardous energy controls (Lockout/Tagout, LOTO, OSHA 1910.147) and effective alternative protective methods, per OSHA’s minor servicing exception.  Due to the complexity of the machines and global safety requirements, MSS verified and validated the machine to numerous U.S. and international safety standards, including ANSI Z244.1, ANSI B11.19, ANSI B11.26, ISO 14120, ISO 13854, ISO 13855, ISO 13857 and ISO 13849.

Then, after installation and before placing the machines into production, MSS was contracted to perform safety validation services as required by the standards.  During the validation phase of the project, MSS traveled to site to inspect all machine safeguarding and validate the functional safety systems.  This safety validation included all aspects of the safety system, including barrier guards, interlocked barrier guards, light curtains, area scanners, the safety controllers and safety software, safety servo systems, variable frequency safety drives (safety VFDs), and pneumatic (air) systems.

After the machine safeguarding design verification, installation, and safety system validation, MSS was pleased to provide the following data in the executive summary of the report.

By involving Machine Safety Specialists (MSS) early in the project, we can ensure your project complies with OSHA, ANSI/RIA, NFPA and ISO safety standards.  By helping you implement the project, we kept the safety project on-track.  Our validation testing and detailed test reports provide peace of mind, and evidence of due diligence if OSHA pays you a visit.   Contact MSS  for all of your Machine Safety Training, Safeguarding Verification, and on-site functional safety validation needs.

Case Study:  Collaborative Robot System

• Is this Collaborative Robot system safe?
• How can we validate the safety of the Collaborative Robot system before duplicating it?
• If we ship these globally, will we comply with global safety standards?
• What if the Collaborative Robot hurts someone?
• What about OSHA?

The OEM called Machine Safety Specialists (MSS) to solve these concerning problems.   Prepared to help, our TÜV certified Machine Safety engineers discussed the Collaborative Robot system, entered an NDA, and requested system drawings and technical information.  On-site, we inspected the Collaborative Robot, took measurements, gathered observations and findings, validated safety functions, and spoke with various plant personnel (maintenance, production, EHS, engineering, etc.).  As part of our investigation, we prepared a gap analysis of the machine relative to RIA TR R15.606, ISO 10218-2, OSHA, ANSI, and ISO standards.  The final report included Observations, Risk Assessments, and specific corrective actions needed to achieve US and global safety compliance.   Examples of our findings and corrective actions include:

• Identification of the correct safeguarding modes (according to RIA TR R15.606-2016 and ISO/TS 15066-2016).
• Observation that Area Scanners (laser scanners) provided by the machine builder were not required, given the Cobot’s modes of operation. Recommended removal of the area scanners, greatly simplifying the system.
• Observation that the safety settings for maximum force, given the surface area of the tooling, provided pressure that exceeds US and global safety requirements. Recommended a minimum surface area for the tooling and provided calculations to the client’s engineers.
• Observation that the safety settings for maximum speed were blank (not set) and provided necessary safety formulas and calculations to the client’s engineers.
• Recommended clear delineation of the collaborative workspace with yellow/black marking tape around the perimeter.

With corrective actions complete, we re-inspected the machine and confirmed all safety settings.  MSS provided a Declaration of Conformance to all applicable US and global safety standards.  The customer then duplicated the machines and successfully installed the systems at 12 plants globally, knowing the machines were safe and that global compliance was achieved.   Another success story by MSS…

[drawattention ID=”5446″]

Case Study:  Robot Manufacturing

The manufacturer hired a robotics integrator and a brief engineering study determined that speed and force requirements required a high-performance Industrial Robot (not a  Cobot ).  The client issued a PO to the integrator, attached a manufacturing specification, and generically required the system to meet “OSHA Standards”.  Within 3 months, the robot integrator had the prototype system working beautifully in their shop and was requesting final acceptance of the system.   This is when the second problem hit –  the US manufacturer experienced a serious robot-related injury .

In the process of handling the injury and related legal matters, the manufacturer learned that generic “OSHA Standards” were not sufficient for robotic systems.  To prevent fines and damages in excess of $250,000, our client needed to make their existing industrial robots safe, while also correcting any new systems in development.   The manufacturer then turned to Machine Safety Specialists (MSS) for help.

Prepared to help, our TÜV certified and experienced robot safety engineers discussed the Industrial Robot application with the client.  MSS entered an NDA and a formal agreement with the client and the client’s attorney.  On-site, MSS inspected the Industrial Robot system, took measurements, gathered observations and findings, tested (validated) safety functions, and met with the client’s robotics engineer to complete a compliance checklist.   As part of our investigation, we prepared a Risk Assessment in compliance with ANSI/RIA standards, an RIA compliance matrix, and performed a gap analysis of the industrial robot systems relative to ANSI/RIA standards.  The final report included a formal Risk Assessment, a compliance matrix, our observations, and specific corrective actions needed to achieve safety compliance.

Examples of our findings and corrective actions included:

• A formal Risk Assessment was required in compliance with ANSI/RIA standards (this was completed by MSS and the client as part of the scope of work).
• Critical interlock circuity needed upgrading to Category 3, PL d, as defined by ISO-13849. (MSS provided specific mark-ups to the electrical drawings and worked with the integrator to ensure proper implementation).
• The light curtain reset button was required to be relocated. (MSS provided specific placement guidance.)
• The safeguarding reset button was required to be accompanied by specific administrative. (MSS worked with the integrator to implement these into the HMI system and documentation).
• The robot required safety soft limits to be properly configured and tested (Fanuc: DCS, ABB: SafeMove2).
• Specific content needed to be added to the “Information for Use” (operation and maintenance manuals).

With corrective actions complete, MSS re-inspected the machine, verified safety wiring, validated the safety functions and provided a Declaration of Conformance for the robot system. The customer then accepted the system, commissioned, and placed it into production.  The project was then deemed a huge success by senior management.   The industrial robot system now produces high-quality assemblies 24/7, the project team feels great about safety compliance, and the attorneys are now seeking other opportunities.   Another success story by MSS…

Case Study: Manufacturing Company

Another question….

Q:  Which safety product company do we trust to perform a risk assessment with your best interest in mind? A:  None of them. Companies selling safety products have a hidden agenda – sell the most products and charge insane dollars for installation! Machine Safety Specialists are safety engineers and consultants who have your best interest in mind. We will conduct an unbiased Risk Assessment and recommend the most sensible, lowest cost, compliant safeguards on the market – with no hidden sales agenda!

Case Study: Machine Safeguarding Example

One photo, two points of view…., safety product company recommendation:.

“Wow – This Customer needs $50K of functional safety equipment on each machine. Add light curtains, safety system, software, etc….”.   Problem solved for $50,000.

MSS Recommendation:

“Bolt down the existing guard, add end cap, remove sharp edges and secure the air line. Add a warning sign with documented training….”.  Problem solved for $50.   Once again, this really happened  – don’t let it happen to you !

Case Study: Risk Reduction

“machine safety specialists’ comprehensive approach to  risk reduction ensured the most complete, sensible, and least expensive solution for compliance” – safety manager.

Green Circle (right): We use all methods of Risk Reduction (elimination, signs, training) – not just guards and protective devices. This is the least expensive and most comprehensive approach. Red Circle (right): Guarding company methods of risk reduction (guards and protective devices) are very expensive, time consuming, and do not mitigate all of the risk.

Case Study - Why Perform a Risk Assessment?

Another frequently asked question is: “ Why do I need a Risk Assessment?” To answer this, please see Case Study: “ Applicable U.S. Machine Safety Codes and Standards”, then please see below… Why Perform a Risk Assessment? A written workplace hazard assessment is required by law.  In section 1910.132(d)(2), OSHA requires a workplace hazard analysis to be performed.  The proposed Risk Assessment fulfils this requirement with respect to the machine(s).

1910.132(d)(2): “The employer shall verify that the required workplace hazard assessment has been performed through a written certification that identifies the workplace evaluated; the person certifying that the evaluation has been performed; the date(s) of the hazard assessment; and, which identifies the document as a certification of hazard assessment.”

A Risk Assessment (RA) is required by the following US standards:

• ANSI Z244.1
• ANSI B11.19
• ANSI B155.1
• ANSI / RIA R15.06

Please note the following excerpt from an actual OSHA citation :

“The machines which are not covered by specific OSHA standards are required under the Occupational Safety and Health Act (OSHA Act) and Section 29 CFR 1910.303(b)(1) to be free of recognized hazards which may cause death or serious injuries.”

In addition, the risk assessment forms the basis of design for the machine safeguarding system.  The risk assessment is a process by which the team assesses risk, risk reduction methods, and team acceptance of the solution.  This risk reduction is key in determining the residual risks to which personnel are exposed.  Without a risk assessment in place, you are in violation of US Safety Standards, and you may be liable for injuries from the un-assessed machines.

Contact Us Today for your Free Risk Assessment Spreadsheet

Download your Free Risk Assessment Spreadsheet

ANSI/RIA Risk Assessment Spreadsheet-Enhanced Three State

Case Study:  Applicable U.S. Machine Safety Codes and Standards

We are often asked: “What must I do for minimum OSHA compliance at our plant?  Do I have to follow ANSI standards?  Why?” The following information explains our answer… Please note the following excerpt from an actual OSHA citation:

 “These machines must be designed and maintained to meet or exceed the requirements of the applicable industry consensus standards.  In such situations, OSHA, may apply standards published by the American National Standards Institute (ANSI), such as standards contained in ANSI/NFPA 79, Electrical Standard for Industrial Machinery, to cover hazards that are not covered by specific OSHA standards .”

  U.S. regulations and standards used in our assessments include:

• OSHA 29 CFR 1910, Subpart O
• Plus, others as applicable….

Please note the following key concepts in the U.S. Safety Standards:

• Control Reliability as defined in ANSI B11.19 and RIA 15.06
• Risk assessment methods in ANSI B11.0, RIA 15.06, and ANSI/ASSE Z244.1
• E-Stop function and circuits as defined in NFPA 79 and ANSI B11.19
• OSHA general safety regulations as defined in OSHA 29 CFR 1910 Subpart O – Section 212
• Power transmission, pinch and nip points as defined in OSHA 29 CFR 1910 Subpart O -Section 219
• Electrical Safety as defined in NFPA 79 and ANSI B11.19.

Note:  OSHA is now citing for failure to meet ANSI B11.19 and NFPA 79 .

Telephone: (740) 816-9178 E-mail: [email protected]

Contact Us Today – We Can Be There Tomorrow!

• Work E-mail *

Live Event:

I am interested in:.

• Machine Safety Audits and Risk Assessments
• Functional Safety and Control Reliability Design Reviews (Verification)
• Stop-time Measurement
• Instructor Lead Training (ILT)
• Online Instructor Lead Training (ILT)
• E-Learning Courses and Certificate Program
• Machine Safeguarding Plans
• SISTEMA Analysis
• Safety System Testing (Validation) and Testing Procedures
• Industrial or Collaborative Robot Safety
• Machine Safeguarding Specification
• Consulting and Expert Witness
• Machine SafetyProTM - Mobile Risk Assessment Software
• Free Risk Assessment Spreadsheet
• En-Tronic FT-50 / FT-100 Parts
• Safety Signs and Labels
• Safety Sign/Label Assessment
• Where did you hear about Machine Safety Specialists?
• Upload Machine Photos Drop files here or Select files Max. file size: 300 MB. empty to support CSS :empty selector. --> Photo Uploads: Please upload photos of machines to evaluate here and provide any additional instructions in the Message field

P.O. Box 1111 Sunbury, OH 43074-9013

An official website of the United States government

The .gov means it's official. Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you're on a federal government site.

The site is secure. The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

• Publications
• Account settings
• Browse Titles

NCBI Bookshelf. A service of the National Library of Medicine, National Institutes of Health.

National Research Council (US) Committee on Risk Assessment Methodology. Issues in Risk Assessment. Washington (DC): National Academies Press (US); 1993.

Issues in Risk Assessment.

• Hardcopy Version at National Academies Press

Appendix E Case Studies and Commentaries

Case study 1: tributyltin risk management in the united states.

R. J. Huggett and M. A. Unger, Virginia Institute of Marine Sciences

Tributyltin (TBT) is a chemical with a variety of biocidal applications, including use as an antifouling agent in boat paints (Blunden and Chapman, 1982). Biological effects of TBT on marine and estuarine organisms and the concentrations of TBT that induce them vary widely among species (Huggett et al., 1992). A water concentration of 1,000 ng/L (1 part per billion) is lethal to larvae of some species, and nonlethal effects have been observed at concentrations as low as 2 ng/L (2 parts per trillion, ppt). Both laboratory and field studies of toxicity were initially hampered by difficulties in measuring the low concentrations that were toxic to some organisms.

Adverse effects on nontarget organisms, including commercially valuable species of shellfish, were observed in Europe in the early 1980s (Alzieu, 1986; Abel et al., 1986). Abnormal shell growth was documented in Crassostrea gigas (European oyster) and linked through laboratory experiments to TBT leached from antifouling paints. That connection led to restrictive regulations in France (in 1982) and Great Britain (in 1985 and 1987). In the United States, concentrations exceeding those determined experimentally to be effective have been found in many areas, particularly in harbors with large marinas. Snails in the vicinity of a marina on the York River, Virginia, were shown to have an abnormally high incidence of imposex (expression of male characteristics by female organisms), an effect previously observed under laboratory conditions in female European oysters, Ostrea edulis (Huggett et al., 1992). EPA began to assess effects of TBT in 1986, but has not yet issued any regulations. Meanwhile, restrictive actions have been taken by states and by the Congress.

A proposal by the U.S. Navy to use TBT paints on its entire fleet was prohibited by Congress in 1986, despite a Navy study that predicted no adverse environmental impact. Virginia enacted legislation and an emergency regulation in 1987, and Maryland, Michigan, and other states have since taken similar actions. Congress enacted national legislation restricting use of TBT paints in 1988. Those actions generally banned or restricted the use of TBT paints on small boats (less than 25 m long) and placed limits on leaching rates from paints used on larger vessels. Studies in Virginia had shown that most TBT releases were from small boats. Small-scale monitoring studies (e.g., in France and Virginia) have shown that the restrictions have been effective in reducing environmental concentrations and adverse impacts of TBT.

Risk management of TBT has been unusual in several ways. The initial basis for concern was field observation of adverse effects, not extrapolation from laboratory bioassays and field chemistry data. Risk assessment and risk management were conducted by state agencies and legislatures, rather than by EPA. Although the risk assessments were made without formalized methods, the results of the independent assessments were the same. Finally, TBT is the first compound banned by the Congress and the first regulated for environmental reasons alone.

(Led by L. Barnthouse, Oak Ridge National Laboratory, and P. F. Seligman, Naval Ocean Systems Center)

The case study addressed, with differing completeness, each of the five recommended steps in risk assessment and management. Hazard identification included the observation of abnormalities in the field and the same effects in experimentally exposed animals. Dose-response identification included data both from the field (correlative) and from the laboratory (experimental). Exposure assessment was based on estimated use and release rates rather than on monitoring or modeling studies. Risk characterization was only qualitative; it did not address such issues as the number and distribution of species that were vulnerable, or the degree of damage to the shellfish industry. Risk management actions were based on the demonstrable existence of hazard, on societal concern for the vulnerable species, and on the ready availability of alternative antifouling agents.

Some workshop participants were critical of the risk assessment approach adopted by Congress and state regulatory agencies. No attempt was made to plan and execute a formal risk assessment. Risk identification was based primarily on data on nonnative species. The Eastern oyster and blue crab, the species putatively at greatest risk, have been found to be less sensitive. Regulatory responses were based on findings of high environmental concentrations of TBT in yacht harbors and marinas, rather than in ecologically important regions such as breeding grounds. The central issue is whether a safe loading capacity (environmental concentration) of TBT for nontarget organisms can be defined, given substantially reduced rates of input. Recent information on fate and persistence, chronic toxicity, and dose-response relationships could support a more quantitative risk assessment with the possibility of more or less stringent restrictions.

CASE STUDY 2: Ecological Risk Assessment for Terrestrial Wildlife Exposed to Agricultural Chemicals

R. J. Kendall, Clemson University

The science of ecological risk assessment for exposure of terrestrial wildlife to agricultural chemicals has advanced rapidly during the 1980s. EPA requires detailed assessments of the toxicity and environmental fate of chemicals proposed for agricultural use (EPA, 1982; Fite et al., 1988). Performance of an ecological risk assessment requires data from several disciplines: analytical toxicology, environmental chemistry, biochemical toxicology, ecotoxicology, and wildlife ecology.

Addressing the ecological risks associated with the use of an agricultural chemical involves a complex array of laboratory and field studies—in essence, a research program. This paper provides examples of integrated field and laboratory research programs, such as The Institute for Wildlife and Environmental Toxicology (TIWET) at Clemson University. Preliminary toxicological and biochemical evaluations include measurements of acute toxicity (LC 50 and LD 50 ), toxicokinetics, and observations of wildlife in areas of field trials. Assessment of reproductive toxicity includes studies with various birds and other wildlife, particularly European starlings that nest at high densities in established nest boxes; these studies include measurements of embryo and nestling survival, postfledgling survival, behavior, diet, and residue chemistry (Kendall et al., 1989). Nonlethal assessment methods include measurement of plasma cholinesterase activity associated with organophosphate pesticide exposures (Hooper et al., 1989). A wide variety of birds, mammals, and invertebrates have been used in these studies.

End points evaluated in wildlife toxicological studies include mortality, reproductive success, physiological and biochemical changes, enzyme impacts, immunological impairment, hormonal changes, mutagenesis and carcinogenesis, behavioral changes, and residues of parent compounds and metabolites (Kendall, 1992).

The paper includes a case history of a comparative evaluation of Carbofuran and Terbufos as granular insecticides for control of corn rootworms. Carbofuran has been responsible for many incidents of wildlife poisoning and is recognized as being very hazardous to wildlife. In contrast, although Terbufos is highly toxic to wildlife in laboratory studies, exposure of wildlife under field conditions appears generally to be relatively low, and widespread mortality is not evident. Field studies of Terbufos conducted by TIWET might be the only ones conducted to date that satisfy EPA's requirements for a Level 2 field study, a more quantitative assessment of the magnitude of the effects of a pesticide than the qualitative Level 1 studies. (Level 2 studies are performed when toxicity tests and use patterns suggest a detailed study is warranted.) Data generated in those studies support an ecological risk assessment for Terbufos that is reported in the paper. However, the research program on Terbufos represents many years of effort with integration of laboratory and field research to achieve a full-scale level 2 study in just one geographic area on one crop. Ecological modeling techniques will be needed to generalize the results to other chemicals or to other situations.

(Led by B. Williams, Ecological Planning and Toxicology, Inc., and J. Gagne, American Cyanamid Company)

Dr. Williams noted that each step in ecological risk assessment is more complex and less understood than the corresponding step in human health risk assessment. Although hazard can be assumed when a toxic chemical is released, the species and populations at risk must first be defined. The appropriate selection of surrogate species for testing in the laboratory is usually unclear. Measurement of environmental concentrations is only the first step in exposure characterization. Exposure assessment also requires consideration of foraging behavior, avoidance, and food-web considerations, as well as spatial and temporal variability. Risk characterization involves comparison of exposure estimates with measures of hazard; this process might result in compounding of errors. Ecological risk assessments do not track individuals over time and so do not accurately reflect population changes.

The activities presented in the case study have a large research component, which is focused on dose-response assessment and exposure assessment. One discussant characterized risk assessment, as presented in the case study, as a retrospective exercise based on focused characterization of hazard and exposure in wildlife. Given the difficulties in conducting environmental risk assessments, the four-part paradigm might not be applicable at levels of organization above that of the population.

CASE STUDY 3A: Models of Toxic Chemicals in the Great Lakes: Structure, Applications, and Uncertainty Analysis

D. M.DiToro, Hydroqual, Inc.

This paper reviewed and summarized efforts to model the distribution and dynamics of toxic chemicals in the Great Lakes, with applications to PCBs, TCDD, and other persistent, bioaccumulated compounds. The models were based on the principle of conservation of mass (Thomann and Di Toro, 1983). Analysis proceeded through five steps: water transport, dynamics of solids, dynamics of a tracer, dynamics of the toxicant, and bioaccumulation in aquatic organisms. Mechanisms considered include settling, resuspension, sedimentation, partitioning, photolysis, volatilization, biodegradation, growth, respiration, predation, assimilation, excretion, and metabolism. The model of toxicant dynamics considered three phases (sorbed, bound, and dissolved) in each of two media (water column and sediments) and 21 pathways into, out of, or between these phases. The model of bioaccumulation included 25 compartments (four trophic levels with one to 13 age classes at each level) with five pathways into or out of each compartment. Because of the large number of coefficients (rate constants), sparseness of knowledge of inputs, and little opportunity for field calibration, uncertainty analysis was important in all the modeling exercises.

The first example modeled the dynamics of total PCBs in Lake Michigan (Thomann and Connolly, 1983). Plutonium-239 was used as a tracer to analyze sediment dynamics, and the model suggested that resuspension is an important mechanism. Calculation of PCB concentrations was limited by an order-of-magnitude uncertainty in the mass loading. Predictions of PCB concentrations and their rate of decline were sensitive to the value assumed for the mass-transfer coefficient for volatilization.

The second example modeled TCDD in Lake Ontario and attempted to predict the relationship between one source of input and the resulting incremental concentrations of TCDD (Endicott et al., 1989). In the absence of knowledge of other inputs, field data could not be used to calibrate the model. Hence, a formal uncertainty analysis was performed with Monte Carlo methods and assumed probability distributions of the rate coefficients. The 95% confidence limits of predicted TCDD concentrations in water and sediment differed by a factor of 10-100. Uncertainties in rate constants for photolysis and volatilization were the most important sources of uncertainty in predicted TCDD concentrations.

The third example extended the Lake Ontario TCDD model to eight other hydrophobic chemicals and incorporated a food-chain model to predict concentrations in lake trout (Endicott et al., 1990). The model predicted wide differences in toxicant concentrations, depending primarily on the degree of hydrophobicity as indexed by the octanol-water partition coefficient, Kow. The range of uncertainty in the predicted concentrations also varied among the chemicals. In-lake removal processes (sedimentation, volatilization, and degradation) were important for all chemicals.

CASE STUDY 3B: Ecological Risk Assessment of TCDD and TCDF

M. Zeeman, U.S. Environmental Protection Agency

This paper is based on a full-scale ecological risk assessment of chlorinated dioxin and furan emissions from paper and pulp mills that use the chlorine bleaching processes (Schweer and Jennings, 1990). Although the risk assessment addressed potential risks to terrestrial and aquatic wildlife exposed to TCDD and 2,3,7,8-tetrachlorodibenzofuran (TCDF) via a number of environmental pathways, the case study was limited to exposure of terrestrial wildlife to TCDD resulting from land disposal of paper and pulp sludges. This route of exposure was identified as one of the most hazardous in the multiroute risk assessment.

The specific exposure pathway considered was uptake of TCDD by soil organisms (earthworms and insects) from soil to which pulp sludge has been applied, and the consumption of soil organisms by birds and other small animals. Transfer factors were estimated both by modeling and from data collected in a field study in Wisconsin, in which an average soil TCDD concentration of 11 ppt led to concentrations of up to 140 ppt in a composite of six robin eggs. The models used three alternative sets of assumptions: low estimate, best estimate, and high estimate. The best estimates of tissue concentrations derived from the model were often similar to those observed in the field study: the low and high estimates were lower and higher, respectively, by a factor of roughly 10.

Risk estimates for terrestrial wildlife were derived by comparing exposure estimates (usually converted to daily intake rates) with benchmark toxicity values. The values used as benchmarks were either lowest-observed-adverse-effect levels (LOAELs) or no-observed-adverse-effect levels (NOAELs) for reproductive toxicity in birds and mammals —specifically, the lowest reported LOAELs and NOAELs. The risk quotient (RQ) for each species considered was defined as the ratio of the estimate of exposure to the corresponding benchmark value. On the basis of transfer estimates for land disposal of paper sludges, RQs could exceed 60:1 for the most exposed species (robins, woodcocks, and shrews). To estimate soil concentrations of TCDD ''safe" for these species, two uncertainty factors of 10 could be applied: one to allow for interspecies variability in sensitivity and one for an extrapolation from laboratory to field and/or the use of a LOAEL as the benchmark value. The corresponding estimates of safe concentrations were estimates that would lead to RQs less than 0.01:1 for the most heavily exposed species considered. Under those assumptions, soil concentrations of TCDD safe for highly exposed species would be about 0.03 ppt.

Led by L. A. Burns, U.S. Environmental Protection Agency, and D. J. Paustenbach, McLaren/Hart)

These case studies present only estimates of environmental concentrations—i.e., exposure assessment—and do not address other elements of risk assessment. Compared with traditional human health assessments, they show a greater concern for accuracy (as opposed "policy-driven conservatism"), a greater use of formal uncertainty analysis, and better opportunities for verifying accuracy of exposure and uptake models.

Criticism of the models focused on the omission of processes and on the assumed linear relationship between loading and environmental concentrations. Omitted processes include in-lake generation of solids (phytoplankton), transport in the benthic boundary layer, effects of water clarity on photolysis rates, and daily cycles in pH. A nonlinear relationship between loading and toxicant concentrations might occur if the toxicant reaches high enough concentrations to change the processes that control its own fate. For example, reduction in fish populations might allow for higher populations of zooplankton, which clarify the water column by decreasing populations of phytoplankton, thereby increasing photolysis rates and stabilizing pH.

CASE STUDY 4: Risk Assessment Methods in Animal Populations: The Northern Spotted Owl as an Example

D. R. Anderson, U.S. Fish and Wildlife Service

This paper described an analysis of northern spotted owl population dynamics performed to support ongoing studies of the impacts of clear-cutting of old-growth forest on the prospects for future survival of this endangered species (Salwasser, 1986). The paper summarized a method for estimating rates of population increase or decrease based on capture-recapture techniques and illustrates the methods with data on the northern spotted owl. The method proceeds in three steps: use of capture-recapture data to estimate age-specific survival or fecundity rates, estimation of the finite rate of population change (Leslie's parameter ), and experiments on samples of marked animals in natural environments. Mathematical models for estimating population parameters, including , have been developed extensively, and computer programs are available (Burnham et al., 1987). Experimental studies are desirable to test hypotheses about relationships between population parameters and risk factors.

The case study was of a population of northern spotted owls in California studied for 6 years (Franklin et al., 1990). Capture-recapture data yielded estimates of age-specific survival and fecundity for females, as well as estimates of mean population size (37 females) and annual recruitment (0 to 19 females; mean, 8). On the average, the eight females entering the population each year would have included six immigrants from outside the study area and only two locally raised recruits. The calculated value of was 0.952 ± 0.028, which indicated a decreasing population.

In this case, the risk factor was clearance of the old-growth forest on which the species is believed to depend. Although the study area contained much suitable habitat, the population appeared not to be self-sustaining, but to be maintained by immigration from remaining areas of old-growth. It was suggested that the study population is temporarily above the long-term carrying capacity because of the drastic loss of habitat in surrounding areas; these circumstances lead to a large "floating" component of the population.

The paper concluded that risk assessment in higher vertebrate populations must often rely on analysis of samples of marked individuals. A robust theory exists for study design and the analysis of such data. Selection of appropriate models is critical for rigorous assessment of impacts. Analysis of capture-recapture data allows inferences about the separate processes of birth, death, emigration, and immigration. Risk to a population does not affect population size directly; rather, it acts on the fundamental processes of birth and death.

(Led by M. E. Kentula, U.S. Environmental Protection Agency, and O. L. Loucks, Miami University)

Dr. Kentula commented that the case study (like others in the workshop) focused on individuals and populations and thus took a bottom-up approach. An alternative, top-down approach is to conduct an ecosystem risk assessment from a landscape perspective. For example, Kentula stated that EPA's Wetlands Research Program is developing methods to assess impacts on landscape function due to cumulative wetlands loss (Abbruzzese et al., 1990). The method proceeds in two-stages: a landscape characterization map is used to classify and rank units of the landscape according to relative risk, and can also be used to set priorities for effort and allocation of resources; a response curve expresses the hypothesized relationship between stressors (such as loss or modification of wetlands) and reduction in landscape functions (e.g., maintenance of water quality, or life support). The system can be used both to identify areas at risk and to guide management decisions for landscapes that are already affected.

Dr. Loucks commented that the case study presents the consequences of the stress to one local owl population at one time. For assessment of risk to the regional or total population, one would need to construct a "dose-response" relationship, in which "dose" would be a measure of the degree of stress (e.g., the percentage of the old-growth forest that has been destroyed) and "response" would be the probability of extinction of the population within an appropriate period (e.g., 250 years). Calculation of the probability from the birth, death, and dispersal rates estimated in the case study would require stochastic population modeling that takes account of uncertainty and variability in the population parameters.

The Endangered Species Act is an example of preemptive risk management, in that a high probability of extinction of a single species is designated as unacceptable. A species-by-species approach, however, does not lead to quantitative assessment of the risk of impoverishment of an ecosystem. Where possible, ecological risk assessment should work across levels of organization and should assess risks of reduction in system utility.

CASE STUDY 5: Ecological Benefits and Risks Associated with the Introduction of Exotic Species for Biological Control of Agricultural Pests

R. I. Carruthers, USDA Agricultural Research Service

The accidental or deliberate introduction of exotic species into regions where they are not native can cause positive, negative, or no observable effects, depending on a wide variety of biological, sociological, economic, and other factors. About 40% of the major arthropod pests (Sailer, 1983) and 50-75% of weed species (Foy et al., 1983) in the United States are introduced species, and introduced pests also include vertebrates, mollusks, and disease organisms that affect animals and plants. Many countries have developed formal programs to limit the introduction and establishment of unwanted exotic organisms, and many have developed methods to assess benefits and risks associated with planned introductions. The United States has no federal statute or set of statutes that governs introductions; instead, it has cumbersome and sometimes conflicting regulations, protocols, and guidelines.

This paper addressed assessment of risks and benefits of "classical biological control" (CBC): the planned introduction of exotic enemies of an introduced pest collected from the pest's home range (DeBach, 1974). Classical biological control (either alone or integrated with other pest management methods) has frequently been successful in controlling introduced pests and often provides large economic or environmental advantages over alternative methods. An example given in the paper is control of the alfalfa weevil: introduction and widespread releases of 11 species of parasitic hymenoptera have yielded substantial control of this major pest with no known negative side effects and with an estimated benefit-to-cost ratio of 87:1.

Risks of CBC programs have three different sources: the organism itself (e.g., parasitism or predation on nontarget species), associated organisms (e.g., pests of the introduced beneficial organism), and unrelated passenger organisms arriving with shipments of the introduced organism. Some adverse effects of all three types have been documented (Pimentel et al., 1984, Howarth, 1991), including local extinctions of nontarget species, especially in island situations. Although there is little documentation of notable adverse impacts of CBC programs in the United States, more precise prediction of benefits and risks would be desirable. Unfortunately, accurate prediction of both positive and negative impacts (target and nontarget effects) of CBC programs has not been achieved. The lack of predictive ability leaves CBC risk assessments in the realm of informed scientific judgment-based on limited published data.

In addition to requirements of various federal laws, guidelines have been developed to improve safety in CBC. Agricultural Research Service protocols (now under revision) require federal permits for importation and movement of organisms, quarantine, authoritative identifications, environmental and safety evaluations, documentation of movements and releases, and retention of voucher specimens. Current policy requires an environmental assessment (EA) to accompany applications for permits for field release of exotic organisms. Although the components of an EA depend on the specific situation, the documentation required is fairly extensive. At any step in the process, a proposed introduction can be deemed inappropriate and the project terminated.

(Led by J. T. Carlton, Williams College, and D. Policansky, National Research Council)

Classical biological control is only one kind of introduction of nonnative species. Others include range expansions (either natural or mediated by human modification of habitats), deliberate introductions to "improve nature" or for aquaculture or horticulture, and a wide variety of accidental introductions. CBC seems to have a better safety record than other types of introduction. It is not clear whether this is because the activity is basically benign, because the safety precautions work well, or because CBC involves small organisms that pose smaller risks than larger organisms. The worst failures in all categories have occurred in insular environments such as islands and lakes.

The assessment of risks posed by introductions has been addressed separately by scientists in different disciplines (e.g., agriculture, freshwater and marine ecology, and nature conservation). Communication between the disciplines is poor, and several sets of criteria, procedures, and protocols have been developed independently. Whereas the U.S. Department of Agriculture has adopted flow charts as a way to systematize decision-making, other agencies (e.g., the International Council for the Exploration of the Sea) have concluded that too little is known about ecosystem functioning for flow charts to be useful.

Dr. Policansky commented that risk assessment for species introductions is difficult to fit into the four-step Red Book paradigm. Hazard is taken for granted (because it is the introduction of the species itself); dose-response and exposure are yes-no categories, not continuous variables, because the more important point is whether the species is present or not, not how much of the species is present. A more suitable paradigm might be that presented in the 1986 NRC report Ecological Knowledge and Environmental Problem-Solving: Concepts and Case Studies , which placed more emphasis on problem-scoping and problem-solving than on categorical activities.

CASE STUDY 1: Uncertainty and Risk in an Exploited Ecosystem: A Case Study of Georges Bank

M. J. Fogarty, A. A. Rosenberg, and M. P. Sissenwine, National Marine Fisheries Service

This paper addressed the risks of overexploitation of harvested marine ecosystems, with specific application to Georges Bank, a highly productive area off the northeastern United States. In this context, risk assessment involves determining the probability that a population will be depleted to an arbitrarily predetermined "small" (e.g., 1% or 5%) size. The "quasi-extinction" level may be defined (Ginzburg et al., 1982) as (1) the population level below which the probability of poor recruitment increases appreciably or (2) the smallest population capable of supporting a viable fishery.

The primary determinant of the long-term dynamics of any population is the relationship between the adult population (stock) and recruitment. The null hypothesis is that the relationship is linear, i.e., that recruitment is independent of density (Sissenwine and Shepherd, 1987). Compensatory changes in survival or in reproductive output result in nonlinear stock-recruitment curves. Nonlinearity permits stable equilibrium under harvesting pressure (i.e., under increased mortality rates), up to a critical exploitation level, beyond which the population will decline to quasi-extinction. Stochastic variation in the stock-recruitment relationship or in multispecies interactions can increase risks of adverse effects at moderate exploitation levels. In practice, because of uncertainties resulting from stochastic variations and measurement errors, it is often impossible to reject the null hypothesis of no compensation. Assuming there is no compensation will, in general, result in a conservative assessment of production capacity and its ability to withstand exploitation.

Haddock populations on Georges Bank fluctuated about relatively stable levels between 1930 and 1960 when the fraction of the total haddock population killed per year by fisherman (annual fishing mortality rate) varied between 0.3-0.6, but collapsed after the fishing mortality rate increased to 0.8 during the 1960s (Grosslein et al., 1980). The empirical relationship between stock and recruitment was extremely variable with little indication of the form of the underlying curve. Analysis of the population dynamics showed that a density-independent null model could not be rejected and gave a neutral equivalent harvest rate of 0.5, which agrees well with the stable period of the fishery. In contrast, the compensatory model is over optimistic with respect to the long-term harvest rate.

The decrease in populations of haddock and other groundfish was accompanied by increases in other species, notably elasmobranchs (rays and sharks). The biomass of predatory species increased dramatically with attendant consequences for the overall system structure (Fogarty et al., 1989). Population modeling suggests that the stock-recruitment relationship for haddock might have been changed and that the population cannot now withstand as heavy fishing mortality as it could before the increase in predation pressure.

Risk assessment for exploited systems must take into account uncertainties in population abundance, harvest rates, and system structure. Adoption of risk-averse management strategies would minimize the possibility of stock depletion or undesirable alterations in the structure of the system.

(Led by R. M. Peterman, Simon Fraser University, and J. L. Ludke, National Fisheries Research Center-Leetown)

Discussion focused on the idea of statistical power—the probability that an experiment (or set of observations) will correctly reject a null hypothesis that is false, i.e., the probability that an experiment will detect effects that actually exist. In fisheries cases, the high degree of variability in population parameters means that most studies have very low power to detect changes, unless the studies are continued for many years or involve frequent measurements (Peterman and Bradford, 1987). Published papers in fisheries biology (and in other disciplines related to risk assessment) rarely report statistical power and hence can misleadingly report negative findings. The case study recommended adopting a conservative null hypothesis to allow for the low power of the observational studies. Other approaches are to improve the design of studies (e.g., by more frequent sampling), to incorporate uncertainties into formal decision analysis, and to reverse the burden of proof (to put the burden of documenting whether detrimental effects are occurring on exploiters of the resource, rather than in the management agency). If "proof" of safety is required, a formal statement of the power of studies should be provided for a size of effect deemed relevant.

The Georges Bank fishery is only one of a long series of cases in which overexploitation has occurred despite a nominal system of scientific stock assessment and fishery management. Discussants generally felt that overexploitation was due to failures of management, rather than to deficiencies in assessment or failure to communicate results to managers.

The assessment of the risk to fish populations associated with exploitation in the Georges Bank case study is implicitly consistent with the 1983 health risk assessment framework, although the explicit steps differ. The case study illustrates the 1983 risk assessment paradigm within the larger context of problem-solving. However, the dose-response and exposure steps might be only loosely analogous. Differing circumstances of function, scale, and certitude could require variation in the method of risk assessment.

The numerous sources of uncertainty in assessing risk associated with exploitation of fish populations vary and increase in magnitude with increase in scale. Regulation of harvest of geographically confined populations can be achieved with greater confidence than can regulation of wide-ranging populations such as Chesapeake Bay striped bass and Lake Michigan lake trout. Sources of uncertainty include variation in recruitment, measurement (which requires many assumptions), and management and institutional characteristics. Management techniques for reducing risks associated with overexploitation of populations are fairly blunt instruments, and strong actions are usually taken only after the fact. Rarely, if ever, are risk reduction measures considered until an actual impact is noticed or a potential threat emerges.

Subtle and cumulative factors that are unknown or are measured imprecisely—e.g., chronic or episodic changes in predation, migration, and disease—are some of the issues with information gaps that contribute to uncertainties in ecological risk assessment. The Georges Bank case study describes multispecies interactions and consequences of selective harvesting practices within the fish community, but falls short of a systematic understanding of cause and effect with regard to changes in multispecies abundance.

• Cite this Page National Research Council (US) Committee on Risk Assessment Methodology. Issues in Risk Assessment. Washington (DC): National Academies Press (US); 1993. Appendix E, Case Studies and Commentaries.
• PDF version of this title (4.6M)

In this Page

• Tributyltin Risk Management In the United States
• Ecological Risk Assessment for Terrestrial Wildlife Exposed to Agricultural Chemicals
• Models of Toxic Chemicals in the Great Lakes: Structure, Applications, and Uncertainty Analysis
• Ecological Risk Assessment of TCDD and TCDF
• Risk Assessment Methods in Animal Populations: The Northern Spotted Owl as an Example
• Ecological Benefits and Risks Associated with the Introduction of Exotic Species for Biological Control of Agricultural Pests
• Uncertainty and Risk in an Exploited Ecosystem: A Case Study of Georges Bank

Recent Activity

• Case Studies and Commentaries - Issues in Risk Assessment Case Studies and Commentaries - Issues in Risk Assessment

Your browsing activity is empty.

Activity recording is turned off.

Turn recording back on

Connect with NLM

National Library of Medicine 8600 Rockville Pike Bethesda, MD 20894

Web Policies FOIA HHS Vulnerability Disclosure

Help Accessibility Careers

Crown land manager resource

• What is Crown land
• Crown reserves directory
• Council Crown land manager
• Roles and responsibilities
• Reserve manager conduct
• Board vacancies
• Meet our managers
• 2021 Awards - Winners and finalists
• 2022 Awards - Winners and finalists
• Legislation
• How the commons system works
• Commons trust board – role and responsibilities
• Management plans for commons
• Leases and licences for commons
• General administration for commons
• Selling, mortgaging and acquiring commons trust land
• Aboriginal interests
• Building and development
• Reserve planning
• Managing assets and heritage
• Environmental management
• Land management agreements
• Bushfires and hazard reduction
• Dividing fences
• Severe weather guidance
• Case study - risk management
• Short-term licences
• Leasing and licencing for terms greater than 12 months
• Setting rents, fees and charges
• Finding a tenant—Public competition or direct negotiation
• Native title, Aboriginal interests and granting tenure
• Contract management
• Visitors to Crown reserves
• Compliance matters
• Holding events
• Crown Reserves Improvement Fund
• Other funding and income
• Crown Land Funding Map
• Crown land manager induction
• Financial activities – getting started
• Learning and development
• Insurance summary table
• CLM Procurement Code of Conduct
• Managing conflicts of interest
• Managing board meetings
• Privacy and personal information
• Public access to government information
• Templates and guides
• Terminology and abbreviations
• News & Events
• Reserve Manager Portal
• Using Crown reserves
• Risk Management

dropdown#toggle"> Explore this section

On this page, example—lawn mowing risk assessment.

In this hypothetical example of a risk assessment, we consider the activity of lawn mowing on a Crown reserve.

Although seemingly a simple activity, there is some degree of risk to staff and visitors that need to be considered.

The first step is to identify hazards based on interviews, research and hands-on experience. This is called a desktop assessment, because it takes place away from the site — perhaps literally at a desk. Hazards identified during the desktop assessment include:

• inexperienced or new personnel
• moving blades of mower
• moving vehicles / equipment
• fuel storage and use
• sun exposure
• mechanical failure
• pedestrian pathway through the reserve
• endangered ecological community (rare orchid) on site
• small stones and other debris on lawn.

This is followed by going to the site and looking around. After walking around the site, the following additional hazards were identified:

• vehicles parked on the road
• undergrowth edging the lawn may harbour snakes (brown snakes are known to inhabit the reserve)
• magpie nests.

Using the risk assessment matrix, risk level is assigned to each hazard, and control measures proposed. The risk level is then revised based on proposed controls. Note that the risks discussed in this example are just a sample of some of the risks, and is not an exhaustive list.

Sign up for our eNewsletter to receive updates.

This Crown land manager web resource was printed on 24 Nov 2023. The information contained in this web resource is based on knowledge and understanding at the time of writing Nov 2023. However, because of advances in knowledge, users are reminded of the need to ensure that the information upon which they rely is up to date and to check the currency of the information by referring to the website (www.reservemanager.nsw.gov.au).

© State of New South Wales through Department of Planning, Industry & Environment 2023.

Page link: https://reservemanager.crownland.nsw.gov.au/using-crown-reserves/risk-management/risk-assessment-template

How to Do a Risk Assessment: A Case Study

Healthy , Organizational Leadership , Winning Strategy | Execution , Organizational Health Management , Risk management , Strategic planning

Christian Leadership Reflections

An exploration of Christian ministry leadership led by CCCC's CEO John Pellowe

There’s no shortage of consultants and authors to tell boards and senior leaders that risk assessment is something that should be done. Everyone knows that. But in the chronically short-staffed world of the charitable sector, who has time to do it well? It’s too easy to cross your fingers and hope disaster won’t happen to you!

If that’s you crossing your fingers, the good news is that risk assessment isn’t as complicated as it sounds, so don’t be intimidated by it. It doesn’t have to take a lot of time, and you can easily prioritize the risks and attack them a few at a time. I recently did a risk assessment for CCCC and the process of creating it was quite manageable while also being very thorough.

I’ll share my experience of creating a risk assessment so you can see how easy it is to do.

Step 1: Identify Risks

The first step is obvious – identify the risks you face. The trick is how you identify those risks. On your own, you might get locked into one way of thinking about risk, such as people suing you, so you become fixated on legal risk. But what about technological risks or funding risks or any other kind of risk?

I found a helpful way to identify the full range of risks is to address risk from three perspectives:

• Two of the mission-related risks we identified at CCCC were 1) if we gave wrong information that a member relied upon to their detriment; and 2) if a Certified member had a public scandal.
• We listed several risks to organization health for CCCC. Among them were 1) a disaster that would shut down our operations at least temporarily, and 2) a major loss from an innovation that did not work.
• We identified a risk related to the sociopolitical environment.

I began the risk assessment by reviewing CCCC from these three perspectives on my own. I scanned our theory of change, our strategy map, and our programs to identify potential risks. I then reviewed everything we had that related to organizational health, which included our Vision 2020 document (written to proactively address organizational health over the next five years),  financial trends, a consultant’s report on a member survey, and a review of our operations by an expert in Canadian associations. I also thought about our experience over the past few years and conversations I’ve had with people. Finally, I went over everything we know about our environments and did some Internet research to see what else was being said that might affect us.

With all of this information, I then answered questions such as the following:

• What assumptions have I made about current or future conditions? How valid are the assumptions?
• What are my nightmare scenarios?
• What do I avoid thinking about or just hope never happens?
• What have I heard that went wrong with other organizations like ours?
• What am I confident will never happen to us? Hubris is the downfall of many!
• What is becoming more scarce or difficult for us?

At this point, I created a draft list of about ten major risks and distributed it to my leadership team for discussion. At that meeting we added three additional risks. Since the board had asked for a report from staff for them to review and discuss at the next board meeting, we did not involve them at this point.

Step 2: Probability/Impact Assessment

Once you have the risks identified, you need to assess how significant they are in order to prioritize how you deal with them. Risks are rated on two factors:

• How likely they are to happen (That is, their Probability )
• How much of an effect could they have on your ministry (Their anticipated Impact )

Each of these two factors can be rated High , Medium , or Low . Here’s how I define those categories:

• High : The risk either occurs regularly (such as hurricanes in Florida) or something specific is brewing and becoming more significant over time, such that it could affect your ministry in the next few years.
• Medium : The risk happens from time to time each year, and someone will suffer from it (such as a fire or a burglary). You may have an elevated risk of suffering the problem or you might have just a general risk, such as everyone else has. There may also be a general trend that is not a particular problem at present but it could affect you over the longer term,
• Low : It’s possible that it could happen, but it rarely does. The risk is largely hypothetical.
• High : If the risk happened, it would be a critical life or death situation for the ministry. At the least, if you survive it would change the future of the ministry and at its worst, the ministry may not be able to recover from the damage and closure would be the only option.
• Medium : The risk would create a desperate situation requiring possibly radical solutions, but there would be a reasonable chance of recovering from the effects of the risk without long term damage.
• Low : The risk would cause an unwelcome interruption of normal activity, but the damage could be overcome with fairly routine responses. There would be no question of what to do, it would just be a matter of doing it.

I discussed my assessments of the risks with staff and then listed them in the agreed-upon priority order in six Probability/Impact combinations:

• High/High – 2 risks
• High/Medium – 1 risk
• Medium/High – 2 risks
• Medium/Medium – 3 risks
• Low/High – 3 risks
• Low/Medium – 2 risks

I felt that the combinations High/Low, Medium/Low, and Low/Low weren’t significant enough to include in the assessment. The point of prioritizing is to help you be a good steward as you allocate time and money to address the significant risks. With only thirteen risks, CCCC can address them all, but we know which ones need attention most urgently.

Step 3: Manage Risk

After you have assessed the risks your ministry faces (steps 1 and 2), you arrive at the point where you can start managing  the risks. The options for managing boil down to three strategies:

• Prevent : The risk might be avoided by changing how you do things. It may mean purchasing additional equipment or redesigning a program. In most cases, though, you probably won’t actually be able to prevent the risk from ever happening. More likely you will only be able to mitigate the risk.
• Mitigate : Mitigate means to make less severe, serious, or painful. There are two ways to mitigate risk: 1) find ways to make it less likely to happen; and 2) lessen the impact of the risk if it happens. Finding ways to mitigate risk and then implementing the plan will take up most of the time you spend on risk assessment and management. This is where you need to think creatively about possible strategies and action steps. You will also document the mitigating steps you have already taken.
• Transfer  or Eliminate : If you can’t prevent the risk from happening or mitigate the likelihood or impact of the risk, you are left with either transferring the risk to someone else (such as by purchasing insurance) or getting rid of whatever is causing the risk so that the risk is no longer applicable. For example, a church with a rock climbing wall might purchase insurance to cover the risk or it might simply take the wall down so that the risk no longer exists.

Step 4: Final Assessment

Armed with all this information, it’s time to prepare a risk report for final review by management and then the board. I’ve included a download in this post to help you write the report. It is a template document with an executive summary and then a detailed report. They are partially filled out so you can see how it is used.

After preparing your report, review it and consider whether or not the mitigating steps and recommendations are sufficient, Do you really want to eliminate some aspect of your ministry to avoid risk? Do you believe that whatever action has been recommended is satisfactory and in keeping with the ministry’s mission and values? Are there any other ways to get the same goal achieved or purpose fulfilled without attracting risk?

Finally, after all the risk assessment and risk management work has been done, the ministry is left with two choices:

• Accept whatever risk is left and get on with the ministry’s work
• Reject the remaining risk and eliminate it by getting rid of the source of the risk

Step 5: Ongoing Risk Management

On a regular basis, in keeping with the type of risk and its threat, the risk assessment and risk management plan should be reviewed to see if it is still valid. Have circumstances changed? Are the plans working? Review the plan and adjust as necessary.

Key Thought: You have to deal with risk to be a good steward, and it is not hard to do.

Share this post

Sign up for Christian Leadership Reflections today!

More from christian leadership reflections.

• The Long-Term Benefits of a Sabbatical (Jun. 14, 2023)
• How to Release Your Mission Statement’s Power (May. 20, 2023)
• A Theology of Strategy Development (May. 8, 2023)
• God’s Christmas Gift to Us: Peace through Christ (Dec. 13, 2022)
• Looking Around: Corporate Values (Oct. 18, 2022)
• Adaptive(17)
• Ample Resources(9)
• Best Practices(10)
• Christian(39)
• Christian Faith(25)
• Christian Fundraising(10)
• Christian Identity(6)
• Christian Mission(1)
• Christian Spirituality(5)
• Christian Witness(7)
• Church-agency(2)
• Collaborative(9)
• Community Leadership(44)
• COVID-19(1)
• Effective(76)
• Employee engagement(1)
• Exemplary(46)
• Flourishing People(34)
• Fundraising(2)
• Governance(25)
• Great Leadership(115)
• Great Leadership(1)
• Healthy(180)
• Impeccable(12)
• Intellectual Creativity(15)
• Leadership(2)
• Leadership - Theology(6)
• No category(2)
• Organizational Health(2)
• Organizational Leadership(54)
• Personal Leadership(60)
• Personal Reflection(8)
• Planful(12)
• Religious Philosophy(1)
• Skillful Execution(9)
• Spirituality of Leadership(32)
• Strategy(34)
• Team Leadership(29)
• Teamship(5)
• Thoughtful(38)
• Trailblazing(16)
• Uncategorized(8)
• Winning Strategy(24)
• A Milestone 360(3)
• Appreciation at Work(3)
• Christian Identity(3)
• Conflict Resolution(4)
• Corporate life as corporate witness(6)
• Dad's Passing(2)
• Delegation God's Way(1)
• Essential Church Leadership(1)
• Faithful Strategy Development(18)
• Harvard Business School(12)
• Hearing God speak(4)
• How a board adds value(5)
• Loving Teamship(3)
• Oxford University(4)
• Pastors: A Hope and a Future(24)
• Program Evaluation(7)
• Sabbatical(37)
• Sector Narrative(4)
• Stanford University(3)
• Who We Serve
• What We Value
• 50th Anniversary
• Board of Directors
• Financials and Policies
• Membership Options
• Accreditation Program
• Member Stories
• Sector Representation
• Legal Defence Fund
• Member Support Team
• Professional Associate Directory
• HR Consulting
• Employee Group Benefit Plans
• Pension Plan
• Christian Charity Jobs
• Canadian Ministry Compensation Survey
• Learning Table Online Courses
• CCCC Knowledge Base
• Live Webinars
• Completing Your T3010
• Free Resources
• Spiritual Resources
• Property and Liability Insurance
• Protection for Vulnerable Persons
• Give Confidently
• CCCC Community Trust Fund
• Donor Information
• Fundraiser Information

Technical Safety / HSE Risk Management / Asset Integrity & Operational Assurance

• Company Overview
• Global Capabilities
• Oil & Gas
• Transportation
• Workshop Facilitation
• Safety Engineering
• Fire Detection & Fire Protection Systems Design
• Qualitative & Quantitative Risk Assessments (QRA)
• HSE MS Development and Compliance
• Occupational Health Risk Management
• Environmental Risk Assessments
• Human Factors Engineering (HFE) and Ergonomics
• Reliability Availability & Maintainability (RAM)
• Risk Based Inspection
• Reliability Centred Maintenance
• Functional Safety Engineering
• Specialist Inspection / Audit Services
• Computational Fluid Dynamics (CFD)

Global Projects

Global projects.

• United Kingdom
• UK North Sea

Case Study 1

Location: Nigeria

MES performed a suite of safety and risk studies for an international operator with operations in Nigeria. Studies included evaluating the fire, explosion and dispersion risks; analysing the suitability of escape route and evacuation procedures; assessing the integrity of emergency systems and verifying the adequacy of active fire protection at the Floating Production Storage and Offloading (FPSO) installation.

MES executed studies for this brown-field FPSO project to a commendable standard and has since continued to strengthen a relationship with this client.

Back to top

Case Study 2

Location: Kazakhstan

MES has supported a number of major projects in Kazakhstan for a number of years now including one of the largest projects Worldwide consisting of offshore facilities, an Onshore oil, gas and sulphur plant and a railway network designed for exporting purposes. MES' involvement has been through all phases of the project from feasibility, FEED, Detailed Engineering through to providing site and operations support.

Some of the studies executed by MES have included fire and explosion studies, risk assessments, facilitating workshops, developing performance standards and HSE Cases and providing direct support to the client assisting with troubleshooting problems faced during the design and construction of the project. MES has also supported the Client on addressing non-conformances raised by the RoK authorities and Independent Verification Body.

Case Study 3

Location: Uganda

Several risk assessment studies were prepared for a client with operations in Uganda.

• A Transport Risk Assessment was prepared for a client to assess a range of options to transfer crude oil to several delivery stations during a conceptual phase of a development project. The study was based on quantifying risks and applying ALARP principles and a Cost Benefit Analysis (CBA) to identify the most risk adverse, least costly option. Risk contours were developed using MERIT and study findings were presented to the client to highlight key issues that should be explored at later stages when developing the project.
• A Deliverability Assessment was also prepared to assess critical bottlenecks in the supply chain. Monte Carlo simulation modeling was performed to provide the client with the minimum level of storage at loading stations and optimum fleet capacity (trucks) to meet annualised deliverability targets. Methods to reduce lag times and make-up shortfalls due to unexpected loss in production were reported to the client.

MES continues to provide dedicated risk support services to this client for its all operations across the world.

Case Study 4

Location: UK

MES were retained by CLIENT to provide specialist Safety and Risk Management services to a large UK Gas Storage Development Project comprising Offshore Wellhead Injection/Production Platforms and an Onshore Terminal. Specific services provided by MES included:

• Long-term secondment of Lead HSE engineer into Project Management team to advise on Safety and Regulatory issues and ensure compliance of FEED activities with COMPANY and Regulatory Standards. The role extended also to HSE review of all FEED documentation (Onshore and Offshore) and preparation, review and clarification of primary EPC tenders.
• Safety and Risk Studies, including Quantitative Risk Assessment of the Onshore terminal to identify all hazards and assess the risks to personnel. MES used the the QRA output to complete further assessments of the Occupied Buildings Risks on the terminal and also to determine the Domino Hazard events to the neighbouring sites.
• Offshore, MES managed the detailed hydrocarbon release and explosion analysis using Computational Fluid Dynmics (CFD) software. This assessment determined the probability of exceeding a structural design loading allowing the design to be accurately specified. MES also conducted studies to review the provision of Sub-Sea Isolation Valves to the main sealines.
• MES, on behalf of CLIENT prepared the draft submissions of the primary UK Regulators: Design Notification (Offshore Safety Case Regulations) and Safety Report (Onshore - COMAH Regulations)

MES' engagement in the project allowed the CLIENT to efficiently fill 'resource' gaps in their project team and to provide expertise in reviewing the FEED Contractor's work and defining requirements for subsequent EPC tenders. MES provided CLIENT with direct working knowledge of the UK Regulatory framework which was essential in engaging the UK Regulator and developing the necessary submission requirements. MES continues to provide the client with dedicated support in the above areas, the contract duration now extending to 2 1/1 years.

Case Study 5

Location: UK North Sea

MES was commissioned to perform a Reliability, Availability and Maintainability (RAM) study for an offshore installation in Northern North Sea. The project scope was to minimize platform lost time by identifying barriers on production efficiency and recommending cost-effective improvements that could be easily implemented.

MES was able to report:

• Critical systems which should be provided with redundancy
• Key maintenance activities which should be implemented on the asset as a minimum.
• Optimised manning levels on the installation required to perform repair work in the event of an equipment failure.
• Critical spares list that should be held offshore.

MES continues to provide integrity support to clients with assets located in North Sea.

Case Study 6

Location: Worldwide

Technical workshops and reviews are essential to any project to identify process hazards (HAZID) and systematically examine a planned operation (HAZOP). MES has consultants with experience spanning over 25 years of industry knowledge and ability chairing HAZID and HAZOP workshop sessions. To date, MES has performed in excess of 100 workshops - including HAZID, HAZOP, ENVID, BOWTIE, SIL and LOPA. MES has been involved on numerous high profile projects within Oil, Gas, Petrochemical and Nuclear industries, of which have included facilitating workshops of short 1 day sessions to longer to more intense programs lasting several weeks.

Case Study 7

Location: Abu Dhabi, UAE

MES were approached to perform a mapping study examining the coverage of existing detector systems on an onshore installation in Abu Dhabi, UAE. MES were able to simulate the 3-dimensional coverage of various fire and gas detection equipment using AMNIS and comment on the following:

• Detector type and suitability for application
• Optimum number in voting arrangement
• Advise on location within 3-dimensional grid space
• Determine the base line coverage in zonal areas and identify zones with non-conformance to performance targets

MES is a specialist provider of Fire and Gas consultancy services and continues to build its experience and reputation in this field.

Case Study 8

Location: Oman

MES has performed a number of Safety, risk and RAM Studies for various operators in Oman. These have ranged from facilitating workshops to carrying out fire and explosion, Quantitative Risk Assessment (QRA), HSE Cases, developing performance standards, Pre-Incident Plans (PIPs), Manual of Permitted Operations (MOPOs) and developing Emergency Response Procedures and Plans. These studies have been conducted for various type of facilities such as pipelines, gas processing plants and complex refineries.

MES' performance and continued growth in Oman has led to the establishment of a small consultancy office based in Muscat in order to further support the needs of our Clients more locally.

• Technical Safety
• HSE Risk Management
• Asset Assurance & Operational Integrity
• Computational Fluid Dynamics

Specialist Software

Resource centre.

• Terms & Conditions
• Privacy & Cookie Policy

Copyright © 2023 Monaco Engineering Solutions

UK T: +44 (0)1372 227 997 UK E: moc/lanoitanretni-sem//ofni.kusem UAE T: +971 (0)4454 1505 UAE E: moc/lanoitanretni-sem//ofni.eausem

• Reference Manager
• Simple TEXT file

People also looked at

Original research article, fire safety risk assessment of workplace facilities: a case study.

• 1 Architectural Engineering Department, King Fahd University of Petroleum and Minerals, Dhahran, Saudi Arabia
• 2 Interdisciplinary Research Center for Smart Mobility and Logistics, King Fahd University of Petroleum and Minerals, Dhahran, Saudi Arabia
• 3 Department of ICT and Natural Sciences, Norwegian University of Science and Technology, Ålesund, Norway

Workplace facilities are organizational capital assets, which entail high risks of fire occurrences. The fire risks increase based on occupants’ behaviors, lack of awareness and poor workspaces safety management. Thus, fire safety risk assessment is vital to raise awareness about workplace fire-safety culture, and to train employees on effective fire response requirements and methods. The literature lacks studies focusing on managing fire safety at the workplace, and limiting occupants dispossessed behaviors. This research presents a case study, which demonstrates the utilization of risk assessment for fire safety prevention in a workplace facility. Relevant literature is synthesized for identifying causes of fire, various propagation hazards, control measures to develop a risk assessment tool based on fire codes. The codes were analyzed by describing the requirements for fire safety precautionary measures, followed by an exemplary assessment. This research aims to provide professional practice and knowledge on the fire risk assessment methodology, serving safety professionals, and facilities managers. It serves to raise awareness on the causes of fire, consequences of fire events, and mitigation strategies in workplace facilities, for the purpose of protecting users’ lives and business properties against fires.

Introduction

Office workplace.

An office building is a form of construction, which provides a workplace for conducting business activities, such as administration, consulting services and client-related services ( Aronoff and Kaplan, 1995 ). As in any built-environment, fires could occur in office properties, due to several causes ( McDermott et al., 2010 ; Campbell, 2013 ; Shang et al., 2013 ). The ramifications of fire occurrence in office properties could be catastrophic, in several dimensions. Fire events have destructive effects on business organizations. Fires could result in serious damages to property, and loss of valuable assets, documents, and data ( Sun and Luo, 2014 ). These consequences cause organizations to lose productive time for business operations, and hence incur financial losses. Fires also have destructive effects on the organizational staff, fire fighters and the public, due to the injuries and fatalities that could happen ( Hall, 2014 ). Thus, facilities managers of office properties should be prepared to conduct regular fire risk assessments, to identify the continually emerging hazards, due to users’ activities, design and operation of the workplace, and to safeguard against fire occurrence. The term hazard is used to describe any source or condition that would result in potential harm to people or properties ( Furness and Muckett, 2007 ). Fire risk assessment procedures comprise the systematic and regular identification of the available fire hazards that could harm the users of office properties, and devising means to reduce these hazards, to save lives and businesses ( Home Office, 2006 ; London Fire Brigade, 2020 ). These procedures would ultimately result in reducing the probability of fire occurrence and guarding against its consequences ( Sun and Luo, 2014 ). Watts and Hall (2016) defined risk assessment as “the process of establishing information regarding acceptable levels of a risk and/or levels of risk for an individual, group, society, or the environment”. They have discussed the lack of availability of a universal approach for fire risk assessment, as the relativity of compromises and complexity of the processes differ in acceptance by its users.

Behavioral-Based Fire Safety for the Workplace

Behavioral-based safety (BBS) is the process of building a strong collaboration among the workplace users, in an attempt to raise awareness and behavioral capacity upon fire safety. Figure 1 presents the strategies and consequences to be considered for behavioral based fire safety practices. It is focusing on workplace users’ actions and behaviors. There have been different approaches undertaking the fire risk assessment of buildings. Within literature, several examples have been presented as research case studies. Brzezińska and Bryant (2020) conducted research utilizing fire strategy risk index to benchmark key performance objectives. The significant considerations for fire risk strategy assessment covered in their study comprised of control of ignition sources, combustibles, compartmentation, smoke control, detection and suppression systems, field service intervention and firefighting. Danzi et al. (2021) proposed a different fire safety assessment approach that is inclusive of occupants’ behaviors, a methodology named fire risk assessment method for enterprises. The proposed method is less time consuming than computational fluid dynamics approaches. Koutsomarkos et al. (2021) discussed the need for simplicity of fire risk indexing, where more complex approaches are deemed less transparent, and non-feasible for its users. Therefore, it is imperative to comprehend the various causes of fire, types of combustibles in office properties. Following a synthesis of the reviewed literature the authors identified three main research questions, as an objective of this study:

FIGURE 1 . Behavioral based fire safety practices.

RQ1) How did the literature discuss behavioral fire safety practices in the context of workplace facilities?

RQ2) What are the fire protection and prevention measures, in the codes, that must be considered in office facilities?

RQ3) How to inspect and assess the behavioral fire safety in workplace office facilities?

Thus, this study aims to develop a risk assessment tool for assessing the compliance level for providing and maintaining compulsory fire protection and prevention requirements in office properties, for the purpose of mitigating fire occurrence. The study also presents a case study to assess the provision and maintenance of fire safety requirements, utilizing the developed risk assessment tool. This paper is of significant value to design professionals, real estate developers and owners, and facilities managers, through raising awareness about the causes of fire, consequences of fire events, and mitigation strategies in office properties. This research provides a comprehensive checklist for conducting periodic fire risk assessments of office buildings.

Research Methodology

This research comprised of a systematic set of activities. These activities conducted to accomplish the objectives of this research:

Synthesizing the relevant published literature in the domain of fire safety in office properties, to identify the various types of combustible contents and causes of fire, and the set of factors that render office properties as a high risk facilities in fire events ( Greenwald, 1991 ; Home Office, 2006 ; Hassanain, 2008 ; Thauvoye et al., 2008 ; Zalok et al., 2008 ; McDermott et al., 2010 ; Kuligowski and Hoskins, 2011 ; Campbell, 2013 ; Shang et al., 2013 ; Khorasani et al., 2014 ; Sun and Luo, 2014 ; The Building Regulation, 2019 ; London Fire Brigade, 2020 ).

Analyzing the fire codes to describe the pertinent requirements for fire safety precautionary measures, for office properties ( International Fire Code, 2018 ; National Fire Protection Association 10, 2018 ; National Fire Protection Association 13, 2019 ; National Fire Protection Association 70, 2020 ; National Fire Protection Association 72, 2019 ; National Fire Protection Association 78, 2020 ; National Fire Protection Association 92, 2018 ; National Fire Protection Association 101, 2021 ).

Developing a fire code-risk assessment tool to assess the compliance level for providing and maintaining fire safety code requirements in office properties, for the purpose of mitigating fire occurrence. The risk assessment tool includes 36 precautionary fire measures, classified under six groups, namely exits, fire protection systems, housekeeping measures, electrical wiring and installations, miscellaneous measures for fire prevention and hazardous materials.

Utilizing the developed fire code-risk assessment tool, in a case study to assess the provision and maintenance of fire safety requirements. The case study required conducting a walkthrough inspection in an office building located in the Eastern Province of Saudi Arabia.

Reporting the findings of the walkthrough inspection in the case study building, and developing a series of corrective actions to upgrade the status of fire safety in the case study office building.

Literature Review

A narrative review of the literature has been utilized to analyze the following dimensions:

Combustible Contents and Causes of Fire in Office Properties

Besides administration, office properties can be used for conducting several activities, such as typing, drafting, filing, book-keeping, and archiving ( The Building Regulation, 2019 ). Thus, fire can take place in these properties, causing injuries, fatalities, and property damages, due to various ignition causes. These causes of ignition include:

Malfunction of cooking equipment: due to electrical faults, while being unattended during their use. These are equipment, such as toasters, microwaves, water heaters and coffee machines, in kitchenettes, could draw excessive current, which causes the equipment to overheat, and cause a fire ( Greenwald, 1991 ).

Malfunction of electrical office equipment: due to electrical faults, lack of regular servicing or misuse. Examples of these equipment include computers, photocopiers, printers, and paper shredders ( The Building Regulation, 2019 ).

Accumulations of flammable paper-based products: placed in adjacent locations to heat sources. These products include files, papers, and books ( Khorasani et al., 2014 ).

Overloaded electrical circuits: due to the need to power multiple office equipment using a limited number of electrical power sockets ( Sun and Luo, 2014 ).

Defective lighting fixtures: such as flickering fluorescent bulbs, where the ballasts, which regulate the flow of current to the lighting fixture cease to function properly. This condition would usually cause the ballasts to overheat and cause a fire ( Hassanain, 2008 ).

Careless disposal of smoking materials: heated tobacco products, in addition to lighters and matches could cause fire if they became in contact with flammable materials, such as paper-product, floor finish, or upholstered furniture at the office ( Campbell, 2013 ).

Space heating equipment: including central heating systems and portable heaters. This heating equipment could cause fires, if they came into close contract with combustible contents in the building ( Campbell, 2013 ).

Open fire doors: that could allow flames and smoke to spread through the building and prevent safe egress from the building during fire events ( McDermott et al., 2010 ).

Office Properties as High-Risk Facilities in Fire Events

Fire risk assessment involves comprehending the factors that contribute to fire occurrence in any given facility ( London Fire Brigade, 2020 ). Design professionals, business owners and facility managers need to realize that it is not feasible for office properties to operate without having some potential fire hazards on the premises. Office properties are considered a high-risk facility type, in fire events, due to several factors. These factors include:

The availability of large number of occupants: office properties, are non-domestic, commercial facilities. They are occupied by large number of occupants, within condensed floor layouts. These occupants could have different mobility levels, and perceptions to hazards that could cause fires. They could be also performing their duties in different locations of the workplace. These facilities could be also accessible by the public, who could be unfamiliar with the layout of the floor plan of the building ( Home Office, 2006 ). This large number of users could pose significant challenges during the evacuation from the building, due to fire emergencies ( Kuligowski and Hoskins, 2011 ). The risk is even higher, in the absence of measures for managing emergency evacuations, due to congestion at the main exits ( Shang et al., 2013 ; London Fire Brigade, 2020 ).

The availabilities of large amount of combustibles: When a fire takes place, the amount of energy that is released, and the duration of burning depend on the mass of the combustibles, or the fire load in the building ( Thauvoye et al., 2008 ; Zalok et al., 2008 ). The fire load usually found in office buildings include papers, files, books, office appliances, electrical equipment, furniture, finishes, plastic and rubber products, partitions ( Sun and Luo, 2014 ), chemicals for photocopiers, and decorations ( Home Office, 2006 ). Large amounts these combustibles are usually present, due to the diversity of activities taking place, and the large number of occupants availably in office properties.

Lack of proper housekeeping measures: Combustible materials, such as cleaning products need to be properly stored. Waste products, such as shredded papers, and packaging materials need to be removed from the premises, on a daily basis. Accumulation of these combustibles could significantly add the fire load in the building, and hence, add to the severity of the fire ( Home Office, 2006 ).

Fire Protection and Prevention Measures in Office Properties

Insufficient fire risk assessment practices in office properties could result in overlooking hazardous conditions that lead to the development of fires. Such fires would result in business interruptions, and hence failure to satisfy business obligations, which would ultimately result in economic losses ( Furness and Muckett, 2007 ). Active and passive fire protection and prevention measures, as mandated by fire codes, could significantly reduce fire hazards ( Troitzsch, 2016 ). Active fire protection measures employ fire detection and notification systems, such as smoke detectors and alarm systems. These active measures also include suppression systems, such as portable extinguishers and automatic sprinkler systems ( Chow, 2005 ). Passive fire protection measures employ the use of flame-resistant systems, such as fire-rated doors, walls, floors and ceilings. Passive measures also include the utilization of flame-retardant materials, for the containment of flames and smoke ( Landucci et al., 2009 ). The measures are illustrated in Figure 2 .

FIGURE 2 . Behavioural based risk assesment tool for fire safety in workplace facilities.

The provision and upkeep of adequate number of exits, through which building users can escape from the building, is a vital measure for preserving lives during fire events ( National Fire Protection Association 101, 2002 ). Facilities managers should ensure that the building layout is not modified in a way that reduces the number of exits, or the capacity of the corridors and exit points. Further, design professionals should ensure that exit routs are continuous from the building’s entry point till the discharge point, to the outside of the building, and that exit doors lead directly to a public space. They should also ensure that the minimum width for any corridor is not less than 1.1 m. Furthermore, the egress doors swing in direction of travel. Additionally, facilities managers should ensure that corridors and exit points are constantly lighted during the building occupancy, and that exit signs are adequately placed, and constantly lighted throughout the building. Moreover, there should be no obstructions, that reduce the width of an exit. In addition, the width of the corridor should not be reduced along the egress pathway. Finally, facilities managers should maintain the provision of the statement “PUSH TO EXIT” on all egress fire doors ( International Fire Code, 2018 ).

Fire Protection Systems

As office properties are high risk type of facilities in fire events, designers and facilities managers need to ensure the adequate provision and operation of the fire protection systems in these facilities. These systems comprise fire extinguishers ( National Fire Protection Association 10, 2018 ), smoke detectors ( National Fire Protection Association 92, 2018 ), fire alarms ( National Fire Protection Association 72, 2019 ), and automatic sprinkler systems ( National Fire Protection Association 13, 2019 ). Specific measures to provide and maintain in office properties include the provision of at least one 2A fire extinguisher per each 557 square meters in low hazard office areas, and maintaining a maximum travel distance of 23 m to any extinguisher. Facilities managers need to ensure that fire extinguishers are located in a visible, yet accessible locations, and are mounted on hangers. These fire extinguishers should be mounted at a height not exceeding 1.5 m from the floor. Furthermore, the fire extinguishers should be serviced on an annual basis ( National Fire Protection Association 10, 2018 ). Additionally, facilities managers should ensure that smoke detectors, firm alarm and extinguishing installations are constantly kept in operational form, and that inspection records of all installation are maintained for the past 3 years. Finally, there is no paint or cover over any sprinkler head, in the building ( National Fire Protection Association 13, 2019 ).

Housekeeping Measures

Housekeeping practices could significantly impact upon exercised initiatives for preventing fire accidents ( Hassanain et al., 2018 ). These practices mandate the storage of combustible materials in an orderly manner. Further, facilities managers should ensure that heating devices are distanced from storage spaces. They should also ensure that exit enclosures are free from combustible materials, and that mechanical rooms are free from combustible materials. Facilities managers should also maintain that dumpsters with a capacity exceeding one cubic meter are stored outside the building ( International Fire Code, 2018 ).

Electrical Wiring and Installations

Since faulty electrical wiring and installations are attributed as the second major cause for fire in office properties ( Campbell, 2013 ), designers and facilities managers should ensure the provision of certain measures, that could potentially reduce fire incidents. These measures primarily relate to the use of extension cords ( National Fire Protection Association 78, 2020 ). The measures mandate that extension cords are grounded, with overcurrent protection. They should directly be connected to wall sockets, and they should not be running through any components of the interior. Further, extension cords should not serve as a replacement for permanent wiring, and they should not be impaired. Moreover, facilities managers should ensure that a sign reading, “Electrical Room” is posted on the doors of all electrical rooms ( National Fire Protection Association 70, 2020 ).

Miscellaneous Measures for Fire Prevention

The miscellaneous measures for fire prevention in office properties mandate that the property has a clear and observable address number. Further, there should be a facilitated access to the fire hydrant. Moreover, an emergency evacuation plan is available in the building ( International Fire Code, 2018 ).

Hazardous Materials

According to National Fire Protection Association 400, (2022) the definition of hazardous materials incorporates “different chemical substances that are in waste or usage formats of storage and handling, that may tolerate physical and health hazards to occupants”. The definition of hazardous materials in this research extends to combustible materials, liquids, and compressed gases. Facilities managers of office properties should ensure that compatible materials are stored separately. They should ensure that the amount of combustible liquids used for operating equipment in the building is limited to 10 gallons. Finally, they should also ensure that rooms where compressed gases are stored are labelled “compressed gas” ( International Fire Code, 2018 ).

Data Collection

A case study was selected to apply and assess the identified protection measures. As a tool for risk assessment Table 1 ; Table 2 were adopted. The data collected was as follows:

TABLE 1 . Reference codes checklist utilized for the development of a behavioral-based risk assessment tool.

TABLE 2 . behavioural-based risk assessment tool for fire safety in workplace facilities.

Case Study Description

The selected case study for validating the developed fire-risk assessment tool, is a three floors office building, with a gross area of 1,692 square meters. It is located in the Eastern Province of Saudi Arabia. The building is classified as “B” occupancy, as per the occupancy classifications of the International Fire Code. The classification of “B” occupancy is used to categorize buildings, or parts of, that are used for offices, for conducting professional and service transactions, and storing records and accounts ( International Fire Code, 2018 ). The building was constructed in 2017, and it is usually occupied by 74 users, on daily basis. Figure 3 illustrates the floor plan of the case study office building.

FIGURE 3 . Floor plan of the case study facility.

Code-based Risk Assessment Tool for Fire Safety

Watts and Hall (2016) have defined checklists as “a common accessory of fire safety consisting of a listing of hazards, usually with recommended practices. A checklist is usually less generic than a model code or standard. It may even be more specific that it is intended to be applied to a single class of buildings, reflecting the special concerns of their owners”. Table 1 illustrates the developed code-based risk assessment tool for fire safety in office properties. The developed risk assessment tool includes 36 precautionary fire measures, classified under six groups as shown in Table 2 , namely exits, fire protection systems, housekeeping measures, electrical wiring and installations, miscellaneous measures for fire prevention and hazardous materials.

Findings and Discussion

A risk assessment walkthrough was carried out in the case study office building. The walkthrough was guided by the developed fire risk assessment tool for assessing the level of compliance level of providing and maintaining fire protection and prevention requirements in office properties. The walkthrough findings reported on the level of compliance of the identified fire safety measures, included in this tool.

Exits: This group included ten measures for fire prevention. The walkthrough revealed that all the identified measures for exits were satisfied, except three. These three measures include lack of compliance of the number of exits with the requirements of fire code, exit doors were found to be swinging in the opposite direction of travel; there were no signs, or instructive statements such as “Push to exit” on all egress fire doors, to indicate the operational direction of the doors.

Fire protection systems: Nine fire prevention measures were included in this group. The walkthrough indicated that the lack of compliance of four out of nine measures. These four measures include exceeding the prescribed 23 m-travel distance to any fire extinguisher in the building. Further, the portable fire extinguishers were neither visible to the building occupants, nor mounted on hangers. Furthermore, there were no inspection records for fire safety installations over the past 3 years.

Housekeeping measures: This group included five fire prevention measures. The walkthrough indicated that all five measures were complying satisfactorily with fire code requirements.

Electrical wiring and installation: This group included six fire prevention measures. The walkthrough inspection revealed that two measures were not complying with fire code requirements. These include the adoption of extension cords as a replacement for permanent wiring, and the absence of posted signs reading “Electrical room” on the doors of all electrical rooms.

Miscellaneous measures for fire prevention: This group included three fire prevention measures. The walkthrough inspection pointed out to two compliance deficiencies with fire code requirements. These include the absence of clear and observable address number on the building, as well as the absence of an emergency evacuation plan in the building.

Hazardous materials: Three fire prevention measures were included in this group. The walkthrough inspection indicated that all three measures were complying satisfactorily with fire code requirements.

The implemented fire risk assessment in this research endorsed the utilization of a standard checklist methodology, as an efficient and cost-economic and a methodical approach for the fire safety management ( Bridges, 2008 ; Sun et al., 2008 ). The developed risk assessment tool included a listing of prescribed fire safety requirements for office properties, classified as “B” occupancies. The implementation of the risk assessment tool was facilitated through a walkthrough inspection. The outcomes from the fire safety checklist provide a practical benefit for guiding facilities managers of office properties on the current level of fire safety measures in their facilities. A checklist is a practical approach to analyze a building in relevance to a code or standard. It is rare that a code or standard applies to a single typology of buildings. The fire protection engineers, and facilities managers must focus on applicable assessment considerations that apply to each specific project, such as in this study for office buildings. A developed checklist can support this approach systematically and reduces requirements’ complexities, to be easily read, understood, and tracked ( Watts and Hall, 2016 ). The variety of codes cited in the paper did not aim to limit the regulatory system referenced for the developed checklist. As the aim is to ensure a comprehensive set of measures for the tool from different regulatory systems, to ensure wider applicability to office buildings. Especially that in Saudi Arabia the local regulations do not provide such a checklist, while it is based on different regulatory systems. In this essence, the approach of developing the tool was followed.

Legislation necessitates comprehensive assessments which ensure compliance with fire safety requirements. The British Standards Institution for example, have developed fire risk assessment code of practice for non-domestic facilities, the code was published in December 2020 and titled as (PAS 79-1:2020). The code delivers technical information on fire safety measures required by legislation, a similar approach has been conducted in this research serving a wider spectrum of codes and standards.

Conclusions and Recommendations

Office properties are considered a high-risk type of facilities in fire events. Provision and maintenance of mandated fire prevention and protection measures result in less number of fires, injuries, fatalities and property losses. This can be achieved through reducing fire hazards in built facilities. This paper presented a systematic approach to assess the level of compliance with compulsory active and passive fire protection and prevention measures, in office properties. The study provides ground for enhancing the behavioural-based fire safety knowledge of design professionals, real estate developers, owners, and facilities managers about the possible fire hazards in office properties. The study presented a risk assessment tool for assessing the compliance level for fire safety requirements, for the purpose of mitigating fire occurrence. The risk assessment tool was utilized during a walkthrough inspection in a case study office building. The level of compliance with each of the measures included in the assessment tool was identified. A plan of corrective actions, in the form of recommendations, was developed to enhance the fire safety performance of the case study building. These recommendations include:

Adding a prefabricated staircase to correct the violation of providing insufficient number of exits according to the requirements of the fire code.

Adjusting the swing direction of the egress door to be in the direction of egress.

Posting the statement “Push to exit” on all egress doors.

Installing additional portable fire extinguishers, so that the travel distance to any extinguisher would not exceed 23 m.

Maintaining regular inspection records of all fire protection systems in the building.

Removing the portable fire extinguishers from the cabinets and mounting them on wall hangers.

Eliminating or minimizing the use of extension cords in the building.

Posting the statement “Electrical room” on all the doors of electrical rooms.

Posting a clear and observable street address number on the building.

Developing and posting an evacuation plan in a visible location in the building.

This paper serves to expand the behavioural-based fire safety knowledge of design professionals, real estate developers, owners, and the facilities management team in office properties on the precautionary measures to mitigate the risks of fire events occurrences. In essence, it serves to raise awareness about the causes of fire and the consequences of fire events, for the purposes of protecting the lives of users and the business properties against fires.

Data Availability Statement

The original contributions presented in the study are included in the article/Supplementary Material, further inquiries can be directed to the corresponding author.

Author Contributions

MH collected the data while MA-H, and AI analyzed the data. All Authors Contributed equally to the conception, methodology and development of the discussion and findings of the research as illustrated and written in the manuscript.

Conflict of Interest

The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.

Publisher’s Note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Acknowledgments

The authors thank King Fahd University of Petroleum and Minerals and Norwegian University of Science and Technology. Also, they would like to thank the case study organization for their time in participating in this study.

Aronoff, S., and Kaplan, A. (1995). Total Workplace Management: Rethinking the Office Environment . Canada: WDL Publications .

Google Scholar

Bridges, W. (2008). “Selection of Hazard Evaluation Techniques,” in Proceedings of the American Society of Safety Engineers’ Middle East Conference Chapter . Bahrain , 1–16.

Brzezińska, D., and Bryant, P. (2020). Risk index Method - A Tool for Sustainable, Holistic Building Fire Strategies. Sustainability 12 (11), 4469. doi:10.3390/su12114469

CrossRef Full Text | Google Scholar

Campbell, R. (2013). U.S. Structure Fires in Office Properties. Technical Report . Quincy, MA, USA: National Fire Protection Association .

Chow, W. K. (2005). Building Fire Safety in the Far East. Architectural Sci. Rev. 48 (4), 285–294. doi:10.3763/asre.2005.4836

Danzi, E., Fiorentini, L., and Marmo, L. (2021). FLAME: A Parametric Fire Risk Assessment Method Supporting Performance Based Approaches. Fire Technol. 57 (2), 721–765. doi:10.1007/s10694-020-01014-9

Elhami Khorasani, N., Garlock, M., and Gardoni, P. (2014). Fire Load: Survey Data, Recent Standards, and Probabilistic Models for Office Buildings. Eng. Structures 58, 152–165. doi:10.1016/j.engstruct.2013.07.042

Furness, A., and Muckett, M. (2007). Introduction to Fire Safety Management . Oxford, UK: Butterworth-Heinemann .

Greenwald, E. K. (1991). Electrical Hazards and Accidents: Their Cause and Prevention . New York, USA: Wiley .

Hall, J. R. (2014). The Total Cost of Fire in the United States. Technical Report . Quincy, MA, USA: National Fire Protection Association .

Hassanain, M. A. (2008). Fire Safety in the Design and Operation of Student Housing Facilities. Struct. Surv. 26 (1), 55–62. doi:10.1108/02630800810857444

Hassanain, M. A., Garkuwa, J. A., and Sanni-Anibire, M. O. (2018). A Code-Compliance Framework for Fire Safety in Student Housing Facilities. Facilities 36 (7/8), 423–436. doi:10.1108/f-12-2016-0099

Home Office (HO) (2006). Fire Safety Risk Assessment: Offices and Shops . London, UK Government, UK: Home Office .

International Fire Code (IFC) (2018). International Fire Code . New Jersey, USA: International Code Council .

Koutsomarkos, V., Rush, D., Jomaas, G., and Law, A. (2021). Tactics, Objectives, and Choices: Building a Fire Risk index. Fire Saf. J. 119, 103241. doi:10.1016/j.firesaf.2020.103241

Kuligowski, E. D., and Hoskins, B. L. (2011). “Analysis of Occupant Behavior during a Highrise Office Building Fire,” in Pedestrian and Evacuation Dynamics . Editors R. Peacock, E. Kuligowski, and J. Averill (Boston, MA: Springer ). doi:10.1007/978-1-4419-9725-8_61

Landucci, G., Rossi, F., Nicolella, C., and Zanelli, S. (2009). Design and Testing of Innovative Materials for Passive Fire protection. Fire Saf. J. 44 (8), 1103–1109. doi:10.1016/j.firesaf.2009.08.004

London Fire Brigade (LFB) (2020). Fire Safety in the Office . London, UK: London Fire Brigade Head Office .

McDermott, H., Haslam, R., and Gibb, A. (2010). Occupant Interactions with Self-Closing Fire Doors in Private Dwellings. Saf. Sci. 48 (10), 1345–1350. doi:10.1016/j.ssci.2010.05.007

National Fire Protection Association (NFPA) 101 (2002). Code for Means of Egress for Buildings and Structures . Quincy, Massachusetts, USA: National Fire Protection Association .

National Fire Protection Association (NFPA) 10 (2018). Standard for Portable Fire Extengishers . Quincy, Massachusetts, USA: National Fire Protection Association .

National Fire Protection Association (NFPA) 101 (2021). Code for Life Safety . Quincy, Massachusetts, USA: National Fire Protection Association .

National Fire Protection Association (NFPA) 13 (2019). Standard for the Installation of Sprinkler Systems . Quincy, Massachusetts, USA: National Fire Protection Association .

National Fire Protection Association (NFPA) 400 (2022). Hazardous Materials Code . Quincy, Massachusetts, USA: National Fire Protection Association .

National Fire Protection Association (NFPA) 70 (2020). National Electrical Code Handbook . Quincy, Massachusetts, USA: National Fire Protection Association .

National Fire Protection Association (NFPA) 72 (2019). National Fire Alarm and Signaling Code . Quincy, Massachusetts, USA: National Fire Protection Association .

National Fire Protection Association (NFPA) 78 (2020). Guide on Electrical Inspections . Quincy, Massachusetts, USA: National Fire Protection Association .

National Fire Protection Association (NFPA) 92 (2018). Standard for Smoke Control Systems . Quincy, Massachusetts, USA: National Fire Protection Association .

Shang, R.-x., Zhang, P.-h., and Zhong, M.-h. (2013). Investigation and Analysis on Evacuation Behavior of Large Scale Population in Campus. Proced. Eng. 52, 302–308. doi:10.1016/j.proeng.2013.02.144

Sun, X.-q., and Luo, M.-c. (2014). Fire Risk Assessment for Super High-Rise Buildings. Proced. Eng. 71, 492–501. doi:10.1016/j.proeng.2014.04.071

Sun, Y., Fang, D., Wang, S., Dai, M., and Lv, X. (2008). Safety Risk Identification and Assessment for Beijing Olympic Venues Construction. J. Manag. Eng. 24 (1), 40–47.

Thauvoye, C., Zhao, B., Klein, J., and Fontana, M. (2008). Fire Load Survey and Statistical Analysis. Fire Saf. Sci. 9, 991–1002. doi:10.3801/iafss.fss.9-991

The Building Regulation (BR) (2019). Fire Safety: Approved Document B , 2. London, United Kingdom: Building other than dwellings .

Troitzsch, J. H. (2016). Fires, Statistics, Ignition Sources, and Passive Fire protection Measures. J. Fire Sci. 34 (3), 171–198. doi:10.1177/0734904116636642

Watts, J., and Hall, J. (2016). “Introduction to Fire Risk Analysis,” in SFPE Handbook of Fire Protection Engineering (New York, USA: Springer ). Chapter 72.

Zalok, E., Hadji Sophocleous, G. V., and Mehaffay, J. R. (2008). Fire Load in Commercial Premises. Fire Mater. 33 (2), 63–78. doi:10.1002/fam.984

Keywords: codes of practice and standards, safety, workplace, fire, risk assesment, facilities

Citation: Hassanain MA, Al-Harogi M and Ibrahim AM (2022) Fire Safety Risk Assessment of Workplace Facilities: A Case Study. Front. Built Environ. 8:861662. doi: 10.3389/fbuil.2022.861662

Received: 24 January 2022; Accepted: 07 February 2022; Published: 07 March 2022.

Reviewed by:

Copyright © 2022 Hassanain, Al-Harogi and Ibrahim. This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) and the copyright owner(s) are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.

*Correspondence: Ahmed M. Ibrahim, [email protected]

† These authors have contributed equally to this work

This article is part of the Research Topic

Insights in Fire Resistant Engineering: 2021

A Case Study of Introducing Security Risk Assessment in Requirements Engineering in a Large Organization

• Original Research
• Open access
• Published: 27 June 2023
• volume  4 , Article number:  488 ( 2023 )

You have full access to this open access article

• Shanai Ardi 1 ,
• Kristian Sandahl   ORCID: orcid.org/0000-0002-3052-5604 2 &
• Mats Gustafsson 1  

1421 Accesses

Explore all metrics

Cite this article

Software products are increasingly used in critical infrastructures, and verifying the security of these products has become a necessary part of every software development project. Effective and practical methods and processes are needed by software vendors and infrastructure operators to meet the existing extensive demand for security. This article describes a lightweight security risk assessment method that flags security issues as early as possible in the software project, namely during requirements analysis. The method requires minimal training effort, adds low overhead, and makes it possible to show immediate results to affected stakeholders. We present a longitudinal case study of how a large enterprise developing complex telecom products adopted this method all the way from pilot studies to full-scale regular use. Lessons learned from the case study provide knowledge about the impact that upskilling and training of requirements engineers have on reducing the risk of malfunctions or security vulnerabilities in situations where it is not possible to have security experts go through all requirements. The case study highlights the challenges of process changes in large organizations as well as the pros and cons of having centralized, distributed, or semi-distributed workforce for security assurance in requirements engineering.

Avoid common mistakes on your manuscript.

Introduction

Many software products are used in sensitive infrastructures where software malfunctions or security vulnerabilities can have significant consequences. Various factors like increased digitalization and geopolitical tensions contribute to the challenges faced by software vendors and result in a significant increase of exposure of software products and an increased risk that an adversary can take advantage of the situation. The increase in exposure and attack surface means that individuals and organizations need to deal with a higher risk to any asset they value in the cyber world.

To mitigate such risks, governments and legislators place ever-increasing demands for security assurance on infrastructure operators and equipment and system vendors, which requires these actors to review and strengthen their processes and methods extensively.

Requirements engineering is one of the earliest phases in the software development life cycle in which software vulnerabilities can be introduced into software products if requirements specifications are inadequate. In recent years, efforts have been made to integrate security risk assessment into requirements engineering activities [ 1 , 2 , 3 , 4 , 5 , 6 , 7 ]. The expected benefit from this is that exposing potential risks early in the requirement engineering phase allows more time for finding solutions to manage the risk. Failure to identify risk in this phase will decrease the overall probability of detecting and preventing vulnerabilities in the product with acceptable costs.

Defining the security objectives of a software product, identifying threats to system assets, estimating the risk level caused by identified threats, and coming up with countermeasures are crucial steps in the process of correctly defining the requirements that will ensure the security of a software product.

Security risk assessment is one of the well-known security activities that is recommended by several software security approaches [ 8 , 9 , 10 , 11 , 12 , 13 , 14 , 15 ] and is a common denominator of several security standards [ 16 , 17 , 18 ]. Getting an understanding of the involved risks by understanding the involved threat models [ 14 ] and problems related to the use cases and misuse cases [ 5 ] enables early detection of potential issues. This understanding also provides a rationale for security-related decisions and for security activities designed and introduced to address security issues.

One common characteristic of most existing approaches is that the assessment activities are performed through heavyweight activities that in many cases are validated in theoretical case studies [ 11 , 19 ]. However, such approaches often turn into key challenges for software vendors that operate using a development context characterized by:

Many small feature-oriented teams;

Teams of developers working according to agile methods and with only basic security knowledge;

Frequent iterations, each comprising a limited number of requirements at a low level of abstraction.

To reconcile the apparent conflict between lean and agile development practices on one side, and traditional heavyweight risk assessment practices on the other, we need to seek out, introduce, and evaluate new practices. Introducing a new method often involves adoption of new technology, changes in work practices, and an additional workload [ 20 ]. This can lead to an acceptance issue for the proposed changes. This issue is especially magnified when competing goals and quality factors must be considered when specifying, designing, and implementing new software solutions. Since these requirements often do not add to functionality, development teams tend to lower their priority to meet deadlines [ 21 ].

Another aspect we have focused on is the challenge of ensuring access to adequate security expertise and security competence. It is widely understood in security community that the basis for security assurance is security awareness among all members of a development organization [ 1 , 2 ]. Considering the increased need for security in software products, the demand for competent expert support and building strong cybersecurity teams in organizations is increasing globally. This has resulted in a security skills gap that is getting bigger every year, according to the International Information System Security Certification Consortium (ISC)2. For these reasons, it is crucial for software and information system vendors to utilize existing cybersecurity expertise to meet cybersecurity requirements.

Forming a central security team to ensure that security activities are handled well has been recommended by several researchers [ 2 , 5 ], but this can introduce bottlenecks, especially in large organizations developing complex products. At the same time, security awareness among developers of a product is the basis for ensuring the security assurance of that product. This poses a knowledge management challenge in the sense that security experts, generally a scarce resource, need to support an often large community of requirements engineers, who are the specialists in the details of the different layers of abstraction in the product. It is usually the case that knowledge about the lowest level of detail is found in development teams. They, not the security experts, are also responsible for implementing and keeping track of the fulfillment of the requirements. The remaining challenge is to find a proper distribution of responsibility between security experts and developers for performing security-related activities.

Another perspective we have included in our approach is to consider security risks associated with requirements in general. This breaks with the traditional mindset in the software development community of considering security separately in requirements engineering and of classifying security requirements as a subgroup of software requirements. Most software requirements are developed in terms of what must happen, but security requirements are driven by a need to mitigate risks and threats to system assets and must be specified in terms of what must not be allowed to happen [ 22 ]. Various methods for eliciting, analyzing, and specifying security requirements have been proposed by researchers [ 22 , 23 , 24 ]. However, identifying concrete advice for immediate deployment of such methods by software vendors is still challenging, especially in the complex context of large-scale software engineering [ 25 , 26 ].

Most contemporary methods use risk assessment for security requirements engineering by focusing primarily on the risks involved with stakeholder goals and/or system-level risks introduced by functional requirements and identifying non-functional security requirements [ 8 , 9 , 10 , 11 , 12 ]. This is vital, but we believe that security cuts across abstraction levels and is also a concern at lower levels of detail in the design of a product. We have seen examples wherein vulnerabilities are introduced into a design at the lowest abstraction levels, as shown in the example presented in in this article.

Based on all above-mentioned considerations this article aims at supporting software vendors by proposing a lightweight security risk assessment method to be applied during requirements engineering phase. The technical contribution presented in this article is consisting of getting high-level product requirements, breaking them down to lower abstraction levels (functionalities) during requirement engineering phase and performing a lightweight security risk assessment to fine-tune the functional requirements to address possible security risks. The security fine-tuned requirements then are used in design and implementation (iteratively or depending on the software development process) reducing the probability of introducing associated risks into the end product. In this contribution, we also experiment the pros and cons of performing these activities by security experts in one end vs requirement engineers in the other end (see Fig.  1 ).

High-level view of the technical approach

We focus on the challenges with the utilization of security competence and through a longitudinal case study evaluate the introduction of our security risk assessment method in a large-scale industrial setting to answer the following research questions:

What are the difficulties of introducing a security risk assessment method in a big organization that is developing complex systems?

When performing security risk assessment, can we bridge the gap between security experts and requirement engineers who are not specialized in security? In that case, what is an efficient distribution of tasks between security experts and requirement engineers?

What are the considerations (introduction or training) needed for engineers to achieve acceptable results?

The remainder of the article is as follows: in section “ Security Risk Assessment ” we provide a thorough description of our lightweight risk assessment method, security risk assessment (SRA). Section “ Case Study ” contains a description of the case study of the introduction of SRA in a large infrastructure development organization is presented in Section “ Case Study ”. A discussion around findings from the case study and a survey of related work are provided in section “ Discussion ” and section “ Related work ”, respectively.

Security Risk Assessment

In this section, we present the SRA method and how it is applied during requirements engineering. The SRA method is designed considering the complexity of the product to be developed and aims at providing a simple method for requirement engineers who are not specialized in security to get better understanding of security risks.

The inputs to the SRA method are requirements that emanate directly from customer requests for added functionality and/or from updates and improvements proposed by developers working on the product. Product managers receive customer requirements that are usually goal-like at a product strategy level. Requirement engineers study these requirements, check their feasibility, priority, and the cost of implementation, break them down to requirements in lower abstraction, and define well-defined and testable requirements that initiate the development project and lead to implementation of the required functionality in the final product.

We use the requirement abstraction model (RAM) by Gorschek et al. [ 27 ] and define four abstraction levels for requirements: product level, feature level, function level, and component level. Product level is the most abstract level and is comparable directly to the product strategies and indirectly to the organizational strategies. An example of a product-level requirement could be “the system shall provide intrusion detection support”. Feature-level requirements are features that the product should support and are an abstract description of the feature itself. An example requirement at this level is “the system shall provide the possibility to log and report security-related events”. The function level is, as the name suggests, a repository for functional requirements and describes what a user should be able to perform/do, for example, “users shall be able to subscribe remotely to receive logs of security-related events”. The component level is of a detailed nature containing information that is closer to how something should be solved, i.e., on the boundary of design information [ 27 ], e.g., “the feature state is enabled/disabled by changing the featureState parameter”.

Method Overview

The SRA method is designed, inspired by the definition of risk by Kaplan and Garrick [ 28 ] where the risk is defined by the answers to three questions:

What can go wrong?

How likely is it to go wrong?

If it does go wrong, what are the consequences?

To answer these questions, we need to understand the scenario or undesirable event that may occur during a product’s runtime. As shown in Fig.  2 , the SRA method consists of three main steps: risk assessment content establishment, risk identification and estimation, and requirements analysis and specification. The preliminary assumption is that there is a feature-level requirement as a starting point to use SRA.

Risk assessment content establishment starts with requirements engineering team getting a feature-level requirement and determining if it is possible to be implemented, what the different implementation alternatives are, and what these alternatives would cost. One of these alternative solutions is then chosen after discussion with the product manager and the function-level/detailed requirements are identified and documented. Such requirements are of a detailed nature representing information that is closer to a description of how something will be implemented. At this step, it is crucial to ensure the following factors while establishing the risk assessment content:

Security objectives of the software project are known for the requirements engineering team.

Assumptions in terms of the users of the functionality and the environment in which the feature will function are defined.

Initial security status of the underlying system is known (in the case of incremental development) based on the security risk assessment of the legacy system (performed in previous releases).

Use cases of the feature have been identified.

Requirements engineers are familiar with basic security concepts, such as the three key security requirements for any asset, namely, the CIA criteria: Confidentiality, Integrity and Availability in the context of the system they are working with [ 29 ].

Risk identification and estimation is done by going through every detailed requirement, documented during risk assessment content establishment, and identifying assets involved in the required functionality, system entry points. Additionaly, attention is given to attacker’s capabilities in terms of misusing the functionality, likelihood and impact of functionality misuse, and possible misuse cases involving harm to the identified assets. This is done by answering the following questions:

What is the asset (to be protected) in the detailed requirement? An asset is something that is valuable for the feature, for example, the functionality provided by the feature, any new data introduced, variables, control parameters, interfaces, protocols, and/or anything that is included in the use case of the feature.

Who has access to the asset and how? The goal is to identify the actors that have access to the asset identified in question 1, for example, end users, developers, and any outsider who might have access to certain variables/parameters through system entry points are considered to be actors.

Can the actor/user identified in question 2 misuse the asset? Considering system and environmental assumptions as well as confidentiality, integrity, and availability criteria, can anyone harm the asset (any scenario)?

How difficult is it to harm the asset? What is the probability over a certain period (e.g., 1 year) and what is the impact of harm?

The answers to the above-mentioned questions are used to define the risk level using the matrix in Fig.  3 . The flowchart in Fig.  4 shows the overview of the SRA process including the above-mentioned steps. In the following section, we illustrate the use of SRA in an example..

Risk-level matrix

SRA process

Requirement analysis and specification is the last step, where the requirements engineering team uses information of the risks identified for every detailed requirement to fine-tune the use cases covered by the requirement so that the risk would be addressed/prevented. This is done either by reformulating the requirement so that the risk is mitigated, or by defining the corresponding component-level requirements to enforce the risk mitigation.

The flowchart in Fig.  4 shows the overview of the SRA process including the above-mentioned steps. In the following section, we illustrate the use of SRA in an example.

Risk assessment content establishment: Telecom networks consist of several subsystems interacting with each other. These subsystems (nodes) are used by operators to serve their customers (subscribers) with fixed and/or mobile services. The overall system is large and is commercially active over several releases. Consequently, including security in such a system and sustaining security throughout the whole life cycle could be a challenging issue requiring continuous improvements. One example set of features requested by operators is features for self-organizing networks (SON), including self-configuration and self-optimization of the nodes in a telecom network. The self-configuration function enables the network to automatically perform installation procedures (plug and play) on the nodes, and self-optimization enables the network to auto-tune its operational parameters using performance measurements that are either performed by the node itself or received from user equipment (UE) [ 30 ].

One type of functionality that is provided as a part of self-configuration is the automatic neighbor relations (ANR) feature. ANR is a known feature in the telecom industry [ 31 ] for automating operation and maintenance of a specific function (handover functionality) when neighbor nodes provide a telecom service to subscribers jointly. The feature-level requirement in this case is the node shall support ANR functionality .

To initiate the development of this feature, we need to define the detailed requirements at the function level. Some examples of these requirements are presented in Table 1 .

Risk identification and estimation: We start from the first detailed requirement and perform the risk assessment by answering the questions mentioned above.

Detailed Requirement 1

What is the asset? What shall be protected?

Asset: disable/enable functionality of the ANR function on one or multiple nodes.

Who has access to the asset and how?

Operators (who configure the features), using a configuration GUI.

Can the actor/user, identified in the previous question, misuse the asset?

This is not likely since the assumption is that operators will not harm their own products/network.

How difficult is it to harm the asset? What is the probability over a certain time period (e.g., 1 year) and what is the impact of harm?

The probability is “almost impossible”, but the impact is “serious” because the ANR functionality would not be available. According to the matrix in Fig. 3 , this will be a low risk.

Detailed Requirement 2

Asset: ANR measurement results from the selected UE.

End user (using UE).

It is possible that a malicious actor could modify measurement reports.

The probability is “possible” and the impact is “serious”, since the measurement reports are used for certain network planning decisions. This is a medium risk and the requirements engineering team shall revisit the requirement. Depending on the system architecture, there could be different alternatives: for example, if it is possible to get required ANR measurements from a source other than UE the initial design can be modified. If getting measurements via UE is the only way (e.g., as a standard method for all telecom vendors), then an additional requirement shall be defined to validate the received values and minimize the impact of malicious reports.

Detailed Requirement 3

Asset 1: collecting reports functionality.

Asset 2: maximum number of relations (variable).

Developer has access to both assets through the code that implements the functionality and defines the maximum number value.

Only if the implementation is modified, the asset can be misused.

Developer has access to both assets through the code that implements the functionality and defines the maximum number value. The probability is “almost impossible” because the functionality will be tested to ensure that the requirement is fulfilled, and the impact is “serious” since the functionality will not be available and the feature-level requirement will not be fulfilled. This is a low risk according to the risk-level matrix.

Requirement analysis and specification: The results of the risk assessment are shown in Table 2 . This table can be used for residual risk management, helping product managers to decide if the cost of mitigating the risks is acceptable or if the risk is relatively low compared to the mitigation cost and the feature can be delivered as it is. For example, if product management decides to address only the medium risk, it can be addressed in different ways. Example alternatives could be to:

Define a criterion to accept measurement reports from approved UEs and add this as a new detailed requirement. Also adjust detailed requirement 2 to cover the criteria.

Accept the risk of getting untrusted data from some UEs, and to minimize the risk get the reports from more than one UE and compare the values before using them. This will lead to several other detailed requirements.

Note that the table can also be used to track the identified risks during the whole development process. This table is reported as a part of the documentation of the requirement engineering phase.

We introduced the SRA method in a software development process in a telecom company that is developing complex products using agile practices (e.g., Scrum or a combination of other agile flavors). To evaluate the application of SRA and find answers to our research questions, we performed a case study. One reason for choosing a case study as the evaluation method was to study the problem in its context and evaluate how our proposed method was used in this context. Another reason was to develop an understanding on how a process improvement attempt through introduction of SRA was received in real-life industrial setup. The case study context was as follows: the target organization is a large enterprise offering telecom and multimedia solutions in a highly competitive market. The setup of the team is a mix of both co-located and remote workers, distributed in different locations. The company has around a hundred thousand employees and the unit supporting the case study consists of around 150 engineers. The development model is a combination of customer and market-driven processes in the sense that requirements are collected from both existing and potential customers. The market demands highly customized solutions with requirements that are compliant with domain-specific standards. There are dozens of development teams working on the subject project. The project time may vary between 6 and 12 months and the requirements engineering activity may take up to 4 weeks. The projects are integrated with the previous baseline of the system and only one product exists at the time.

The target organization has a security framework that includes security design rules and generic security requirements to be followed and fulfilled during the software development life cycle. Security risk assessment as part of the organizational security framework is performed for all the products in the company portfolio. A central security team consisting of security experts performs security risk assessments on all feature requirements and feeds the findings back to the development process.

We defined the following variables to be studied to answer the research questions:

Deployment of the method in the requirement analysis (during requirements engineering):

Comprehensibility of the documentation introducing the method.

The overhead of applying the method.

Applicability of the method in an industrial setup as explained above in the case study context:

Acceptance by requirements engineers.

Shortcomings and improvement possibilities.

Effects/benefits of applying the method:

Number of identified vs missed risks.

We used a single case study design as defined in [ 32 ], with the telecom company being the overall context and performed the case study in three iterations followed by a final root cause analysis on the findings of the third iteration to identify the way forward, as shown in Fig.  5 and over a period of 4 years. We used the process as described by Runeson et al. to design the case study with a flexible design, based on qualitative data [ 33 ]. The first case started with applying the SRA in a certain context by pilot subjects and the contexts of succeeding cases were adjusted after analyzing the results of the previous cases. The initial state of the iterations was a team of security experts performing the SRA activity. We then examined the consequences of fully distributing this task to non-security-expert requirements engineers, and finally a semi-distributed setup where an SRA forum would perform further analysis of results by requirements engineers if needed.

Case study process

For the first iteration, nine pilot subjects were identified using a focus group [ 34 ] of five technical team leaders, who received a presentation of the goal of the case study and, in an open discussion session moderated by the researcher, nominated candidates to be pilot subjects. The selected subjects had deep knowledge of the software product’s architecture and its value to the customers. The subjects worked either alone or in a team of two or more engineers. The subjects applied SRA during requirements engineering activity and answered a questionnaire about method conformance, domain conformance, and general feedback.

Process conformance questions focused on characterization of the method and an assessment of how it is performed. Domain conformance questions focus on learning about subjects’ knowledge concerning security and requirements engineering, and finally to get general feedback for improving the method.

We analyzed the final feedback from pilot subjects, based on the variables we had defined.

Deployment of the Method

An average of 6 h was spent on performing the risk assessment and documenting the requirements and risks. According to six of the participants, analysis time overhead was considered acceptable with respect to the planned time. One of the participants mentioned that it took a long time to perform the analysis and one of the participants answered that the time could vary based on complexity of the feature. Seven participants saw no specific hindrance to deploying the method, and one of the subjects felt that the study team’s lack of security knowledge could be a major hurdle.

Applicability of the Method

All participants found the method beneficial in finding the risks and that it should be used for all requirements. According to all participants, the introduction presentation was enough to start using the method. In the general feedback, one subject was interested in getting a presentation of the existing security capabilities of the system, as this would help system engineers reuse the already existing mechanisms as risk mitigations. Another suggestion was to provide a list of security best practices to be considered by system engineers when, for example, new attributes and new interfaces are introduced by a feature. The example-driven nature of the method was important for understanding the usability of the method, according to one of the participants.

Effects/Benefits of Applying the Method

One of the participants mentioned that even if there might be no or low security risk, the assessment helped in reaching that conclusion. Only one of the participants was already familiar with security topics and for the rest of them it was their first time thinking about security issues. One of the participants found no risk, four of them identified two medium-level risks each, and the rest identified only low-level risks. Based on the results we concluded that the method could help system engineers to consider the security aspects of technical solutions using the proposed method with minimum overhead. All medium-level risks were reported to product managers to discuss a cost-effective mitigation or to be considered in negotiations with customers if required. Two of the risks resulted in new feature-level requirements from product managers and the rest of them were not prioritized in the upcoming release from a business point of view.

Iteration 2: Case Study with 45 Subjects

After the first iteration was completed, the decision was to extend the scope and apply the method to an entire release project, wherein all of the system engineers on that project would apply the method to all of its features in that project.

Subject and Case Selection

The target release project consisted of 45 features to be implemented and integrated into a legacy telecom product. In this iteration, we provided a 1-h training for all system engineers studying these 45 feature requirements to present the security risk assessment method. We also modified the security impact chapter in the mandatory document that was to be written in the pre-study phase. This document describes the systemization of the feature and includes the list of detailed requirements. The security chapter was updated to require that the results of the security risk assessment be documented and reported in the chapter.

Data Collection

We had three sources for data collection. We used a two-step qualitative data collection method in this iteration, which took the form of a questionnaire to be answered by the subjects, followed by individual interviews to get a more in-depth view of the subjects’ opinions. In parallel, all the reports were systematically reviewed by the central security team and the data provided in the security impact chapter were reviewed. The goal was to analyze the outcome of the modifications to the pre-study process and compare the results of the security risk assessments done by the subjects with the results of the same analysis as performed by the central security team. This approach helped to determine whether all the risks had been identified by the subjects. To ensure ethical considerations, all subjects were informed about the purpose of the activity and asked to give consent on the use of their contributions in this research approach. This included the information they provided about their own technical background and experience.

As with the first iteration, the questionnaire included questions about process conformance (PC), domain conformance (DC), and general feedback (GF).

Process conformance (PC) and general feedback (GF)

The questions on PC and GF, which placed more focus on gathering statistical data about the application of the method, were as follows:

(PC) Did you attend training on the method and the new document template?

(PC) Did you use the proposed method?

Yes: describe the differences you see between this template and the old one.

No: why not?

(PC) How long did it take for you to perform the risk analysis on the detailed requirements and document it? How long was the whole study?

(GF) What are the pros and cons you see in this method, as mentioned in the security impact chapter?

(GF) Talk about your opinion regarding any significant problems that might hinder the deployment and use of the method.

(PC) How much training do you think is needed to be able to use the method?

(PC) Did you identify any risk for your feature and what was the level of the risk?

Yes: what did you do with the risks you identified?

No: why do you think you did not identify any risk?

(GF) What are your suggestions to improve the risk analysis method and instruction document?

(GF) Is there anything more you would like to add?

Questions about the subjects’ pre-knowledge in security and their depth of knowledge about the product were handed out in a separate set.

We organized training sessions and presented the SRA method and examples of how to apply it to all subjects. During the roadshow, we also went through the changes applied to the “security impact” chapter in the pre-study report document template.

After the project was closed, the subjects were asked to answer the questionnaire and then invited to a 30 min interview (for each functional requirement). A total of 41 subjects responded to the questionnaire and participated in interviews. The interview sessions were semi-structured [ 34 ] with a mix of open and closed questions. The interview agenda is:

Meeting starts with a presentation of the interviewer.

The interviewer explains the goal of the interview.

The subject is asked to sign the statement of consent to use the data in the research project.

The subject is asked to present information about their own background.

The subject provides information on what the study is about.

The interviewer walks through the answers provided by the subject and takes notes of the reasons for the answers.

The interviewer provides information on how the data will be analyzed.

The notes from each interview were sent to the subject after the interview for a second review.

The questionnaires were printed, and the answers provided by the respondents were independently analyzed and categorized by the three authors. The independent analyses were subsequently compared and reconciled with only minor inconsistencies noted that could all be resolved through a joint review of the interpretation of the answers and clarifications given in the interviews. There were four categories of subjects as shown in Table 3 .

The studies in which the method was applied were of varying complexity and length. One subject reported having spent 5 min out of 3 months, and another reported having spent half a day out of 2 weeks. A majority (18 out of 26) of the subjects that used the method report having spent 2 h or less on applying the method. Four subjects reported having spent more than 2 h. Four subjects did not answer the question about how much time was spent applying the method. The subject spending half a day out of 2 weeks had not attended the roadshow and reported having to overcome a threshold for using the method for the first time.

In the questionnaire, most respondents provided feedback and suggestions for improvements. The most frequent feedback (from more than half of all subjects) contained a suggestion to introduce a concept of “No impact” to be used when a simple review makes it obvious that the change being studied will not introduce new risks. Other common items of feedback were each expressed by about a quarter of the subjects: suggestions to provide more examples of risks as it might occur in different types of system features, a concern over slip-through or that risks might be introduced in later stages of the process, that the context in which risk was to be assessed needed to be better defined, and mention of the use or need for a subject matter expert to complete the assessment.

In the context of knowledge supply, approximately, one-third of the subjects expressed a need for getting expert support when needed and one-third expected improved/additional training.

Other feedback included suggestions for using structured queries, the need for continuous training, and the need to also consider risks holistically at the system level and not just at the feature level.

Among subjects in categories A and C (see Table 3 ) that have applied the method ( n  = 26), our analysis shows a generally positive or neutral attitude toward the setup. 14 subjects categorized their impression of the method as ‘worked well’ or ‘worthwhile’, while 5 subjects expressed an opinion of ‘not worthwhile’. The remaining seven subjects that used the method did not state any valuation. See Fig.  6 .

Applicability of the method according to subject categories

Of the 15 subjects in categories B and D who did not apply the method, six found the method ‘not worthwhile’ and two found it somehow disturbing. Four subjects had applied parts of the method and thought it ‘worked well’. The remaining three did not express an opinion about the method.

We analyzed the results to list the risks identified by the subjects. The pre-studies were then reviewed by security experts and the cases where additional risks were listed by security experts were identified. Figure  7 shows the number of risks identified by subjects vs. security experts based on subject categories.

Risks found by subject categories vs. security experts

We also went through the collected data to identify the possible benefits of applying this method regarding increasing security awareness among requirements engineers. We were able to categorize the answers into three main categories as in Fig.  8 :

22 subjects who clearly stated that they had no security background and became aware of security and security issues during this case study.

13 subjects who had at least basic security knowledge prior to the case study, but who also found it useful to be given instructions on how to perform security assessments.

Six subjects who did not have basic security knowledge and it was not evident that the proposed approach and case study affected their security awareness.

Security awareness categories

Concluding Remarks: Iteration 2

In this study, we observed that those who have participated in the training and tried to use the method found almost the same number of risks as the security experts. The cost of applying the method was acceptable. When the results were presented to the company, two things were concluded:

The value of making early security risk analysis on a detailed level of requirements is high and should be continued.

However, as many subjects indicated, more training and support from security experts were necessary.

Iteration 3: Additional Expert Support

As mentioned earlier, the initial state for starting the process of proposing our approach was risk assessments of implemented features conducted by a central security team consisting of security experts. We then studied the impact of decentralizing this activity to system engineers with no specialization in security. This way of working continued in the same way as in iteration 2 above with more training and dialog with security experts. Feedback was continually collected. As the final step in the third iteration, we modified the proposal to provide security expert support to system engineers performing the risk assessment when needed.

In this iteration, the risk assessment activity was included as a mandatory checkpoint in the pre-study process during requirement analysis and it was defined as a part of the definition of “done” for the pre-studies. This strengthens the requirements on using the method compared to iteration 2. The security expert team was renamed to security risk assessment (SRA) forum and an improved workflow was defined as shown in Fig.  9 .

SRA workflow

In this workflow, requirement engineers perform a risk assessment according to the method in section “ Security Risk Assessment ” and sends the results to the SRA forum. A security expert then goes through the results and either approves them or identifies the need for expert involvement and in-depth analysis. If necessary, the in-depth analysis is then done in an SRA workshop and the security expert team assists the requirements engineers with in-depth analysis. In this way, there is already a quality control process being performed on the assessments done by the requirements engineers. We applied this process in eight releases projects in the subject organization.

To evaluate the outcome of these changes, we used the statistical data collected by the organization for follow-up purposes. The organization uses this data to go through the pre-study documentations and review the security risk assessment results. As a result of this review, all studies must have a proper security risk assessment documentation, approved by the SRA forum. By analyzing this statistic, we identified three categories of studies:

Studies with missing security risk assessment documentation (no assessment reported in pre-study documentation).

Studies with incomplete security risk assessment data provided in the pre-study documentation and no communication with the SRA forum.

Studies with proper security risk assessment provided in the pre-study document, which had passed through the SRA forum (with the results of the analysis performed by the requirement engineers either being approved directly or after expert involvement through an SRA workshop).

Table 4 shows the statistics for these categories. The requirements engineers responsible for the studies in categories 1 and 2 were invited to a root cause analysis workshop and their input on the causes of identified issues was discussed with them. All the participants were encouraged to share their ideas and give feedback about the method, and a recorder took notes on the board to capture all of the input.

The five whys method [ 36 ] was then used to identify the root causes of the identified issues. The following root causes were identified:

Security awareness/competence: Due to reorganizations, and responsibility relocations, new teams started on the project without getting the planned training on applying the method. The statistics in different releases have a correlation with changes in the organization.

The training material is old and needs to be refreshed and adjusted to the agile teams’ way of working which changes regularly.

The old template for the pre-study document (without the security chapter) was used for documenting the pre-study in some of the studies.

There was a lack of communication to pre-study drivers that it is mandatory to complete the security chapter.

The SRA forum was not sufficiently introduced to the new pre-study drivers.

The pre-study documentation including the security chapter (to include security risk assessment) exists, but is not linked into project management tools, which led to missing documentation when working on the statistics above.

The method is focused on the new (delta) functionality in the product, since the new requirements are used as an input to the security risk assessment. However, the study driver must have access to the security risks that were identified for the legacy system when the new feature is an incremental change in functionality.

Based on these findings several corrective actions were identified: security guardian(s) were appointed in each project to ensure that the security risk assessment would be in place before respective project milestones/checkpoints. The guardian also supports the function of the security risk assessment forum representing the respective project. Security guardians are project managers that ensure mandatory project activities are performed, including security.

It was ensured that the release project checklist is updated and includes security risk assessment as a mandatory checkpoint to pass. It was also ensured that the SRA forum representative is invited to the final review of the pre-study documentation. Training material was updated and the training program was improved to include SRA forum information to cover all new engineers. It was ensured that the documentation template would be updated as required.

We also analyzed the email throughput in the SRA forum mailbox and listed the statistics about the emails sent to the SRA forum by unique individual senders (requests for SRA forum support) as shown in Fig.  10 . The increasing trend in the number of emails can be interpreted as a sign of increased security awareness among pre-study drivers and the increasing number of security risk assessments performed for studies that require approval from the SRA forum.

Statistics on number of emails sent to SRA forum by unique individual senders

We proposed the application of a method in a telecom company and studied different aspects of introducing such a method in the context of the target company. This approach examined the target company's journey through several steps of changes, based on a continuous improvement mindset.

The journey started from an initial status of security risk assessments being performed by a centralized team of security experts who did not have deep technical knowledge of the lower abstraction level of the respective functionality of the system under assessment. This assessment was performed in requirement verification. During our research journey, we examined introducing security risk assessment activity to be performed during requirements engineering and through a completely distributed approach, by letting requirements engineers with deep technical knowledge, but no specialization in security, perform the assessment. One of the goals was to ensure that introduction of security considerations into the product’s functionality as early as possible, and the other goal was to eliminate the bottleneck of a central team conducting the security assessment activity for all features of the project. In the third round, the approach was modified to examine a cooperative setup involving both individual requirements engineers as well as the central security team. The first iteration of our case study can be defined as exploratory [ 33 ], which helped us to find out how the requirements engineering was performed and if SRA could be applied by pilot subjects. The output from this study led us to the idea of training subjects on how to apply SRA and study the outcome in the second iteration. The second iteration could be defined as explanatory [ 33 ], as it was used to seek an explanation of the outcome of iteration 1 (subjects performing SRA without receiving any training) with the case where subjects did get a training on the method. The output from this study helped us to define the type of support needed by security experts. The third iteration focused on a descriptive study of the organization in the last 2 years with requirements engineers using the SRA method and improved the application of the method by involving security experts to triage when needed.

The results of our extensive case study allowed us to answer the research questions we had defined:

What are the difficulties of introducing such a method in a big organization that is developing complex systems? We realized in each case study iteration that by adding SRA to the existing way of working and to the development artifacts in the company, the application of the method is impacted by the efficiency/deficiency of the original artifacts. Changes in the organization must also be monitored to adjust the proposed method.

When performing security risk assessment, can we bridge the gap between security experts and requirement engineers who are not specialized in security? In that case, what is an efficient distribution of tasks between security experts and requirement engineers? The case study showed that expert involvement could not be eliminated to ensure that the quality of the risk assessment is acceptable and that all risks are identified. Based on this finding, we also learned that changes of this type must be managed over time to achieve the desired results. It was also observed that the bottleneck issue could be solved in a cooperative approach and, as we see in the results of iteration 2, most subjects reported manageable overhead with respect to total time of the pre-study. Considering the increasing number of features to be implemented (see Table 4 ) in a project, the overhead factor became important.

What considerations (introduction or training) are needed for engineers to achieve acceptable results? During all iterations of the case study, one of the main elements of feedbacks we received was related to training and providing examples and background material for requirement engineers as well as the possibility of supervision/consulting supported by security experts. The results clearly showed that having basic security knowledge, as well as understanding the purpose and expected outcome of the security risk assessment is a crucial prerequisite to achieving the desired results. It is also important to ensure that training is refreshed continuously and is adapted to the changes in the organization, development processes, and daily way of working. Note that the emphasis in our case study has always been on basic security knowledge and understanding what security principles are in terms of confidentiality, integrity, and availability rather than knowledge of sophisticated attack patterns, threat models, etc.

In summary, despite all obstacles, comparing the initial state with the existing state, we see an obvious increase in security awareness in the company and among developers, since everyone is expected to see security considerations as a part of the functional requirements to be developed in the final product. We have effectively shifted security risk assessment that had previously been done in later stages of the development to the earliest stage where the requirements are elicited to implement the functionality. Through the continuous improvement process, we managed to reform the central team of subject matter experts, who were serving the development activities in a support function to the SRA forum that acts in a corrective function.

As stated by Runeson et al. [ 33 ], about the nature of the case studies, the case study methodology can primarily be used for exploratory purposes, but it can be used for explanatory and descriptive purposes if the generalizability of the situation or phenomenon is of secondary importance. During design and implementation of the case studies, our assumption was that the results could be transferable, and we believe the results provided a deeper understanding of the phenomena under study. We also believe that providing the details of factors defining the context of cases study (the size of the company, complexity of the product, the type of development process, the size of the project, and the abstraction level of requirements) supports transferability goals. It allows the readers of our results to make inferences about how our findings match their context and which part of our solution can be transferred to their respective settings [ 35 ]. Any software or system which has interfaces and/or is communicating with its surrounding is subject to risks and needs a security risk assessment to be prepared for being resilient. SRA can be performed on any system and in any abstraction level, on a whole system within its boundaries or on the components of any system and is not limited to telecom products.

We analyzed the validity threats of our results based on Runeson et al.’s checklist [ 33 ]. For construct validity and to ensure that researcher and subjects have the same interpretation of the operational measures, we used both questionnaire and interview sessions to go through the answers to the questionnaire. The case study design and three different iterations of the case study contribute to the internal validity and help to ensure that various factors are considered in the findings. This includes the factors of the technical background and security competence of the subjects, as well as the organizational way of working and processes that are already in place, but which may differ from project to project. The same characteristics of our approach help with analysis of the external validity, since it is performed by different subjects in different projects over an extended period of time. To support the reliability of the findings, all steps of the case study activities were designed and reviewed by three researchers, and to reduce bias by individual researchers, we conducted data analysis after the third iteration by three researchers independently.

Related Work

To identify related work in risk-based requirements engineering, we performed a literature review and went through the publications on research approaches to security risk assessments applied in requirements engineering as well as similar empirical studies. During this literature study, we compared the novelty of our contribution with existing research contributions, considering that:

We use security risk assessment in requirement analysis of all functional requirements, not just security requirements.

Our focus is on assets at a lower abstraction level than similar approaches, which start mostly from strategic interests of stakeholders or objectives. Going from system-level to subsystem-level analysis highlights the functional aspects of the solution to be developed that might be missed in higher-level analysis [ 37 ]. Identifying risks at this level helps us to refine the solution to counter the risk by choosing a security-tuned solution.

We emphasize the technical knowledge of requirements engineers supported with security training and security expert consulting (when needed), to distribute the overhead of security activities instead of using the limited resource of security experts.

We have empirically verified the proposed approach in an industrial setup, over the course of several years and in large-scale software development projects using agile methods. This has provided a good understanding and lessons learned about the realities of introducing such approaches in a real-life setup.

Identifying system assets, formulating significant threats to the software system, and associating the probability and impacts of risks with the system requirements have been presented in several articles and in various dimensions [ 8 , 9 , 10 , 11 , 12 , 38 ]. Franqueira et al. introduce an agile security risk management approach that addresses the topic of performing risk assessments in development process iterations. This approach focuses on supporting decision making on mitigations to be incorporated into the next iteration of development [ 8 ]. Asnar et al. propose a goal-oriented approach for analyzing risks along with stakeholder interests and identify countermeasures as a part of system requirements [ 13 ]. In a similar approach, Mayer et al. [ 9 ] propose using risk analysis in security requirements engineering of information systems that focus on business assets. Firesmith [ 22 ] presents different types of security requirements and provides guidelines for system engineers to specify security requirements. These guidelines are used to ensure that security requirements are not confused with architectural security mechanisms. Our approach is similar to these works in that it focuses on the knowledge of system engineers rather than security engineers. Laoufi [ 10 ] also aims at identification of security requirements for information systems from risk analysis and uses ontologies to do so. He also focuses only on security requirements and no empirical evaluation of his approach is presented. All the approaches mentioned aim at identifying security requirements using security risk assessment, compared to our approach that applies risk assessment to all requirements, resulting in requirements that have been fine-tuned for security. In this way, we ensure that the security considerations are built into the requirements and consequently into design of the system under development.

Note that there are various definitions for security requirements in the requirements engineering and security engineering communities. Within requirements engineering, security is often classified as a non-functional requirement [ 39 , 40 ]. An example from the security engineering community, common criteria (CC) [ 41 ] distinguishes between two types of security requirements: functional and assurance. Security functional requirements describe security properties that users can detect by direct interaction with the system or by the systems’ response to stimulus. Security assurance requirements are process requirements that require active investigation and evaluation by the IT system to determine their security properties [ 42 ].

We agree with the statement that “no common agreement exists on what a security requirement is” [ 23 ] and various approaches [ 22 , 24 ], [ 43 , 44 , 45 , 46 , 47 ] define different extents for security considerations covered by security requirements and different levels of details on how to cope with security requirements. In our approach, we do not separate security and non-security requirements; instead, we propose to define and “security-tune” function-level requirements after considering the relevant security risks. Considering security, as a part of designing the solution will ensure that security aspects are not ignored. Haley et al . [ 43 ] recommend security requirements “… to express what is to happen in the given situation, as opposed to what is not ever to happen in any situation.” In our approach, we use the same mindset and propose risk analysis for every detailed requirement, considering the context in which the requirement is to be implemented.

Focusing on the assets, in a similar approach to ours, Vasilevskaya et al. use risk assessment (consequence assessment) to decide which asset to prioritize for protection, and this is used as an input to selection of security mechanism to protect the asset in embedded systems [ 48 ]. This approach also combines security expertise with embedded system engineering knowledge, although the approach does not target requirements engineering.

We reuse the concept of misuse cases [ 49 ] to detect the possibilities to abuse the functionality and identify the risks. Misuse cases are introduced by Sindre et al. [ 50 ] and extend traditional use cases by specifying behavior not wanted in the proposed system. Mwambe and Echizen [ 51 ] focus on supporting information systems security during the design phase. As an extension of unified modeling language (UML) activity diagrams, mal-activity diagrams (MAD) have also been used to model malicious and risk mitigation processes.

In our literature review and going through the relevant survey studies on information security risk analysis and security requirements engineering such as [ 52 , 53 ], we found some similar empirical studies with industrial setups. Oyetoyan et al. [ 11 ] presented an empirical study with an extensive presentation of the case study and its results with partially overlapping research question. Challenges of applying threat modeling in agile development are presented by Cruzes et al . [ 54 ]. This approach uses a similar research method to ours and presents challenges to adoption of threat modeling as a security practice in a smaller development organization. The challenges identified by this contribution are mapped to our findings in some of the cases such as challenges with having distributed teams or the importance of providing security expert support in certain discussions.

Morrison et al. [ 55 ] surveyed several security-focused open source projects to collect evidences on adherence to the number of software development security practices. According to their findings, training is positively correlated with the use of these practices and we see a similar finding in our work as well: training system engineers improves the use of security risk assessment as a security best practice. In a similar way, we also observed that the use of a simplified security risk assessment method that is designed with ease of use in mind is impacted by various factors.

Security has become a critical part of nearly every software engineering project and identifying and performing proper activities to ensure security is one of the challenges of software vendors. The work presented in this article proposes the introduction of a risk assessment method in requirement engineering and studies the realities and challenges of applying this method in a real-life industrial setup. The goal of this validation step was to see if it is possible with a small effort to introduce such a risk assessment approach. In this approach, requirements engineers who are not specialized in security attempt to efficiently find security risks early in the development process as well as to gather information on the outcome. Lessons learned from this validation activity showing the need of systematic interaction between security experts and requirements engineers may provide a basis for being prepared and facilitating similar approaches.

The risk-based requirements engineering method provides incentives in the sense that system engineers find the risks involved with their proposed solutions immediately. When developing solutions, they can react accordingly by fine-tuning the solution or by adding new requirements. This is an immediate perceived benefit and is one of the factors that increases the acceptance of the method. In our industrial case study, we examined the applicability and usability of the method when used by distributed teams, developing complex products in agile ways. We started on a small scale, iteratively improved the application of the method, and increased the scale.

For future work, we are focusing on applying the method in a different organization to measure the correlation in findings. The next step of our research is to analyze the quality and quantity of risks identified by the subjects and compare them to similar case studies with security experts as the subjects. This could be performed in a quantitative approach to identify the risk coverage of the method. Another area to be considered as future work is to create a database of different types of known security risks which can be used as a reference during the assessment performed by requirement engineers. Such a database would of course need to be supported by known security modeling methods such as various threat models, attack trees [ 5 ], etc. to ease the navigation and usage. SRA is not limited to identify a specific type of risks and answering the mentioned three questions and the type of risk to the identified assets can result in any type of risks. By providing a starting point for requirement engineers through a list of example risks for similar systems, there is a possibility to minimize the probability of missing a risk type.

Data Availability

No raw data is available.

Code Availability

Not applicable.

McGraw G. Software security. IEEE Secur Priv. 2004;2(2):80–3.

Article   Google Scholar  

Howard M. Building more secure software. IEEE Secur Priv. 2004;2(6):63–5.

Ardi S, Byers D and Shahmehri N Towards a structured unified process for software security, Proc. Int. Workshop on Software Engineering for Secure Systems (SESS), Shanghai, China, pp. 3–10. (2006)

Lipner S. B The trustworthy computing security development lifecycle, Proc. ACSAC 04, 20 th Annual Computer Security Applications Conference, Tucson, USA, pp. 2–13. (2004)

McGraw G. Software Security: Building Security In. Boston: Addison-Wesley; 2006.

Viega J, McGraw G (2011) Building Secure Software: How to Avoid Security Problems the Right Way. Boston: Addison-Wesley; 2011.

McGraw G, Migues S, West J, (2018) Building Security In Maturity Model (BSIMM 8), https://www.bsimm.com/ . Accessed 2020–02–10

Franqueira V.N.L, Bakalova Z, Than Tun T, Daneva Towards agile security risk management in RE and beyond, Proc. 1st Int. Workshop on Empirical Requirements (EMPIRE), Trento, Italy, pp. 33–36. (2011)

Mayer N, Rifaut A, Dubois E Towards a risk-based security requirement engineering framework, Proc. 11th Int. Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ'05), Los Alamitos, USA, pp 83–97. (2005)

Laoufi N, From risk analysis to the expression of security requirements for systems information, Proc. Fourth International conference on Cyber security, cyber warefare and digital forensics, Jakarta, Indonesia, pp 84–89. (2015)

Oyetoyan T. D, Soares Cruzes D, Gilje Jaatun M, An empirical study on relationship between software security skills, usage and training needs in agile settings, International Conference on Availability, Reliability and Security, Salzburg, Austria, pp 548–555. (2016)

Savola R. M, Väisänen T, Evesti A, Savolainen P, Kemppainen J, Kokemäki M. Towards risk-driven security measurement for android smartphone platform, International Information Security South Africa conference, Johannesburg, South Africa, pp. 1–8. (2013)

Asnar Y, Giorgini P, Mylopoulos J. Goal-driven risk assessment in requirements engineering. Requir Eng. 2011;16(2):101–16.

Howard M, Lipner S. The security development lifecycle. Redmond, Washington: Microsoft Press; 2006.

Google Scholar  

The CLASP application security process. Secure Software Inc. 2005. https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf . Accessed 23 Jun 2023.

Guide for conducting risk assessment, NIST Special Publication 800–30, https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf . Accessed 23 Jun 2023.

ISO/IEC 27000: https://www.iso.org/standard/73906.html . Accessed 23 Jun 2023.

ISC2 Cybersecurity workforce study (2019), https://www.isc2.org/Research/Workforce-Study . Accessed 23 Jun 2023.

Herrmann A, Morali A RiskREP: Risk-Based Security Requirements Elicitation and Prioritization, Proc. Perspectives in Business Informatics Research, Riga, Latvia, pp. 155–162. (2011)

Umarji M, Seaman C. Predicting acceptance of software process improvement. SIGSOFT Softw Eng Notes. 2005;30(4):1–6.

Borg A, Yong A, Carlshamre P, Sandahl K The bad conscience of requirements engineering: an investigation in real-world treatment of non-functional requirements, Proc. 3rd International Conference on Software Engineering Research and Practice in Sweden (SERPS'03), pp. 1–8. (2003)

Firesmith DG. Engineering security requirements. J Object Technol. 2003;2(1):53–68.

Tondel A, Gilje Jaatun M, Meland PH. Security requirements for the rest of us: a survey. IEEE Softw. 2008;25(1):20–7.

Mead N.R, Houg E.D, Stehny T.R, Security quality requirements engineering (SQUARE) methodology, Software Eng. Inst. Carnegie Mellon University, Techncial Report CMU/SEI-2005-TR-009. (2005)

Luburic N, Sladic G, Milosaljevic B Applicability issues in security requirements engineering for agile development, Proc. International Conference on Applied Internet and Information Technologies, Bitola, Macedonia, DOI: https://doi.org/10.20544/AIIT2018.I02. (2018)

Poller A, Kocksch L, Turpe S, EPP F. A, Kinder-Kurlansa K. Can security become a routine?: A study of organizational changes in an agile software development group, Cumputer Supported Cooperative Work (CSCW), Portland, Oregon, USA, pp 2849-2503

Gorschek T, Wohlin C. Requirements abstraction model. Requirements Eng. 2007;11(1):79–101.

Kaplan S, Garrik BJ. On the quantitate definition of risk. Risk Anal. 1981;1(1):11–27.

Stalling W, Brown L. Computer security, principles and practice. Hoboken: Prentice hall; 2007.

http://www.3gpp.org/SON , Accessed 2021–03–09

http://www.3gpp.org/ftp/Specs/html-info/25484.htm , Accessed 2021–03–09

Yin R. K Case study research: Design and Methods, Fourth Edition, Applied Social Research Methods Series. (2009)

Runeson P, Höst M. Guidelines for conducting and reporting case study research in software engineering. J Empirical Softw Eng Springer. 2009;14(2):131–64.

Kitzinger J. Qualitative research: introducing focusgroups. BMJ. 1995. https://doi.org/10.1136/bmj.311.7000.299 .

Polit DF, Tatano Beck C. Generalization in quantitative and qualitative research: myths and strategies. Int J Nurs Stud. 2010;47(11):1451–8.

Samuel JB, Marathamuthu MS, Murugaiah U. The use of 5-WHYs technique to eliminate OEE’s speed loss in a manufacturing firm. J Qual Maint Eng. 2015;21(4):419–43.

Alexander I. Misuse cases: use cases with hostile intent. IEEE Softw. 2003;20(1):58–66.

Salehie M, Pasquale L, Omoronyia I, Ali R, and Nuseibeh B Requirements-driven adaptive security: Protecting variable assets at runtime, 20th IEEE International Requirements Engineering Conference (RE), Chicago, IL, USA, pp. 111-120. (2012)

Chung L, Nixon BA, Yu E, Mylopoulos J. Non-functional requirements in software engineering. Dordrecht: Kluwer Academic Publishers; 2000.

Book   MATH   Google Scholar  

Burge J, Brown D (2002) NFRs: fact or fiction? Worcester Polytechnic Institute, Technical Report, WPI-CS-TR-02–01.

http://commoncriteriaportal.org . Accessed 2019–03–30

Wilander J, Gustavsson J Security requirements - a field study of current practices, E-Proc. The Symposium on Requirements Engineering for Information Security (SREIS), Paris, France. (2005)

Haley CB, Laney R, Moffett J, Nuseibeh B. Security requirements engineering: a framework for representation and analysis. IEEE Trans Softw Eng. 2008;34(1):133–53.

Apvrille A, Pourzandi M. Security software development by example. IEEE Secur Priv. 2005;3(4):10–7.

Boström B, Wäyrynen J, Boden M (2006) Extending XP practices to support security requirements engineering International Workshop on Software Engineering for Secure Systems (SESS). Shanghai, pp. 11–18

Souag A, Mazo R, Salinesi C, Comyn-Wattiau I. Using the AMAN-DA method to generate security requirements: a case study in the maritime domain. Requirements Eng. 2018;23(1):557–80.

Villamizar H, Kalinowski M, Garcia A, Mendez D. An efficient approach for reviewing security-related aspects in agile requirements specifications of web applications. Requirements Eng. 2020;25:439–68.

Vasilevskaya M, Nadjm-Tehrani S Model-based Security Risk Analysis for Networked Embedded Systems, Proc. The 9th International Conference on Critical Information Infrastructures Security (CRITIS) Limassol, Cyprus, pp. 381–386. (2014)

Hope P, McGraw G, Anton AI. Misuse and abuse cases: getting past the positive. IEEE Secur Priv. 2004;2(3):90–2.

Sindre G, Opdahl A.L Eliciting security requirements with misuse cases, Proc. 37th International Conference on Technology of Object Oriented Languages and Systems (TOOLS-37’00) Sydney, Australia, pp. 120–131. (2000)

Mwambe O, Echisen I Security oriented malicious activity diagrams to support information systems security, International conference on advanced information networking and applications workshop Taipei, Taiwan, pp. 74–81. (2017)

Behnia A, Abd Rashid R, Chaudhry JA. A survey of information security risk analysis methods. Smart Comput Rev. 2012;2(1):79–64.

Souag A, Mazo A, Salinesi C, Comyn-Wattiau I. Reusable knowledge in security requirements engineering: a systematic mapping study. Requirement Eng. 2016;21:251–83.

Cruzes D, Gilje Jaatun M, Bernsmed K, Tondel I.A Challenges and experinces with applying Microsoft Threat Modeling in Agile Development Projects, 25 th Australasian Software Engineering Conference, Adelaide, Australia, pp. 111–120. (2018)

Morrison P, Smith B.H, Williams L Surveying security practice adherence in software development, Proc. of the Hot Topics in Science of Security: Symposium and Bootcamp, ACM International Conference Proceeding Series Part F127186, New York, USA, pp. 85–94. (2017)

Download references

Acknowledgements

Funding for this work was provided from Ericsson AB and Linköping University. Proofreading of a late draft of the article was done by Brittany Shahmehri and David Partain.

Open access funding provided by Linköping University. This research was funded by Ericsson AB and Linköping University.

Author information

Authors and affiliations.

Ericsson AB, Linköping, Sweden

Shanai Ardi & Mats Gustafsson

Department of Computer and Information Science, Linköping University, Linköping, Sweden

Kristian Sandahl

You can also search for this author in PubMed   Google Scholar

Contributions

A comprehensive description of the security risk assessment (SRA) method; a longitudinal case study of introducing SRA in a large organization; a survey of related work.

Corresponding author

Correspondence to Kristian Sandahl .

Ethics declarations

Conflict of interest.

Ardi and Gustafsson are both employed at Ericsson AB, full time. Sandahl is employed full time at Linköping University and is a senior member of IEEE.

Additional information

Publisher's note.

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Rights and permissions

Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/ .

Reprints and Permissions

About this article

Ardi, S., Sandahl, K. & Gustafsson, M. A Case Study of Introducing Security Risk Assessment in Requirements Engineering in a Large Organization. SN COMPUT. SCI. 4 , 488 (2023). https://doi.org/10.1007/s42979-023-01968-x

Download citation

Received : 28 June 2021

Accepted : 27 May 2023

Published : 27 June 2023

DOI : https://doi.org/10.1007/s42979-023-01968-x

Share this article

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Requirements analysis
• Risk assessment
• Process improvement
• Find a journal
• Publish with us