security risk assessment case study

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 )

Cite this article

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  

3416 Accesses

Explore all metrics

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.

Similar content being viewed by others

A Security Requirement Engineering Case Study: Challenges and Lessons Learned

Identifying Security Requirements Body of Knowledge for the Security Systems Engineer

Risk-Based Elicitation of Security Requirements According to the ISO 27005 Standard

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
• Track your research

Help | Advanced Search

Computer Science > Computers and Society

Title: information security risks assessment: a case study.

Abstract: Owing to recorded incidents of Information technology inclined organisations failing to respond effectively to threat incidents, this project outlines the benefits of conducting a comprehensive risk assessment which would aid proficiency in responding to potential threats. The ultimate goal is primarily to identify, quantify and control the key threats that are detrimental to achieving business objectives. This project carries out a detailed risk assessment for a case study organisation. It includes a comprehensive literature review analysing several professional views on pressing issues in Information security. In the risk register, five prominent assets were identified in respect to their owners. The work is followed by a qualitative analysis methodology to determine the magnitude of the potential threats and vulnerabilities. Collating these parameters enabled the valuation of individual risk per asset, per threat and vulnerability. Evaluating a risk appetite aided in prioritising and determining acceptable risks. From the analysis, it was deduced that human being posed the greatest Information security risk through intentional/ unintentional human error. In conclusion, effective control techniques based on defence in-depth were devised to mitigate the impact of the identified risks from risk register.

Submission history

Access paper:.

• Other Formats

References & Citations

• Google Scholar
• Semantic Scholar

DBLP - CS Bibliography

Bibtex formatted citation.

Bibliographic and Citation Tools

Code, data and media associated with this article, recommenders and search tools.

• Institution

arXivLabs: experimental projects with community collaborators

arXivLabs is a framework that allows collaborators to develop and share new arXiv features directly on our website.

Both individuals and organizations that work with arXivLabs have embraced and accepted our values of openness, community, excellence, and user data privacy. arXiv is committed to these values and only works with partners that adhere to them.

Have an idea for a project that will add value for arXiv's community? Learn more about arXivLabs .

The Ohio State University

• BuckeyeLink
• Search Ohio State

The Security Risk Assessment Handbook: A Complete Guide for Performing Security Risk Assessment

Information Security Risks Assessment: A Case Study

2018, ArXiv

Owing to recorded incidents of Information technology inclined organisations failing to respond effectively to threat incidents, this project outlines the benefits of conducting a comprehensive risk assessment which would aid proficiency in responding to potential threats. The ultimate goal is primarily to identify, quantify and control the key threats that are detrimental to achieving business objectives. This project carries out a detailed risk assessment for a case study organisation. It includes a comprehensive literature review analysing several professional views on pressing issues in Information security. In the risk register, five prominent assets were identified in respect to their owners. The work is followed by a qualitative analysis methodology to determine the magnitude of the potential threats and vulnerabilities. Collating these parameters enabled the valuation of individual risk per asset, per threat and vulnerability. Evaluating a risk appetite aided in prioritising...

Related Papers

Adrian Munteanu

Encyclopedia

Ievgeniia Kuzminykh

Chanchala Joshi

With the increasing need of securing organization's computing environment, a security risks management framework is essentially needed that define the security risks management process accurately. In this regard, numerous risks management frameworks have been developed, and many more are emerging every day. They all have very different perspectives and addressing problems differently, though with the same basic goal of risks mitigation in direction of information security. Information is a critical asset for every organization and hence development and implementation of strategic plans for information security risks mitigation should be an essential part of every organizations operation. This paper compares and analyzes the different activities, inputs and outputs required by each information security risk assessment models. The primary goal of the paper is to identify which information security risk assessment model assesses information security risk effectively. The comparative study helps in evaluating the models' applicability to an organization and their specific needs.

10 International Conference on Cyber Security and Computer Science (ICONCS 18), 2018

Berker Kilic

Nowadays risks related to information security are increasing each passing day. Both public enterprises and private sector are working on information security to provide information security. It is inevitable that the institutions must use the most appropriate methodology and tools for their own needs and legal responsibilities to provide information security. Particularly Personal Data Protection Law, the legal regulations and the development of cybersecurity risks oblige the public institutions and enterprises to establish information security management systems. In this study, methodology and tools covered under the Risk Management / Risk Assessment methodology and tools within the European Union Agency For Network and Information Security (ENISA)'s Threat and Risk Management studies are investigated. In the study, the seventeen methods and thirty one tools which are studied by ENISA on the inventory work are introduced on the basic level. The methods and tools are compared among themselves in different aspects such as the type of risk classification, the reference level, the definition of applicability, the lifecycle, the usage of them licensed.

Journal of Information Systems Engineering and Business Intelligence

Rias Kumalasari Devi

Background: Information security is essential for organisations, hence the risk assessment. Information security risk assessment (ISRA) identifies, assesses, and prioritizes risks according to organisational goals. Previous studies have analysed and discussed information security risk assessment. Therefore, it is necessary to understand the models more systematically. Objective: This study aims to determine types of ISRA and fill a gap in literature review research by categorizing existing frameworks, models, and methods. Methods: The systematic literature review (SLR) approach developed by Kitchenham is applied in this research. A total of 25 studies were selected, classified, and analysed according to defined criteria. Results: Most selected studies focus on implementing and developing new models for risk assessment. In addition, most are related to information systems in general. Conclusion: The findings show that there is no single best framework or model because the best framew...

Information security risk assessment (RA) plays an important role in the organization’s future strategic planning. Generally there are two types of RA approaches: quantitative RA and qualitative RA. The quantitative RA is an objective study of the risk that use numerical data. On the other hand, the qualitative RA is a subjective evaluation based on judgment and experiences which does not operate on numerical data. It is difficult to conduct a purely quantitative RA method, because of the difficulty to comprehend numerical data alone without a subjective explanation. However, the qualitative RA does not necessarily demand the objectivity of the risks, although it is possible to conduct RA that is purely qualitative in nature. If implemented in silos, the limitations of both quantitative and qualitative methods may increase the likelihood of direct and indirect losses of an organization. This paper suggests a combined RA model from both quantitative and qualitative RA methods to be u...

Journal of International Commercial Law and Technology

Verine Etsebeth

Reliability Engineering & System Safety

Sergio Guarro

Compunet ( The Egyptian Information Journal )

Mohamed El Hadi

RELATED PAPERS

Steven Gurley

angel barba velez

ELAHMAR Sid Ahmed , Benotmane Noureddine

International Journal of Physical Education & Sports Sciences

jai bhagwan singh

Journal of Entrepreneurship and Innovation in Emerging Economies

Elizabeth Ajayi

Essex文凭证书 埃塞克斯大学毕业证

出售英国伯明翰城市大学 bcu毕业证毕业文凭证书托业成绩单原版一模一样

hgvfgd ghtgf

MIX Sustentável

Valderi Leite

Revista Ciências & Ideias ISSN: 2176-1477

Alexandre Lopes de Oliveira

European Neuropsychopharmacology

Ali H Rafati

Microporous and Mesoporous Materials

D. Kostadinova

BMGN - Low Countries Historical Review

janny de jong

International Journal of Pediatrics

Sombat Tapanya

Vinay Ready

Brazilian Journal of Cardiovascular Surgery

Ahmet Elibol

H.G. Georgiadis

Journal of Vacuum Science & Technology B: Microelectronics and Nanometer Structures

Niels Sondergaard

Juan Ricardo Palacio

Combinatorial Chemistry & High Throughput Screening

Alain MUSELLI

RELATED TOPICS

•   We're Hiring!
•   Help Center
• Find new research papers in:
• Health Sciences
• Earth Sciences
• Cognitive Science
• Mathematics
• Computer Science
• Academia ©2024

Information Security Risks Assessment: A Case Study

Owing to recorded incidents of Information technology inclined organisations failing to respond effectively to threat incidents, this project outlines the benefits of conducting a comprehensive risk assessment which would aid proficiency in responding to potential threats. The ultimate goal is primarily to identify, quantify and control the key threats that are detrimental to achieving business objectives. This project carries out a detailed risk assessment for a case study organisation. It includes a comprehensive literature review analysing several professional views on pressing issues in Information security. In the risk register, five prominent assets were identified in respect to their owners. The work is followed by a qualitative analysis methodology to determine the magnitude of the potential threats and vulnerabilities. Collating these parameters enabled the valuation of individual risk per asset, per threat and vulnerability. Evaluating a risk appetite aided in prioritising and determining acceptable risks. From the analysis, it was deduced that human being posed the greatest Information security risk through intentional/ unintentional human error. In conclusion, effective control techniques based on defence in-depth were devised to mitigate the impact of the identified risks from risk register.

Samuel Cris Ayo

Bonaventure Ngala

Olasunkanmi Amzat

Robin Lal Khoshi

Samarappulige Isuru Madusanka

Related Research

Assessing risks and modeling threats in the internet of things, risk assessment graphs: utilizing attack graphs for risk assessment, finding security threats that matter: an industrial case study, a continuous risk assessment methodology for cloud infrastructures, psp framework: a novel risk assessment method in compliance with iso/sae-21434, abc: a cryptocurrency-focused threat modeling framework, a model for android and ios applications risk calculation: cvss analysis and enhancement using case-control studies.

Please sign up or login with your details

Generation Overview

AI Generator calls

AI Video Generator calls

AI Chat messages

Genius Mode messages

Genius Mode images

AD-free experience

Private images

• Includes 500 AI Image generations, 1750 AI Chat Messages, 30 AI Video generations, 60 Genius Mode Messages and 60 Genius Mode Images per month. If you go over any of these limits, you will be charged an extra $5 for that group.
• For example: if you go over 500 AI images, but stay within the limits for AI Chat and Genius Mode, you'll be charged $5 per additional 500 AI Image generations.
• Includes 100 AI Image generations and 300 AI Chat Messages. If you go over any of these limits, you will have to pay as you go.
• For example: if you go over 100 AI images, but stay within the limits for AI Chat, you'll have to reload on credits to generate more images. Choose from $5 - $1000. You'll only pay for what you use.

Out of credits

Refill your membership to continue using DeepAI

Share your generations with friends

The Risk Assessment Case Study

Unified Security and Safety Risk Assessment - A Case Study on Nuclear Power Plant

Ieee account.

• Change Username/Password
• Update Address

Purchase Details

• Payment Options
• Order History
• View Purchased Documents

Profile Information

• Communications Preferences
• Profession and Education
• Technical Interests
• US & Canada: +1 800 678 4333
• Worldwide: +1 732 981 0060
• Contact & Support
• About IEEE Xplore
• Accessibility
• Terms of Use
• Nondiscrimination Policy
• Privacy & Opting Out of Cookies

A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity. © Copyright 2024 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.

To read this content please select one of the options below:

Please note you do not have access to teaching notes, risk assessment of digital library information security: a case study.

The Electronic Library

ISSN : 0264-0473

Article publication date: 6 June 2016

This paper uses the GB/T20984-2007 multiplicative method to assess the information security risk of a typical digital library in compliance with the principle and thought of ISO 27000. The purpose of this paper is to testify the feasibility of this method and provide suggestions for improving information security of the digital library.

Design/methodology/approach

This paper adopts convenience sampling to select respondents. The assessment of assets is through analyzing digital library-related business and function through a questionnaire which collects data to determine asset types and the importance of asset attributes. The five-point Likert scale questionnaire method is used to identify the threat possibility and its influence on the assets. The 12 respondents include directors and senior network technicians from the editorial department, comic library, children’s library, counseling department and the learning promotion centre. Three different Guttman scale questionnaires, tool testing and on-site inspection are combined to identify and assess vulnerabilities. There were different Guttman scale questionnaires for management personnel, technical personnel and general librarian. In all, 15 management librarians, 7 technical librarians and 72 ordinary librarians answered the vulnerability questionnaire. On-site inspection was conducted on the basis of 11 control domains of ISO 27002. Vulnerabilities were scanned using remote security evaluation system NSFOCUS. The scanning covered ten IP sections and a total of 81 hosts.

Overall, 2,792 risk scores were obtained. Among them, 282 items (accounting for 10.1 per cent of the total) reached the high risk level; 2 (0.1 per cent) reached the very high risk level. High-risk items involved 26 threat types (accounting for 44.1 per cent of all threat types) and 13 vulnerability types (accounting for 22.1 per cent of all vulnerability types). The evaluation revealed that this digital library faces seven major hidden dangers in information security. The assessment results were well accepted by staff members of this digital library, which testified to the applicability of this method to a Chinese digital library.

Research limitations/implications

This paper is only a case study of a typical Chinese digital library using a digital library information security assessment method. More case-based explorations are necessary to prove the feasibility of the assessing strategy proposed in this study.

Originality/value

Based on the findings of recent literature, the authors found that very few researchers have made efforts to develop methods for calculating the indicators for digital library information security risk assessment. On the basis of ISO 27000 and other related information security standards, this case study proposed an operable method of digital library information security risk assessment and used it to assess a the information security of a typical Chinese digital library. This study can offer insights for formulating a digital library information security risk assessment scale.

• Digital library
• Risk assessment
• Vulnerability
• Information security

Acknowledgements

The authors gratefully acknowledge the financial support for this study by the national social science fund project of China. Project number is 12ATQ001.

Han, Z. , Huang, S. , Li, H. and Ren, N. (2016), "Risk assessment of digital library information security: a case study", The Electronic Library , Vol. 34 No. 3, pp. 471-487. https://doi.org/10.1108/EL-09-2014-0158

Emerald Group Publishing Limited

Copyright © 2016, Emerald Group Publishing Limited

Related articles

We’re listening — tell us what you think, something didn’t work….

Report bugs here

All feedback is valuable

Please share your general feedback

Join us on our journey

Platform update page.

Visit emeraldpublishing.com/platformupdate to discover the latest news and updates

Questions & More Information

Answers to the most commonly asked questions here

• Thursday, 30th May, 2024
• Rest of the World
• Health & Wellbeing
• Life & Style

In Historic Verdict, Trump Convicted of Falsifying Business Records, To be Sentenced July 11 2 hours ago

Nigeria condemns israel’s attack on gaza, insists rights of civilians must be preserved 8 hours ago, court restrains pro-wike lawmakers from parading themselves as rivers assembly members 10 hours ago, s’court grants accelerated hearing in fg’s suit seeking lg autonomy 10 hours ago, latest headlines.

NPFL: Remo Stars in Must-win Clash with Kano Pillars to Keep Title Hopes Alive 

Another Super Eagles Star, Tella, Out of S’Africa, Benin Rep. Games

Hugo Broos Names Tough Bafana Squad for Eagles

Elegbeleye insists Startimes was Only Broadcast offer for NPFL

Critical analysis of property tax assessment as revenue for government: a case study of port harcourt.

ESV Ekine, Augustine Nordi Prince,

Property tax assessment is a vital source of revenue for governments worldwide, and Nigeria is no exception. In Port Harcourt, the Rivers State government relies heavily on property tax assessment as a means of generating revenue to fund public goods and services. However, the effectiveness of property tax assessment as a revenue stream for government has been a subject of debate among scholars and policymakers. This analysis will critically examine the property tax assessment system in Port Harcourt, highlighting its strengths, weaknesses, and potential for improvement. Strengths:

• Stable Revenue Source: Property tax assessment provides a stable source of revenue for the government, as property owners are required to pay taxes annually.
• Wide Coverage: The tax net is cast wide, covering both residential and commercial properties, ensuring that a significant portion of the population contributes to the revenue pool.
• Easy to Administer: Property tax assessment is relatively easy to administer, as the tax base is easily identifiable, and the tax rate is fixed. Weaknesses:
• Inequitable Distribution: The tax burden is not distributed equitably, as some property owners pay more than others, despite having similar properties.
• High Tax Rate: The tax rate is high, which can lead to tax evasion and a reduction in compliance.
• Inefficient Administration: The tax administration process is often inefficient, leading to delays and loss of revenue. Case Study: Port Harcourt

Port Harcourt, the capital city of Rivers State, has a large and growing population, with a significant number of properties, both residential and commercial. The city generates a substantial amount of revenue from property tax assessment, which is used to fund public goods and services. However, the property tax assessment system in Port Harcourt faces several challenges, including:

• Inadequate Tax Base: The tax base is narrow, with many properties exempt from taxation, reducing the revenue potential.
• Low Compliance: Tax compliance is low, with many property owners failing to pay their taxes, resulting in a significant loss of revenue.
• Inefficient Tax Administration: The tax administration process is often inefficient, leading to delays and loss of revenue. Conclusion: Property tax assessment is a vital source of revenue for governments, but its effectiveness is dependent on several factors, including the tax base, tax rate, and tax administration. In Port Harcourt, the property tax assessment system faces several challenges, including an inadequate tax base, low compliance, and inefficient tax administration. To improve the effectiveness of property tax assessment as a revenue stream for government, the following recommendations are made:
• Broaden the Tax Base: The tax base should be broadened to include all properties, both residential and commercial, to increase the revenue potential.
• Reduce the Tax Rate: The tax rate should be reduced to make it more affordable for property owners, increasing compliance and reducing tax evasion.
• Improve Tax Administration: The tax administration process should be improved, with the use of technology and efficient administrative processes, to reduce delays and increase revenue collection.

References:

• Adeoye, B. (2017). Property Taxation in Nigeria: A Review of the Legal Framework. Journal of Law and Policy, 12(1), 1-15.
• Aluko, O. (2019). Property Tax Assessment in Nigeria: A Critical Analysis. Journal of Taxation, 10(2), 1-12.
• Federal Inland Revenue Service (FIRS). (2020). Tax Reform: A Guide to the New Tax Law. FIRS Publication.
• International Association of Assessing Officers (IAAO). (2019). Property Tax Assessment: A Guide to Best Practices. IAAO Publication.
• Rivers State Government. (2020). Port Harcourt Property Tax Assessment Law. Rivers State Government Publication. Note: The references provided are a selection of examples, and there are many more studies and resources available that support the critical analysis of property tax assessment as revenue for government, with a case study of Port Harcourt.

Related Articles

Founded on January 22, 1995, THISDAY is published by THISDAY NEWSPAPERS LTD., 35 Creek Road Apapa, Lagos, Nigeria with offices in 36 states of Nigeria , the Federal Capital Territory and around the world. It is Nigeria’s most authoritative news media available on all platforms for the political, business, professional and diplomatic elite and broader middle classes while serving as the meeting point of new ideas, culture and technology for the aspirationals and millennials. The newspaper is a public trust dedicated to the pursuit of truth and reason covering a range of issues from breaking news to politics, business, the markets, the arts, sports and community to the crossroads of people and society.

Helpful Links

• Privacy Policy
• Terms & Conditions

You can email us at: [email protected] or visit our contact us page.

Misleading and avoidable: design-induced biases in observational studies evaluating cancer screening—the example of site-specific effectiveness of screening colonoscopy

• Find this author on Google Scholar
• Find this author on PubMed
• Search for this author on this site
• ORCID record for Malte Braitmaier
• ORCID record for Sarina Schwarz
• ORCID record for Vanessa Didelez
• ORCID record for Ulrike Haug
• For correspondence: [email protected]
• Info/History
• Preview PDF

Objective Observational studies evaluating the effectiveness of cancer screening are often biased due to an inadequate design where I) the assessment of eligibility, II) the assignment to screening vs. no screening and III) the start of follow-up are not aligned at time zero (baseline). Such flaws can entail misleading results but are avoidable by designing the study following the principle of target trial emulation (TTE). We aimed to illustrate this by addressing the research question whether screening colonoscopy is more effective in the distal vs. the proximal colon.

Methods Based on a large German health care database (20% population coverage), we assessed the effect of screening colonoscopy in preventing distal and proximal CRC over 12 years of follow-up in 55–69-year-old persons at average CRC risk. We applied four different study designs and compared the results: cohort study with / without alignment at time zero, case control study with / without alignment at time zero.

Results In both analyses with alignment at time zero, screening colonoscopy showed a similar effectiveness in reducing the incidence of distal and proximal CRC (cohort analysis: 32% (95% CI: 27% - 37%) vs. 28% (95% CI: 20% - 35%); case-control analysis: 27% vs. 33%). Both analyses without alignment at time zero suggested a difference in site-specific performance: Incidence reduction regarding distal and proximal CRC, respectively, was 65% (95% CI: 61% - 68%) vs. 37% (95% CI: 31% - 43%) in the cohort analysis and 77% (95% CI: 67% - 84%) vs. 46% (95% CI: 25% - 61%) in the case-control analysis.

Conclusions Our study demonstrates that violations of basic design principles can substantially bias the results of observational studies on cancer screening. In our example, it falsely suggested a much stronger preventive effect of colonoscopy in the distal vs. the proximal colon. The difference disappeared when the same data were analyzed using a TTE approach, which is known to avoid such design-induced biases.

Competing Interest Statement

The authors have declared no competing interest.

Funding Statement

BIPS intramural funding

Author Declarations

I confirm all relevant ethical guidelines have been followed, and any necessary IRB and/or ethics committee approvals have been obtained.

The details of the IRB/oversight body that provided approval or exemption for the research described are given below:

In Germany, the utilisation of health insurance data for scientific research is regulated by the Code of Social Law. All involved health insurance providers as well as the German Federal Office for Social Security and the Senator for Health, Women and Consumer Protection in Bremen as their responsible authorities approved the use of GePaRD data for this study. Informed consent for studies based on claims data is required by law unless obtaining consent appears unacceptable and would bias results, which was the case in this study. According to the Ethics Committee of the University of Bremen studies based on GePaRD are exempt from institutional review board review.

I confirm that all necessary patient/participant consent has been obtained and the appropriate institutional forms have been archived, and that any patient/participant/sample identifiers included were not known to anyone (e.g., hospital staff, patients or participants themselves) outside the research group so cannot be used to identify individuals.

I understand that all clinical trials and any other prospective interventional studies must be registered with an ICMJE-approved registry, such as ClinicalTrials.gov. I confirm that any such study reported in the manuscript has been registered and the trial registration ID is provided (note: if posting a prospective study registered retrospectively, please provide a statement in the trial ID field explaining why the study was not registered in advance).

I have followed all appropriate research reporting guidelines, such as any relevant EQUATOR Network research reporting checklist(s) and other pertinent material, if applicable.

The following points were changed in this revision: 1) Figure 1 showed results belonging to a sensitivity analysis instead of the main analysis. This was corrected with this revision. 2) An acknowledgement statement was included.

View the discussion thread.

Thank you for your interest in spreading the word about medRxiv.

NOTE: Your email address is requested solely to identify you as the sender of this article.

Citation Manager Formats

• EndNote (tagged)
• EndNote 8 (xml)
• RefWorks Tagged
• Ref Manager
• Tweet Widget
• Facebook Like
• Google Plus One

Subject Area

• Epidemiology
• Addiction Medicine (325)
• Allergy and Immunology (633)
• Anesthesia (168)
• Cardiovascular Medicine (2409)
• Dentistry and Oral Medicine (291)
• Dermatology (208)
• Emergency Medicine (382)
• Endocrinology (including Diabetes Mellitus and Metabolic Disease) (854)
• Epidemiology (11817)
• Forensic Medicine (10)
• Gastroenterology (705)
• Genetic and Genomic Medicine (3782)
• Geriatric Medicine (351)
• Health Economics (638)
• Health Informatics (2415)
• Health Policy (941)
• Health Systems and Quality Improvement (909)
• Hematology (343)
• HIV/AIDS (790)
• Infectious Diseases (except HIV/AIDS) (13358)
• Intensive Care and Critical Care Medicine (770)
• Medical Education (371)
• Medical Ethics (105)
• Nephrology (403)
• Neurology (3536)
• Nursing (199)
• Nutrition (531)
• Obstetrics and Gynecology (683)
• Occupational and Environmental Health (671)
• Oncology (1839)
• Ophthalmology (541)
• Orthopedics (222)
• Otolaryngology (287)
• Pain Medicine (234)
• Palliative Medicine (67)
• Pathology (449)
• Pediatrics (1041)
• Pharmacology and Therapeutics (427)
• Primary Care Research (425)
• Psychiatry and Clinical Psychology (3204)
• Public and Global Health (6198)
• Radiology and Imaging (1298)
• Rehabilitation Medicine and Physical Therapy (753)
• Respiratory Medicine (833)
• Rheumatology (380)
• Sexual and Reproductive Health (375)
• Sports Medicine (325)
• Surgery (407)
• Toxicology (51)
• Transplantation (173)
• Urology (148)