ISO 27005:2022 Adaptations

The Risk source field identifies the actor, origin, or cause associated with a risk scenario. It complements the existing threat, vulnerability, and risk-description fields and can remain empty when the analyst does not want to qualify the source yet.

Each analysis is initialized with a reusable list of default risk sources:

MONARC now lets the analyst define analysis-level reassessment trigger criteria from the analysis actions menu. The dedicated Reassessment trigger criteria dialog is used to maintain the list of conditions that require the analysis to be reviewed again.

The dialog is also part of the MONARC method. Open it from either of these method substeps:

Each criterion contains:

The list supports creation, edition, activation or deactivation, deletion, and manual reordering. When no criterion is defined, the dialog shows an explicit empty-state message for the analysis.

The Monitoring approach field documents how the trigger is detected in practice, for example through SOC alerts, vulnerability scans, audit findings, regulatory updates, or supplier notifications.

Both information and operational risk sheets now guide the analyst to describe Risk context as a scenario rather than as a short technical note.

The field guidance explicitly encourages the analyst to include:

The inline example follows this structure and the help text also asks the analyst to describe the consequence explicitly, for example as data loss, service disruption, or customer data disclosure. This keeps the risk description aligned with ISO 27005:2022 scenario-based wording without changing the underlying risk model.

Each information and operational risk sheet now contains a Governance & review section. This section groups accountability and monitoring data in one place.

The Monitoring and review part of the sheet provides:

The suggested review frequencies are:

The On trigger value is intended to be used together with the reassessment trigger criteria maintained at analysis level. For each risk, these review fields are exported, reported, and available in the risks-management batch update view when the current linked supervisor is allowed to update review metadata.

When an analyst enters a Last review date, MONARC proposes the Next reassessment date one year later. The analyst can keep the suggested value or replace it. Related reassessment trigger criteria can be selected only after a next reassessment date is available; multiple criteria may be linked to the same risk.

When a risk’s next reassessment date is in the past, the information-risk table, operational-risk table, and risks-management table show an orange warning icon next to its identifier. The tooltip gives the expired date. The risk warning is deliberately driven by the explicit next reassessment date, while the analysis warning is calculated from its last review date and selected analysis-level review frequency.

At analysis level, the reassessment trigger criteria also gained the Monitoring approach field. This complements the per-risk review metadata by documenting how trigger conditions are monitored or detected.

Residual risk acceptance is now recorded explicitly in a dedicated Residual acceptance section on both risk-sheet types. This makes the acceptance of the residual risk traceable after treatment rather than leaving it implicit in the treatment status alone.

The section records:

The guidance text also covers the case where no treatment is applied and the residual risk is accepted as is. The interface uses explicit statuses such as Accepted and Not accepted, and the risk tables display a visual indicator for non-accepted residual risk decisions.

The evaluation-scale screen now uses the label Impact evaluation (severity of consequences) to clarify the meaning of the impact model.

This is a terminology clarification only:

The intent is to align the guide and the user interface with ISO 27005:2022 without renaming the underlying data model everywhere or changing existing calculations.

The Risk analysis context dialog now contains a second tab named Interested parties & requirements. This tab lets the analyst document stakeholders and their needs as part of the context-establishment work.

Each entry stores:

The list supports creation, edition, deletion, and manual reordering. An empty analysis displays a dedicated message until at least one interested party is recorded.

The tab extends the first substep of Step 1, Context Establishment: open Risks analysis context and then select Interested parties & requirements.

These entries are included in deliverables through the TABLE_INTERESTED_PARTIES tag and can also be exported and imported with the analysis when assessment export is enabled.

The platform now manages analysis-level Supervisors instead of relying only on free-text risk owners. Supervisors are maintained from the analysis actions menu in a dedicated dialog.

Each supervisor can contain:

The available roles are used to drive behavior in the risk sheets and the risks-management view. In practice, the same supervisor may act as:

In information and operational risk sheets, the Risk owner field now uses the analysis supervisor list instead of a plain reusable text value. When allowed, the user can also open the supervisors dialog directly from the risk sheet to add a new supervisor without leaving the current risk.

Reports and exports also include supervisors, linked users, roles, and assigned risks through the supervisors appendix generated by the TABLE_RISK_OWNERS deliverable tag.

The supervisors model is the first part of MONARC’s governance, risk, and compliance (GRC) functionality. It establishes accountable roles and linked users for the current analysis; the GRC capabilities will be extended in future releases.

Residual acceptance is now tied to an explicit approver workflow based on analysis supervisors. The workflow supports three main cases.

The decision fields remain disabled until an effective approver exists. When the current user is not the effective linked approver, the sheet displays a read-only warning and blocks decision changes.

The section also records performer information:

The Set my account as performer action is provided for cases where the acting user is allowed to complete the approval. Changing the risk owner can reset residual-acceptance data when the approver relationship changes.

Information and operational risk sheets now include a dedicated History section. This section exposes the analysis history entries related to the current risk in a read-only table.

The history view provides:

The available change-type filter covers:

Long values can be expanded inline through Show and collapsed through Hide. When no entry exists, the sheet displays No history available.

This history is append-only from the user perspective: the guideable interface exposes it for consultation only and does not provide any manual edit or delete action.

Users linked to an active analysis supervisor can access a dedicated Risks management view when they have at least one applicable supervisor role and assigned risks. The entry point is visible:

The My risk analysis list shows the number of risks assigned to the current linked supervisor as owned and approvals. Select Manage my risks for an analysis to open the filtered view directly. A linked supervisor with no assigned risks sees No assigned risks and no management action.

The page only shows risks where the current linked supervisor is involved, either as:

Instead of the normal analysis filters, the page exposes a role-based batch update panel. Depending on the supervisor role, it allows batch updates of:

Use the decision filter to narrow the list, select the relevant risks with their checkboxes, enter the fields to update, and select Update. The export button downloads the displayed risks-management data as CSV.

The table also displays the risk owner, risk source, and residual-risk approver. Those assignments are displayed for context but are not editable from the batch view; update them from the corresponding risk sheet. Each batch execution reports how many risks were updated and how many were skipped, and skipped rows include the justification.

Use the Export (CSV) button to download the risks currently shown in this view. The export contains both information and operational risks and includes the visible governance fields, source, linked trigger criteria, residual approver, and residual-decision data.

The table itself keeps the relevant ISO 27005:2022 fields visible in one place, including: