Feedback

Objective of the request ------------ In many entities, information is maintained by different roles and teams. Currently, this information is often in a common structure, which creates several problems: Users see fields that aren't relevant to their work Fields can be changed by mistake Clarity suffers Responsibilities for data are not clearly separated The aim of this requirement is therefore to divide entities into logically separated areas (sections), which can each be provided with their own access rights. Structured areas within an entity ------------------------------ Within an entity, it should be possible to define various areas, such as: master data process information Risk analysis Business Impact Analysis (BIA) Compliance information These areas combine thematically related fields. This makes the structure of an entity much clearer and easier to adapt to different usage scenarios. Role-based access control to areas ----------------------------- It should be configurable for each area: Who can see the information Who can edit the information This allows different teams to maintain different parts of an entity without having access to all fields. Use case: processes ---------------- One specific use case concerns the maintenance of process information. In our case, information about processes is maintained by different roles: Product teams or departments maintain basic process information Agents or risk owners maintain risk scores and assessments The risk scores are maintained by the agents and are sometimes calculated automatically, while basic information comes from other teams. Separate areas with appropriate authorizations can prevent data from being accidentally overwritten or changed. Use Case: Business Impact Analysis (BIA) ----------------------------- Another problem occurs when carrying out a business impact analysis (BIA). When editing a BIA, users only want to see and edit the relevant fields. Currently, it often happens that users “stumble” across other fields of the entity while editing and may accidentally change them. Separate areas with appropriate authorizations or editing views could focus on the actually relevant information. Validation and data quality --------------------- In addition, it should be possible to clearly identify: Which fields are not filled Which fields contain incorrect or incomplete data Ideally, this should be visually emphasized, for example by: Status indicators per area Marking mandatory fields Validation when saving This makes it easy to see whether an entity has been fully maintained or whether information is still missing. Expected added value ----------- This feature would provide several benefits: better structuring of complex entities clear separation of responsibilities for data reduced risk of unintended changes focused processing of specific tasks (e.g. BIA or risk analysis) better data quality through visible validation and completeness verification

Product requirement: Expanded relationships between entities with additional attributes Objective of the request ------------ Entities can currently be linked together, but no additional information can be collected in the relationship itself. In many applications, however, it is necessary for a relationship between two objects to have its own attributes. The aim of this requirement is therefore to add additional fields to links between entities so that information can be stored directly at the relationship. Extend relationships with additional information -------------------------------- When linking two entities, it should be possible to collect additional information that is specific to that relationship. The relationship thus becomes its own information carrier. This means that not only are the two objects connected to each other, but that metadata can also be stored via this connection. This information should both: directly when creating the link as well as via forms or questionnaires can be recorded. Use case: processes and systems -------------- A central use case concerns the linking of processes and systems. A process can be connected to multiple systems. At the same time, each system can have different requirements or characteristics in the context of this process. Examples of such information in the relationship: criticality of the system for the process RTO/ RPO requirements manual replacement procedure responsibilities special operating requirements This information does not apply to the system in general, but exclusively to the relationship between a specific process and a specific system. Use Case: Business Continuity Management (BCM) -------------- In BCM, additional information on the relationship between processes and supporting systems must often be documented. examples: Dependence of the process on the system maximum tolerable downtime alternative systems or workarounds special restart requirements This information belongs logically to the relationship and not exclusively to one of the two entities. More use cases --------------- treaties Linking contracts to systems or suppliers may require additional information, such as: Contract relevance for a specific system SLA parameters Duration or notice periods in the context of a specific use risk assessments Even in risk assessments, information can be specific to a relationship. examples: Risk of a system for a specific process Evaluation of the probability of occurrence in the context of this relationship existing controls for this specific dependency Integration with forms ---------------- In addition, it should be possible to enter this information directly via forms or questionnaires. Sample flow: Select a process Selecting a system Collecting additional information about the relationship Automatic creation of the link including the entered attributes As a result, relationships between entities can be recorded in a structured and consistent manner without the need for subsequent manual maintenance of the data. Expected added value ----------- This feature would allow: significantly more precise modelling of dependencies between objects structured recording of complex relationships Better mapping of real requirements in areas such as BCM, risk management and contract management automated creation and maintenance of relations via forms

I would like to be able to create Dashboards with the following information: 📋 Dashboards • Tasks completed vs. overdue • % of compliance per period • Compliance with recurring tasks • Nº of Evidence in non-compliance • Evidence associated with critical tasks • Active vs. inactive controls • Controls with associated tasks • Controls without evidence According to the IA Act (Artificial Intelligence Act) regulation, we must add the following fields to the Systems:  Does it contain AI?  AI Act classification  Human supervision defined? I am a Formalize customer through Una Seguros in Portugal. ----------------------------------------------------------------------- Gostaria de poder criar Dashboards com a seguinte informação: 📋 Dashboards • Tasks concluídas vs em atraso • % de cumprimento por período • Cumprimento de tasks recorrentes • Nº Evidências em incumprimento • Evidências associadas a tarefas críticas • Controlos ativos vs inativos • Controlos com tasks associadas • Controlos sem evidência De acordo com o regulamento IA Act (regulamento Inteligência Artificial), devemos adicionar os seguintes campos aos Sistemas:  Contém IA?  Classificação AI Act  Supervisão Humana definida? Sou cliente do Formalize através da Una Seguros em Portugal ------------------------------------------------

I want to create a field in a questionnaire where I want the user to be able to select responsible user from a drop down list catching the data of existing users.

We’re making it possible for controls to start with no default value in the status field. This makes it easier to track which controls have actually been assessed and identify gaps in your framework.

We’re adding the ability to stop recurring tasks while keeping their full history intact. This will make it easier to manage recurring activities that are no longer needed, without affecting records of past work. By preserving completed occurrences while stopping future ones, you’ll maintain a clear audit trail and accurate visibility into what has already been done.

We’re introducing the ability to distinguish between requirements and controls within frameworks. This will make it easier to model governance structures in a way that reflects how compliance frameworks work in reality. By clearly classifying items and linking requirements to the controls that support them, you’ll gain a more accurate view of how obligations are met. This improves transparency, strengthens audit readiness, and helps you demonstrate compliance with greater confidence.

There should be the option to synchronize users of a specific Entra Group to Formalize, so I don't have to create users in formalize manually. Currently I can only sync full list of all users as employees to formalize, which are not used for login permissions as users.

We would like a button to create a risk from a supplier or system view. During the registration process of a supplier or system, a risk assessment is performed on some of them. It would be nice if we could create risks from the view of that specific supplier or system and making it automatically linked instead of having to click on risks module and link them afterwards

Currently only singular tasks can be connected to a risk strategy via "Update risk strategy". It would be nice if recurring tasks could also be linked to risk strategies because a recurring review is seen as a mitigation for some risks