# IoT Security Risk Management Strategy Reference Model (IoTSRM2)
## 4 Related Work
In addition, from the 25 selected IoT security best practices, seven of them clearly described the methodology used for developing the recommended IoT security requirements (i.e., [26; 28; 41; 55; 56; 57; 58]), four of them partially described their methodology (i.e., [30; 40; 61; 43]), while the remaining ones have not described their methodology (i.e., [44; 45; 46; 47; 48; 49; 59; 60]). Regarding the seven selected IoT security best practices that clearly described their methodologies, AIOTI [41] provided details about the aspects discussed as part of the four sessions workshop, CSDE [26] developed the IoT security requirements by identifying common IoT security device capabilities from Convening the Conveners (C2) organizations, ENISA [57] analyzed the data received through a series of interviews for recommending the IoT security requirements, and the other four IoT security best practices of ENISA (i.e., [28; 55; 56; 58]) used the ENISA's five-step methodology involving both desktop research and interviews. Compared with the high-level five-step methodology from ENISA (i.e., [28; 55; 56; 58]), our proposed three-phased methodology for developing the IoTSRM2 consists of nine steps, and it is much more comprehensive as it provides a far greater level of detail with respect to the steps involved. Even though our proposed methodology from this article has different objectives than the studies conducted by ENISA [28; 55; 56; 58], similar to the methodology of ENISA (i.e., [28; 55; 56; 58]) which included scope definition, desktop research, and analysis and development tasks, among others, our proposed methodology for developing the IoTSRM2 includes several steps related to scoping, analysis, and creation phases that involve extensive research work. In addition, in contrast to the research works performed by AIOTI [41], CSDE [26], and ENISA [57] which are limited to workshops, surveys, and interviews, respectively, our proposed methodology from this article is based on selected IoT security best practices. Furthermore, from the perspective of the extent of applicability to this evaluation criterion, our proposed methodology for developing the IoTSRM2 differentiates from the methodologies provided by AgeLight LLC [40], BITAG [43], DCMS [61], and ETSI [30], as it is much more detailed than the ones of the four selected IoT security best practices which offered limited details. Thus, first, AgeLight LLC [40; 77] developed the recommended IoT security requirements based on seven pre-established guiding tenets and dozens of industry and governmental efforts. AgeLight LLC [40; 77] provided merely a couple of the efforts on which its methodology was built on rather than providing all sources and did not clearly outline the ways in which these efforts were used to develop the recommended IoT security requirements. Second, BITAG [43] did not outline the scenarios used by the Technical Working Group (TWG) representatives for achieving consensus around the recommended IoT security requirements through the BITAG's consensus process. Then, DCMS [27; 61] described the methodology for developing the IoT security requirements half-way as it provided only the methodology for mapping of recommendations and guidance rather than the entire methodology used [27]. As for ETSI [30], it mentioned that its methodology relied solely on a documentary review of published standards, recommendations, and guidance on IoT security and privacy and provided the sources used to develop the recommended IoT security requirements, but it did not explain how these sources were put together and processed. **E3: Mapping of IoT security requirements/controls to NIST CSF's Categories and Subcategories**  
As per Table 10 above, none of the 25 selected IoT security best practices provided a complete mapping of their recommended IoT security requirements to the NIST CSF's Categories and Subcategories.