The EMERALD project reached its milestone MS5 in October 2025. This milestone, located in month 24, corresponds to the second version (V2) of the EMERALD CaaS components.
EMERALD context
The context diagram shown in Figure 1 presents the EMERALD process workflow. The compliance evaluation process is initiated by the Compliance Manager, who defines the Audit Scope based on Security Schemas. These schemas provide the regulatory and technical framework against which the Target of Evaluation (ToE) – comprising cloud services, documentation, and software artifacts provided by the Cloud Service Provider- is assessed.
Once the Audit Scope is established, the Metric Owner is responsible for assigning the implementation of required metrics to the Metric Implementer. These metrics are integrated into the Evidence extractors and are used to collect Evidence, which subsequently contributes to the generation of Assessment Results.
The Internal Auditor then uses these Assessment Results to produce a Compliance Report, which supports the Compliance Manager in refining or adjusting the Audit Scope as needed.
Based on the Assessment Results, the External Auditor evaluates the overall compliance of the ToE with the defined Security Scheme and determines whether a Certificate should be issued. The Certificate constitutes the primary output of the process and serves as a digital representation of a formal certification. It is issued on behalf of a Certification Body, of which the External Auditor acts as a representative.
Figure 1
Architecture
The EMERALD architecture, first defined in M12 (October 2024), has been refined and finalized during the second year of the project. Twelve interconnected components form the EMERALD Compliance-as-a-Service (CaaS) framework, as shown in Figure 2:
- Next-generation evidence gathering components, including AMOE (policy documents), Codyze and eknows-e3 (source code), AI-SEC (AI models), Clouditor-Discovery (cloud configurations), and CertGraph (knowledge graph for evidence organization).
- Automatic evidence management components, including the Evidence Store, Assessment, Evaluation, Orchestrator, and Trustworthiness System (TWS).
- Smart metric mapping components, including Mapping Assistant for Regulations with Intelligence (MARI) and the Repository of Controls and Metrics (RCM).
- A seamless auditing experience for users via a user-friendly Emerald UI.
Figure 2
The architecture activity produced a total of 59 requirements, including both functional requirements associated to the components, which define the behaviour of the system, and non-functional requirements, which define the framework constrains, business driven requirements and UI/UX requirements.
Each component has been technically defined by its requirements -to describe its functionality- , its data model -to show the structure of the data managed-, its sequence diagram -to show how it dynamically interacts with other parts of the system-, and its interfaces -or API endpoints that are used by the rest of components.
Status at M24
An in-depth analysis of the requirements has been performed, including matrices tracing the coverage provided by the requirements to validate the pilots, the Key Results and the Key Performance Indicators. The analysis shows that most of the business requirements are covered by the technical requirements, which means that the component design is well aligned with the final users’ needs. The completion status of the EMERALD CaaS components (V2) shows that, in month 24, 54% of the requirements is over 90% of implementation; and that the average progress of the project is 82%.
All this information has been compiled in the deliverable D1.4 – EMERALD architecture V2, while the source code of the open source components is available in the EMERALD Public repository, under the tag “M24”.
