# Towards Agile Cybersecurity Risk Management for Autonomous Software Engineering Teams
## 5 Discussion  
In this study, we set out to identify how challenges associated with cybersecurity risk management in agile software projects have been addressed in the literature, and through these insights propose a framework for agile cybersecurity risk management. In our review, we found two primary approaches: some research explored the idea of incorporating agile practices into the existing risk management processes, e.g., [48, 51], that is to say, using agile tools for handling risks. While others investigated specific risk management frameworks that were fused into already existing agile software development processes, e.g., [54, 58, 60]. Regardless, we could not identify if either approach is beneficial over the other in terms of addressing the five identified challenges. However, by building upon insights gained from these studies to address the challenges, our study extends previous research, but also complement previous reviews on agile risk management, such as [PERSON] et al. [61] and [PERSON] and [PERSON] [50]. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Framework Step** & **Activity** & **Output** & **Challenge** \\ \hline Risk collection & Daily stand-up & Defined RI & \(C_{1}\) \\  & 1 st risk assessment & Defined RI & \(C_{1},C_{2}\) \\ Risk refinement & Backlog refinement & Prioritisation & \(C_{1},C_{2},C_{4}\) \\  & 2 nd risk assessment & Defined RI & \(C_{1},C_{2},C_{4}\) \\  & Requirement & Requirements & \(C_{1},C_{2}\) \\  & management & RI prioritisation & \(C_{1},C_{2}\) \\ Risk mitigation & Sprint planning & Prioritisation & \(C_{2},C_{3}\) \\  & Task execution & Risk mitigation & \(C_{2},C_{3}\) \\ Knowledge transfer & Retrospective & Knowledge & \(C_{4}\) \\ Escalation & Escalation to & Prioritisation & \(C_{5}\) \\  & stakeholder & Prioritisation & \(C_{5}\) \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Defined steps of the proposed framework including output for each activity, and corresponding challenges that are addressed. To get an indication of whether or not the characteristics of how the identified challenges could be addressed, statements based on these characteristics were formulated and served as the basis for surveying their relevance. These statements also served as the foundation for the proposed framework. As such, one limitation of the study is that the survey targeted the attitude towards the framework's steps, but not the framework as a whole. Furthermore, considering the sample size, no statistical tests were used to find significant relationships from the respondents data. Instead, the survey was used to provide an external indicator on the steps appropriateness, but not to generalise the results. Future research is therefore recommended to further refine and validate the findings. To overcome some of the limitations of this study, qualitative studies (e.g., case-studies, observations, and interviews) are recommended to increase the scope of knowledge of cybersecurity in agile development teams (e.g., motivations, challenges, and enablers), but also to test and validate the proposed framework presented herein. In practice, this could lead to new insights on how, when, and whom should perform risk management activities in agile software development projects. The resulting framework addresses the five identified challenges and incorporates insights gained from the review in five different steps: risk collection, risk refinement, risk mitigation, knowledge transfer, and escalation. The risk collection and risk refinement steps are designed to address \(C_{1}\) and \(C_{2}\), since all security activities are tightly connected to daily and weekly ceremonies and directly impact requirement and development changes (via re-prioritisation). Additionally, due to frequent assessment of risk impact in the risk refinement step, the team have a continuous attention on the risk mitigation work and can re-prioritise and change accordingly. The risk mitigation step therefore enforces clear definitions of mitigation activities and testability thereof.