Add a risk register

[lb-consult]

Hello,

I really like this tool. I find it easy to use and elegant.
I understand that it is "control-centric", but I think it would be great to also integrate a risk register.

It would help with section 8.2 of ISO27001:
"The organization shall retain documented information of the results of the information security risk
assessments."

Would you consider that for a future release?

Thanks
LB

[dbarzin]

Thank you for your kind words and for this valuable suggestion! I'm glad you're finding Deming useful and appreciate the feedback.

You're absolutely right about the risk register being an important component for comprehensive ISO27001 compliance. Adding a risk register would be a natural evolution that could benefit many users implementing various compliance frameworks.

I'm definitely open to considering this for a future release. It would require some design work to integrate it seamlessly with the existing control management, but it's a feature that makes a lot of sense.

If you have any specific requirements or ideas about how you'd envision this feature working, feel free to share them here. Community input helps shape the roadmap!

Thanks again for taking the time to suggest this.

Best regards,
Didier

[lb-consult]

To start with something simple, I would start by introducing a new element named "risk" with the following attributes:

• Name
• Description
• Creation date
• Review frequency -> Add entries to the "planning" module.
• Probability : scale from 1 to 5
• Comments on probability
• Impact : scale from 1 to 5
• Comments on impact
• Status : Not evaluated | Not Accepted | Temporarily Accepted | Accepted | Mitigated | Transferred | Avoided
• Comments on status
• Linked controls : required if status is "Mitigated". Link to existing controls.
• Action plan : required if status is "Not Accepted". To be link with the existing "Action plans" module.
• Owner : person responsible to review the risk and confirmed the status at regular interval (based on review frequency)

I would also add a risk matrix to the dashboard, showing in each cell the number of risks per status (with color coding or icons).

[gorth-git]

Hi all,

building on the “risk register” idea, I’d like to propose a lightweight, risk-based prioritization method inspired by an ISACA approach used in a Cyber Security Check (CSC-IT). The goal is to (1) quickly identify which business processes are most critical to assess first, and (2) enable a clean mapping to ISO/IEC 27001:2022 and BSI Standard 200-3 so we can derive actionable measures from the results.

Core idea: risk assessment per business process (asset = business function)
In this model, the “assets” are business functions / business processes (e.g., Fulfillment, Development, Customer Support).
For each business process we identify the supporting IT services (e.g., CRM, ticketing, ERP, VPN, web shop) and then estimate information security risk (CIA) within that process based on:

• Exposure (reachability of the service)
• Known vulnerabilities / weaknesses of the service
• Impact to the organization if that process (and the information it handles) is disrupted/compromised

This produces a pragmatic risk score that helps auditors/assessors focus limited resources on the highest-risk processes first.

Minimal data structure

For each Business Process:

• Process name (coarse or detailed)
• Linked IT services (list)
• Exposure (0–2)
• Vulnerability level (1–4)
• Likelihood (derived)
• Impact (2/3/5/6)
• Risk score (derived)
• Risk owner/Process Owner (should be defined)
• Review frequency / reassessment trigger (planned intervals + when significant changes occur)
• Links to controls / action plans (for treatment)

Exposure (0–2)

• 0 = not reachable (offline / not networked)
• 1 = reachable across internal segments, but not from the Internet
• 2 = reachable from Internet / external networks (e.g., mail server, webshop, VPN)

Vulnerability level (1–4)

• 1 = unknown / none known
• 2 = known, but not externally exploitable
• 3 = publicly known and exploitable internally
• 4 = publicly known and exploitable externally
  (Note: “externally exploitable” may also include phishing/scam as an attack vector.)

Impact (2 / 3 / 5 / 6)

• 2 = negligible (no negative effects expected)
• 3 = moderate (operations can be restored in reasonable time)
• 5 = high (no quick recovery; no viable compensation like manual processes)
• 6 = critical / existential (could threaten the company)

Calculation

• Likelihood = Exposure + Vulnerability
• Risk = Likelihood * Impact

This results in a simple, workshop-friendly assessment that supports consistent prioritization.

Alignment with BSI Standard 200-3 (IT-Grundschutz)

(Reference: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Grundschutz/International/bsi-standard-2003_en_pdf.html )

The likelihood/impact logic and the use of a risk matrix can be aligned with BSI Standard 200-3 risk analysis and risk evaluation:

• Our Likelihood (derived from Exposure + Vulnerability) can serve as a pragmatic proxy for the BSI probability/frequency dimension (especially for a first triage).
• Impact maps directly to the BSI damage extent dimension.
• The resulting risk score can be mapped to risk categories (e.g., low/medium/high) as part of risk evaluation, similar to BSI’s matrix-based approach.

This is meant as a lightweight prioritization step; deeper scenario-based analysis can follow BSI 200-3 where required.

Example (as plain lists)

• Business process: Customer Support

  • IT services: CRM, customer portal
  • Exposure: 2 (Internet-facing portal)
  • Vulnerability: 3 (publicly known, internally exploitable)
  • Likelihood: 5
  • Impact: 3
  • Risk: 15

• Business process: Billing

  • IT services: ERP
  • Exposure: 1 (internal only)
  • Vulnerability: 2 (known, not externally exploitable)
  • Likelihood: 3
  • Impact: 5
  • Risk: 15

Why this matters for ISO/IEC 27001:2022 mapping (6.1.2 / 8.2 / 6.1.3)

This approach can be aligned with ISO/IEC 27001:2022 in a direct way:

• Clause 6.1.2 (Planning – risk assessment method & criteria):
  The definitions of Exposure, Vulnerability level, Impact categories, the calculation rules, and the risk acceptance criteria (e.g., thresholds such as “risk ≥ X requires treatment”) form the risk assessment methodology and consistent evaluation criteria.

• Clause 8.2 (Operation – performing the risk assessment):
  Applying the method to business processes and their supporting IT services—at planned intervals and when significant changes occur—is the operational execution of the risk assessment.

• Clause 6.1.3 (Planning – risk treatment):
  The ranked risks drive risk treatment decisions (avoid/modify/share/retain), selection of controls, and the linkage to action plans and the Statement of Applicability.

The resulting risk entries feed naturally into risk treatment decisions, selection of controls, and ultimately the Statement of Applicability.

Suggested implementation

In addition to the generic “risk register” entity, this model adds a practical structure:

1. Risk is linked to a Business Process (primary “asset”)
2. Business Process is linked to IT services (supporting assets)
3. Store Exposure, Vulnerability level, Impact
4. Auto-calculate Likelihood and Risk score
5. Add risk acceptance thresholds to classify risks (e.g., accept / monitor / treat)
6. Provide a view to rank processes by risk (for audit/assessment planning)
7. Allow linking:
   • to ISO/IEC 27001 controls (existing control catalog)
   • to action plans (existing action plan module)

This keeps things “control-centric” but adds a risk-first workflow:
Business processes → risk ranking → treatment decision → control selection → actionable measures.

Please comment (RfC) whether the proposal would be suitable and where this should best fit in the data model / UI.

[arnaud-lxbg]

Hi,
This is a very good idea, although challenging as this can go very fast in something very complex, especially as everyone has their own criteria for exposure, impact...
So this should remain a risk register and not a risk analysis tool. In that condition, the easiest way would be that every field is a free text.

The risk can be the outcome of an action plan, but also an input for a measurement result (not a control as the risk is timebound).

[dbarzin]

🎉 The risk register is now available in version 2025.04.10 !!!

Preview:

and have look at the documentation : https://dbarzin.github.io/deming/risks/

If you have an account, it has been deployed in our demo server.

[lb-consult]

Thanks a lot @dbarzin.
I have reserved some time to give it a look on Friday.

[dbarzin]

Friday, which week ?

[lb-consult]

It was planned for last Friday but I had to work on an incident response...

[dbarzin]

I can give you access to a demo environment, just send me and email.

[lb-consult]

I'm spent a bit of time experimenting and here is a first round of comments:

• I think there should be a way to directly access the risk register without first showing the risk matrix and then clicking on one of the score/status.
• It would be great to have a multi-step process for risk acceptance similar to what is existing for exceptions.
• I really like the possibility to select the risk scoring methodology
• It should be possible to filter which risks are visible in the Risk Matrix. For exemple, one may want to remove transferred or avoided risks from the matrix. Having all the risks always visible in the matrix can quickly make the matrix useless.
• There is a small display bug when I click on one of the number in the risk matrix I'm redirected to a risk register view which is just showing the corresponding risk but no filters are selected (quite confusing at first)

[dbarzin]

I'm spent a bit of time experimenting and here is a first round of comments:

* I think there should be a way to directly access the risk register without first showing the risk matrix and then clicking on one of the score/status.

Good point. I'll add a dedicated menu item for the risk register alongside the existing risk matrix entry.

* It would be great to have a multi-step process for risk acceptance similar to what is existing for exceptions.

Great idea. I'll implement a review/approval process similar to the exception management workflow.

* I really like the possibility to select the risk scoring methodology

Glad you find it useful! It was one of the key design goals for this module.

* It should be possible to filter which risks are visible in the Risk Matrix. For exemple, one may want to remove transferred or avoided risks from the matrix. Having all the risks always visible in the matrix can quickly make the matrix useless.

Absolutely agree — a matrix with all risks regardless of treatment status quickly loses its value. I'll add filtering options (e.g. by treatment: transferred, avoided, etc.).

* There is a small display bug when I click on one of the number in the risk matrix I'm redirected to a risk register view which is just showing the corresponding risk but no filters are selected (quite confusing at first)

Confirmed. When clicking a cell in the matrix, the risk register should open pre-filtered accordingly. I'll fix this and update the thread once it's available.

Thanks for the thorough feedback — very helpful for shaping the module!

[dbarzin]

Some updates on this issue.

I'm spent a bit of time experimenting and here is a first round of comments:

* I think there should be a way to directly access the risk register without first showing the risk matrix and then clicking on one of the score/status.

Good point. I'll add a dedicated menu item for the risk register alongside the existing risk matrix entry.

A new menu entry has been added at the side menu for the risk matrix.

* It would be great to have a multi-step process for risk acceptance similar to what is existing for exceptions.

Great idea. I'll implement a review/approval process similar to the exception management workflow.

This is still in progress.

* I really like the possibility to select the risk scoring methodology

Glad you find it useful! It was one of the key design goals for this module.

* It should be possible to filter which risks are visible in the Risk Matrix. For exemple, one may want to remove transferred or avoided risks from the matrix. Having all the risks always visible in the matrix can quickly make the matrix useless.

Absolutely agree — a matrix with all risks regardless of treatment status quickly loses its value. I'll add filtering options (e.g. by treatment: transferred, avoided, etc.).

Filters have been added.

* There is a small display bug when I click on one of the number in the risk matrix I'm redirected to a risk register view which is just showing the corresponding risk but no filters are selected (quite confusing at first)

Confirmed. When clicking a cell in the matrix, the risk register should open pre-filtered accordingly. I'll fix this and update the thread once it's available.

This is fixed, there is now a visible filter selected.