A risk is not something that might fail. It is a design decision.
Most risk registers are spreadsheets nobody consults after the audit. In Dexon BPM the risk is an object of the architecture: it conditions the design of the processes it affects, it is anticipated by indicators tied to it, and it cannot be deleted while anything depends on it.
The register
Three stages, declared separately
Every entry in the register runs a full cycle, and the three stages are recorded apart — because conflating them is exactly what produces registers nobody uses. A register that keeps a single rating cannot tell whether the current level is the result of a decision or of luck.
Risk as a design condition
If the risk is fraud, the process includes segregation of duties. Not a note in the margin.
A risk is a possibility that demands an architectural decision. The methodology treats it as a condition of the process design, on the same footing as a regulation or a service level — and the platform verifies that every critical risk has a visible treatment in the approved process.
Fraud →
Verification steps, segregation of duties or automatic rules in the path — not a reminder to be careful.
Missed service levels →
Monitoring, alarms and escalation routes designed into the flow before the first case runs.
Poor data quality →
Validation, enrichment or integration at the activity that captures the data, with mandatory fields per state.
Verified at approval →
A process objective is well-formed only when every critical risk it declares has a declared treatment. The conformance check marks the gap; the owner cannot approve around it.
Key risk indicators
The KRI is a relationship, not a checkbox
Early-warning signals are what you observe before a risk materialises. Every signal that can be quantified is a candidate for a measurement element linked to the risk — and a register with declared signals and no indicators measuring them is describing, without saying so, the work still missing.
This contradicts common practice on purpose: the same measurement element can carry a target — and so be a KPI — and a link to a risk — and so be a KRI — without duplicating the object or forcing an artificial choice. And because a measurement element can also be linked to a capability, three processes failing at once can be read as one weak capability instead of three unrelated problems.
What the link gives you
→One measurement element, two roles: target makes it a KPI, the risk link makes it a KRI.
→Classification — strategic, process, service, data, capability — is derived from the anchor and its relationships. Nobody types it, so it cannot contradict the structure.
→Alignment with capabilities answers the question a KPI-only system cannot: do these failures share a weak capability?
Integrity
A risk in use cannot be deleted
The uses of a risk are the processes whose design it conditions, the portfolio elements analysed against it, and the KRIs that anticipate it. From that follows a rule the platform enforces: an entry that is in use is not removed. Its uses are unlinked first, leaving a trace of the decision.
The reason is not bureaucracy. A register from which referenced risks can be deleted is a register nobody can trust — and impact analysis stops being reliable with it. Before changing a risk, the platform shows what depends on it: the processes, the portfolio, the indicators. The impact is queried from the live repository, not written from memory.
Accountability
Who answers for the indicator — and in which role
Alignment boards assign each measurement element to the person or unit that answers for it, per fiscal year, with its own target and weight. The board distinguishes three forms of responsibility that practice tends to confuse:
Without that distinction, accountability becomes an argument about who is to blame. With it, it becomes a conversation about what belongs to whom. And the board's target may differ from the institutional target — that is what deploying a goal means.
Who this is for
Risk, compliance and internal audit
Risk officers →
A register with a full cycle per entry, linked to the processes it conditions and the indicators that anticipate it.
Compliance →
Treatments that are controls in the process path, verified at approval — not commitments in a document.
Internal audit →
Every instance leaves who acted, on what data, under which rule; every risk shows what depends on it before anyone changes it.
Related
Bring one of your risks
Pick a risk your auditors ask about. In a working session we show the full path: inherent exposure, the treatment inside the process, the indicator that anticipates it, and what the platform says before anyone touches it.