D4.2 Results of the UI-UX requirements analysis and the work processes – v2

Deliverable D4.2 Results of the UI-UX requirements analysis and the work processes – v2 Editor(s): Angela Fessl, Katharina Stefan Responsible Partner: Know Center Research GmbH Status-Version: Final – v1.0 Date: 30.04.2025 Type: R Distribution level (SEN, PU): PU D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 2 of 128 www.emerald-he.eu Project Number: 101120688 Project Title: EMERALD Title of Deliverable: D4.2 Results of the UI-UX requirements analysis and the work processes – v2 Due Date of Delivery to the EC 30.04.2025 Workpackage responsible for the Deliverable: WP4 - User interaction and user experience development Editor(s): Angela Fessl, Katharina Stefan (KNOW) Contributor(s): Simone Franza, Leonie Disch (KNOW) Björn Fanta, Franz Deimling, (FABA) Julius Holderer (IONOS) Ramon Martin de Pozuelo, Marti Fabregat I Pous (CXB) Natalia Sobieska (CF) Mika Leskinen, Antti Kantero (NIXU/DNV) Reviewer(s): Olivia Kagerer (FABA) Juncal Alonso, Cristina Martínez (TECNALIA) SAB Reviewer(s): Samu Nisula (NIXU/DNV) Marti Fabregat (CXB) Björn Fanta (FABA) Sebastian Kucharski (CF) Ali Nikoukar (IONOS) Constantino Vázquez (ONS) Approved by: All Partners Recommended/mandatory readers: WP1, WP2, WP3, WP5, WP6 Abstract: Final version of the report on the elicited UI-UX requirements from the target group. Work processes and workflows that should be covered with the user interface concept, and final personas and scenarios. Keyword List: UI/UX Requirements, Works Processes, Personas, Scenarios Licensing information: This work is licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0 DEED https://creativecommons.org/licenses/by-sa/4.0/) Disclaimer Funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union. The European Union cannot be held responsible for them. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 3 of 128 www.emerald-he.eu Document Description Version Date Modifications Introduced Modification Reason Modified by v0.1 23.03.2025 First draft version Angela Fessl, Katharina Stefan (KNOW) v0.1 01.04.2025 QA review Olivia Kagerer (FABA) v0.2 02.04.2025 Feedback integration of QA review Angela Fessl, Katharina Stefan (KNOW) v0.3 03.04.2025 Feedback integration and review with TECNALIA Cristina Martinez (TECNALIA) v0.4 03.04.2025 Feedback integration of TECNALIA review Angela Fessl, Katharina Stefan (KNOW) v0.5 03.04.2025 SAB Review Samu Nisula (NIXU/DNV) Marti Fabregat (CXB) Björn Fanta (FABA) Sebastian Kucharski (CF) Ali Nikoukar (IONOS) Constantino Vázquez (ONS) v0.6 14.04.2025 SAB Review Integration Angela Fessl (KNOW) v0.7 22.04.025 Final Review Juncal Alonso, Cristina Martínez (TECNALIA) v0.8 23.04.2025 Addressing the comments from Final Review Angela Fessl (KNOW) v1.0 30.04.2025 Submitted to the European Commission Juncal Alonso, Cristina Martínez (TECNALIA) D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 4 of 128 www.emerald-he.eu Table of contents Terms and abbreviations ............................................................................................................... 9 Executive Summary ..................................................................................................................... 10 1 Introduction ......................................................................................................................... 11 1.1 About this deliverable .................................................................................................. 11 1.2 Document structure ..................................................................................................... 12 1.3 Updates from D4.1....................................................................................................... 13 2 Methodology ....................................................................................................................... 16 2.1 Interactive Interview Session ....................................................................................... 17 2.2 Interviews .................................................................................................................... 17 2.3 Focus Groups & Process Workshops ........................................................................... 19 2.4 Personas & Scenarios Workshops ............................................................................... 20 3 Results of the Interactive Interview Session ....................................................................... 25 4 Work Processes ................................................................................................................... 29 4.1 Work Processes in Workflow Representation ............................................................. 29 4.2 Work Processes of Compliance and Security Managers per Pilot Partner .................. 30 4.2.1 Pilot 1: IONOS .................................................................................................... 31 4.2.2 Pilot 2: CloudFerro (CF) ..................................................................................... 39 4.2.3 Pilot 3: Fabasoft (FABA) ..................................................................................... 46 4.2.4 Pilot 4: CaixaBank (CXB)..................................................................................... 52 4.2.5 Auditors (NIXU/DNV) ......................................................................................... 59 4.2.6 Compliance Manager (NIXU/DNV) .................................................................... 67 4.3 Blueprint for introducing EMERALD in audit preparation ........................................... 74 5 Personas, Personas-on-the-go and Scenarios ..................................................................... 79 5.1 Riley – Cloud Service Provider Compliance Manager .................................................. 81 5.1.1 Scenario A: Riley – Managing a New Audit Scope ............................................. 82 5.1.2 Scenario B: Riley – Manage all Controls of an Audit Scope ............................... 82 5.1.3 Scenario C: Riley – Uncover all “blind spots” .................................................... 83 5.1.4 Scenario D: Riley – Updating a certification scheme ......................................... 83 5.1.5 Scenario E: Riley – Accompanying an Audit ...................................................... 83 5.2 Emerson - Compliance Manager in Financial Service Institution ................................ 84 5.2.1 Scenario: Emerson – Bring Your Own Certification Scheme ............................. 85 5.3 Dylan – Internal Control Owner ................................................................................... 85 5.3.1 Scenario: Dylan – Internal Control Owner Control Implementation ................. 87 5.4 Morgan – Technical Implementer ............................................................................... 87 5.4.1 Scenario A: Morgan – Checking Metrics and Evidence ..................................... 89 5.4.2 Scenario B: Morgan – Removal of Metric .......................................................... 89 D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 5 of 128 www.emerald-he.eu 5.5 Charlie – Internal Auditor ............................................................................................ 90 5.5.1 Scenario: Charlie – Preparation of an Audit by an Internal Auditor .................. 91 5.6 Jarkko – Lead Auditor .................................................................................................. 92 5.6.1 Scenario A: Jarkko – Scoping ............................................................................. 93 5.6.2 Scenario B: Jarkko – Preparing for Audit ........................................................... 94 5.6.3 Scenario C: Jarkko – Organizational Audit ......................................................... 94 5.6.4 Scenario D: Jarkko – Certification ...................................................................... 94 5.7 Eero – Technical Auditor .............................................................................................. 94 5.7.1 Scenario A: Eero – Technical Audit .................................................................... 95 5.7.2 Scenario B: Eero – Reporting ............................................................................. 96 6 UI/UX Requirements (version 2) ......................................................................................... 97 6.1 Newly Added UI/UX Requirements since M9 ............................................................ 101 7 Conclusions ........................................................................................................................ 105 8 References ......................................................................................................................... 106 9 APPENDIX A: Interview Documents ................................................................................... 108 9.1 Interview Guideline ................................................................................................... 108 9.2 Participant Information Sheet ................................................................................... 111 9.3 Consent Form ............................................................................................................. 113 9.4 Data Protection Information...................................................................................... 114 10 APPENDIX B: Original User Scenario Descriptions ............................................................. 115 10.1 Scenarios Riley ........................................................................................................... 115 10.2 Scenario Emerson ...................................................................................................... 117 10.3 Scenario Dylan ........................................................................................................... 118 10.4 Scenario Morgan ........................................................................................................ 118 10.5 Scenario Charlie ......................................................................................................... 118 10.6 Scenarios Jarkko ......................................................................................................... 119 10.7 Scenarios Eero ........................................................................................................... 121 11 APPENDIX C: UI/UX Requirements elicited before M9 ..................................................... 122 List of Tables TABLE 1. OVERVIEW OF DELIVERABLE UPDATES WITH RESPECT TO D4.1 .................................................... 13 TABLE 2. OVERVIEW OF THE CONDUCTED INTERVIEWS ........................................................................... 19 TABLE 3. OVERVIEW OF THE CONDUCTED FOCUS GROUPS AND PROCESS WORKSHOPS ................................. 20 TABLE 4. OVERVIEW OF ALL PERSONA AND SCENARIO WORKSHOPS ......................................................... 21 TABLE 5. STATUS OVERVIEW OF THE DEVELOPMENT OF PERSONAS, SCENARIOS AND USER JOURNEYS ........... 23 TABLE 6. ANSWERS GIVEN TO Q1: “HOW DO THE CURRENT AUDIT PREPARATION PROCESSES LOOK LIKE FOR YOUR PILOT?” .................................................................................................................................. 25 TABLE 7. SUMMARY OF ANSWERS GIVEN TO THE QUESTION Q2: “WHAT ARE THE “PAIN POINTS” FOR YOUR CURRENT AUDIT PROCESS?” ....................................................................................................... 26 TABLE 8. SUMMARY OF ANSWERS GIVEN TO THE QUESTION Q3: “ARE THERE ANY SPECIFIC TASKS TO BE SOLVED BY EMERALD?” ..................................................................................................................... 26 D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 6 of 128 www.emerald-he.eu TABLE 9. SUMMARY OF ANSWERS GIVEN TO THE QUESTION Q4: “HOW CAN EMERALD HELP MITIGATE THESE “PAIN POINTS”? EXPECTATIONS?” .............................................................................................. 27 TABLE 10. SUMMARY OF ANSWERS GIVEN TO THE QUESTION Q5: “WHAT TOOLS ARE YOU CURRENTLY USING FOR THE AUDITS IN YOUR PILOT?” ..................................................................................................... 28 TABLE 11. SUMMARY OF ANSWERS GIVEN TO THE QUESTION Q6: “WHICH CERTIFICATION SCHEMES ARE YOU AS PILOT INTERESTED IN?” ............................................................................................................. 28 TABLE 12. PRESENTATION OF ALL SHAPES USED IN THE WORKFLOW REPRESENTATION OF THE AUDIT PREPARATION PROCESSES .............................................................................................................................. 30 TABLE 13. STATUS OF THE UI/UX REQUIREMENTS REGARDING THE CLICKABLE PROTOTYPE .......................... 98 D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 7 of 128 www.emerald-he.eu List of figures FIGURE 1. OVERALL METHODOLOGY APPLIED IN WP4............................................................................ 17 FIGURE 2. IONOS – SIMPLE PROCESS REPRESENTATION WITHOUT EMERALD SUPPORT ............................. 32 FIGURE 3. IONOS – WORKFLOW REPRESENTATION WITHOUT EMERALD SUPPORT .................................. 34 FIGURE 4. IONOS – SIMPLE PROCESS REPRESENTATION WITH EMERALD SUPPORT ................................... 35 FIGURE 5. IONOS – WORKFLOW REPRESENTATION WITH EMERALD SUPPORT ........................................ 38 FIGURE 6. CLOUDFERRO – SIMPLE PROCESS REPRESENTATION WITHOUT EMERALD SUPPORT ..................... 40 FIGURE 7. CLOUDFERRO – WORKFLOW REPRESENTATION WITHOUT EMERALD SUPPORT .......................... 42 FIGURE 8. CLOUDFERRO - SIMPLE PROCESS REPRESENTATION WITH EMERALD SUPPORT ........................... 43 FIGURE 9. CLOUDFERRO - WORKFLOW REPRESENTATION WITH EMERALD SUPPORT................................. 45 FIGURE 10. FABASOFT – SIMPLE PROCESS REPRESENTATION WITHOUT EMERALD SUPPORT ....................... 46 FIGURE 11. FABASOFT – WORKFLOW REPRESENTATION WITHOUT EMERALD SUPPORT ............................. 48 FIGURE 12. FABASOFT – SIMPLE PROCESS REPRESENTATION WITH EMERALD SUPPORT ............................. 49 FIGURE 13. FABASOFT - WORKFLOW REPRESENTATION WITH EMERALD SUPPORT ................................... 51 FIGURE 14. CAIXABANK – SIMPLE PROCESS REPRESENTATION WITHOUT EMERALD SUPPORT ..................... 53 FIGURE 15. CAIXABANK – WORKFLOW REPRESENTATION WITHOUT EMERALD SUPPORT........................... 55 FIGURE 16. CAIXABANK – SIMPLE PROCESS REPRESENTATION WITH EMERALD SUPPORT ........................... 56 FIGURE 17. CAIXABANK – WORKFLOW REPRESENTATION WITH EMERALD SUPPORT ................................ 58 FIGURE 18. NIXU/DNV – SIMPLE PROCESS REPRESENTATION WITHOUT EMERALD SUPPORT .................... 60 FIGURE 19. NIXU/DNV – WORKFLOW REPRESENTATION WITHOUT EMERALD SUPPORT .......................... 62 FIGURE 20. NIXU/DNV – SIMPLE PROCESS REPRESENTATION WITH EMERALD SUPPORT .......................... 64 FIGURE 21. NIXU/DNV - WORKFLOW REPRESENTATION WITH EMERALD SUPPORT ................................ 66 FIGURE 22. NIXU/DNV CM – SIMPLE PROCESS REPRESENTATION WITHOUT EMERALD SUPPORT .............. 67 FIGURE 23. NIXU/DNV CM – WORKFLOW REPRESENTATION WITHOUT EMERALD SUPPORT ................... 69 FIGURE 24. NIXU/DNV CM – SIMPLE PROCESS REPRESENTATION WITH EMERALD SUPPORT .................... 71 FIGURE 25. NIXU/DNV CM - WORKFLOW REPRESENTATION WITH EMERALD SUPPORT .......................... 73 FIGURE 26. EMERALD BLUEPRINT WORKFLOW REPRESENTATION - PART 1 .............................................. 76 FIGURE 27. EMERALD BLUEPRINT WORKFLOW REPRESENTATION – PART 2 ............................................. 77 FIGURE 28. EMERALD BLUEPRINT WORKFLOW REPRESENTATION – PART 3 ............................................. 78 FIGURE 29. OVERVIEW OF THE THREE STAKEHOLDER GROUPS AND THE RESPECTIVE PERSONAS ..................... 80 FIGURE 30. RILEY – CLOUD SERVICE COMPLIANCE MANAGER ................................................................. 81 FIGURE 31. PERSONA-ON-THE-GO FOR RILEY – CLOUD SERVICE COMPLIANCE MANAGER............................ 82 FIGURE 32. RILEY – UPDATING A CERTIFICATION SCHEME ....................................................................... 83 FIGURE 33. EMERSON – COMPLIANCE MANAGER IN FINANCIAL SERVICE INSTITUTION ................................ 84 FIGURE 34. PERSONA-ON-THE-GO FOR EMERSON – COMPLIANCE MANAGER IN FINANCIAL SERVICES ............ 85 FIGURE 35. DYLAN – INTERNAL CONTROL OWNER ................................................................................ 86 FIGURE 36. PERSONA-ON-THE-GO FOR DYLAN – INTERNAL CONTROL OWNER ........................................... 87 FIGURE 37. MORGAN – TECHNICAL IMPLEMENTER ............................................................................... 88 FIGURE 38. PERSONA-ON-THE-GO FOR MORGAN – TECHNICAL IMPLEMENTER .......................................... 89 FIGURE 39. SCENARIO B: MORGAN – REMOVAL OF METRIC ................................................................... 90 FIGURE 40. CHARLIE – AUDITOR ........................................................................................................ 91 FIGURE 41. PERSONA-ON-THE-GO: CHARLIE – INTERNAL AUDITOR .......................................................... 91 FIGURE 42. JARKKO – LEAD AUDITOR ................................................................................................. 93 FIGURE 43. PERSONA-ON-THE-GO FOR JARKKO – LEAD AUDITOR ............................................................ 93 FIGURE 44. EERO – TECHNICAL AUDITOR ............................................................................................ 95 FIGURE 45. PERSONA-ON-THE-GO FOR EERO – TECHNICAL AUDITOR ....................................................... 95 FIGURE 46. SCENARIO A: RILEY – MANGING A NEW AUDIT SCOPE ......................................................... 115 FIGURE 47. SCENARIO B: RILEY – MANAGE ALL CONTROLS OF AN AUDIT SCOPE ...................................... 115 FIGURE 48. SCENARIO C: RILEY – UNCOVER ALL “BLIND SPOTS” ............................................................ 116 FIGURE 49. SCENARIO E: RILEY – ACCOMPANYING AND AUDIT .............................................................. 116 D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 8 of 128 www.emerald-he.eu FIGURE 50. EMERSON – BRING YOUR OWN CERTIFICATION SCHEME ....................................................... 117 FIGURE 51. DYLAN – INTERNAL CONTROL OWNER CONTROL IMPLEMENTATION ...................................... 118 FIGURE 52. SCENARIO A: MORGAN – CHECKING METRICS AND EVIDENCE .............................................. 118 FIGURE 53. SCENARIO 3: CHARLIE – PREPARATION OF AN AUDIT BY AN INTERNAL AUDITOR ....................... 118 FIGURE 54. SCENARIO A: JARKKO – SCOPING ..................................................................................... 119 FIGURE 55. SCENARIO B: JARKKO – PREPARING FOR AUDIT .................................................................. 119 FIGURE 56. SCENARIO C: JARKKO – ORGANIZATIONAL AUDIT ............................................................... 120 FIGURE 57. SCENARIO D: JARKKO - CERTIFICATION ............................................................................. 120 FIGURE 58. SCENARIO A: EERO – TECHNICAL AUDIT............................................................................ 121 FIGURE 59. SCENARIO B: EERO - REPORTING ..................................................................................... 121 D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 9 of 128 www.emerald-he.eu Terms and abbreviations AI Artificial Intelligence AMOE Bring Your Own Certification Scheme BSI Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik) C5 Cloud Computing Compliance Criteria Catalogue CaaS Compliance-as-a-Service1 CM Compliance Manager CSP Cloud Service Provider CSV Comma-separated value DoA Description of Action DORA Digital Operational Resilience Act EC European Commission ECB European Central Bank EUCS European Union Cybersecurity Certification Scheme for Cloud Services GA Grant Agreement to the project GDPR General Data Protection Regulation GUI Graphical User Interface IaaS Infrastructure as a Service ICO Internal Control Owner ISO International Organization for Standardization KPI Key Performance Indicator KR Key Result MARI Mapping Assistant for Regulations with Intelligence MS Teams Microsoft Teams RCM Repository of Controls and Metrics SaaS Software as a Service SAB Security Advisory Board SO Service Owner SOC Security Operations Center frameworks SP Service Provider TRL Technology Readiness Level UI User Interface UNED Universidad Nacional de Educación a Distancia (National University of Distance Education) UX User Experience 1 Please note that in previous deliverables and in the DoA, the term Certification-as-a-Service was used to stand for CaaS. Compliance has now been introduced to clarify that EMERALD can be used to assess both normative models and internal organizational models. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 16 of 128 www.emerald-he.eu 2 Methodology The overall methodology of WP4 follows a co-design, participatory and contextual design approach (see [3], [4], [5], [6]) using different methods such as interviews, focus groups, and workshops. Such a co-design approach aims at bridging the gap between technology designers, developers, and target users. Terms like co-design, participatory and contextual design highlight similar concepts, emphasizing the active involvement of all stakeholders to meet both the individual and organizational needs [7]. Participatory design is also seen as an emancipatory act, allowing users to have a say in the tools they use [6]. Co-creation involves shared creativity [5], while co-design applies this creativity throughout the entire design process. Active user participation throughout development is encouraged, creating a hybrid space that combines user and developer attributes. This shift from “user as subject” to “user as partner” has changed stakeholder roles [5], with users potentially becoming meta-designers and researchers acting as facilitators. Co-design is characterized by iterative learning processes involving all stakeholders. Goal: We have decided to use co-design as an overall methodology for the WP4 activities. We see this approach as a viable means to bridge the gap between EMERALD technology partners and EMERALD pilot partners to develop a sophisticated EMERALD UI/UX. Thereby, the aim of the co-design is: • to get a good understanding of the underlying processes and workflows regarding the preparation and implementation of audits and the certification of cloud services, • to elicit a set of requirements for developing the EMERALD UI/UX, • to develop personas, scenarios, and user journeys (presented in D4.3 [8] and D4.4 (M24)), and • to develop a full-featured clickable prototype of the EMERALD UI. We conducted the elicitation process iteratively to continuously involve the target groups throughout the different activities and processes, gather their feedback and insights, and allow their input to be integrated on the fly. The final goal is to design a sophisticated EMERALD UI that integrates the needs of all involved parties (pilot partners – compliance managers, security managers, internal auditors; auditors – external and technical auditors; and component owners). The methodology we followed, and the corresponding results derived are depicted in Figure 1. First, we conducted an interactive interview session at the first face-to-face general assembly in Bilbao, in March 2024. The aim was to get insights about the pilot partners, their pain points and needs during setting-up and conducting audit processes. The results are presented in Section 3. Then we performed semi-structured interviews with the target users, including auditors, compliance managers, and security managers from the different pilot partners and external auditors, which were followed by doing online focus groups. This activity resulted in simple processes for all involved partners. We did a second review round in form of process workshops after we had transformed all simple processes into workflow representations. Then, we developed a general blueprint that is valid for all pilots. The simple processes as well as the workflow representations are presented in Section 4. After the first round of interviews and focus groups, we conducted several online workshops in June 2024 and September 2024 for the development of personas, scenarios and user journeys. In Section 5, we present the final set of personas and scenarios (the user journeys are presented in D4.3 [8] and D4.4 (M24). From all collected insights of the activities, we developed a set of 25 UI/UX requirements for developing the EMERALD UI, which are presented in Section 6. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 17 of 128 www.emerald-he.eu 2.1 Interactive Interview Session The interactive interview session was conducted at the general assembly in Bilbao, in March 2024. The goal of this session was to get insights about the pilot partners, their pain points, and their needs during setting-up and conducting audit processes, as well as to get first ideas or insights on where the EMERALD UI could support them. A set of six questions was prepared: • Q1: How do the current audit preparation processes look like for your pilot? • Q2: What are the “pain points” for your current audit process? • Q3: Are there any specific tasks to be solved by EMERALD? • Q4: How can EMERALD help mitigate these “pain points”? Expectations? • Q5: What tools are you currently using for the audits in your pilot? • Q6: Which certification schemes are you as pilot interested in? Procedure This interview session was conducted in the whole plenum of the general assembly in Bilbao. At the beginning of the interview session, the idea of the session was introduced to the whole consortium. After all pilot partners agreed to participate, they were asked to answer the above questions one after the other. Additionally, all EMERALD partners in the meeting had the opportunity to ask further questions of interest. The interactive interview session was recorded, later on transcribed, and qualitatively analysed. The results of this session can be found in Section 3. 2.2 Interviews The overall goal of the interviews was twofold: First, with the interviews we aimed to get a deeper understanding of how the audit preparation processes of the pilot partners and the audit processes of the external auditors (NIXU/DNV) took place. In the context of EMERALD [2], the target groups are, on the one hand, the pilot partners, and particularly those employees who are responsible for preparing and ensuring compliance with cybersecurity standards in the Figure 1. Overall methodology applied in WP4 D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 18 of 128 www.emerald-he.eu respective organisations. These employees consist of (internal) auditors, chief information security managers, compliance managers, security managers, etc. The second target group is (external) auditors, i.e., auditors who are assigned to conduct the cybersecurity audits within the scope of an official audit. Second, the interviews helped us to elicit requirements for the development of the EMERALD UI/UX. In more detail, the goal of the interviews is to elicit in-depth insights about the work of auditors, compliance managers (CM), and (chief information) security managers in relation to continuous cloud auditing processes. With the interviews we aimed to get: i) a good understanding of the work of our target users in general, ii) activities and tasks relevant to the certification process of cloud computing systems, iii) insights on how EMERALD could support these working activities, iv) insights about the target users’ expectations regarding the EMERALD UI, v) insights about existing pain points, and vi) information about the users’ background knowledge, especially regarding artificial intelligence (AI) (as some parts of EMERALD will use AI technologies). By analysing the given answers, we were able to elicit a first set of UI requirements. Accordingly, we prepared an interview guideline covering the following topics: i) questions to obtain general information about the participants, including their background (education) and their role in the company including the respective activities, ii) questions about the workflows for the audit preparation, iii) questions about how EMERALD could support them, and iv) questions about AI in general and AI literacy in specific. To comply with the current GDPR, we also prepared an information sheet for participants, which provided interviewees with all relevant information about the interview, including the data protection. We also prepared a consent form that allowed us to obtain the written consent from the participants to use the interview results. In addition, we provided a data protection information sheet. All prepared documents can be found in APPENDIX A: Interview Documents and were also added to the EMERALD D7.2 deliverable [9]. Procedure To invite our respective target groups, we contacted the EMERALD pilot partners and the external auditors and asked them to bring us in contact with their (internal) auditors, compliance managers and information security managers. We scheduled an interview appointment with all interviewees. In advance, we sent them the participant information sheet and the data protection sheet and gave them the possibility to clarify any open questions. We then asked them to sign the consent form and send it back to us. All but one of the interviews were conducted via MS Teams, recorded, and later transcribed. One of the interviews was conducted offline – meaning that CaixaBank received the interview guideline from us and collected the answers from their Information Security Governance team in a written way. The primary interview data was analysed through qualitative content analysis, following Glaeser and Laudel [10]. The basic procedure consists of understanding and interpreting the collected texts (interview transcripts) in a systematic and rule-based way. The aim of this analysis is to uncover the workflows and processes on how to prepare for an audit, existing pain points, how the EMERALD UI might help, and to derive concrete requirements for the EMERALD UI/UX development. The results were condensed into one slide set per pilot partner. These slide sets were sent out to the respective partners in preparation for the planned focus groups (see Section 2.3). Altogether, we have conducted 8 interviews in the timespan of March 2024 to February 2025 with compliance managers, security managers and auditors, as depicted in Table 2. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 19 of 128 www.emerald-he.eu Table 2. Overview of the conducted interviews Pilot Partners Participants Type IONOS • 1 interview with a leader of the security management team Online in MS Teams • 1 interview with a security manager Online in MS Teams CloudFerro • 1 Interview with a compliance manager Online in MS Teams • 1 Interview with a security manager Online in MS Teams Fabasoft • 1 Interview with 3 compliance managers Online in MS Teams CaixaBank • 1 (written) interview with the information security governance team Written interview answers NIXU/DNV • 1 Interview with 3 auditors Online in MS Teams • 1 interview with a compliance manager Online in MS Teams 2.3 Focus Groups & Process Workshops To complement the interviews, we held a focus group per pilot, where all interviewees or partners from the respective pilot or external auditors from NIXU/DNV participated in, allowing for an in-depth discussion on the derived results and clarification of any possible misunderstandings. Focus groups can typically be seen as group interviews but guided by specific triggers for discussion [11]. In our case, the triggers were the consolidated results of the individual interviews, which consisted of a summary of the general insights gained from the interactive interview session of the general assembly in Bilbao (March 2024), the processes derived from the individual interviews, and our interpretation of where the EMERALD UI could offer support. These processes were presented in a simple process format. In the next step, we further improved and enhanced the elicited processes. First, we transferred the simple processes into workflow representations – one covering the status quo and one covering the status of how the process would look like with the EMERALD UI. Then, we set up a series of process workshops with all pilot partners and the external auditors to perform another review round on the processes. Finally, we were able to derive a blueprint process serving as an overall EMERALD process for all pilot partners. Procedure To set up a focus group, we contacted the pilot partners and the interview participants via email. In this email, we invited the participants to an online focus group and attached the corresponding slide set with our interview findings. Additionally, the participants were asked to go through the slide set before the focus group was scheduled to ensure they could provide us with valuable feedback and additional details beyond the already collected data. During the focus group, we guided the participants through the prepared slide set and asked for concrete input and feedback. This time, the discussion was not recorded, but notes were taken. After the focus group, the slide set with the processes was adapted with all gained insights and sent out again to the respective focus group participants. We have conducted 4 focus groups as depicted in Table 3. The explicit focus group with IONOS was omitted (as it took some time to do the second interview) and instead combined with the final workshop for the process validation. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 20 of 128 www.emerald-he.eu Table 3. Overview of the conducted focus groups and process workshops Pilot Participants Type CloudFerro • 1 focus group with the consortium member Online in MS Teams • 1 process workshop with the consortium member Online in MS Teams Fabasoft • 1 focus group with 1 compliance manager and 1 consortium member Online in MS Teams • 2 process workshops with the consortium members Online in MS Teams CaixaBank • 1 focus group with the pilot partners Online in MS Teams • 1 process workshop with the consortium member Online in MS Teams DNV/NIXU • 1 focus group with 1 compliance manager and the NIXU/DNV project manager from the consortium Online in MS Teams • 2 process workshops with the consortium members, an external auditor and a compliance manager Online in MS Teams In the next step, we further improved and enhanced the first elicited simple processes. For each pilot partner and the auditors, we transferred the manual process, and the process enhanced with the EMERALD solution into the two respective workflow representations. As a result, we created for each pilot partner and the auditors an individual Miro 4 board, where we included both processes. Additionally, we added a first version of the blueprint, where we tried to combine all different processes into one that should be valid for all pilot partners. Afterwards, we sent the pilot partners and the auditors an email with the link to the boards and asked them to go through the processes and gather feedback. We set up individual process workshops (February/March 2025) with the pilot partners and auditors, as presented in Table 3, where we went through the processes together to see what to improve, we integrated the collected feedback and adapted the processes accordingly. Additionally, we asked all invited parties to have a final look at the processes to confirm that they were ok for them. These activities resulted in the final definition of the processes for the pilot partners and the auditors: the current “as-is” process, and the process with EMERALD support. Additionally, a blueprint process that is valid for all pilot partners was created. This blueprint could be of interest for other companies who would like to use the EMERALD solution to support their audit preparation processes. The final processes per pilot partner and auditors, and the blueprint are presented in Section 4. 2.4 Personas & Scenarios Workshops Based on the insights gained from the interviews and the focus groups, e.g., what the audit preparation processes and audits in general look like, which persons and roles are involved in these processes and what information is needed, a first Personas and Scenarios workshop was organised. The goal of this workshop was to develop detailed personas and scenarios on how the target groups will use the EMERALD UI and which functionalities should be available. Personas are a goal-directed design tool introduced by Cooper [12]. A persona typically represents a fictional individual or a representative group of persons with similar characteristics (see [13], [14]). They are often described in a narrative way to make the person seem authentic and to provide the needs of these individuals in the related context [15]. Personas are typically 4 https://miro.com/ D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 21 of 128 www.emerald-he.eu used in combination with scenarios. Scenarios describe, in a narrative way, how target users will ideally interact with the developed technology [16]. After developing personas and scenarios, user journeys [17] are another design method to help understand the interaction between a user and a technology. The initial user journeys have been presented in D4.3 [8] and the final user journeys will be presented in D4.4 (M24). Overall, defining personas and engaging in scenarios helps to gain a deeper understanding of the users, their tasks, and their interactions with the system. The results of the workshops should tailor the UI/UX of EMERALD to the specific needs of the users (e.g., compliance managers and auditors). The aim is to clarify how the different user groups will interact with the EMERALD UI during different working activities and tasks. Furthermore, this will help gathering information on the functionalities to be provided in the EMERALD UI. Altogether, we have conducted four workshops based on the insights gained from the interviews and focus groups, as presented in Table 4. In the two workshops held in June 2024, we were able to derive four personas and three scenarios. As the development of the personas and scenarios was not completed, we set up again two other workshops in autumn 2024. One workshop with NIXU/DNV to create auditor-specific personas and scenarios, and another with the EMERALD consortium partners to finalize and expand existing work. Finally, we developed seven personas across three stakeholder groups and 16 scenarios. Table 4. Overview of all Persona and Scenario Workshops Personas & Scenario Workshop Date Type Workshop Results Personas & Scenarios Workshop Part I 05.06.2024 Online in MS Teams Development of 4 Personas: Emerson, Riley, Dylan, Charlie Personas & Scenarios Workshop Part II 12.06.2024 Online in MS Teams Development of 3 Scenarios for Emerson, Dylan, Charlie Personas & Scenarios Workshop with NIXU/DNV 13.08.2024 Online in MS Teams Development of 2 Personas and 2 Scenarios for Jarkko and Eero Personas & Scenarios Workshop Part III 07.10.2024 Online in MS Teams Development of 1 additional Persona, Morgan, and all missing scenarios Once all the relevant personas and scenarios were elaborated and well defined, we derived from them the so-called “personas-on-the-go”. “Personas-on-the-go” provide a very concise, precise summary of our personas, highlighting key characteristics in a brief description. These ensure that target users and external audiences can quickly understand the purpose and needs of the personas in relation to the EMERALD UI. All personas, the respective scenarios and the “personas-on-the-go” are presented in Section 5. Procedure To invite participants to the workshop, we contacted the pilot partners and all members of WP4 and WP5 by email. All Personas & Scenarios Workshops were conducted online using MS Teams. To facilitate collaboration, we used Miro, an online collaborative whiteboard. Below, we describe all Persona & Scenarios Workshops done in more detail: Workshop Part I: The first part of the workshop was attended by 11-14 participants. The agenda was as follows: first, we introduced how to use the Miro Board. Then, we set the stage and goal of the workshop and invited the participants to take part in an activity, namely, to note down D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 22 of 128 www.emerald-he.eu their expectations towards the workshop shortly. Afterwards, we presented a summary of the work processes elicited from the different pilot partners’ interviews. Having this information in mind (and on the Miro board), we divided the participants into four groups. Each group was asked to create a persona, using a predefined persona template, representing one of the targetusers of the EMERALD Project. The persona template consisted of three parts with several sub-topics: • About the persona: This part includes private information, occupation, goal, and other characteristics. • What do I do: This section collects working tasks, motivation and goals at work, frustrations and pain points. • Contacts: Information about departments and roles the persona is working with. • Work context: This covers information about day-to-day tasks, and where the EMERALD UI could help. Workshop Part II: The second part of the workshop was attended by eleven participants. The agenda was as follows: first, we made a short recap of the first part of the workshop by briefly summarizing the four personas developed. Second, we introduced scenarios and user stories as co-design method in general. Then, we presented 6 pre-defined scenarios as starting points. Afterwards, we divided the participants into three groups and asked them to create a scenario for the persona they had developed in the first workshop. They could use one of the pre-defined scenarios as a starting point. After developing the scenario, they were asked to break it down into different steps to determine how the persona would interact with the EMERALD UI and to discuss these user stories in relation to the pre-defined mock-ups. The activities of both workshops resulted in four personas: Emerson – Compliance Manager in Financial Services, Riley – Cloud Provider Compliance Manager, Dylan – Internal Control Owner, Charlie – Internal Auditor, and three scenarios: Scenario 1: Emerson – Bring your own certification scheme, Scenario 2: Dylan – ICO Requirement Implementation and Scenario 3: Charlie – Preparation of an audit by an internal auditor. Persona & Scenario Workshop with NIXU/DNV: The Workshop with NIXU/DNV was held in August 2024. This workshop was conducted online in MS Teams, and we used Miro again to facilitate the collaboration. Before the workshop, we enhanced the already existing EMERALD Miro board to develop auditor personas. We held a short meeting with the colleagues from NIXU/DNV and explained what we would like to have and how to use the Miro Board. We also explained the two templates we had prepared for the development of personas and scenarios that we used in the previous workshops. Subsequently, we asked them to develop necessary personas and define respective scenarios for each persona themselves. Afterwards, we held a workshop to go through the personas and the respective scenarios and to discuss and refine them in detail. These activities resulted in two new personas – Jarkko – Lead auditor in a consulting company and Eero – Technical auditor in a consulting company. Final Personas & Scenarios Workshop Part III: The final workshop was attended by twelve participants. Before inviting all EMERALD partners to the third persona & scenario workshop, we read D5.1 – Pilot definition, set-up & validation plan [18]. The goal was to investigate which additional stakeholders were involved within the pilot definitions and set-up (see D5.1 [18], Section 2). We created a table with all involved stakeholders mentioned in the pilot definitions and discussed with the consortium which of them are relevant for EMERALD. Subsequently, we agreed on a list representing all EMERALD stakeholders and identified, which of them are still D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 23 of 128 www.emerald-he.eu missing. This served as a starting point for the final workshop where we prepared a Miro board with a structured template. We highlighted the still missing gaps regarding one persona, several scenarios and user journeys. The corresponding templates were documented in D4.1 [1] – Figure 2 and D4.3 [8], Figure 2. Table 5 reflects the final status upon completion of all workshops. Additionally, we developed a first set of user journeys for the respective personas which will be presented in D4.4 – User Interaction and User Experience Concept – v2 (M24). These user journeys are closely tied to the scenarios and the ongoing development of the EMERALD UI and are therefore under continuously development. Table 5. Status Overview of the Development of Personas, Scenarios and User Journeys Roles Notes Personas Scenarios User Journeys Compliance Stakeholders Compliance Manager UI/UX: they will be merged in one role in the EMERALD UI Riley done in progress Compliance Manager for financial services Emerson done in progress Internal Control Owner - Dylan done in progress Technical Stakeholder Technical Implementer One role covering all technical roles including the metric implementer, developers, etc. (Old name: Metric Implementor) Morgan done in progress Auditor Stakeholders Internal Auditor - Charlie done in progress External Lead Auditor UI/UX: they will be merged in one role in the EMERALD UI Jarkko done in progress External Technical Auditor Eero done in progress Gender-bias in Personas and Scenarios It is known from literature that gender bias during technology development is a problem because women are often under-represented in design teams and in co-creation and co-design processes (see [19], [20], [21]). With regard to personas, several strategies on how to mitigate gender bias during the development of personas and scenarios exist – one of them is to use gender-neutral personas (see [22], [23]) and to formulate scenarios in a gender-neutral way. Therefore, we created a list of gender-neutral names to use during the workshops, and did not ask for a specific gender in the persona template. Afterwards, all gender-specific formulations were removed (e.g., all wording referring to he/she was replaced with they). To make the development of the personas more fun for the participants, we asked them to create a profile picture for each persona. Originally, we planned to remove the profile pictures from the final personas. However, instead of removing the profile pictures, we made them gender-neutral for several reasons. • Inclusivity: Gender-neutral personas ensure that all users, regardless of gender identity, feel represented and considered in design and decision-making processes [23]. • Avoiding Bias: Gendered personas can reinforce stereotypes, such as associating certain roles or behaviours with specific genders. Neutral figures help prevent these biases. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 24 of 128 www.emerald-he.eu • Flexibility: Gender-neutral personas can be more universally applicable, allowing stakeholders to focus on user needs, behaviours, and challenges rather than genderbased assumptions [23]. • Encouraging Diversity: They foster a more diverse and equitable approach to problemsolving, ensuring that solutions do not unintentionally exclude or disadvantage any group [23]. • Reflecting Reality: Many real-world scenarios involve individuals whose gender is not immediately relevant or who identify outside the binary. Gender-neutral personas acknowledge this diversity [24]. Using gender-neutral profile pictures makes personas and scenarios more inclusive, adaptable, and effective in addressing a broad range of users’ needs. Therefore, we decided to keep the profile pictures. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 25 of 128 www.emerald-he.eu 3 Results of the Interactive Interview Session The interactive interview session was conducted per pilot at the general assembly in Bilbao (March 2024). The results are presented below as follows: first, for each question a short summary is presented, followed by a table summarizing the results of all pilots in more detail. Q1: How do the current audit preparation processes look like for your pilot? All pilot partners described the audit preparation processes very similarly. Audits take place yearly up to every 4-5 years. The frequency of the audit depends on the type of the audit (e.g., some audits take place yearly, some only every 2-3 years) and the standard that is audited. Typically, the preparation of an audit is a repetitive and time-consuming manual process that involves many people from different departments, as described in Table 6. Table 6. Answers given to Q1: “How do the current audit preparation processes look like for your pilot?” Q1: How do the current audit preparation processes look like for your pilot? Pilot 1: IONOS Pilot 2: CloudFerro Pilot 3: Fabasoft Pilot 4: CaixaBank • repetitive manual processes • involvement of various teams • rely on external consultancy companies • based on a spreadsheet → turned into tickets • documents such as employee certifications, need to be formalized and presented • multiple audits yearly • time-consuming • audits last 2-4 days • significant preparation time • manual preparation of procedures, policies, and documentation • traditional audits: not always able to deal with automatically collected evidence or digital support of the steps • automatically collected pre-processed evidence has to be presented as manual evidence • auditors are able to have the evidence chains • many people involved in preparing the audit and during the audit • major tool: spreadsheet • create a huge number of tickets and issues that need to be addressed by a lot of people • pilot covers several environments • continuous assessment on own premises • internal audit yearly, with additional audits for cloud provider license renewals • periodic audits by ECB every 4-5 years, covering all aspects of bank security • audits occur annually Q2: What are the “pain points” for your current audit process? The pilot partners mentioned similar “pain points” that they must deal with during the audit preparation phase, as presented in Table 7. Pain points mentioned are that i) the audit preparation phase is a very costly process as it involves consultancy from outside, and many people and departments from inside, ii) it is a very time-consuming process to show evidence for all requirements necessary for the respective audit, and iii) it needs manual verification of extensive documents. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 32 of 128 www.emerald-he.eu 4.2.1.2 Workflow Representation of the Process without EMERALD support In the next step, we transferred the simple process representation into a detailed workflow representation. This representation was discussed with the colleagues from IONOS, to investigate if the workflow representation is correct. After some minor improvements, the resulting workflow process is presented in Figure 3. • Phase 1 – Preparation (Figure 3, Phase 1): o Landscape preparation: CM prepares the system landscape for setting up the audit preparation process. o Change management: CM initiates the change management and uses the established internal control system including a spreadsheet. • Phase 2 – Documentation (Figure 3, Phase 2): o Documentation: In the second step, the CM needs to ensure that all mandatory documents as well as the system descriptions are up to date. • Phase 3 – Management of Controls (Figure 3, Phase 3): o Security policies and controls: CM organizes all security policies with controls. o Spreadsheet creation: CM manages the controls in a spreadsheet. The spreadsheet consists of information such as: controls; control frequency; type of control; responsible person for the control; evidence we need to show that it has been implemented. • Phase 4 – Audit Scope (Figure 3, Phase 4): o Audit scope: CM needs to keep the audit scope description up to date. o Control checking: CM checks the status of the controls and escalates if the evidence reported is insufficient or not prepared in time. • Phase 5 – Audit Setup (Figure 3, Phase 5): o Audit setup: The Event Manager sets up the audit and decides on the audit team (external notified body). o Renew contract: After deciding for an audit, the IONOS team updates the contract with the auditors. If the audit is against BSI C5, there needs to be a certificate confirming no conflicts of interest (both sides). o Set practicalities: Audit dates, scope and parameters are set and need to be agreed to. Also, the individual audit plan must be agreed to. Figure 2. IONOS – Simple process representation without EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 33 of 128 www.emerald-he.eu o Report creation: Reports must be created: including an internal control system with all established controls and the mapping to BSI C5 criteria. o Hand over report: Reports must be handed over to the auditors at the beginning of the audit. D4.2 Results of the UI-UX requirements analysis and the work processes – v2 Version 1.0 – Final. Date: 30.04.2025 © EMERALD Consortium Contract No. GA 101120688 Page 34 of 128 www.emerald-he.eu Figure 3. IONOS – Workflow Representation without EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 35 of 128 www.emerald-he.eu 4.2.1.3 Simple Process with EMERALD support For each of the five phases mentioned above in the IONOS audit preparation process, we have derived some ideas on how the audit preparation process of cloud solutions at IONOS could be supported by the EMERALD UI, as shown in Figure 4. • Phase 1 – Preparation (Figure 4, Phase 1): o Setup controls: The CM can use EMERALD to support the preparation process by getting the list with all controls. • Phase 2 – Documentation (Figure 4, Phase 2): o Upload documents: The CM can upload all relevant and updated documents into the EMERALD UI. o Extract evidence: EMERALD can help extract evidence from the documents and map them to the controls. o Visualisation of Controls/Metrics and Evidence: EMERALD UI/UX provides a table showing the controls/metrics and the found evidence and links to the respective documents. • Phase 3 – Management of Controls (Figure 4, Phase 3): o List of controls: EMERALD provides the list of the controls for the CM. o Management of controls: The CM can use EMERALD to manage the controls; assign responsible people to a control; add documentation, and keep track of the evidence; etc. • Phase 4 – Audit Scope (Figure 4, Phase 4): EMERALD can help to keep the audit scope upto-date. • Phase 5 – Audit Setup (Figure 4, Phase 5): o Reporting: EMERALD can support preparing and printing out the reports (e.g., different formats, different content) that need to be handed over to the auditors at the beginning of the audit. 4.2.1.4 Workflow Representation of the Process with EMERALD support In the next step, we transferred the simple process representation into a detailed workflow representation. This representation was again discussed with the colleagues from IONOS, to Figure 4. IONOS – Simple process representation with EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 36 of 128 www.emerald-he.eu investigate if the workflow representation is correct. After some minor improvements, the resulting workflow process is presented in Figure 5. • Phase 1 – Preparation (Figure 5, Phase 1): o System landscape preparation: CM prepares the system landscape for the audit. o CM initiates change management: CM uses the established internal control system (including spreadsheet) to initiate the change management. o Upload Controls: CM uploads the certification scheme, thus the extracted controls, into EMERALD. o EMERALD: EMERALD makes all controls available. o EMERALD: EMERALD automatically assigns metrics to controls. • Phase 2 – Documentation (Figure 5, Phase 2): o Check Metrics: CM goes through all automatically assigned metrics to a control. o Metric Check not ok: CM checks all metrics and changes them where needed. o Metric Check ok: CM continues in the process. • Phase 3 – Management of Controls (Figure 5, Phase 3): o Setup target of evaluation: New target of evaluation needs to be set up and the appropriate evidence extractors need to be installed. There, the CM can upload the policy documents in EMERALD. o The CM sets up the audit scope using the created target of evaluation in EMERALD. o EMERALD automatically extracts metrics-related data/information from the documents and makes the assessment results available to the CM. o Managing Controls: CM can manage all controls in EMERALD. o Filtering Controls: CM can filter for all controls that are still marked as “open” and manually check the assessment results. o Check for next open Control: If a next open control exists, the CM checks the control and its assessment results / evidence. o Check Assessment Result: If the check is ok, based on the available assessment results, CM can set the control / metric in EMERALD to compliant. o Check Assessment Result: If the check is not ok, CM/Person assigns control/metric to a person or a department. The person checks the assessment results of the assigned control/metric provided in EMERALD. o Check Assessment Result (by Person): If the check is ok based on the available assessment results, the person can set a control/metric to compliant in EMERALD. o Check Assessment Result (by Person): If the check is not ok, but the person knows how to solve it, the person implements the metric and sets the metric/control in EMERALD to compliant. o In both cases, the person assigns the control/metric back to the CM. o All Controls Checked: After the CM has checked all controls/metrics and documents, the CM consolidates everything for the audit. • Phase 4 – Audit Scope Management (Figure 5, Phase 4): o Keep Audit Scope Up-to-date: CM needs to keep the audit scope description up-todate. o Check Audit Scope Reporting: CM checks the reporting and escalates if the evidence reported is insufficient or not prepared in time with the help of EMERALD. • Phase 5 – Audit Setup (Figure 5, Phase 5): o Setup Audit: The Event Manager sets up the audit and decides for the audit team (external company). o Renew Contract: After deciding for an audit team, IONOS needs to update the contract with the auditors. If the audit is against BSI C5, there needs to be a certificate confirming no conflicts of interest (both sides). D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 37 of 128 www.emerald-he.eu o Set Practicalities: Audit dates, scope and parameters are set and need to be agreed upon. Also, the individual audit plan must be agreed to. The decision needs to be made on whether EMERALD can be used during the audit. o Use EMERALD: If it is agreed to that the audit can be conducted with the support of EMERALD, it can be used to evaluate controls/metrics, assessment results and documents. o Use EMERALD: If it is not agreed to that the audit can be conducted with the support of EMERALD, all evidence must be handed over to the auditors at the beginning of the audit; this includes the internal control system with all established controls, evidence and the mapping to BSI C5 criteria. D4.2 Results of the UI-UX requirements analysis and the work processes – v2 Version 1.0 – Final. Date: 30.04.2025 © EMERALD Consortium Contract No. GA 101120688 Page 38 of 128 www.emerald-he.eu Figure 5. IONOS – Workflow Representation with EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 39 of 128 www.emerald-he.eu 4.2.2 Pilot 2: CloudFerro (CF) We conducted two interviews with CloudFerro employees: one with a compliance manager and one with a security manager. Afterwards, we conducted a focus group with CloudFerro to validate our findings regarding the processes with them. From these discussions the simple process of how to prepare for an audit was derived. Figure 6 presents the simple process of an audit preparation process as it is now, while Figure 8 presents the simple process enhanced with the EMERALD support. After having transferred the simple process into the workflow representation, we conducted a workshop with an employee from CloudFerro to discuss the workflow representation and to adapt it – if necessary. The CF workflow representation for the current audit preparation process without EMERALD support is presented in Figure 7, and the workflow representation with EMERALD support is presented in Figure 9. In the following we present the simple process and the corresponding workflow presentation covering the audit preparation processes as they are now. Then we present the simple process and the elaborated workflow representation as they would look like using the EMERALD solution. 4.2.2.1 Simple Process without EMERALD support The simple process without EMERALD support consists of the following four phases: • Phase 1 – Starting with analysis (Figure 6, Phase 1): In phase 1, the responsible person starts with a coordination check and contacts the certification board. The audit preparation process differs a bit depending on whether the audit preparation is done for a new certification scheme, for an existing certification scheme that was updated, or for checking the current certification scheme. If a new certification scheme is added, more work is needed to fulfil all controls. If a certification scheme was updated, they check which controls were updated and which are new. Their goal is to implement as many controls as possible in the most efficient way. • Phase 2 – Standard (Figure 6, Phase 2): In phase 2, the responsible person deals with the respective certification scheme to be prepared. They buy either the new standard or organize the updated standard. They go very carefully through the respective standard and elicit either all controls from the new standard or only the new and updated controls from the updated standard. • Phase 3 – Check with documentation (Figure 6, Phase 3): All controls need to be clarified on how to deal with them if they need to be implemented (technically), if respective documents need to be updated, etc. Where necessary, other departments or individuals will be contacted to help clarify controls. • Phase 4 – Identify gaps (Figure 6, Phase 4): In this phase, all existing gaps are identified to manage open controls and discuss how to deal with them. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 40 of 128 www.emerald-he.eu 4.2.2.2 Workflow Representation of the Process without EMERALD support In the next step, we transferred the simple process representation into a detailed workflow representation. This representation was again discussed with the colleagues from CloudFerro, to investigate if the workflow representation is correct. After some minor improvements, the resulting workflow process is presented in Figure 7. • Phase 1 – Starting with analysis (Figure 7, Phase 1): o Coordination check and standard: In the first phase, the CM does a coordination check and gets in contact with the certification board. Additionally, the CM checks the new or updated standard. • Phase 2 – Standard (Scheme) (Figure 7, Phase 2): o Standard (scheme): Depending if the CM has to deal with the same standard as in the last audit, an updated version of the standard or a new standard, the CM needs to do different activities: ▪ Same standard: No activities are required here. ▪ Updated standard: CM needs to check for the new or updated controls in the standard. ▪ New standard: CM needs to buy the new standard and get familiar with it. The CM has to extract all controls from the new standard. • Phase 3 – Check with documentation (Figure 7, Phase 3): o Check documentation: The CM needs to check back the new or updated controls with the corresponding documents. The CM makes sure to find the exact information to fulfil the controls. The CM writes down their responses for each control and makes sure to provide the documentation and provide links to their solution. o Contact colleagues: As a CM does not always have all detailed domain knowledge about all controls, the CM contacts colleagues and/or departments to clarify the new or updated controls. • Phase 4 – Identify gaps (Figure 7, Phase 4): o Identify gaps: The CM and their colleagues identify gaps in the documentation and try to implement as much for the new/updated control as possible. Figure 6. CloudFerro – Simple process representation without EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 41 of 128 www.emerald-he.eu • Phase 5 – Managing controls (Figure 7, Phase 5): o Spreadsheet or word document: Depending on the standard, the CM creates a spreadsheet or a word document in which all controls are managed. The CM creates new controls or updates existing controls and their progress of implementation. o Organizational and technical controls: For organizational controls, the CM checks if in some of their documents something is written about the control. Depending on the text found, the CM must decide: i) if the written text is ok, then nothing needs to be done; ii) if the written text needs to be updated in line with the control; or iii) if there is no written text referring to the control, then the text needs to be written. For the technical controls, the CM relies on best practices and the company’s CI/CD to initiate the required implementation (software updates, implementation of security tools, configuration changes...). o Final check: Finally, the CM needs to consolidate everything for the audit. Afterwards the CM plans the audit with an external notified body and clarifies the details including the date, the audit scope, the target of evaluation, and other logistics. D4.2 Results of the UI-UX requirements analysis and the work processes – v2 Version 1.0 – Final. Date: 30.04.2025 © EMERALD Consortium Contract No. GA 101120688 Page 48 of 128 www.emerald-he.eu Figure 11. Fabasoft – Workflow Representation without EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 49 of 128 www.emerald-he.eu 4.2.3.3 Simple Process with EMERALD support For each of the three phases mentioned above in the Fabasoft audit preparation process, we have derived some ideas on how the audit preparation process of cloud solutions at Fabasoft could be supported by the EMERALD UI, as shown in Figure 12. • Phase 1 – Set-up Mapping (Figure 12, Phase 1): EMERALD can support the compliance manager with the following tasks for setting up the mapping: o Control overview: EMERALD can create a list with all controls of the respective certification scheme for the upcoming audit. o Control metrics: EMERALD can provide the possibility to set the respective metrics for all controls. o Control status: EMERALD can show the status of each control on two levels – compliance level and status level. • Phase 2 – Set-up (Figure 12, Phase 2): EMERALD can support the compliance manager with the following tasks: o Filtering: EMERALD allows to filter for controls that need further input. o Add notes: EMERALD allows to add notes to a control e.g., suggestions on how a control could be addressed. o Assigning controls: EMERALD allows to assign controls to departments or individuals and vice versa, controls can be assigned back to the compliance manager. • Phase 3 – Verification (Figure 12, Phase 3): EMERALD can support the compliance manager and the other departments with the following tasks during the verification phase: o Verification by departments or individuals: EMERALD allows the respective departments or individuals to verify the controls. o Verification by the compliance managers: EMERALD allows the compliance manager to mark the respective controls as ready for being used in an audit. 4.2.3.4 Workflow Representation of the Process with EMERALD support In the next step, we transferred the simple process representation into a detailed workflow representation. This representation was again discussed with the colleagues from Fabasoft, to investigate, if the workflow representation is correct. After some minor improvements, the resulting workflow process is presented in Figure 13. • Phase 1 – Set-up Mapping (Figure 13, Phase 1): EMERALD can support the compliance manager with the following tasks for setting up the mapping: o Setup the certification scheme: Using EMERALD, the CM can either upload a new certification scheme or use an existing scheme that is available in EMERALD. EMERALD makes the scheme and all respective controls available and automatically assigns metrics to the controls. Figure 12. Fabasoft – Simple process representation with EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 50 of 128 www.emerald-he.eu o Check metrics: The CM uses EMERALD to check all suggested metrics that were assigned to a control and can decide if the metrics are ok or need to be changed. o Setup target of evaluation: After having set up the scheme and assigned for each control the respective metrics, the CM sets up a target of evaluation. Additionally, the CM can (with the help of the IT department) set up the respective evidence extractors (e.g., AI-SEC, AMOE, Clouditor Discovery, Codyze, eknows-e3). o Setup Audit Scope: Finally, the CM creates a new audit scope in EMERALD using the newly created target of evaluation and the respective certification scheme, including its controls and metrics. • Phase 2 – Mapping (Figure 13, Phase 1): In the mapping phase, EMERALD can support the compliance manager with the following tasks: o Automatic evidence extraction: EMERALD tries to automatically extract evidence for all controls and their metrics. The EMERALD UI presents a list of all controls and metrics and the extracted assessment results from the evidence extractors. o Filter controls: The CM can filter for all controls and metrics and check manually all assessment results. o CM checks non-compliant controls/open metrics: Especially for those controls or metrics that are non-compliant or open the CM needs to decide what to do. First, the CM checks the assessment results. Depending on the assessment results and depending on the CMs domain knowledge, the CM has two options: i) the CM can decide for a control that the assessment results (or at least one assessment results) for metric(s) are ok and change the metric status to ok; ii) the CM can assign the control or metric to another person or department. o Person checks non-compliant controls/open metrics: If a CM assigns a control or metric to an individual, that person must review the corresponding assessment results. This person has three possible courses of action: ▪ If the person possesses the necessary domain knowledge, they verify the accuracy of at least one of the provided assessment results, mark the control as compliant or the metric as done, and return it to the CM. ▪ If the person can implement the metric’s measurement, the person proceeds with the implementation, documents the actions taken, and then reassigns the control or metric to the CM. ▪ If the person lacks the expertise to implement the control or metric, the person either returns it to the CM or forwards it to another individual who might have the required knowledge. Ultimately, all controls should be reassigned to the CM. • Phase 3 – Verification (Figure 13, Phase 3): EMERALD can support the compliance manager and the other departments with the following tasks during the verification phase: o Validity check: In the final phase of the process, the CM does a validity check, thus, a final check that all respective controls are compliant. o Filter for controls: To do so the CM goes through all controls again, checks all controls especially those that have been assigned back to the CM or need more discussions. D4.2 Results of the UI-UX requirements analysis and the work processes – v2 Version 1.0 – Final. Date: 30.04.2025 © EMERALD Consortium Contract No. GA 101120688 Page 51 of 128 www.emerald-he.eu Figure 13. Fabasoft - Workflow Representation with EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 52 of 128 www.emerald-he.eu 4.2.4 Pilot 4: CaixaBank (CXB) With CXB, we conducted a written interview with compliance managers. Additionally, after having analysed the results, we conducted a focus group with the responsible compliance manager and the project manager on behalf of CXB for EMERALD to get input and feedback about the derived simple processes. Figure 14 presents the current simple process of an audit preparation process referring to a cloud service provider where CXB is a customer, while Figure 16 presents the simple process enhanced with the EMERALD support. After having transformed the simple process representation into a workflow representation, we conducted a workshop with the CXB colleagues to validate the processes. Figure 15 presents the derived workflow representation of the simple process as it is now, and Figure 17 presents the workflow representation with EMERALD support. First, we present the simple process and the corresponding workflow presentation covering the processes as they are now. Then, we present the simple process and the elaborated workflow representation as it would look like using the EMERALD solution. 4.2.4.1 Simple Process without EMERALD support The simple process without EMERALD support consists of the following five phases: • Phase 1 – Initiation (Figure 14, Phase 1): The service owner (SO) of CXB initiates the information acquisition from a cloud service provider (CSP) with the help of the questionnaire. When having received the filled in questionnaire from the CSP, the CM determines alignment with predefined parameters provided by the CSP. • Phase 2 – Risk Gathering (Figure 14, Phase 2): The service provider (SP) gathers the UNED Service Risk Information. Based on this information, the SO issues the security questionnaire to the CSP to collect detailed information about their data handling and data processing. • Phase 3 – Matrix Creation (Figure 14, Phase 3): With the help of the information collected from the second questionnaire, the CM generates the control & evidence matrix for managing the CSPs controls. Then the CM asks the CSP to submit the evidence of compliance for the identified controls to CXB. • Phase 4 – Risk Analysis (Figure 14, Phase 4): Based on the evidence received, the CM conducts a risk analysis and control evaluation to assess residual risks. If the risk of an evidence for a control is too high, the CM develops remediation plans or explore alternative solutions. If the risk of evidence is acceptable, the CM performs a continuous monitoring and periodic re-evaluation of the controls, and the evidence assigned. • Phase 5 – Reporting (Figure 14, Phase 5): In this phase different reports are created: o Audit Report: outlines areas of compliance and non-compliance. o Track Record of Evidence: includes documentation provided by the CSP, results of risk analysis, evidence of the implementation of controls. o Compliance Status: documents the compliance of the service with standards, regulations and risk thresholds of CaixaBank. o Re-evaluation: provides the documentation of ongoing monitoring and periodic reevaluation process. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 53 of 128 www.emerald-he.eu 4.2.4.2 Workflow Representation of the Process without EMERALD support In the next step, we transferred the simple process representation into a detailed workflow representation. This representation was again discussed with the colleagues from CXB, to investigate if the workflow representation is correct. After some improvements, the resulting workflow process is presented in Figure 15. • Phase 1 – Initiation (Figure 15, Phase 1): o Initiating the process: The Service Owner is initiating the acquisition of information from a third-party cloud service provider by sending out a questionnaire. o Governance and compliance review: When having received the filled in questionnaire from the CSP, the CM reviews the governance and compliance information to determine its alignment with predefined parameters, considering data types and processing locations provided by the CSP. • Phase 2 – Risk Gathering (Figure 15, Phase 2): o Risk gathering: The CSP needs to gather the service risk information focusing on various risk taxonomies like legal, business continuity, IT, and security. o Security questionnaire: The SO issues the security questionnaire to the CSP to gather detailed information about their data handling practices, including the types of information processed, data processing locations, and handling methods. This questionnaire is designed to assess the provider’s compliance with specific security controls. • Phase 3 – Matrix Creation (Figure 15, Phase 3): o Control-evidence matrix: The CM generates a control and evidence matrix based on the service type and the information provided in the security questionnaire. The control matrix, which is predefined, is then sent to the CSP. o The CSP provides evidence of compliance for the identified controls, such as security certifications and policies. • Phase 4 – Risk Analysis (Figure 15, Phase 4): o Based on the evidence received, the CM conducts a risk analysis and control evaluation to assess residual risks against the acceptable threshold. Depending on the risk assessment, the following options are possible (two options for risks above the threshold): Figure 14. CaixaBank – Simple process representation without EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 54 of 128 www.emerald-he.eu ▪ Risks too high (above threshold): The CSP needs to develop remediation plans and explore alternative solutions. ▪ Risks too high (above threshold): The CSP needs to send other solutions or means to mitigate the risk. ▪ Risk acceptable: The CM continues the monitoring and periodic reevaluation of the controls and their evidence to ensure continued compliance and address any changes as needed. • Phase 5 – Reporting (Figure 15, Phase 5): In this phase the different types of reports are created: o Audit Report: This document compiled by auditors summarizes the findings of the audit process. It outlines areas of compliance and identifies any non-compliance issues. o Track Record of Evidence: A comprehensive record of evidence is gathered and maintained. This evidence includes documentation provided by the service provider, results of risk analysis, evidence of controls. o Compliance Status: The audit process results in a determination of the compliance status of the service in question. It indicates whether the service meets the established standards, regulations, and risk threshold. o Categorization of the Service: The outcome also includes documentation of the ongoing monitoring and periodic re-evaluation process. This ensures that compliance is maintained over time and that any changes or updates are addressed promptly. D4.2 Results of the UI-UX requirements analysis and the work processes – v2 Version 1.0 – Final. Date: 30.04.2025 © EMERALD Consortium Contract No. GA 101120688 Page 55 of 128 www.emerald-he.eu Figure 15. CaixaBank – Workflow Representation without EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 56 of 128 www.emerald-he.eu 4.2.4.3 Simple Process with EMERALD support In the next step, we transferred the simple process representation into a detailed workflow representation. This representation was again discussed with the colleagues from CXB, to investigate, if the workflow representation is correct. After some minor improvements, the resulting workflow process is presented in Figure 16. • Phase 1 – Initiation (Figure 16, Phase 1): This phase is out of the scope of EMERALD. • Phase 2 – Risk Gathering (Figure 16, Phase 2): This phase is out of the scope of EMERALD. • Phase 3 – Matrix Creation (Figure 16, Phase 3): EMERALD can provide support by creating the controls and evidence matrix. Additionally, EMERALD can provide support by providing a possibility for managing customized security schemes. • Phase 4 – Risk Analysis (Figure 16, Phase 4): The CSP can use EMERALD to provide evidence for the controls to the CM of CXB. The CM can then use EMERALD as a baseline to do the risk analysis. • Phase 5 – Reporting (Figure 16, Phase 5): The EMERALD UI could help with the creation of some reports such as the outcome of an audit (overview of controls and evidence), tracking the record of evidence, compliance state of controls and evidence and re-evaluation. 4.2.4.4 Workflow Representation of the Process with EMERALD support In the next step, we transferred the simple process representation into a detailed workflow representation. This representation was again discussed with the colleagues from CXB, to investigate, if the workflow representation is correct. After some minor improvements, the resulting workflow process is presented in Figure 17. • Phase 1 – Initiation (Figure 17, Phase 1): This phase is out of the scope of EMERALD. o Initiating the Process: The Service Owner initiates the acquisition of information from a third-party cloud service provider by sending out a questionnaire. o When having received the filled-in questionnaire from the CSP, the CM reviews the governance and compliance information to determine its alignment with predefined parameters, considering data types and processing locations provided by the CSP. • Phase 2 – Risk Gathering (Figure 17, Phase 2): This phase is out of the scope of EMERALD. o Risk Gathering: The service provider (SP) needs to gather the service risk information focusing on various risk taxonomies like legal, business continuity, IT, and security. o Security Questionnaire: The SO issues the security questionnaire to the cloud service provider to gather detailed information about their data handling practices, Figure 16. CaixaBank – Simple process representation with EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 57 of 128 www.emerald-he.eu including the types of information processed, data processing locations, and handling methods. This questionnaire is designed to assess the providers’ compliance with specific security controls. • Phase 3 – Matrix Creation (Figure 17, Phase 3): o Define Own Certification Scheme: In EMERALD, CXB can define their own certification scheme based on the answers provided by the questionnaire from the CSPs – using existing controls from different schemes and defining their own controls. o Replace Control and Evidence Matrix: By setting up an audit scope with a target of evaluation and with the new certification scheme, EMERALD can replace the CXB control and evidence matrix. o Provide Access to EMERALD: The service owner provides the CSP access to EMERALD instance, and they set up the EMERALD evidence extractors. o Automatic Evidence Extraction: EMERALD tries to extract evidence for all controls and their metrics automatically. o List of Controls and Assessment Results: EMERALD provides a list of all controls and their respective assessment results and the CSP can ensure that everything is set up. o CSP informs CXB: CSP informs the service owner that everything is set up and the service owner informs the compliance manager. • Phase 4 – Risk Analysis (Figure 17, Phase 4): o Check Controls and Assessment Results: CM checks the controls and their assessment results / evidence in EMERALD. o Risk Analysis & Control Evaluation: The evidence provided undergoes a risk analysis & control evaluation to assess residual risk against the acceptable threshold. Depending on the risk assessment, the following options exist (two options for risks above the threshold): ▪ Risks too high (above threshold): The CSP needs to develop remediation plans and explore alternative solutions. ▪ Risks too high (above threshold): The CSP needs to send other solutions or means to mitigate the risk. ▪ Risk acceptable: The CM continues the monitoring and periodic reevaluation of the controls and their evidence to ensure continued compliance and addresses any changes as needed. • Phase 5 – Reporting (Figure 17, Phase 5): In this phase different types of reports are created, where EMERALD might support the report creation: o Audit Report: This document compiled by auditors summarizes the findings of the audit process. It outlines areas of compliance and identifies any non-compliance issues. o Track Record of Evidence: A comprehensive record of evidence is gathered and maintained. This evidence includes documentation provided by the service provider, results of risk analysis, evidence of controls implementation. o Compliance Status: The audit process results in a determination of the compliance status of the service in question. The compliance status indicates whether the service meets the established standards, regulations, and risk threshold. o Categorization of the Service: The outcome also includes documentation of the ongoing monitoring and periodic re-evaluation process. This ensures that compliance is maintained over time and that any changes or updates are addressed promptly. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 64 of 128 www.emerald-he.eu 4.2.5.4 Workflow Representation of the Process with EMERALD support In the next step, we transferred the simple process representation into a detailed workflow representation. This representation was again discussed with the colleagues from NIXU/DNV, to investigate, if the workflow representation is correct. After some minor improvements, the resulting workflow process is presented in Figure 21. • Phase 1: Initiating and Preparation (Figure 21, Phase 1): o Audit scope: The auditor and the customer define the audit scope together. o Documentation & self-assessment form: The auditor asks the customer for documentation and a filled-in self-assessment form. o EMERALD support: The EMERALD UI can provide the policy documents (if uploaded in EMERALD) and the self-assessment form. Both can be accessed by the auditors. • Phase 2: Audit Activities & Phase 3: Technical Testing/Validation (Figure 21, Phase 2 & 3): o Audit meeting: The auditors open the meeting and set up the practicalities and logistics. The auditors review the documentation. The auditors can use EMERALD to check the different assessment results for all controls. o Check controls: The auditors need to check all technical and organisational controls. ▪ Audit scope: Auditors can use EMERALD to review the organisational and technical controls and their fulfilment regarding the standard in the respective “Audit scope”. The auditor can review the (organisational) documentation using EMERALD. The technical auditor can use EMERALD to review the technical assessment results. ▪ Certification scheme: Auditors can use EMERALD to validate the metrics set for the controls of a scheme. It provides an overview of the controls, and the metrics assigned to them. “Security Center” → “Certification Schemes” ▪ Self-assessment form: EMERALD provides a self-assessment questionnaire for EUCS, which the customers fill in. Auditors can access this questionnaire to simplify the audit process. o Auditor conducts workshops on the customers’ side to interact with the customer and use EMERALD as a baseline. • Phase 4: Reporting (Figure 21, Phase 4): o Report: After the auditors have completed the audit, they compile their findings into a report. The report includes details about the audit process, the scope, findings, Figure 20. NIXU/DNV – Simple process representation with EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 65 of 128 www.emerald-he.eu observations, recommendations, and any non-conformities identified during the audit. Such a report is only accessible by auditors with the appropriate security clearance. o Report generation with EMERALD: Auditors can use EMERALD to create the report. EMERALD provides different reports according to the selected certification scheme; reports should be generated in different formats such as .xlsx, docx or pdf. • Phase 5: Closing the meeting (Figure 21 and Figure 19, Phase 5): o Closing meeting: The auditors hold a closing meeting with the customers to discuss the audit findings. This meeting provides an opportunity for clarifications, discussions about non-conformities, and agreeing on any necessary corrective actions. The auditors can use EMERALD to guide the discussions about the individual controls and assessment results. • Phase 6: Certificate (Figure 21, Phase 6): o Certification: Depending on the audit criteria and standard and if all controls have been met, the auditors may grant a certificate of compliance. EMERALD does not support this step. D4.2 Results of the UI-UX requirements analysis and the work processes – v2 Version 1.0 – Final. Date: 30.04.2025 © EMERALD Consortium Contract No. GA 101120688 Page 66 of 128 www.emerald-he.eu Figure 21. NIXU/DNV - Workflow Representation with EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 67 of 128 www.emerald-he.eu 4.2.6 Compliance Manager (NIXU/DNV) We conducted an interview with a compliance manager from NIXU/DNV which was organised by the NIXU/DNV EMERALD project manager. Additionally, after having analysed the results, we conducted a focus group with the responsible compliance manager and the NIXU/DNV EMERALD project manager to get input and feedback about the derived simple processes. Figure 22 presents the simple process of an audit preparation process as it is now, while Figure 24 presents the simple process enhanced with the EMERALD support. After having transformed the simple process representation into a workshop representation without and with EMERALD support, we conducted a workshop with the NIXU/DNV colleagues to validate the processes. Figure 23 presents the derived workflow representation of the simple process as it is now, and Figure 25 presents the workflow representation with EMERALD support. We first present the simple process and the corresponding workflow presentation covering the processes as they are now. Then, we present the simple process and the elaborated workflow representation as it would look like using the EMERALD solution. 4.2.6.1 Simple Process without EMERALD Support The simple process without EMERALD support consists of the following five phases: • Phase 1 - Preparation and Setup (Figure 22, Phase 1): Phase 1 is the setup, including establishing the compliance framework, setting up the continuous compliance monitoring process, and informing all relevant stakeholders. • Phase 2 - Monitoring and Identification (Figure 22, Phase 2): In this phase, the continuous monitoring and identification of the controls and the respective evidence should take place. If some deviations or non-conformities are identified, the relevant stakeholders need to be informed. • Phase 3 - Evaluation & Decision Making (Figure 22, Phase 3): In this phase, identified deviations or non-conformities need to be evaluated, and a decision must be taken if and how corrective actions will be taken. • Phase 4 - Corrective Action Planning & Implementation (Figure 22, Phase 4): If it has been decided to take corrective actions, these actions must be planned, pursued, and implemented. • Phase 5 – Reporting (Figure 22, Phase 5): In this phase, all activities done regarding the controls and their evidence, as well as all information related to corrective actions, need to be summarised in reports to be available for the audit. Figure 22. NIXU/DNV CM – Simple process representation without EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 68 of 128 www.emerald-he.eu 4.2.6.2 Workflow Representation of the Process without EMERALD Support In the next step, we transferred the simple process representation into a detailed workflow representation. While the workflow follows a continuous compliance management process with a loop, the loop itself is not explicitly depicted in the representation. This representation was again discussed with the colleagues from NIXU/DNV, to investigate if the workflow representation is correct. After some minor improvements, the resulting workflow process is presented in Figure 23. • Phase 1 - Preparation & Setup (Figure 23, Phase 1): o Stakeholder Engagement: The CM identifies key stakeholders, including technical architects, security managers, and compliance managers, and establishes regular meeting schedules for setting up the audit preparation process. o Controls: The CM identifies external and internal requirements to select suitable compliance frameworks in relation to the cloud service that will be audited. o Establish Compliance Frameworks: The CM determines the compliance frameworks relevant to the organisation, e.g. ISO 27001, SOC, and GDPR. o Continuous Compliance Monitoring Setup: The CM sets up all respective systems and the governance model for continuous monitoring of the compliance status, including tools and dashboards, etc. • Phase 2 - Monitoring and Identification (Figure 23, Phase 2): o Continuous Monitoring: The CM collects reports and dashboard information regularly to monitor compliance status against established frameworks. o Deviation Identification: The CM uses tools and dashboards (e.g., Excel for tracking, manual processes, leverage specialized compliance monitoring tools like Azure’s internal tools 6 ) to identify deviations from compliance controls. • Phase 3 - Evaluation & Decision Making (Figure 23, Phase 3): o Deviation Evaluation: The CM evaluates identified deviations to determine their acceptability or if corrective actions are required. o Exception Management and Risk Identification: Exception and risk management are closely connected and iterated processes. o Exception Management: Setting exceptions - when during evaluation something is found to be not compliant but might be acceptable in a specific environment or under distinctive conditions and thus, no corrective actions are needed there, exceptions are defined and set. o Risk Identification: For each identified exception, the risk is assessed and is either accepted and reported or corrective steps will be taken. • Phase 4 - Corrective Action Planning & Implementation (Figure 23, Phase 4): o Corrective Action Planning: The CM plans corrective actions for identified deviations and assigns responsibilities to relevant personnel. o Corrective Action Implementation: The CM and the relevant personnel implement corrective actions and address technical issues and policy-related concerns. • Phase 5 – Reporting (Figure 23, Phase 5): o Compliance Trend Development: The CM pursues the compliance trend development of the controls and does manual reporting. o Documentation and Reporting: The CM summarises discussions and reviews information before presenting it in the respective audits. 6 https://azure.microsoft.com/ D4.2 Results of the UI-UX requirements analysis and the work processes – v2 Version 1.0 – Final. Date: 30.04.2025 © EMERALD Consortium Contract No. GA 101120688 Page 69 of 128 www.emerald-he.eu Figure 23. NIXU/DNV CM – Workflow Representation without EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 70 of 128 www.emerald-he.eu 4.2.6.3 Simple Process with EMERALD Support For each of the five phases mentioned above in the simple process of the audit preparation, we have derived some ideas on how the audit preparation process of cloud solutions could be supported by the EMERALD UI, as shown in Figure 24. • Phase 1 - Preparation & Setup (Figure 24, Step 1): EMERALD can provide support for the following tasks: o Setup: EMERALD can support the setup of the respective compliance framework, standards, or certification schemes. o Cloud service: EMERALD can support the selection of the cloud solution to be audited. o Continuous monitoring setup: EMERALD can support the definition of specific parameters for the continuous monitoring of controls and evidence. o Tasks: EMERALD can support task management throughout the audit preparation process. • Phase 2 - Monitoring and Identification & Phase 3 - Evaluation & Decision Making (Figure 24, Step 2 – Step 3): EMERALD can provide support for the following tasks: o Continuous monitoring: EMERALD can help to support continuous monitoring of the cloud service according to different parameters. The EMERALD UI should provide a dashboard that integrates data from different targets of evaluation to have all data and critical deviations in one glance. Thereby, EMERALD should show possible deviations or non-conformities found. o Log historical data (e.g., when was a deviation, how was this solved, etc.): Additionally, the EMERALD UI should provide activity log data in the form of a history to make all changes of controls or metrics visible, traceable and transparent. • Phase 4 - Corrective Action Planning & Implementation (Figure 24, Step 4): EMERALD can provide support for the following tasks: o Corrective action management: EMERALD should allow the possibility of noting down decisions made regarding the implementation of corrective actions. This includes, for example, having a list of pending tasks that allows to plan and follow up the implementation of the corrective actions. o History: EMERALD can collect, save and visualise a history log file of all tasks and activities performed within the EMERALD UI. • Phase 5 – Reporting (Figure 24, Step 5): EMERALD can provide support for the following tasks: o Controls and evidence: EMERALD could offer the possibility to create a document covering all information about the controls and metrics and the respective assessment results and evidence. o Support during audits: EMERALD could provide the possibility to download different types of reports to support the audit preparation process (e.g., different documents in different formats like Excel sheets, Word Files, etc.). D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 71 of 128 www.emerald-he.eu 4.2.6.4 Workflow Representation of the Process with EMERALD support In the next step, we transferred the simple process representation into a detailed workflow representation. While the workflow follows a continuous compliance management process with a loop, the loop itself is not explicitly depicted in the representation. This representation was again discussed with the colleagues from NIXU/DNV, to investigate, if the workflow representation is correct. After some minor improvements, the resulting workflow process is presented in Figure 25. • Phase 1 - Preparation & Setup (Figure 25, Step 1): o Stakeholder engagement: The CM identifies key stakeholders, including technical architects, security managers, and compliance managers, and establishes regular meeting schedules. o Controls: The CM identifies external and internal requirements to select suitable compliance frameworks in relation to the cloud service that will be audited. o Establish compliance frameworks: The CM determines the compliance frameworks relevant to the organisation, e.g., ISO 27001, SOC, and GDPR. o Continuous compliance monitoring setup: CM prepares and uploads the certification scheme or works with an existing scheme in EMERALD. o The EMERALD UI makes available all controls and automatically assigns metrics to controls. • Phase 2 - Monitoring and Identification (Figure 25, Phase 2): o Continuous monitoring: CM collects reports and dashboard information regularly to monitor compliance status against established frameworks. o Deviation identification: CM sets up a target of evaluation and audit scope in EMERALD. CM uses the different views and functionalities of the EMERALD UI to access controls that are noncompliant. o EMERALD: EMERALD tries to automatically extract evidence for all controls and their metrics. o EMERALD: EMERALD provides a list of all controls, metrics, and the respective assessment results for each audit scope. • Phase 3 - Evaluation and Decision Making & Phase 4 – Corrective Action Planning & Implementation (Figure 25, Phase 3 & 4): o Check controls: CM manually checks all assessment result for all controls and metrics in EMERALD and can filter for all controls that are still marked as “open”. o If all controls/metrics are compliant or not open anymore, the CM continues with Phase 5. o Check assessment results: The CM checks for each control and metrics and the assessment results/evidence in EMERALD. Figure 24. NIXU/DNV CM – Simple process representation with EMERALD support D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 72 of 128 www.emerald-he.eu o Deviation evaluation: The CM identifies deviations to determine their acceptability or if corrective actions are required. Depending on what is necessary, the CM either cares for the exception and risk management or with the implementation of corrective actions. o Exception management and risk identification: Exception and risk management are closely connected and iterated processes. ▪ Exception management: Setting exceptions - when during evaluation something is found to be not compliant but might be acceptable in a specific environment or under distinctive conditions and thus, no corrective actions are needed there, exceptions are defined and set. ▪ Risk identification: For each identified exception, the risk is assessed and is either accepted and reported or corrective, steps will be taken. o Corrective action planning: ▪ The CM plans corrective actions for the identified deviations. ▪ Corrective action planning: CM assigns controls or metrics to relevant personnel. ▪ Check assessment result: Assigned person checks the assessment results of the assigned control/metric provided in EMERALD. ▪ Corrective action implementation: The person implements the corrective actions, addressing technical issues and policy-related concerns accordingly. ▪ Person assigns the control/metric in EMERALD back to the CM. • Phase 5 – Reporting (Figure 25, Phase 5): o Compliance trend development: The CM pursues the compliance trend development of the controls and does manual reporting. o Documentation and reporting: The CM summarizes discussions and reviews information before presenting it in the respective audits. D4.2 Results of the UI-UX requirements analysis and the work processes – v2 Version 1.0 – Final. Date: 30.04.2025 © EMERALD Consortium Contract No. GA 101120688 Page 73 of 128 www.emerald-he.eu Figure 25. NIXU/DNV CM - Workflow Representation with EMERALD support D4.2 Results of the UI-UX requirements analysis and the work processes – v2 Version 1.0 – Final. Date: 30.04.2025 © EMERALD Consortium Contract No. GA 101120688 Page 80 of 128 www.emerald-he.eu Figure 29. Overview of the three stakeholder groups and the respective personas D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 81 of 128 www.emerald-he.eu 5.1 Riley – Cloud Service Provider Compliance Manager The first persona – a cloud service provider compliance manager – was named Riley and is depicted in Figure 30. • About Riley: Riley is 26 years old, single, reads mystery novels, and has a Maine Coon cat as a pet. Riley recently graduated and has started the first full-time position as a compliance manager. Riley’s responsibilities as a compliance analyst are organizing audits and managing the scheduling of different compliance schemes. Her/his overall goal is to gain experience as a compliance manager and grow to become a senior compliance manager. • Tasks, Motivation, and Pains: Riley’s tasks consist of checking audit timelines, organizing and delegating tasks during audits, being the contact person for auditors, and reporting audit status internally. Riley’s goals are to support the company in being trustworthy, perfecting audit processes, being up to date with security standards, and performing tasks more efficiently. Pain points for Riley are the dependency on others to finish tasks timely, the lack of efficient audit tools, and the lack of understanding of complex certification frameworks. • Contacts: Riley’s contacts are the managing board of the company, the chief information security manager, the financial department, developers, and as external contacts, the auditing companies and auditors. • Work Context: EMERALD should help Riley with the day-to-day tasks by speeding up the work. For that, traceability and transparency of the work should be ensured. Further, process steps should be automated, and metrics, controls and evidence should be made reusable for upcoming audits. Simplifying the creation of audit reports would also help Riley in their day-to-day work. Figure 31 summarizes Riley’s main characteristic in a “persona-on-the-go”. Figure 30. Riley – Cloud Service Compliance Manager D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 82 of 128 www.emerald-he.eu 5.1.1 Scenario A: Riley – Managing a New Audit Scope In this scenario, Riley’s goal is to manage a new audit scope as shown in Figure 46 (in Section 10, APPENDIX B). From the C-Level Riley was informed that a new certification scheme for one of their cloud services needs to be used – namely BSI C5. Thus, they need to familiarize themselves with the new certification scheme and prepare the company for the new audit with the EMERALD solution. Therefore, Riley opens EMERALD and navigates to the Certification Schemes to upload a new certification scheme (EMERALD Components: MARI, RCM). Riley uses the Control Mapping function in EMERALD to find out which controls of the previously used EUCS do map to controls offered by the new scheme BSI C5, additionally the metrics of the corresponding controls in EUCS can be transferred. Riley also navigates to the Metrics Mapping to manually map metrics to controls. Then Riley sets up a target of evaluation which includes a three steps description of the cloud solution, setting up all relevant EMERALD extractors and enables, if desired, the Trustworthiness System. Riley creates an audit scope with the newly created target of evaluation and certification scheme and checks the respective assessment results and evidence of the controls retrieved so far. Lastly, Riley uses the newly created audit scope to manage the new certification scheme for the selected cloud service. 5.1.2 Scenario B: Riley – Manage all Controls of an Audit Scope In this scenario, Riley is part of an audit that will take place in two months to renew certificates regarding EUCS as shown in Figure 47 (see Section 10, APPENDIX B). Riley checks the respective audit scope in the EMERALD UI to identify if all controls of the scheme can be met with some evidence (technical or organisational). Riley can use filters to better understand the overall status of the controls. Riley knows that all controls marked with a green checkmark are compliant. Riley can open the respective control (Control Details View) to get more information about the available assessment results. Additionally, Riley can either assign non-compliant controls directly to a person or department. Figure 31. Persona-on-the-go for Riley – Cloud Service Compliance Manager D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 83 of 128 www.emerald-he.eu 5.1.3 Scenario C: Riley – Uncover all “blind spots” When preparing for an audit, Riley is responsible that all controls are fulfilled and there are no blind spots as shown in Figure 48 (see Section 10, APPENDIX B). In the EMERALD UI all controls have an owner (initial creator of the audit scope) and a status (compliant/ non-compliant). For further investigation Riley needs to distribute the non-compliant controls to a colleague or department by assigning them via the EMERALD UI to the respective control or metric. Any additional communication regarding a follow-up process and an escalation needs to be performed outside of EMERALD. 5.1.4 Scenario D: Riley – Updating a certification scheme In this scenario, an audit will be conducted in five months to renew one of the certificates for EUCS. Since the last audit the EUCS has been updated, Riley needs to investigate which of the controls have been changed or added (this will not be supported by EMERALD). Riley opens the EMERALD UI and uploads the new EUCS version as a new certification scheme and creates a new audit scope. In the Metrics Mapping Riley can check for each control the associated metrics. In the respective Audit Scope Overview Riley discovers controls that are non-compliant and need to be further dealt with. For this process Riley uses the EMERALD UI to assign the non-compliant controls to another department or colleague. The scenario was revised from the original version by the pilot partners as presented in Figure 32 to transparently reflect that the initial description was not fully supported by the EMERALD UI, while ensuring the core use case remains viable. 5.1.5 Scenario E: Riley – Accompanying an Audit In this scenario, Riley is accompanying an audit. They are the most important contact person when an audit is taking place at the CSP as presented in Figure 49 (see Section 10, APPENDIX B). Riley is part of an audit team on the companies’ site, to support the external auditors conducting the audit against a certain standard, e.g., EUCS or BSI C5 on the company’s premises. The lead auditor has already selected a big sample of controls that need to be checked during the audit. To ensure that the cloud system is compliant with the selected controls, Riley can present the individual evidence of the controls in the EMERALD UI to the lead auditor. Figure 32. Riley – Updating a certification scheme D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 84 of 128 www.emerald-he.eu 5.2 Emerson - Compliance Manager in Financial Service Institution The second persona – a compliance manager in a financial service institution – was named Emerson and is depicted in Figure 33. • About Emerson: Emerson is 35 years old and married, plays basketball, and has a rabbit as a pet. Emerson has 5 years of experience in the current position. The job description states that Emerson focuses on risk management of third-party cloud services, assesses controls based on risk and regulation, manages contractual agreements, and monitors compliance. Responsibilities include process supervision, evaluating and validating compliance with security measures, and managing data privacy security. The overall goal of Emerson is to ensure that all service providers are compliant with given standards. • Tasks, Motivation and Pains: Emerson’s tasks consist of, among other things, the definition of the audit scheme including controls that must be fulfilled by the cloud service provider, and the assessment of provided evidence for respective controls. In that, goals are to ensure that all service providers comply with the current regulations and ensure safety by mitigating risks associated with audit requirements. Pain points in Emerson's day-to-day are that the communication with other departments is sometimes not fluid, tasks like verification of multiple evidence is not automated but must be done manually, and the management of a high volume of providers and their evidence is tough and time-consuming. • Contacts: Emerson's workplace contacts are the cloud service management, IT, and legal teams. • Work Context: EMERALD could help Emerson in the day-to-day tasks by providing a centralised point for evidence, metrics, and controls, further by automating tedious processes and management of numerous audits and thus minimizing human error and workload. Figure 34 summarizes Emerson’s main characteristic in a “persona-on-the-go”. Figure 33. Emerson – Compliance Manager in Financial Service Institution D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 85 of 128 www.emerald-he.eu 5.2.1 Scenario: Emerson – Bring Your Own Certification Scheme Generally, in this scenario Emerson’s goal would be to define their own certification scheme, thus, the new certification scheme should be a selection and combination of controls from other certification schemes ("Bring Your Own Certification Scheme - BYOCS" option) as presented in Figure 50 (see Section 10 , APPENDIX B). Therefore, Emerson opens the view that allows to set up a new certification scheme and selects a set of controls from available certification schemes (e.g., EUCS, BSI C5). Their line manager then informs Emerson that Department X has decided to acquire a new cloud service provider - namely XYZ. Emerson creates an audit scope to manage cloud solutions and the corresponding BYOCS. Emerson opens EMERALD, selects the audit scope and the XYZ cloud solution to be audited, and uploads all relevant documents (links, etc.). Emerson’s task is to go through and check all controls, for which Emerson goes to the EMERALD UI. Emerson uses different EMERALD UI functionalities to filter the controls and uses different visualizations of the overall status of all controls to determine which controls need to be dealt with and which are already compliant. 5.3 Dylan – Internal Control Owner The third persona – an internal control owner – was named Dylan and is depicted in Figure 35. • About Dylan: Dylan is 45 years old, married, enjoys golf and has three cats and one snake as pets. Dylan's job experience entails ten years as a programmer and fifteen years as a team lead and product owner. Dylan's responsibilities as head of production service include leading a team and overseeing and planning product development and backend services. Regarding audits, Dylan's responsibility is to ensure that controls are addressed, and all evidence is collected. The overall goal is to have no non-compliance for all services. • Tasks, Motivation and Pains: Dylan's tasks consist of defining metrics, collecting evidence for controls, and assigning and delegating control implementation to the team. In that, the Figure 34. Persona-on-the-go for Emerson – Compliance Manager in financial services D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 86 of 128 www.emerald-he.eu goals are to increase transparency, traceability, and accessibility of evidence. Additional goals are to have no non-compliances and to ensure high security. Pain points are manual tasks that must be addressed in addition to the day-to-day activities, repetitive tasks, and tracking control distribution can be difficult. • Contacts: Dylan's internal contacts in the company are other control owners, internal auditors, team members (especially implementers), and the compliance manager. Externally, Dylan gets in contact with auditors. • Work Context: EMERALD could help Dylan in their day-to-day tasks by simply delegating tasks, providing an overview of assigned controls and displaying assessment results. Further, tracking the progress of ongoing audits and the possibility of defining target values and having evidence monitoring and extraction tools. Figure 36 summarizes Dylan’s main characteristic in a “persona-on-the-go”. Figure 35. Dylan – Internal Control Owner D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 87 of 128 www.emerald-he.eu 5.3.1 Scenario: Dylan – Internal Control Owner Control Implementation Overall, in this scenario Dylan opens the EMERALD UI, assesses a control that is still open and would like to delegate the implementation of this control to a colleague Y as presented in Figure 51 (see Section 10 , APPENDIX B). Y selects a set of metrics that matches the controls, implements the control and informs Dylan via the EMERALD UI that the metric was implemented. Dylan checks whether the metric has been implemented correctly and meets the control. 5.4 Morgan – Technical Implementer The fourth persona – a technical implementer (metric implementer, developers, etc.) – was named Morgan and is depicted in Figure 37. • About Morgan: Morgan is 30 years old, single, a dog owner and enjoys gaming and ping pong. Morgan has been working in DevOps for ten years and their current responsibilities are as a DevOps Expert. Morgan’s overall goal is to improve traceability and transparency as well as to have a more structured approach to implementation. • Tasks, Motivation and Pains: Morgan’s tasks, among others, include implementing metrics, deploying new cloud services, adjusting configurations to align with security policies, and setting up verification mechanisms for upgrades. Ensuring a structured approach to metric implementation, centralized reporting, and clear visibility into controls is crucial. Morgan’s focus is on early problem detection, maintaining traceability and ensuring transparency across all processes. Pain points include diverse tools for the evidence collectors, no overview of evidence, and impacts of system upgrades. • Contacts: Morgan is solely communicating internally with the compliance manager, internal control owner and technical implementer as well as a technical auditor. Figure 36. Persona-on-the-go for Dylan – Internal Control Owner D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 88 of 128 www.emerald-he.eu • Work Context: In Morgan’s daily activities, the EMERALD UI could enhance the workflow by offering a comprehensive to-do list, allowing Morgan to easily track which controls are assigned to them. It could also display an overview of metrics, including values, history, and status, with the ability to directly notify the compliance manager when a metric is successfully implemented. A central information hub would provide quick access to control statuses and would enable Morgan to review and reassess assigned controls, with the option to decline those out of scope. Additionally, the EMERALD UI could allow Morgan to check the status of certificates and evidence, ensuring all relevant information is easily accessible in one place. Figure 38 summarizes Morgan’s main characteristic in a “persona-on-the-go”. Figure 37. Morgan – Technical Implementer D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 89 of 128 www.emerald-he.eu 5.4.1 Scenario A: Morgan – Checking Metrics and Evidence In this scenario, Morgan is checking their assigned metrics as presented in Figure 52 (see Section 10 , APPENDIX B). They begin by selecting an evidence extraction tool and verifying the accuracy of the target values for the specific metric. Additionally, they review the status of the evidence and controls associated with previously processed metrics. If everything is correct, Morgan notifies the compliance manager that the metrics have been successfully implemented. If issues arise, they return to the specific metrics to troubleshoot and debug. 5.4.2 Scenario B: Morgan – Removal of Metric In this scenario, Morgan previously had to manually remove metrics and related scripts. With the EMERALD UI, manual removal of metrics is no longer necessary, though the underlying use case remains valid. Instead, EMERALD offers the Metrics Mapping function where metrics can be assigned and unassigned to a specific control. Due to this direct support in the EMERALD UI, compliance managers can now directly make these changes themselves when doing the mapping of metrics to controls. Thus, there is no need for Morgan to remove or adapt anything. For transparency and completeness, the scenario is still presented in its original form in Figure 39. Figure 38. Persona-on-the-go for Morgan – Technical Implementer D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 96 of 128 www.emerald-he.eu 5.7.2 Scenario B: Eero – Reporting Eero reports back to the lead auditor with his findings. They identified all non-compliances and created an audit report where they document and translate all non-compliances (see Figure 59 in APPENDIX B: Original User Scenario Descriptions). D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 97 of 128 www.emerald-he.eu 6 UI/UX Requirements (version 2) All requirements for the EMERALD UI/UX were elicited during all activities (e.g. interviews, focus groups, workshops…) that have been conducted in WP4. The goal of the requirements is to collect all features and needs of the pilot partners and component owners to design and develop the EMERALD UI, resulting in 25 requirements overall. All requirements have been added to the common Git repository of the EMERALD project. Every requirement was described with the following fields: Requirement Id, short title, description, status, priority, component, source, type, related KR, related KPI, and validation acceptance criteria. Additionally, we added information about the current progress status of the requirements regarding the clickable prototype of the EMERALD UI. The progress status of the requirements regarding the implementation of the UI have been reported in D4.5 (M15) [25] and will be reported in D4.6 (M27). The related key result and KPI for all the UI/UX requirements are: • KR6: EMERALD UI/UX - User experience for complexity reduction: A user interaction concept and conducted studies to show what information each user needs in an audit process. The concept shall lead to a user interface (UI), which is tailored to the users’ needs during all stages of an audit and guides them through the process of identifying problems top-down – from high-level requirements down to specific implementation in documents (e.g., policies) or technical specifications [2]. • KPI 6.3: Provide a graphical user interface for role-based access to certification information content [2]. Table 13 provides an overview of all UI/UX requirements and the current progress regarding the implementation of the clickable prototype of the EMERALD UI. All requirements that have been elicited before M9 have been presented using their full description in APPENDIX C: UI/UX Requirements elicited before M9. All newly elicited requirements since M9 are presented in Section 6.1. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 98 of 128 www.emerald-he.eu Table 13. Status of the UI/UX requirements regarding the clickable prototype ID Short title Description Progress UIUX.01 Landing Page The landing page of the UI has to provide quick access to the following views: • Audit Scope Creation View • MARI Tool View • Certification Schemes Manager View 95% - Addressed – waiting for feedback and input from all EMERALD partners UIUX.02 Audit Scope Creation View There must be a view to create and save a new audit scope. This view allows to: • Setup a name for the audit scope • Select one of the available targets of evaluation • Select one of the available certification schemes • Upload policy documents The available targets of evaluation and certification schemes must be retrieved from the backend. Once the audit scope is saved, the policy documents must be uploaded to the backend. 90% - Mostly addressed - maybe some minor changes to come UIUX.03 Controls Overview View There must be a view where all the controls are presented. The controls must be fetched from the backend for the currently selected audit scope. For each control show: • ID • Description • Category • Person or department to whom the control is currently assigned • Compliance Compliance can be one of: • Compliant • Non-compliant 80% - The control overview view is there; it still needs to be decided which status information will be shown. UIUX.04 Controls Overview View: Progress Indicators On the Controls Overview View a chart must present the status and the compliance of the controls. 80% - The chart in the control overview view is there, but it still needs to be decided what to exactly show there. UIUX.05 Controls Overview View: Filtering and Searching It must be possible to filter the controls by each of the presented columns. It must also be possible to search for specific controls by entering either the ID or parts of the description. 100% - Addressed D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 99 of 128 www.emerald-he.eu ID Short title Description Progress UIUX.06 Policy Documents Manager View There must be a view where users can manage (upload, remove) the policy documents. 90% - Still some minor things to implement UIUX.07 Policy Documents Manager View: Metrics Selection It should be possible to select one or more metrics per policy document. When extracting evidence from this document, the AMOE component should only consider the selected metrics. 100% UIUX.08 Evidence Extractors View There must be a view where users can see the status of the evidence extractors. This view must also allow to pause or enable existing ones. If one of the evidence extractors triggers an error, this should be presented here. 95% - Addressed - maybe some minor changes to come UIUX.09 Control Detail View There must be a view where the users can see all the details related to a single control. All the information available about the control should be listed here. 95% - Mostly addressed – it needs to be decided which information about the control should be presented. UIUX.10 Control Detail View: Assignment There must be an element, which the user can use to assign a control to another user or a department. 95% - Addressed – maybe some minor changes to come. UIUX.11 Control Detail View: History There must be a view, where the user can check the entire history of a control. 75% - Mostly addressed – it needs to be decided which information should be displayed there. UIUX.12 Control Detail View: Evidence There must be a view where the user can check the evidence gathered for the metrics of a control. 80% - Work in progress UIUX.13 Control Detail View: NonCompliance There must be an explanation, why the current control is not compliant. 80% - Work in progress UIUX.14 MARI Tool View There must be a view, where the user can interact with the MARI tool. 95% - Addressed – maybe some minor changes to come UIUX.15 Certification Schemes Manager View There must be a view, where the user can see the available certification schemes. 95% - Addressed – maybe some minor changes to come UIUX.16 Certification Schemes Manager View: BYOCS On the Certification Schemes Manager View it should be possible to create a new certification scheme by selecting controls from existing certification schemes or by defining custom controls. (BYOCS = Bring Your Own Certification Scheme). 90% - Addressed - maybe some minor changes to come D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 100 of 128 www.emerald-he.eu ID Short title Description Progress UIUX.17 Certification Schemes Manager View: Import/Export On the Certification Schemes Manager View it should be possible to import new certification schemes or to export existing ones via a CSV file or OSCAL format files. 90% - Import & Export Addressed - maybe some minor changes to come. UIUX.18 Trustworthiness Check The EMERALD UI should display a symbol to let the user know if the integrity of the evidence and/or assessments has been compromised. The integrity check should happen at regular intervals and can be manually triggered by the user. 100% - The symbol is available and allows the user to re-trigger the integrity check; if necessary, users can see and download a report containing the compromised evidence and/or assessments. UIUX.19 Intuitive and Smooth UI The EMERALD UI must be user-friendly and easy to use, so that all employees can understand it. The UI must allow to easily monitor compliance status across various targets of evaluation. Furthermore, the initial load of the UI should not exceed normal timing on a standard broadband connection and must respond to user actions within few seconds for all interactions. 70% - Work in progress UIUX.20 Reusable metrics It must be possible to reuse already-setup metrics. The metrics must be suggested to the user, when a second certification scheme is looked at, so that the user does not have to remember that these metrics exist. 80% - Work in progress UIUX.21 Transfer of Audit to EMERALD The EMERALD UI should have a wizard or a workflow that helps new users to transfer current audit processes to EMERALD. 20% - Difficult UIUX.22 Control Detail View: Manual Evidence Controls that cannot be automatically assessed should have a field where the user can upload a file as evidence. 90% - Addressed UIUX.23 Reporting Users of the EMERALD UI can create different reports e.g., list of noncompliant controls, export into different formats (e.g. xlsx, pdf. docx). 0% - to be discussed UIUX.24 UI Documentation There should be a documentation (in form of text or videos) of the EMERALD UI in clear and understandable language so that users can easily understand the tool and the components to onboard tool administrators, compliance managers and other target users. 0% - to be discussed D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 101 of 128 www.emerald-he.eu ID Short title Description Progress UIUX.25 SelfAssessment Questionnaire for EUCS There should be the possibility to perform a self-assessment (in the form of a questionnaire) of the fulfilment degree of the EUCS certification scheme for various levels (Basic, Substantial, and High) in the EMERALD UI. The questionnaire will allow users to answer a series of questions to evaluate the fulfilment of each control involved. It also provides the option for users to enter comments related to each question, as well as textual references to locate the evidence supporting the given answer. The system will generate a summary dashboard displaying quantitative values that reflect the degree of fulfilment for each level. Additionally, auditors will have access to the questionnaire, where they can review the self-assessment and enter non-conformities for any controls that are not fulfilled, providing a comprehensive overview of the certification status. 5% - Work in progress 6.1 Newly Added UI/UX Requirements since M9 Below we present the eight additional requirements for the EMERALD UI/UX, which have been added since M9. In this case we present the whole description and the status progress for the clickable prototype. Field Description Requirement id UIUX.18 Short title Trustworthiness Check Description The EMERALD UI should display a symbol to let the user know if the integrity of the evidence and/or assessments has been compromised. The integrity check should happen at regular intervals and can be manually triggered by the user. Status Implemented (in clickable prototype) Priority Must Component TWS Source Component Type GUI Related KR KR7_INTEROP Related KPI - Validation acceptance criteria The symbol should be visible and reflect the status of the integrity of the evidence and assessments. Furthermore, it must be possible to trigger a new check manually. Progress 100% - The symbol is available and allows the user to re-trigger the integrity check; if necessary, users can see and download a report containing the compromised evidence and/or assessments. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 102 of 128 www.emerald-he.eu Field Description Requirement id UIUX.19 Short title Intuitive and Smooth UI Description The EMERALD UI must be user-friendly and easy to use, so that all employees can understand it. The UI must allow to easily monitor compliance status across various targets of evaluation. Furthermore, the initial load of the UI should not exceed normal timing on a standard broadband connection and must respond to user actions within few seconds for all interactions. Status Proposed Priority Must Component EmeraldUI Source Pilots Type GUI Related KR KR6_EMERALD UI/UX Related KPI KPI::6.3 Validation acceptance criteria Validate the design by performing workshops with the target users. Progress 70% - Work in progress Field Description Requirement id UIUX.20 Short title Reusable metrics Description It must be possible to reuse already-set-up metrics. The metrics must be suggested to the user, when a second certification scheme is looked at, so that the user does not have to remember that these metrics exist. Status Implemented (in the clickable prototype) Priority Must Component EmeraldUI, RCM, MARI Source Pilots Type GUI Related KR KR6_EMERALD UI/UX Related KPI KPI 6.3 Validation acceptance criteria Metrics that have already been set up, should be suggested to the user, when setting up a new certification scheme. Progress 80% - Work in progress Field Description Requirement id UIUX.21 Short title Transfer of Audit to EMERALD Description The EMERALD UI should have a wizard or a workflow that helps new users to transfer current audit processes to EMERALD. Status Proposed Priority Should Component EmeraldUI Source Pilots Type GUI Related KR KR6_EMERALD UI/UX D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 103 of 128 www.emerald-he.eu Related KPI KPI 6.3 Validation acceptance criteria The wizard/workflow is present and can be understood (validation via workshop) by new users. Progress 20% - Difficult Field Description Requirement id UIUX.22 Short title Control Detail View: Manual Evidence Description Controls that cannot be automatically assessed should have a field where the user can upload a file as evidence. Status Proposed Priority Should Component EmeraldUI, Clouditor-Evidence Store, Clouditor-Assessment Source Pilots Type GUI Related KR KR6_EMERALD UI/UX Related KPI KPI 6.3 Validation acceptance criteria It is possible to upload evidence files for manual controls. Progress 90% - Addressed Field Description Requirement id UIUX.23 Short title Reporting Description Users of the EMERALD UI can create different reports e.g., list of non-compliant controls, export into different formats (e.g. xlsx, pdf. docx). Status Proposed Priority Should Component EmeraldUI Source Pilots Type GUI Related KR KR6 EMERALD UI/UX Related KPI KPI 6.3 Validation acceptance criteria Reports can be created and downloaded. Progress 0% - to be discussed Field Description Requirement id UIUX.24 Short title UI Documentation Description There should be a documentation (in form of text or videos) of the EMERALD UI in clear and understandable language so that users can easily understand the tool and the components to onboard tool administrators, compliance managers and other target users. Status Proposed Priority Should Component EmeraldUI D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 104 of 128 www.emerald-he.eu Source Pilots Type GUI Related KR KR6_EMERALD UI/UX Related KPI KPI 6.3 Validation acceptance criteria Documentation should cover all components of EMERALD as well as the tool itself in a clear and understandable language. Plausible Measurements: ▪ Review the documentation to ensure it includes detailed descriptions, usage guidelines, and interactions for each component in EMERALD. • Conduct usability tests/pilots with auditors to evaluate their understanding and ease of onboarding using the documentation and user manuals. Progress 0% - to be discussed Field Description Requirement id UIUX.25 Short title Self-Assessment Questionnaire for EUCS Description There should be the possibility to perform a self-assessment (in the form of a questionnaire) of the fulfilment degree of the EUCS certification scheme for various levels (Basic, Substantial, and High) in the EMERALD UI. The questionnaire will allow users to answer a series of questions to evaluate the fulfilment of each control involved. It also provides the option for users to enter comments related to each question, as well as textual references to locate the evidence supporting the given answer. The system will generate a summary dashboard displaying quantitative values that reflect the degree of fulfilment for each level. Additionally, auditors will have access to the questionnaire, where they can review the self-assessment and enter nonconformities for any controls that are not fulfilled, providing a comprehensive overview of the certification status. Status Proposed Priority Should Component EmeraldUI Source Component Type GUI Related KR KR6_EMERALD UI/UX Related KPI KPI 6.3 Validation acceptance criteria Ensure users can answer questions, add comments and references, and save responses; verify the dashboard displays accurate fulfilment levels, auditors can review assessments and document non-conformities, and that auditors can track and resolve nonconformities effectively. Progress 5% - Work in progress D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 105 of 128 www.emerald-he.eu 7 Conclusions This deliverable presents the results of task T4.1 – Requirements engineering with compliance managers and auditors and T4.2 – Modelling work processes. Therefore, it has presented the overall methodology used in WP4 and the results achieved by applying different methods in the context of the EMERALD project. In more detail: • We derived first insights about the pilots’ audit preparation processes in general, their needs, some pain points and expectations towards EMERALD. This was needed to get first ideas or insights on where the EMERALD UI could support them during the audit preparation and execution process. • For each of the pilot partners and the auditors and compliance managers from NIXU/DNV we were able to derive concrete work processes about the audit preparation and the audit execution. These processes present the preparation and execution of audits from the perspective of compliance managers, security managers, and auditors including the working tasks, the information and data they need to do their tasks, and how the EMERALD solution could be used to support them. • From the individual work processes, we developed a universally applicable blueprint for implementing EMERALD in audit preparation and audit execution workflows. This blueprint may be valuable for other companies seeking to use the EMERALD solution to enhance their audit preparation processes or to support audit executions. • We derived seven personas divided into 3 different stakeholder groups – 3 personas related to the compliance stakeholders, one persona related to the technical stakeholders and 3 personas related to auditor stakeholders. For these personas, we developed a “persona-on-the-go” and 18 detailed scenarios. The personas and scenarios helped us to understand the roles and tasks of compliance managers, auditors, and technical stakeholders. This is essential for designing a system that effectively supports certification preparation and audit execution and for identifying the key functionalities needed in the EMERALD UI to support each stakeholder group. • Finally, we were able to derive 25 UI/UX requirements for developing the EMERALD UI. T4.1 and T4.2 have ended in M18 of the EMERALD project. This means that we presented the final work processes, personas and scenarios, and the requirements. However, the work in WP4 will be continued using the results gained from T4.1 and T4.2. On the one hand, for T4.3 we will use the results to further develop the clickable prototype of EMERALD and bring it into a state that has implemented all requirements (to a certain extent). Additionally, we will ensure that the prototype supports the respective work processes and use the personas as baseline roles for the user administration in EMERALD, including to inform which user is allowed to do what in the EMERALD UI. On the other hand, the work for T4.3 is strongly aligned with T4.4, where the EMERALD UI will be implemented. Thus, results gained T4.3 that are based on T4.1 and T4.2 will directly be taken over in T4.4. D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 112 of 128 www.emerald-he.eu Benefits of the participation It is likely that you might not receive any direct personal benefit for your participation in this interview besides possibly learning more about the EMERALD project in general. However, by participating you will make a substantial contribution to the success of the EMERALD project, as we need your expertise for developing a good and easy-to-use EMERALD UI/UX that supports you during your work. Disadvantages and/or risks of the participation No risk is foreseen. You are only requested to be available to participate. Confidentiality and publication of the study data Any responses you provide in the interview can be recorded or written down. The data, however, will not include any personal identification; hence it will not be possible to identify you afterwards. All the data you provide will be anonymised and treated confidentially. The information you provide will be analysed and presented in project reports together with the information from other participants. The raw data will be stored in the internal servers of the Know-Center protected by passwords that are only known to researchers conducting the interview. All the raw data will be stored for 5 years after the project finalisation. Funding of the research The research leading to this interview has received funding from the European Union’s Horizon Europe Research and Innovation Programme, under Grant Agreement no 101120688. Contact for further information or in case of withdrawal from the study DI Dr. Angela Fessl, Know-Center GmbH, [email protected] D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 113 of 128 www.emerald-he.eu 9.3 Consent Form Background of this study EMERALD is a Horizon Europe Project (GA no.: 101120688) with the objective to pave the road towards Compliance-as-a-Service (CaaS) for continuous certification of harmonized cybersecurity schemes like the EUCS. This interview is conducted within WP4 – User Interaction and User Experience development of the EMERALD Project. The goal of this interview is to elicit requirements from our target groups such as auditors/chief information security managers/compliance managers etc. necessary for developing the integrated EMERALD UI. In more detail, our goal is to elicit in-depth insights about your work as auditors/chief information security managers/compliance managers in relation to continuous cloud auditing processes. Statement of researcher's responsibility As researcher, I have explained the nature of this research study and the procedures to be undertaken in this context. I have offered to answer any questions and fully answered such questions. Declaration of participant I confirm that: I am 18 years old or older and I am competent to provide consent. I have read and understood the information about this study, as provided in the Information Sheet. I have also had the opportunity to ask questions, and all my questions have been answered to my satisfaction. I freely and voluntarily agree to participate in this research study. I understand that I may refuse to answer any question and that I may withdraw at any time without being penalised for withdrawing nor questioned on why I have withdrawn. I agree that my personal information will remain confidential and that my data will be used anonymously and securely in research and publications, in a way that my identity cannot be revealed. I understand that other researchers will have access to this data only if they agree to preserve the confidentiality of the data. I agree to the terms and to the recording of the consent procedure/ and interview (phone interviews) Participant: ________________________ ______________________________ ________________ Name Signature Date Researcher: ________________________ ______________________________ ________________ Name Signature Date D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 114 of 128 www.emerald-he.eu 9.4 Data Protection Information Controller: Know-Center GmbH Research Center for Data Driven Business & Big Data Analytics, Sandgasse 36/4, 8010 Graz Contact: [email protected] Data protection officer: Data Protection Officer of Know-Center GmbH Sandgasse 34/4, 8010 Graz Contact: [email protected] Purpose of processing: Maintaining business contacts to the extent that this is covered by the reasons for being contacted to which the data subject has consented. Data: Name, e-mail address, relevant for contacting the interview partners to which they have given their consent. Basis in law: Consent pursuant to GDPR Art 6 (1) (a) Recipient: No transmission to third parties; no contract processing Transmission to third countries: No Duration of storage: Until the time when you withdraw your consent. Irrespective of withdrawal of consent, the data will be deleted if your e-mail address becomes invalid or if we receive notification that communications are undeliverable. Data subject rights: You have the right to: - Information and access, to find out whether we have personal data of yours stored and what data it is. - Rectification – correction and/or completion of your personal data that are incorrect or incomplete - Erasure – deletion of your personal data that are being processed in a manner which is not lawful or is no longer lawful - Restriction of processing - Data portability - Withdraw consent that you have given, effective for the future: i.e., further processing of your data is then not allowed from that point in time onwards, unless there is an overriding legitimate reason for doing so. - Object to any assertion by Know-Center GmbH of an overriding legitimate interest in storing/processing the data To exercise these rights please contact [email protected]. You also have a right to make a complaint to the Data Protection Authority. In this regard, we also refer to their homepage, which can be accessed under the link https://www.dsb.gv.at D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 115 of 128 www.emerald-he.eu 10 APPENDIX B: Original User Scenario Descriptions In the following sections we included all user scenario descriptions that have not been adapted. The adaptation of the user scenarios took place if there was an adaption needed based on the technical feasibility in EMERALD. 10.1 Scenarios Riley Figure 46. Scenario A: Riley – Manging a new audit scope Figure 47. Scenario B: Riley – Manage all Controls of an Audit Scope D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 116 of 128 www.emerald-he.eu Figure 48. Scenario C: Riley – Uncover all “blind spots” Figure 49. Scenario E: Riley – Accompanying and audit D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 117 of 128 www.emerald-he.eu 10.2 Scenario Emerson Figure 50. Emerson – Bring your own certification scheme D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 118 of 128 www.emerald-he.eu 10.3 Scenario Dylan 10.4 Scenario Morgan 10.5 Scenario Charlie Figure 51. Dylan – Internal Control Owner Control Implementation Figure 52. Scenario A: Morgan – Checking Metrics and Evidence Figure 53. Scenario 3: Charlie – Preparation of an audit by an internal auditor D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 119 of 128 www.emerald-he.eu 10.6 Scenarios Jarkko Figure 54. Scenario A: Jarkko – Scoping Figure 55. Scenario B: Jarkko – Preparing for audit D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 120 of 128 www.emerald-he.eu Figure 56. Scenario C: Jarkko – Organizational Audit Figure 57. Scenario D: Jarkko - Certification D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 121 of 128 www.emerald-he.eu 10.7 Scenarios Eero Figure 58. Scenario A: Eero – Technical Audit Figure 59. Scenario B: Eero - Reporting D4.2 Results of the UI-UX requirements analysis Version 1.0 – Final. Date: 30.04.2025 and the work processes – v2 © EMERALD Consortium Contract No. GA 101120688 Page 128 of 128 www.emerald-he.eu Field Description Requirement id UIUX.17 Short title Certification Schemes Manager View: Import/Export Description On the Certification Schemes Manager View it should be possible to import new certification schemes or to export existing ones via a CSV file. Status Implemented (in clickable prototype) Priority Could Component EmeraldUI, Clouditor-Orchestrator, RCM Source Pilot Type GUI Related KR KR6_EMERALD_UI/UX Related KPI KPI 6.3 Validation acceptance criteria It is possible to import or export the desired certification scheme using a CSV file.