ICT and operational risk
Open one risk and see the record behind the score.
Severity, affected assets, ownership, and activity history stay together, with evidence and controls one step away.
- Connected context
- Service, asset, finding, control, and provider stay linked to the risk.
- Accountable treatment
- Owners, due dates, evidence, and validation remain visible.
- Source-level review
- Management views retain a route to the records behind each status.
01 / 04
Risk register
Compare the risks competing for attention.
Filter the ICT risk register by type, then compare impact and lifecycle state before opening the record that needs review.
- Compare impact and lifecycle state in the same row.
- Narrow the register by risk type before review.
- Open the source record directly from the register.
02 / 04
Finding triage
Decide what happens to each finding.
From the finding record, start a review, promote it to a risk, link it to an existing risk, or discard it after checking the context.
- Keep the originating finding and evidence visible.
- Link or promote only after a human review.
- Record discarded and reopened decisions.
03 / 04
Treatment and validation
Turn the chosen response into work with a deadline.
The treatment register shows response strategy, lifecycle state, and due date. Expand a row to check its objective and linked risks before acting.
- Compare strategy, lifecycle state, and due date.
- Expand a row to read its objective and plan.
- Open the linked assessed risk from the same record.
04 / 04
Management view
See what crossed the line before the next review.
Open, high or critical, and overdue risks are counted separately. The attention list then leads straight to the record behind each warning.
- Surface overdue and incomplete work.
- Keep scope, period, and ownership clear.
- Open the source risk, task, or treatment from the status.
Deployment and fit
Fit the workflow to the bank’s operating model.
Defined deployment boundary
Application placement, identity, data, backup, and support responsibilities are confirmed during implementation.
Institution-specific method
Roles, assessment criteria, lifecycle states, review points, and approvals follow the agreed operating model.
Explicit integration scope
Supported imports and interfaces are separated from additional implementation work.
Practical questions
What teams usually ask before a walkthrough.
01 Can RiskDam follow our existing risk methodology? +
The implementation is configured around the agreed assessment method, roles, lifecycle states, and review points. The walkthrough should use one representative method and risk to confirm fit.
02 Can we bring existing risks and findings into the system? +
Supported import formats and the required data cleanup are confirmed during implementation. A sample of current records is reviewed before a migration scope is agreed.
03 How is deployment handled? +
Deployment topology, identity, data location, backups, updates, monitoring, support access, and recovery responsibilities are agreed with the customer.
04 Can roles and approvals reflect our governance model? +
Role access and review steps are configured for the agreed workflow. Availability can depend on permissions, enabled modules, and implementation scope.
05 Does RiskDam make an institution compliant? +
No software certifies an institution’s compliance by itself. RiskDam supports the records, evidence, ownership, and reporting workflows used to meet applicable requirements.
Review one real workflow
Bring one representative ICT risk.
We will trace it from finding and assessment to ownership, treatment, evidence, and review using non-confidential data.
A representative scenario is enough. Do not send confidential risk details by email.