Improving with kawak®

Currently, by periodically monitoring a control within the risk module, the tool allows management comments to be recorded, but it lacks a specific and structured field to dictate the final result of the Effectiveness Measurement (for example, being able to classify it as: “Effective”, “Ineffective” or “With an opportunity for improvement”). The suggestion is to incorporate a field (either a drop-down list or a parametric qualification matrix) directly into the control's tracking window, which allows leaving a formal and direct record of whether the control is actually fulfilling its objective. Implementing this improvement would bring the following benefits: Methodological compliance (ISO): It allows the software to be aligned directly with regulatory requirements and internal methodologies that require periodic evaluation of the actual effectiveness of the implemented operational controls. Agile decision-making: By having this field standardized, reports or filters could be generated to quickly identify controls classified as “Ineffective”, making it easier to take actions (such as redesigning them or opening a new Treatment Plan). Ease of auditing: Provides clear, direct and visual evidence in front of internal or external auditors, demonstrating not only that the control is being followed up, but that its real capacity to mitigate risk is assessed

Context: Currently, in the Risks module, when a treatment plan reaches 100% execution of its activities, the platform allows it to be converted into a control. Problem: When you make this conversion, the original treatment plan disappears from the plans section. This creates a traceability gap in the face of our internal policies (which require evidence of the formulation of a plan for each risk). In addition, when reviewing the new control in its respective section, there is no label or visual mark to identify that its origin was a treatment plan. Proposed solution: We suggest implementing one of these two alternatives so as not to lose methodological traceability: That the original treatment plan does not disappear, but rather changes to a historical status such as “Converted to Control”, remaining visible in the plans section. That when the new control is generated, it includes an automatic field or visual label that clearly indicates “Source: Treatment Plan”.

Currently, the record of the materialization of a risk is managed through the Event Management module. However, when browsing the overview of the Risk Matrix, it is not possible to identify at a glance which of the risks listed have a real history of materialization. The proposal consists of adding a visual identifier (such as an alert icon, a tag or a specific column) to the main visual of the matrix that marks those risks that have already been implemented materializado.La implementing this improvement would provide the following benefits: Immediate traceability: Visually connect the history of events with risk planning without having to cross reports from two strategic modules distintos.Priorizaci: It allows process leaders and senior management to focus their quick attention to risks that are failing in reality operativa.Gesti on proactive: It facilitates the identification of risks that require an urgent reassessment of probability (rising to the level immediately higher after an event) and an adjustment in the strength of its controls.

Context: In the daily management of the Information Assets module, we make constant updates to the records, such as adjustments to the identification of the asset, the last monitoring carried out or the results of the last evaluation. Problem: Currently, the platform does not have a visible and detailed “change control” within the asset sheet. The tool doesn't allow us to track which exact field was modified (old value vs. new value). This creates a large gap in traceability, which gives us direct observations during internal auditing exercises for Information Security (ISO 27001). Proposed solution: Enable a log or modification history directly on the resume of each information asset. It is essential that this record automatically shows the date, the responsible user and the exact detail of what specific information was updated or evaluated.

It may be the case that the RR calculation can be carried out by manual re-evaluation and that it can be planned with an expiration date and a pending issue to the evaluator.

As an opportunity for improvement, email alerts could be generated to those responsible for executing Risk controls, days before their expiration, with the objective of expanding the alert and not limiting it to what is pending in the main menu. Additionally, the configuration module could be included in “Newsletters” to activate it if considered appropriate, as well as in the case of commitments in the minutes and the context module of the organization.

Proposal: Expand the Event Manager, integrated with the Kawak Risks module, to incorporate the registration and management of events associated with Occupational Safety and Health (OSH) and Environmental Management, in addition to the categories currently available: operational, information security and cybersecurity. This extension will make it possible to integrate into a single tool the identification, reporting, monitoring and management of events that may materialize institutional risks, strengthening prevention, traceability and timely action. A more comprehensive, preventive and articulated risk management.

When entering MY PENDING - RISKS AND OPPORTUNITIES - MONITORING RISK CONTROL, 2 additional buttons were implemented and 2 options (EXECUTION OR FOLLOW-UP) were implemented, however, when reviewing the parameterization of our system, the check for Cargo Execution Managers is found (inactive) and the Monitoring Manager (Active), which means by default the system should not allow the leader to change the condition that is being enabled at the time of recording his monitoring.

Current Situation: In the Event Management module, the setting “Who performs the shutdown?” It only allows three options: the person who performs the last action, which is determined manually, or the person who reports the event. This implies that, when the closure is determined manually, the reporter must select in each record the person responsible for the closure, which can lead to errors in the assignment or delays when it is not clear who should close the event depending on the process involved. Improvement proposal: Include a fourth option in the “Who performs the shutdown?” configuration referred to as “By Process”. By selecting this option, the system should enable a parameterization table or list where a closure manager can be assigned for each process defined in the system. Expected operation: When a user fills out the incident or event report and selects the “Affected Process”, the system would automatically assign as responsible for the closure the person previously parameterized for that process, without the need for manual selection in the “Responsible for the Closure” field. Benefits: The assignment of the closure would be standardized and aligned with the organization's process structure, manual assignment errors would be eliminated, the processing of the report would be expedited and it would be guaranteed that the event always reaches the person with the responsibility and knowledge of the affected process for analysis and closure.

It is necessary to be able to assign and modify permissions massively when creating risks, by users, positions or groups This in order to facilitate the transitions of users and positions in companies