- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
3 weeks ago - edited 3 weeks ago
One of the most overlooked parts of IRM implementations is the taxonomy that sits underneath everything. We often talk about Authority Documents (regulations, frameworks, standards) and Risk Statements (potential events that may impact objectives) but without a structured Risk & Control Taxonomy, things quickly become fragmented.
Why does taxonomy matter?
-
It provides a common language across the organisation.
-
It avoids duplicate risks/controls being defined in silos.
-
It ensures traceability back to regulations (authority documents or risk framework) and policies.
-
It makes reporting & analytics meaningful.
In practice:
-
Risk Taxonomy → groups risks into logical families (strategic, operational, compliance, IT, etc.)
-
There is no "one-size-fits-all." It depends on how you want to organize risk statements.
-
A Risk Framework is essentially a group of risk statements, which can be drilled down by levels if you nest them.
-
-
Control Taxonomy → organizes controls (preventive, detective, corrective) and aligns them to objectives or frameworks
-
In the current version (v21.0) there’s no “level” field at the control objective level (and it should exist.. I’ve raised this as an idea). Risk Statements have a Level field so the absence on Control Objectives breaks parity and complicates the taxonomy.
-
Control objectives should always connect to citations so compliance scores can properly roll up to the top authority document.
-
Depending on the detail you need, control objectives can be broken down and nested so scores cascade upward.
-
Together, they form the backbone of a connected compliance and risk ecosystem.
My advice is don’t overcomplicate it.
Start with 2–3 levels (e.g., Category → Sub-Category → Risk/Control) and refine as you scale.
Question to the community:
How detailed is your Risk & Control Taxonomy? Do you keep it simple, or have you gone for a very granular model (process → sub-process → risk/control)?
#PolicyComplianceManagement #RiskManagement
- 259 Views