# IoT Security Risk Management Strategy Reference Model (IoTSRM2)
## 4 Related Work
Furthermore, from the perspective of the extent of applicability to this evaluation criterion, compared with the mappings provided in the eleven selected IoT security best practices which offered incomplete or limited details, the mapping involved in the proposed methodology for developing the IoTSRM2 applies to all IoTSRM2 controls, and it is much more detailed. Thus, first, AgeLight LLC [40], and ENISA [28; 55; 56; 58] provided this type of mapping without indicating the associated unique identifiers (UIDs) of the in-scope IoT security requirements from the relevant IoT security best practices. Second, IoTAC [51], NHTSA [60], and NIST [53] provided this type of mapping only for some of their IoT security requirements without indicating the associated unique identifiers (UIDs) of the in-scope IoT security requirements from the relevant IoT security best practices. Then, NEMA [52] provided this type of mapping only for some IoT security requirements with the associated unique identifiers (UIDs) of the in-scope IoT security requirements from the relevant IoT security best practices. Furthermore, IoTSF [50; 69] provided the mapping of framework sections to ETSI TS 103 645 as part of the IoTSF Compliance Questionnaire [69], but this mapping was limited to framework sections rather than recommended IoT security requirements. In addition, CSA [46] provided the mapping of each IoT security requirement to the applicable control identifier(s) (IDs) of a best practice which is focused on cloud security (i.e., CSA Cloud Control Matrix--CCM) instead of IoT security. **E7: Prioritization of the recommended IoT security requirements/controls**  
Our proposed IoTSRM2 provides prioritized IoTSRM2 controls. In addition, from the 25 selected IoT security best practices, three of them provided the prioritization of the recommended IoT security requirements (i.e., [42, 49, 61]), four of them partially provided the prioritization of the recommended IoT security requirements (i.e., [40, 47, 50, 54]), while the remaining ones did not provide this prioritization. Regarding the three selected IoT security best practices that provided the prioritization of the recommended IoT security requirements, Commonwealth of Australia [42] and DCMS [61] prioritized their IoT security requirements recommending industry to prioritize the top three in the short-term and IEEE [49] prioritized its eleven IoT security requirements based on their relevance to IoT. Similar to these three IoT security best practices, our proposed IoTSRM2 provides prioritized IoTSRM2 controls. However, compared with these IoT security best practices which provided the prioritization of their IoT security requirements without describing how their prioritization resulted, our proposed methodology for developing the IoTSRM2 outlines the way in which the prioritization of IoTSRM2 controls for each IoTSRM2 objective was made. In addition, our proposed IoTSRM2 provides the prioritization of IoTSRM2 domains based on the number of IoTSRM2 objectives corresponding to each IoTSRM2 domain. Furthermore, from the perspective of the extent of applicability to this evaluation criterion, compared with the prioritizations provided in the four IoT security best practices which covered only some IoT security requirements or offered limited details, the prioritization from IoTSRM2 covers all IoTSRM2 controls, and it is much more clearly outlined. Thus, first, AgeLight LLC [40] provided only the mechanism for prioritizing the IoT security requirements which consists of rating each security requirement based on company risk (i.e., user benefit, ecosystem impact, financial impact, hazardization, development effort and costs, regulatory risk). Second, GSM Association [47] prioritized only some IoT security requirements as \"Critical\", \"High\", \"Medium\", and \"Low\" instead of prioritizing all recommended IoT security requirements.