# Towards Agile Cybersecurity Risk Management for Autonomous Software Engineering Teams
## 4 Results
### An Agile Cybersecurity Risk Management Framework  
The proposed framework (depicted in Figure 4) is divided into five steps, each of which addresses one or more of the five challenges discussed in Section 2.4, with subsequent activities (see Table 2). Based on the characteristics of the solutions identified for challenges C1 and C2, a first step in an agile cybersecurity risk management framework is proposed to include risk assessments, to be connected to daily and weekly ceremonies and thus directly impact requirement and development changes. However, to avoid security teams from developing requirements that are then coordinated retroactively with the development team [59], these early assessments are proposed to consist of only a first, initial collection and subjective prioritisation--not a full risk analysis and evaluation, which could otherwise overload the agile project [2, 3, 29, 30]. As such, this first step is referred to as a _Risk Collection_. A deeper analysis of the early assessed risks is instead carried out later on, e.g., during the backlog refinement to allow for more natural re-prioritisation of mitigation work, and is therefore referred to as the _Risk Refinement_. To counter the challenge of undocumented experience and knowledge (\(C_{4}\)), e.g., gained from the risk assessments, a session for discussing and documenting lessons learned related to cybersecurity during the retrospective is proposed, here referred to as the _Knowledge Transfer_. Similarly, to alert stakeholders and management on relevant risks to better delegate effort and resources (\(C_{5}\)), an iterative _Escalation_ activity is included throughout the entire process to refrain from severe risk being addressed late and with limited follow-up [17]. Although the framework is team-centred, it consists of activities towards upper management and stakeholders as well. The framework uses the following terminology: _Risk Item_ (RI), which refers to an identified and described risk; _Risk Backlog_ (RB), which is the list of all RI's for the team and will act as the primary documentation of the overall risk management; and _Security Activity_ (SA), which refers to any type of activity that generates output to be used by the risk assessment framework, e.g., threat modelling exercises, code reviews, SAST reporting, or internal audits (\(C_{3}\)). The frameworks steps are as follows. _Risk Collection:_: This step consists of two activities: (1) a daily walk-through of new, current and unmitigated risks, and (2) a quick initial risk assessment, RI creation and prioritisation (a maximum of a few minutes of assessment). These activities should be extensions of the daily stand-up, i.e., a natural part of the daily synchronisation work. Input to these activities should be established SA that are parts of the SDLC, e.g., static code analysis tools, monitoring or code review exercises, thus any type of SA should feed data to these daily activities. Any risk assessment framework can be used for the risk assessment part of the step. _Risk Refinement:_: This step consists of a weekly, or bi-weekly, walk-through of the cybersecurity RB and could be an extension of the regular backlog refinement ceremony, hence the PO is part of this step. This activity aims to create better understanding and overall prioritisation of the current RB. A second risk assessment of the RI:s should occur with a deeper analysis than the initial activity in the previous step. A first element of knowledge transferring may happen within this step. In this step, each RI should also be described with a mitigation proposal and aligned with requirements (or lead to new requirements that affect the ordinary backlog). This step should produce RI:s that are ready for the next sprint planning. Any risk assessment framework can be used for the risk assessment part of the step. _Risk Mitigation:_: This step's aim is to enforce risk mitigation tasks, e.g., executing explicit code changes, introduction of new processes or knowledge-sharing activities.