Feedback

With SCIM support, user provisioning and deprovisioning can be automated through your identity provider, helping ensure access is always up to date and aligned with your internal security policies. This reduces manual effort for administrators and supports a more secure and scalable user management process.

We’re expanding approval flows to support more advanced and flexible setups across the platform. This will make it easier to validate changes, control automated actions, and align approvals with how your organization actually operates. With support for dynamic and conditional approvals, you’ll be able to assign the right reviewers based on context, enforce meaningful checks, and safely automate more of your processes without risking unreviewed changes.

In our Unified Control Framework (master framework), each control is linked across multiple frameworks, recurring tasks, policies, and even down to asset-level controls. Today, it is almost impossible to maintain these links manually — especially when ensuring that tasks and evidence remain correctly associated with the master control - and everything in-between. We request functionality that allows a “master control” to serve as the authoritative parent control. When this master control is linked to an ISO 27001 control (or any other framework requirement), all related recurring tasks, evidence, and other linked elements should automatically inherit upward to the master control. This would allow the master control to function as a consolidated overview that clearly shows our compliance status, without requiring manual re-linking or maintenance across frameworks.

Today its not possible to have a owner (accountable) on a task, and the accountable can then point on a responsible for actually doing the task. Could be a HR manager beeing accountable for procedure beeing reviewed, but he/She might want to use one from the team to perform the actual review. HR Manager is Accountable for the action/task to happen in decent quality- USer xx is responsible for actually doing the task.

When building new automation which should run weekly, it's extremely time demanding to test the workflow, since it's not possible to do a "Run Now". So when we build the automation we have to wait a week - correct errors - wait a week - correct errors - wait a week etc. Otherwise we can only use a nother trigger, and since it's not possible to change trigger afterwards, we have to build the entire automation and afterwards re-build with correct trigger.

We want to be able to change trigger, after a automation has been build. When we build a automation/workflow, we often have to change the trigger afterwards - e.g. if a automatiion today is running daily, but we've learned that it would be better to run weekly - Then we need to build the entire automation from scratch again. This increases the risk of errors when the automation has to be manually recreated from scratch, and furthermore, it is extremely time‑consuming to rebuild it.”

We use SAML for login. But we still have to use a certain amount of time on administering users. We have to create all users who should have access, manually and assign permissions. We have delete users manually We don't have a central view of which tasks/risks/Supplier/contracts etc. a user is responsible for when we delete a user. Both Creation of users, deletion of users, administering permissions, should be based on AD/M365 groups.

We are currently trying to implement a Unified Control Framework and linking all controls from different frameworks to one "master" framework. This should enable us to centrally manage compliance of 3 ISO standards, NIS etc. without doing the same task multiple times. When we have Connected a control to a master control, it only shows the name, which make is hard to identify the correct framework.

Background/ Problem After completing a questionnaire, the process is currently ending without structured further processing. There are the following deficiencies: No mechanism for defining a responsible user in the workflow The respondent (filler) is no longer used in the process Unable to generate automatic tasks from the deal Downstream activities must be initiated manually This results in: lack of process continuity manual rework lack of traceability Objective 2 After completing a questionnaire, you should: a responsible user can be defined in the workflow The determination is flexible: via a field in the questionnaire or via the respondent A task can be created automatically for the respondent

Background/ Problem Currently, processes and systems can only be assigned to one Responsible User. In addition, roles already exist that are assigned to processes, but: Roles cannot be used as filters Departments are not structurally integrated The API doesn't allow you to create or manage roles or departments This creates the following problems: Processes are not represented cleanly from an organizational point of view Filtering by organizational units is not possible Roles and departments must be maintained manually Automated synchronization with external sources is difficult This results in low transparency and poor navigability in the overview. Objective 2 The platform should enable: Assigning processes and systems not only to a user, but also to roles and departments Filtering by roles and departments Overview of these assignments Managing roles and departments via the API This allows organizations to model their structure correctly. Feature requirements 3.1 Overview (UI) The following information must be visible in the process and system overview: Responsible User Assigned role (s) Assigned department Display requirements: Roles are presented as a list or tags Departments also as tags or their own column If there are multiple roles → show all example: Responsible Roles Department process Incident Management Max Mustermann Security Manager, SOC Analyst IT Security Filter function Filter options must be extended to include: Filter by roller Department Responsible user (existing) demeanour Multiple selections possible Combination with other filters is possible Filters must work for both processes and systems example: filters: Department = IT Security Role = SOC Analyst → shows all relevant processes/systems. Data model Entity: Role Attributes: id Name Description (optional) relationship: Role ↔ processes (many-to-many) Role ↔ systems (many-to-many) Entity: Department Attributes: id Name Description (optional) relationship: Department ↔ Processes Department ↔ Systems API requirements The API must support the following features. Roles API Create a role POST /roles payload { “name”: “SOC Analyst”, “description”: “Security Operations Center Analyst” } Departments API Create a department POST /departments payload { “name”: “IT Security” } attribution Processes and systems must be able to be assigned roles and departments. example: PATCH /process/ {id} payload { “roles”: ["SOC Analyst"], “department”: “IT Security” } Migration/ Transition Current state: Roles are already assigned to processes Departments do not yet exist in a structured way Transition: Departments are created manually Synchronization is then carried out via API Existing roles are retained Roles can also be filtered Non-goals This change does not include: role-based permissions (RBAC) organizational hierarchies automatic HR synchronization Success criteria The function is considered successful if: Roles and departments are visible in the overview Filtering by roles and departments works Roles and departments can be created via API Processes and systems can be filtered organizationally