Digital Risk and Controls Framework
A conceptual framework and logical object model for managing digital risk within enterprise risk management. Risk-led, evidence-based, decision-oriented.
One outcome, nine domains, one golden thread.
The board view of how digital risk is held within appetite.
This framework rests on a simple conviction: digital risk is enterprise risk, and it must be managed the same way. Against a defined appetite, on evidence, and in service of decisions. It is risk-led rather than control-led. Controls exist to hold named exposures within appetite, and every control traces back to a risk scenario. A control without operating evidence is treated as a design intention, not a managed risk, and every artifact the framework produces exists to support a recorded, accountable governance decision.
What holds this discipline together is the golden thread. Every governance decision traces back, link by link, to the corporate objective it protects, and forward to the evidence proving that controls operate. One unbroken line of sight from boardroom intent to operational proof.
The framework is built in two layers on one model: a conceptual framework for orientation, and a logical object model that can be implemented directly in GRC tooling. Its nine domains map to recognized ERM, security and regulatory standards, so nothing is invented from scratch. AI is included rather than treated separately: overlays such as ISO/IEC 42001 and the EU AI Act instantiate through the same nine domains.
Achieve corporate objectives with digital risk held within defined appetite.
The single outcome the whole framework serves.
Every link is specified in the object relationship catalog. Governance decisions close the loop back into appetite, treatment and control design.
Foundations
Core concepts, principles and building blocks. What digital risk is, and how the framework structures and models it.
Why this framework exists
In digitally dependent organizations, every corporate objective now depends on digital services, data, cloud infrastructure, third parties and, increasingly, AI. Any of these can cause or amplify enterprise risk. A failed platform is an operational loss, a data breach is a regulatory and reputational event, and a mis-governed AI model can be all three at once.
Yet in most organizations the picture is fragmented. Risks are tracked in silos, controls are documented but never evidenced in operation, and assurance runs disconnected from the risks it should inform. Nobody can answer the board's simplest question with confidence: are we within appetite?
This framework closes those gaps. It treats digital risk as a source and context of enterprise risk inside ERM, not a parallel discipline, and connects obligations, appetite, assets, scenarios, controls, evidence, assurance and decisions into one traceable whole.
Risk-led, not control-led
Controls exist to hold named exposures within appetite; every control traces to a risk scenario.
Evidence-based
A control without operating evidence is a design intention, not a managed risk.
Decision-oriented
Every artifact in the framework exists to support a recorded, accountable governance decision.
What the framework is
Conceptually, the framework is nine connected domains. Laws and regulation defines what is imposed. Enterprise direction and appetite defines what the organization wants and will tolerate. Digital context and dependency maps what it depends on. Risk scenario and exposure names what could go wrong. Control design defines what is done about it. Control operation and evidence proves what actually happens. Assurance and reliance confirms whether that proof can be trusted.
Two domains cut across all the others. Governance and stakeholders sets direction, appetite, accountability and decision rights, and makes the decisions. Monitoring and reporting watches indicators against thresholds and escalates whatever breaches.
Logically, the framework is an object model. Every risk, control, evidence record, assurance opinion and decision is a defined object with a named owner and explicit relationships. Nothing exists as an orphaned register entry.
Two layers, one model
A conceptual framework for orientation, and a logical object model you can implement in GRC tooling.
Standards-aligned
Each domain maps to recognized ERM, security and regulatory standards. Nothing is invented from scratch.
AI included, not separate
AI overlays such as ISO/IEC 42001 and the EU AI Act instantiate through the same nine domains. There is no separate AI framework.
The golden thread
The framework's defining property is traceability. A corporate objective is delivered by a digital service. The service is exposed to a risk scenario. The scenario is assessed and treated. Treatment drives control objectives and control activities. Controls produce evidence. Evidence is tested and assured. Assurance informs a reliance decision. Metrics track the whole chain, and governance decides.
Every link is deliberate. If any is missing, whether a control with no scenario behind it, a risk with no accountable owner, or an assessment resting on no current evidence, the framework makes the gap visible instead of letting it hide in a register.
Obligations and appetite constrain every step. The chain does not just describe how digital risk is managed. It demonstrates that it is managed within the boundaries the enterprise and its regulators have set.
Gaps become visible
An orphaned control or an unowned risk is a broken link you can see, own and fix.
A loop, not a line
Governance decisions feed back into appetite, treatment and control design. The chain closes on itself.
Decisions, not documentation
Traceability turns risk management from a documentation exercise into decision-making.
Digital risk within enterprise risk management
Digital context contributes to enterprise risk outcomes.
Digital dependencies, technologies, threats or failures can cause or amplify enterprise risks. Digital risk is a risk source and context, not a sixth risk category alongside strategic, financial, operational, compliance and people risk.
Enterprise risk categories
Strategic, financial, operational, compliance and people. The categories ERM already manages.
Digital risk sources
Information and technology, cyber, data and artificial intelligence. Each can cause or amplify the categories above.
Risk appetite
The amount and type of risk the enterprise is willing to accept, quantified as tolerance and impact thresholds.
Controls evidenced in operation
Designed and operating controls that hold risk within appetite, with proof that they run.
Scroll the diagram sideways, or open it full size.
One outcome: achieve corporate goals with digital risk held within defined appetite.
The framework on a page
Nine connected domains, from legal obligations to assurance, wrapped by governance and monitoring. Seven run in sequence from obligation to assurance. Two cut across all of them: governance sets direction, appetite, accountability and decision rights, and monitoring escalates exceptions and the decisions they require.
Scroll the diagram sideways, or open it full size.
Framework domains in detail
Each domain holds a defined set of objects. Nothing in the model floats free of a domain, and nothing in a domain exists without an owner and explicit relationships.
Scroll the diagram sideways, or open it full size.
Alignment with established standards
Each framework domain maps to recognized ERM, security and regulatory standards.
| Framework domain | COSO ERM (2017) | ISO 31000 / 27001 | NIST CSF 2.0 | COBIT 2019 | DORA |
|---|---|---|---|---|---|
| 1. Governance & Stakeholders | Governance & Culture | Leadership & commitment (31000 §5.2) | Govern (GV) | EDM01–EDM05 | Art. 5: governance & management body |
| 2. Laws & Regulation | Strategy & Objective-Setting (external context) | Context of the organization (§5.4) | GV.OC: Organizational Context | MEA03: Compliance | Entire regulation as binding obligation |
| 3. Enterprise Direction & Appetite | Strategy & Objective-Setting | Risk criteria (§6.3.4) | GV.RM: Risk Mgmt Strategy | EDM03, APO12 | Art. 6: risk tolerance in ICT framework |
| 4. Digital Context & Dependency | Performance: context for identification | Asset mgmt (27001 A.5, A.8) | ID.AM: Asset Management | APO03, BAI09 | Art. 8; Art. 28–30: ICT third parties |
| 5. Risk Scenario & Exposure | Performance: identifies & assesses risk | Risk assessment (§6.4) | ID.RA: Risk Assessment | APO12: Managed Risk | Art. 8: identification & classification |
| 6. Control Design | Performance: implements risk responses | Risk treatment (§6.5); 27001 Annex A | Protect (PR) | BAI, DSS design practices | Art. 9: protection & prevention |
| 7. Control Operation & Evidence | Review & Revision | Operation (27001 §8) | Protect (PR); Detect (DE) | DSS01–06, MEA01 | Art. 10–11: detection, response, recovery |
| 8. Assurance & Reliance | Review & Revision | Internal audit (27001 §9.2) | Independent assessment | MEA04: Assurance | Art. 24–27: resilience testing incl. TLPT |
| 9. Monitoring & Reporting | Information, Communication & Reporting | Monitoring & review (§6.6, §9.1) | DE.CM; GV.OV: Oversight | MEA01–MEA03 | Art. 13: learning; Art. 19: incident reporting |
Indicative alignment only, not a statement of compliance or one-to-one equivalence. AI-specific overlays such as ISO/IEC 42001 and the EU AI Act instantiate through the same nine domains.
Canonical end-to-end traceability
Canonical traceability means every governance decision can be traced back, link by link, to the corporate objective it ultimately protects, and forward to the evidence proving controls operate. The chain is canonical because it is the single authoritative path that every object and relationship in the framework must map onto.
The chain is the framework's connective tissue. It turns the meta-model in annexure A and the relationship catalog in annexure B from static definitions into operating logic, with obligations and appetite constraining each step. This is what enables impact analysis, audit-ready lineage and closed-loop governance.
Scroll the diagram sideways, or open it full size.
Obligations and appetite (domains 2 and 3) constrain every step of the chain. Governance decisions close the loop back into appetite, treatment and control design.
The risk and control object model
The logical model implements the conceptual framework. Obligations run through risks, controls and assurance to governance decisions. Every element is a defined object with a named owner and explicit relationships, and the seven spines below are the primary paths that connect them.
Scroll the diagram sideways, or open it full size.
Governance and stakeholders sits above all seven spines: forums exercise decision rights, approve policy and standards, authorize exceptions, and record every outcome as a documented decision record. Monitoring and reporting sits below them, escalating threshold breaches to those same forums. The complete relationship set is specified in annexure B.
Operating the framework
Processes, cadences and lifecycle activities. How risks get assessed, treated, evidenced, and learned from when things go wrong.
Run the lifecycle
Practitioners apply the framework as a repeating cycle. Establish context by capturing obligations and setting appetite and tolerance. Identify by mapping digital services, assets and dependencies, then defining risk scenarios against them. Assess by rating inherent exposure, applying evidenced control effect, and comparing residual to tolerance. Treat by choosing a response, assigning owners and recording the decision. Operate and evidence by running the controls and capturing proof as you go. Assure by testing, forming opinions and confirming reliance. Monitor by tracking indicators against thresholds and reporting to forums.
Governance sits at the center throughout. It sets direction and appetite at the start, and receives escalations and makes recorded decisions at every stage. The cycle is re-opened by triggers such as an incident, a material change, a control failure, a threshold breach or a new obligation, not only by the calendar.
Scroll the diagram sideways, or open it full size.
Evidence or it did not happen
A control without operating evidence is an intention, not a mitigation. It earns no rating credit.
One accountable owner
Residual risk is accepted by the accountable risk owner, never by the control operator.
Trigger-driven re-assessment
An incident, a material change, a failed test, a threshold breach or a new obligation re-opens the cycle immediately, not just the annual cycle.
Governance closes the loop
Breached thresholds and overdue remediation escalate to forums with defined decision rights.
Rate what you can prove
Assessment uses one likelihood by impact scale, 1 to 25, for the whole framework. Rate the inherent exposure of a named scenario linked to real services and assets, not abstract categories, then apply the effect of controls to reach residual. Control credit is earned, not assumed. Only controls that are both well designed and evidenced in operation move the score. Design intent alone earns nothing.
Scroll the diagram sideways, or open it full size.
Inherent risk
Likelihood times impact of the named scenario with no controls in place. It anchors where control investment matters most.
Control effect (evidenced only)
The reduction from controls that are well designed and evidenced in operation (D6 and D7). Design intent alone earns no credit.
Residual risk
The exposure that remains after control effect, re-rated on the same 1 to 25 scale, owned by the accountable risk owner and recorded in a versioned, point-in-time assessment.
Compare to tolerance (D3)
Within appetite, accept and monitor. Above appetite, treat or escalate to governance with a formal decision record.
Inherent and residual use the same scale. The evidenced control effect moves the score down and left. The 1 to 25 result is a risk classification score, not a loss forecast, and it is only as good as its evidence.
Confidence and evidence reliability
Keep three concepts distinct. Control effectiveness asks whether the control works. Evidence reliability asks whether the proof is complete, accurate, timely and trusted. Assessment confidence expresses how much trust to place in the residual conclusion. Missing evidence is not proof of failure; it downgrades confidence and is escalated per policy.
Control effectiveness
How well the control actually works.
- Design effectiveness: the control, as designed, is capable of mitigating the risk
- Operating effectiveness: it operates as intended, consistently, across the period
- Informed by testing, monitoring and assurance results
Evidence reliability
How reliable the proof is.
- Completeness: all required evidence is captured
- Accuracy: evidence reflects actual operation
- Timeliness: current for the period assessed
- Provenance: trusted source, unbroken chain
- Coverage: spans the population, not a sample of convenience
Assessment confidence
How much trust to place in the residual conclusion.
- High: current, reliable evidence; consistent results
- Moderate: largely reliable evidence with minor gaps
- Low: material evidence gaps or stale proof
- Uncertain: evidence unavailable or unreliable; escalate
Worked case: strong design, no reliable evidence, no incident. Effectiveness is uncertain, confidence is low, credit is withheld and the gap escalates. It does not re-rate automatically to inherent.
Risk treatment: four responses
When residual risk sits above tolerance, the accountable owner chooses one of four responses, approves it at the right forum, records it, and re-assesses residual afterwards.
Accept
Take the risk knowingly, with no further action beyond monitoring.
When to use
Residual is within appetite, or the cost of further control exceeds the exposure.
Guardrail
Only the accountable risk owner may accept. Acceptances are time-bound, with expiry and review date. A risk above appetite is never accepted on cost grounds alone; it requires the delegated governance decision.
Mitigate
Reduce likelihood or impact with new or improved controls.
When to use
A cost-effective control exists and its operation can be evidenced.
Guardrail
Every new control gets an owner, an evidence requirement and a test plan (D6 and D7).
Transfer
Shift financial impact to a third party via insurance or contract.
When to use
Impact is insurable, or a supplier can contractually bear the loss.
Guardrail
Accountability cannot be transferred. Regulators hold you responsible for outcomes.
Avoid
Stop or exit the activity, service or technology that creates the exposure.
When to use
Exposure exceeds appetite and cannot be reduced or transferred.
Guardrail
Assess exit dependencies and transition risk before switching anything off.
Every treatment decision is recorded as a documented decision record (D1) with forum, date and rationale. Risk acceptances are time-bound and expiry triggers re-assessment, never silent renewal. Treatment actions are tracked to closure like remediation actions (D7), with owners and due dates. Appetite breaches that cannot be treated escalate to the risk committee for explicit acceptance or avoidance. Treatment actions address exposure; remediation actions address known deficiencies. Related, but distinct.
Incident and issue feedback loop
Real events are the framework's best calibration data. Every material incident updates scenarios, controls and appetite.
Scroll the diagram sideways, or open it full size.
Incident
A declared risk event under active management, handled through this loop and linked back to its scenario.
Finding
A control deficiency identified by testing or assurance (D7 and D8), remediated without waiting for an incident.
Issue
A known problem or accepted gap, tracked with owner, action and due date until closed or formally accepted.
The closure test for every material incident: it maps to a scenario that predicted it, or a new one is created; a control that failed, or a gap now designed; and a decision record showing what changed.
Start small, trace end to end
Do not boil the ocean. Start with the critical digital services and material scenarios, and build the minimum viable trace for each. A thin, unbroken chain from service to governance decision beats a deep but disconnected inventory.
The minimum viable trace for any material risk.
Four quarters to running
Foundations, then risk and control baseline, then evidence and assurance, then monitor and optimize.
Score per domain
Maturity is rated domain by domain to expose uneven strength across cyber, data and AI.
Chain first, depth later
The unbroken chain comes first. Depth, breadth and automation come later.
Organizing and adopting
Who does what, with which tools, and how to get started and mature.
Governance decision rights
Governance closes the loop. Every decision type has an owner, an authority and a recorded, expiring outcome, captured as a documented decision record.
| Decision type | Decision owner | Recommender | Approver | Escalation forum | Validity / expiry | Decision record |
|---|---|---|---|---|---|---|
| Risk acceptance | Risk owner | 1st line | Delegated authority | Risk Committee | Time-bound; review date | DR ref (acceptance) |
| Appetite breach | CRO / 2nd line | 2nd line | Risk Committee | Board | Until remediated | DR ref (breach) |
| Treatment decision | Risk owner | 1st line | Per decision rights | Risk Committee | Until re-assessed | DR ref (treatment) |
| Reliance decision | 2nd line / relying function | Assurance provider | Relying function | Audit Committee | Defined period & scope | DR ref (reliance) |
| Policy exception | Policy owner (2nd line) | 1st line | Policy owner | Risk Committee | Time-bound; expiry | DR ref (exception) |
| Control exception | Control owner | Control operator | 2nd line | Risk Committee | Time-bound; expiry | DR ref (exception) |
| Remediation extension | Issue owner | 1st line | 2nd line | Risk Committee | New due date approved | DR ref (extension) |
| Risk closure | Risk owner | 1st line | 2nd line | Risk Committee | Permanent; evidenced | DR ref (closure) |
Illustrative. Populate with organization-specific delegated authority.
Escalation follows the same four levels whatever the decision type. Owners operate within appetite and declare breaches. The digital risk function provides second-line review and challenge. The risk committee accepts risks and approves exceptions. The board and audit committee handle appetite changes and material acceptances.
Scroll the diagram sideways, or open it full size.
Tooling and system of record
Where each domain's objects live, and the integrations that keep the model connected.
| Framework domain | System of record | Objects held | Key integrations |
|---|---|---|---|
| 1. Governance & Stakeholders | GRC governance module; board portal | Forums, decision rights, decision records | Receives escalations from risk and reporting |
| 2. Laws & Regulation | Obligations register; horizon scanning | Laws, regulations, contractual obligations | Obligations mapped to policies and controls |
| 3. Enterprise Direction & Appetite | GRC policy module | Policies, appetite statement, tolerances | Tolerances feed KRI and KCI thresholds |
| 4. Digital Context & Dependency | CMDB; data catalog; vendor register | Services, apps, data assets, AI models, 3rd parties | Scopes assessments; syncs to risk register |
| 5. Risk Scenario & Exposure | GRC risk register | Scenarios, risk assessments, treatment decisions, owners | Consumes CMDB context; feeds reporting |
| 6. Control Design | GRC control library | Control objectives, activities, owners | Controls mapped to risks and obligations |
| 7. Control Operation & Evidence | GRC testing module; ITSM; SIEM | Evidence, test results, findings, remediation | Pulls evidence from source systems |
| 8. Assurance & Reliance | Audit management system | Plans, workpapers, findings, opinions | Relies on GRC evidence and test records |
| 9. Monitoring & Reporting | BI and dashboards over GRC data | KRIs, KCIs, KPIs, thresholds, reports | Aggregates GRC, ITSM and SIEM feeds |
Illustrative reference architecture. A single GRC platform typically hosts domains 2, 3, 5, 6 and 7, and integration quality matters more than tool choice. Master data rule: every object carries a unique ID, one authoritative system of record, defined synchronization rules, ownership and version lineage.
Maturity model and adoption roadmap
Five levels, each with an exit test. Score maturity per domain rather than as one enterprise number: strength in cyber does not imply strength in AI, and a single score can obscure exactly the gap that matters. The first year runs one theme per quarter.
Scroll the diagram sideways, or open it full size.
Months 0 to 3 · Foundations
Stand up governance forums and decision rights, approve the appetite and policy set, and prioritize critical digital services and material scenarios rather than a full asset catalog.
Months 3 to 6 · Risk and control baseline
Build a risk scenario library per domain, map obligations to control objectives, and design and document the key controls.
Months 6 to 9 · Evidence and assurance
Define evidence requirements and start testing, remediate findings and track them to closure, and agree the assurance plan and reliance mapping.
Months 9 to 12 · Monitor and optimize
Deploy KRI and KCI dashboards against thresholds, report to governance and escalate breaches, and recalibrate appetite and control design.
Minimum viable trace for any material risk: service, scenario, owner, assessment, treatment, key control, evidence, monitoring, decision.
Meta-model and conventions
Element kinds, cardinality and versioning rules that govern the object model.
Element types
| Model element | Meaning | Framework examples |
|---|---|---|
| Object | Persistent governed entity | Risk scenario · Control activity · Digital service |
| Attribute | Property of an object | Control type · Frequency & trigger · Finding severity |
| Relationship | Directed link with cardinality | Risk scenario mitigated by control objective (M:M) |
| Assessment | Point-in-time, versioned evaluation | Risk assessment · Assurance opinion |
| Event | Occurrence triggering workflow | Risk event · Incident · Threshold breach |
| Decision | Authorized, time-bound outcome | Risk acceptance · Treatment decision · Reliance decision |
| Metric | Measurement against a threshold | KPI · KRI · KCI · SLA |
| Record | Proof of execution or decision | Evidence record · Test result & record · Decision record |
Conventions
Cardinality
Relationships are 1:1, 1:M or M:M. The digital dependency graph is M:M throughout.
Versioning
Assessments, decisions, evidence, tests and thresholds are versioned and point-in-time.
Primary and secondary
A primary relationship is the main traceability path. A secondary relationship reinforces, informs or feeds another element.
Object relationship catalog
Every relationship in the object model, specified end to end.
| Object | Relationship | Object |
|---|---|---|
| 1. Governance & stakeholders | ||
| Principles | shape → | Enterprise direction & appetite |
| Forums | exercise → | Decision rights |
| Forums | review → | Risk exposure, appetite breaches & assurance reporting |
| Policy & standards approval | approves → | Policy & internal standards |
| Forums | produce → | Decision record (documented) |
| Decision rights | authorize → | Risk acceptance, exceptions & remediation extensions |
| Threshold breach / material finding | escalates to → | Forums |
| Risk acceptance | recorded as → | Decision record (D1) |
| Treatment decision & reliance decision | recorded as → | Decision record (D1) |
| 2. Laws & regulation | ||
| Law / regulation / standard | imposes → | Binding & voluntary obligations |
| External contracts | create → | Binding & voluntary obligations |
| 3. Enterprise direction & appetite | ||
| Binding & voluntary obligations | constrain the pursuit of → | Corporate objectives |
| Binding & voluntary obligations | translated into → | Policy & internal standards |
| Binding & voluntary obligations | direct trace → | Control objective |
| Policy & internal standards | inform → | Risk appetite statement |
| Policy & internal standards | implemented by → | Control objective |
| Policy & internal standards | govern → | Digital context (all assets) |
| Risk appetite statement | quantified as → | Tolerance & impact threshold |
| Risk appetite statement | informs → | Control objective |
| Corporate objectives | drive → | Digital services & capabilities |
| Tolerance & impact threshold | calibrates → | Thresholds |
| 4. Digital context & dependency | ||
| Any digital object | depends on (M:M) → | Any other digital object |
| Digital services & capabilities | delivered by → | Digital process & products |
| Digital process & products | supported by → | Applications & platforms |
| Applications & platforms | process & store → | Data assets |
| Data assets | consumed by → | AI model & automation |
| AI model & automation | runs on → | Infrastructure & cloud |
| Infrastructure & cloud | provided by → | 3rd & 4th parties |
| Digital services & capabilities | scoped into → | Risk domain |
| Any digital dependency | at risk in (M:M) → | Risk scenario |
| Any digital dependency | may introduce → | Threat & cause |
| 3rd & 4th parties | risk drivers of → | Digital services & capabilities |
| 5. Risk scenario & exposure | ||
| Risk domain | contains → | Risk scenario |
| Risk scenario | caused by → | Threat & cause |
| Threat & cause | may lead to → | Risk event |
| Risk event | impacts → | Business exposure |
| Risk event | may become → | Incident |
| Risk scenario | assessed through → | Risk assessment (versioned) |
| Business exposure | impacts → | Corporate objectives |
| Risk assessment | records → | Inherent & residual rating |
| Risk assessment | leads to → | Treatment decision |
| Risk scenario | mitigated by → | Control objective |
| Residual risk | evaluated against → | Tolerance & impact threshold |
| Control effectiveness | informs → | Residual risk (rating) |
| Residual risk | accepted by → | Risk owner |
| Risk owner | owns → | Risk scenario |
| Risk owner | formalizes → | Risk acceptance |
| 6. Control design | ||
| Control objective | achieved by → | Control activity |
| Control activity | assigned to → | Control owner |
| Control owner | accountable for → | Control effectiveness |
| Control activity | defines → | Evidence requirement |
| Control activity | produces → | Evidence record |
| 7. Control operation & evidence | ||
| Evidence requirement | satisfied by → | Evidence record |
| Test result & record | evaluates → | Evidence record |
| Test result & record | informs → | Control effectiveness |
| Test result & record | may identify → | Finding |
| Finding | may be raised as → | Issue |
| Issue | drives → | Remediation action |
| Issue | triggers re-run of → | Risk assessment |
| Remediation action | strengthens → | Control activity |
| Remediation action | retested by → | Test result & record |
| 8. Assurance & reliance | ||
| Assurance activity | performed by → | Assurance provider |
| Assurance activity | tests, re-performs or relies on → | Test result & record |
| Assurance activity | covers → | 3rd & 4th parties |
| Assurance activity | results in → | Assurance result |
| Assurance result | identifies → | Finding |
| Assurance result | informs → | Control effectiveness |
| Assurance result | leads to → | Assurance opinion |
| Assurance opinion | supports → | Reliance decision |
| 9. Monitoring & reporting | ||
| Digital services & capabilities | measured by → | KPI |
| Digital services & capabilities | committed in → | SLA (commitment) |
| Risk scenario & exposure | monitored by → | KRI |
| Control design | monitored by → | KCI |
| Thresholds | applied to → | KRI / KCI |
| Threshold breach (event) | escalates to → | Forums |
| Control operation & evidence | feeds → | Reports |
| Assurance & reliance | feeds → | Reports |
| Reports | escalate to → | Forums |
Roles and accountability
Object-level accountability for each role across the three lines.
The three lines model
How responsibility splits before assigning R, A, C and I.
Own and manage risk
Business and technology management
- Runs day-to-day processes, platforms and services
- Owns each risk and the controls that treat it
- Operates controls and produces the evidence
- Remediates gaps and reports on status
Typically Responsible: executes controls, delivers evidence
Oversee and challenge
Risk, compliance and security functions
- Sets the framework: policies, appetite, methods
- Advises, challenges and monitors the 1st line
- Aggregates risk reporting for governance
- Owns the framework, not the risk itself
Typically Accountable or Consulted: owns framework, challenges
Independent assurance
Internal audit
- Independent of management; reports to the Audit Committee
- Gives objective assurance over the 1st and 2nd lines
- Tests design and operating effectiveness
- Relies on evidence, not assertions
Typically Informed: provides independent assurance
Object-level RACI
| Framework domain & object | Board & Risk Cttee | Business & service owners (1st) | Control owners & operators (1st) | Risk & compliance (2nd) | Internal audit (3rd) |
|---|---|---|---|---|---|
| 1. Governance & stakeholders | |||||
| Principles | A | R | I | C | I |
| Forums | A | R | I | C | I |
| Policy & standards approval | A | C | I | R | I |
| Decision rights | A | R | I | C | I |
| Decision record | A | I | I | R | I |
| 2. Laws & regulation | |||||
| Law / regulation / standard | I | C | I | A / R | I |
| External contracts | I | A / R | C | C | I |
| 3. Enterprise direction & appetite | |||||
| Corporate objectives | A | R | I | C | I |
| Binding & voluntary obligations | I | C | I | A / R | I |
| Policy & internal standards | A | C | I | R | I |
| Risk appetite statement | A | C | I | R | I |
| Tolerance & impact threshold | A | C | I | R | I |
| 4. Digital context & dependency | |||||
| Digital services & capabilities | I | A / R | C | C | I |
| Digital process & products | I | A / R | C | C | I |
| Applications & platforms | I | A | R | C | I |
| Data assets | I | A / R | C | C | I |
| AI model & automation | I | A / R | C | C | I |
| Infrastructure & cloud | I | A | R | C | I |
| 3rd & 4th parties | I | A / R | C | C | I |
| 5. Risk scenario & exposure | |||||
| Risk domain | I | C | I | A / R | I |
| Risk scenario | I | A | C | R | I |
| Threat & cause | I | C | C | A / R | I |
| Risk event | I | A / R | C | C | I |
| Business exposure | I | A / R | I | C | I |
| Risk assessment | I | A / R | C | C | I |
| Risk owner | I | A / R | I | C | I |
| Risk acceptance | C | A / R | I | C | I |
| Treatment decision | C | A / R | I | C | I |
| 6. Control design | |||||
| Control objective | I | A | C | R | I |
| Control activity | I | A | R | C | I |
| Control effectiveness | I | A | R | C | I |
| Control owner | I | A / R | C | I | I |
| 7. Control operation & evidence | |||||
| Evidence requirement | I | C | A / R | C | I |
| Evidence record | I | I | A / R | C | I |
| Test result & record | I | I | A / R | C | I |
| Finding | I | C | A / R | C | I |
| Issue | I | A | R | C | I |
| Remediation action | I | A | R | C | I |
| 8. Assurance & reliance | |||||
| Assurance activity | I | C | C | C | A / R |
| Assurance provider | A | I | I | C | R |
| Assurance result | I | C | C | C | A / R |
| Assurance opinion | I | I | I | C | A / R |
| Reliance decision | I | C | I | A / R | C |
| 9. Monitoring & reporting | |||||
| KPI | I | A / R | C | C | I |
| SLA (commitment) | I | A / R | C | C | I |
| Thresholds | I | C | C | A / R | I |
| KRI | I | C | C | A / R | I |
| KCI | I | C | R | A | I |
| Reports | I | C | R | A | I |
R = responsible, A = accountable, C = consulted, I = informed. Illustrative allocation; calibrate to your operating model and regulatory expectations. Board "A" denotes approval and oversight, never performance. The control owner, who is accountable, is distinct from the control operator, who performs.
Worked examples
Fourteen different digital risks, each examined through the same nine domain lenses.
The digital risk universe
There are more digital risks than organizations normally identify and try to manage. Most digital risk programs concentrate on five well-understood types: ITGC, ITAC, cyber, data and AI. These are necessary, but they describe how well the digital estate is controlled, not whether the strategy behind it is sound, the architecture can change, the vendors will hold, or the organization can absorb what is coming. A risk that is never named carries no owner, no appetite, no controls and no assurance.
Digital strategy risk
The digital direction is misaligned or overtaken by disruption, and investments fail to deliver value or market position.
Digital and enterprise architecture risk
Complexity, legacy and technical debt make the estate rigid, fragile and expensive to change.
Digital transformation and change risk
Major programs overrun, under-deliver benefits or fail at adoption.
Digital third-party and cloud risk
Vendor concentration, opaque subcontractor chains and lock-in undermine resilience and leverage.
Digital operations and resilience risk
Outages, capacity shortfalls and weak incident response push services beyond tolerance.
Digital regulatory and compliance risk
Digital regulation arrives faster than the control environment can absorb it.
Digital product and channel risk
Flawed products, journeys and pricing harm customers and conduct outcomes.
Digital workforce and skills risk
Scarce talent, key-person dependency and shadow IT erode capability and control.
Emerging technology risk
New technologies are adopted without assessment, or ignored until obsolescence itself becomes the risk.
A risk that is not named is not managed. Every type above needs an owner, an appetite statement, controls, evidence and assurance, exactly like the familiar five.
At a glance
Fourteen worked examples, one pattern. Every area instantiates the same nine domains and the same golden thread.
| Worked example | Headline risk | Accountable executive | Decision forum |
|---|---|---|---|
| I&T ITGC | Uncontrolled change on the core ERP platform | CIO | IT Governance Committee |
| I&T ITAC | A misconfigured three-way match in ERP payables | CFO | Finance Systems Steering Committee |
| Cyber | Ransomware on the core customer platform | CIO | Operational Risk Committee |
| Data | Degraded customer data quality in the reporting platform | CDO | Data Governance Council |
| AI | Drift and bias in the credit-decisioning model | Chief Data & AI Officer | AI Governance Board |
| Digital strategy | A stale digital strategy loses the market | CDO | Board Strategy Committee |
| Digital architecture | Technical debt freezes the estate | Chief Architect | Architecture Review Board |
| Digital transformation | A major program overruns and adoption stalls | Program Sponsor (CFO) | Transformation Steering Committee |
| Third-party & cloud | Cloud concentration meets an unworkable exit | COO | Third-Party Risk Committee |
| Digital operations | An outage breaches impact tolerance | COO | Operational Resilience Committee |
| Digital regulation | Regulation outpaces the control environment | Chief Compliance Officer | Regulatory Change Board |
| Digital product | A flawed digital journey harms customers | Chief Product Officer | Product Governance Committee |
| Digital workforce | Key-person loss meets shadow IT | CHRO and CIO (joint) | People & Capability Committee |
| Emerging technology | An unassessed pilot reaches production | CTO | Emerging Tech Review Board |
The examples in full
Each example below is a complete nine-domain instantiation, from obligation to governance decision. Every statement is an instance of an object in the model.
I&T ITGCUncontrolled change on the core ERP platformCIO · IT Governance Committee
IT Governance Committee holds decision rights. The CIO is accountable executive, and the escalation path to the Audit Committee is defined and recorded.
ICFR and SOX requirements on financial reporting, external audit reliance on ITGCs, and DORA ICT change-management expectations create binding obligations.
Risk appetite: no tolerance for unauthorized changes to systems supporting financial reporting. Emergency changes are ratified within 48 hours.
The ERP platform runs on hybrid infrastructure, integrates 40 or more applications, and is changed by internal DevOps teams and a vendor AMS provider.
An unauthorized or failed change could corrupt financial data and halt close. Risk assessment RA-014 v2: inherent 16, above tolerance, moving to residual 8 at moderate confidence. Risk owner: CIO. Treatment decision: mitigate.
Control objective: only authorized, tested changes reach ERP production. Controls: CAB approval workflow, segregation of developer and deployer access, automated pipeline release gates. Control owner: Head of IT Operations.
Monthly change-sample testing evidenced. Two emergency changes lacked retrospective approval; finding raised, remediation due in 30 days. Deployment logs reviewed weekly.
Internal audit re-performs change testing on a sample. External audit places reliance on ITGCs. Finding rated medium; opinion effective with exceptions; reliance qualified.
KCI: share of changes with complete approvals, threshold 100%, at 98.5% and breached. Reported to the IT Governance Committee; residual risk re-accepted by the CIO under delegated authority (DR-121, review by Q3).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
I&T ITACA misconfigured three-way match in ERP payablesCFO · Finance Systems Steering Committee
Finance Systems Steering Committee holds decision rights. The CFO is accountable executive, and the escalation path to the Audit Committee is defined and recorded.
ICFR accuracy requirements, tax and VAT reporting rules, and anti-fraud obligations create binding obligations on payment integrity.
Risk appetite: no tolerance for material misstatement. Duplicate or invalid payments above €50k trigger mandatory investigation.
The ERP payables module processes 30,000 invoices a month. Match configuration is maintained by the application team, and vendor master data feeds from the procurement system.
A misconfigured tolerance could let invalid invoices pay out. Risk assessment RA-022 v1: inherent 15, above tolerance, moving to residual 6 at high confidence. Risk owner: Financial Controller. Treatment decision: mitigate.
Control objective: only valid, matched invoices are paid. Controls: automated three-way match (ITAC), configuration change control which relies on ITGC, duplicate-payment detection. Control owner: Finance Systems Manager.
Quarterly configuration baseline check evidenced. One tolerance threshold was changed without approval; finding raised, remediation due in 30 days. Match exceptions reviewed daily.
Internal audit tests configuration and re-performs the match on a sample. Because ITGCs are effective, benchmarking reliance is permitted; opinion effective.
KCI: match-exception override rate, threshold under 2%, at 3.1% and breached. Reported to the Finance Systems Steering Committee; residual risk re-accepted by the CFO under delegated authority (DR-131, review by Q2).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
CyberRansomware on the core customer platformCIO · Operational Risk Committee
Operational Risk Committee holds decision rights. The CIO is accountable executive, and the escalation path to the Board Risk Committee is defined and recorded.
GDPR 72-hour breach notification, DORA major-incident reporting, and customer contract SLAs create binding obligations.
Risk appetite: no tolerance for outages of critical customer services beyond four hours, and none for loss of customer data.
The platform runs on public cloud IaaS operated by a third-party MSP and processes 2 million customer records.
Ransomware could cause a multi-day outage plus data loss. Risk assessment RA-001 v3: inherent 20, above tolerance, moving to residual 12 at moderate confidence. Risk owner: COO. Treatment decision: mitigate.
Control objective: ensure the platform can be restored within the impact tolerance defined in domain 3. Controls: immutable backups, EDR, privileged access management. Control owner: CISO.
Monthly restore test evidenced. The last test failed for one database; finding raised, remediation due in 30 days. EDR alerts triaged daily.
Internal audit re-performs the restore test on a sample. Finding rated medium; opinion effective with exceptions; reliance qualified.
KCI: restore-test success rate, threshold 100%, breached. Reported to the Operational Risk Committee; residual risk re-accepted by the COO under delegated authority (DR-114, review by Q2).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
DataDegraded customer data quality in the reporting platformCDO · Data Governance Council
Data Governance Council holds decision rights. The CDO is accountable executive, and the escalation path to the Executive Risk Committee is defined and recorded.
The GDPR accuracy principle, BCBS 239 risk-data aggregation expectations and regulatory reporting obligations create binding obligations.
Risk appetite: no regulatory report is filed on unvalidated data. The data-quality score for critical data elements must stay at or above 98%.
Customer data is mastered in the CRM and flows through 12 pipelines to the reporting platform. A third-party provider enriches 2 million records.
A pipeline defect could feed wrong data into regulatory reports. Risk assessment RA-031 v2: inherent 16, above tolerance, moving to residual 9 at moderate confidence. Risk owner: CDO. Treatment decision: mitigate.
Control objective: critical data elements are accurate, complete and timely at the point of use. Controls: data-quality rules at ingestion, reconciliation to source, lineage and ownership register. Control owner: Head of Data Management.
Daily data-quality dashboard evidenced. The completeness rule failed for two feeds; issue raised, backfill due in 14 days. Reconciliations reviewed weekly.
Internal audit traces lineage and re-performs reconciliations for a sample of critical data elements. Finding rated medium; opinion effective with exceptions; reliance qualified.
KCI: critical-element data-quality score, threshold at or above 98%, at 96.4% and breached. Reported to the Data Governance Council; residual risk re-accepted by the CDO under delegated authority (DR-142, review by Q2).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
AIDrift and bias in the credit-decisioning modelChief Data & AI Officer · AI Governance Board
AI Governance Board holds decision rights. The Chief Data and AI Officer is accountable executive, and the escalation path to the Board Risk Committee is defined and recorded.
EU AI Act high-risk obligations, GDPR Article 22 rights on automated decision-making, and anti-discrimination law create binding obligations.
Risk appetite: no tolerance for unexplained adverse decisions on protected groups. Models run in production only with a current, approved validation.
The credit model is retrained monthly on the customer data platform, hosted on a cloud ML service, with features from a vendor feature store.
Drift or biased retraining could harm customers and breach law. Risk assessment RA-045 v1: inherent 20, above tolerance, moving to residual 12 at moderate confidence. Risk owner: CRO. Treatment decision: mitigate.
Control objective: model decisions stay accurate, fair and explainable within approved bounds. Controls: independent validation before release, bias and drift monitoring, human-in-the-loop override. Control owner: Head of Model Risk.
Monthly drift and fairness report evidenced. One fairness metric breached after retraining; the version was rolled back, finding raised, remediation due in 30 days.
Independent model validation re-performs fairness testing and internal audit reviews the MLOps pipeline. Finding rated medium; opinion effective with exceptions; reliance qualified.
KCI: disparate-impact ratio, threshold at or above 0.8, breached once. Reported to the AI Governance Board; deployment frozen until re-validation approved by the CRO (DR-156, review by Q2).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
Digital strategyA stale digital strategy loses the marketCDO · Board Strategy Committee
Board Strategy Committee holds decision rights. The CDO is accountable executive, and the escalation path to the full Board is defined and recorded.
Listing rules and investor-disclosure obligations on strategy and principal risks apply, and sector licensing rules constrain admissible digital business models.
Risk appetite: no digital investment outside the approved strategy. Concentration in unproven ventures is capped at 15% of the digital portfolio.
The growth plan depends on the digital channel platform, a partner ecosystem and two strategic technology alliances. Competitor platforms reshape customer expectations quarterly.
A platform competitor undercuts the core offering, stranding digital investments. Risk assessment RA-021 v1: inherent 20, above tolerance, moving to residual 12 at low confidence. Risk owner: CDO. Treatment decision: mitigate.
Control objective: the strategy stays valid and every funded initiative traces to it. Controls: annual strategy review with market scan, quarterly portfolio re-prioritization, stage-gated investment approval. Control owner: Head of Strategy.
Quarterly portfolio reviews evidenced. Two initiatives were found without a trace to the strategy and funding was paused. Market-scan refresh completed and minuted.
Internal audit reviews the strategy process end to end and an external advisor benchmarks the portfolio. Finding rated medium; opinion effective with exceptions.
KRI: digital revenue against plan, threshold minus 10%, at minus 14% and breached. Reported to the Board Strategy Committee; strategy refresh brought forward (DR-201, review by Q2).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
Digital architectureTechnical debt freezes the estateChief Architect · Architecture Review Board
Architecture Review Board holds decision rights. The Chief Architect is accountable executive, and exceptions escalate to the IT Governance Committee under a defined, recorded path.
DORA ICT risk-management and resilience-by-design expectations apply, and sector outsourcing rules require documented architecture for critical or important functions.
Risk appetite: no new point-to-point integrations on core platforms. Technical-debt remediation receives at least 15% of annual change capacity.
The estate spans 300 or more applications, three cloud providers and a legacy core. Forty percent of interfaces are undocumented point-to-point links built over a decade.
Architecture rigidity delays a regulatory change program beyond the statutory deadline. Risk assessment RA-032 v3: inherent 16, above tolerance, moving to residual 9 at moderate confidence. Risk owner: Chief Architect. Treatment decision: mitigate.
Control objective: change lands only on sanctioned architecture. Controls: ARB design-gate approval, target-architecture roadmap, technical-debt register with funded remediation. Control owner: Head of Architecture.
Design-gate decisions logged for every release. Three solutions bypassed the ARB via a project fast-track; finding raised, remediation due in 60 days.
Internal audit tests design-gate operation on a sample, and an external architecture assessment runs every two years. Finding rated medium; opinion effective with exceptions.
KCI: share of changes passing the design gate, threshold 100%, at 96% and breached. Reported to the IT Governance Committee; technical-debt funding uplift approved (DR-214).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
Digital transformationA major program overruns and adoption stallsProgram Sponsor (CFO) · Transformation Steering Committee
Transformation Steering Committee holds decision rights. The Program Sponsor, the CFO, is accountable executive, and stage-gate escalation to the Executive Committee is defined and recorded.
Works-council consultation duties apply to workforce change, and regulatory notification is required before migrating regulated processes to new platforms.
Risk appetite: no go-live without a tested rollback. Benefit erosion beyond 20% of the approved case triggers mandatory re-baselining.
The program replaces the 20-year-old ERP core, touches 60 interfaces and 3,000 users, and runs alongside two other major change programs competing for the same experts.
Program overrun and weak adoption erode benefits and destabilize operations. Risk assessment RA-045 v2: inherent 20, above tolerance, moving to residual 10 at moderate confidence. Risk owner: Program Sponsor. Treatment decision: mitigate.
Control objective: change lands on time, adopted and within the benefits case. Controls: stage-gate reviews with independent QA, benefits-realization tracking, adoption and training metrics. Control owner: Transformation Office.
Gate 3 passed with conditions, evidenced in the gate log. Adoption at 55% against an 80% plan in two divisions; corrective training plan evidenced and tracked to closure.
Internal audit reviews gates and benefits reporting, and independent program assurance reports at every gate. Finding rated medium; opinion effective with exceptions.
KPI: benefits realized against plan, threshold 90%, at 78% and breached. Reported to the Steering Committee; scope re-baselined (DR-228, review at next gate).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
Third-party & cloudCloud concentration meets an unworkable exitCOO · Third-Party Risk Committee
Third-Party Risk Committee holds decision rights. The COO is accountable executive, and material-vendor escalation to the Board Risk Committee is defined and recorded.
DORA third-party provisions and sector outsourcing guidelines bind critical ICT providers. Contracts must secure audit, reporting and exit rights.
Risk appetite: no critical service on a single region. Every critical provider has a tested exit plan, and workload concentration above 60% triggers review.
Seventy percent of workloads run on one hyperscaler, the payments platform depends on a fourth-party subprocessor, and key contracts renew within 18 months.
A regional outage plus lock-in halts customer channels beyond tolerance. Risk assessment RA-051 v2: inherent 16, above tolerance, moving to residual 8 at moderate confidence. Risk owner: COO. Treatment decision: mitigate.
Control objective: critical services survive provider failure. Controls: multi-region failover, tested exit plans, contractual audit and reporting rights, concentration dashboard. Control owner: Head of Vendor Management.
Annual failover test evidenced. The exit-plan test for the payments platform is overdue by one quarter; finding raised, remediation due in 45 days.
Internal audit tests failover evidence, and reliance is placed on the provider's SOC 2 report after formal review. Finding rated medium; opinion effective with exceptions.
KCI: share of critical providers with a tested exit plan, threshold 100%, at 88% and breached. Reported to the Third-Party Risk Committee; remediation ordered (DR-233).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
Digital operationsAn outage breaches impact toleranceCOO · Operational Resilience Committee
Operational Resilience Committee holds decision rights. The COO is accountable executive, and severity-1 incidents escalate to the Executive Committee within one hour.
DORA resilience-testing and incident-reporting deadlines apply, and sector rules require defined impact tolerances for important business services.
Risk appetite: no important business service outage beyond a four-hour impact tolerance, and every severity-1 incident gets a post-mortem within five working days.
The customer channel spans 12 services across cloud and on-premise, operated follow-the-sun. Peak load reaches six times the average at month-end.
A failed change during peak halts the channel beyond tolerance. Risk assessment RA-063 v1: inherent 16, above tolerance, moving to residual 8 at moderate confidence. Risk owner: COO. Treatment decision: mitigate.
Control objective: important services stay within impact tolerance. Controls: capacity and performance testing, scenario-based resilience testing, incident runbooks, failover drills. Control owner: Head of Service Operations.
Quarterly resilience test evidenced. One severe-but-plausible scenario exceeded tolerance by 40 minutes; finding raised, runbook updated and re-tested within 30 days.
Internal audit observes the annual scenario test and the regulator reviews the resilience self-assessment. Finding rated medium; opinion effective with exceptions.
KCI: share of important services tested within tolerance, threshold 100%, at 92% and breached. Reported to the Resilience Committee; failover investment approved (DR-241).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
Digital regulationRegulation outpaces the control environmentChief Compliance Officer · Regulatory Change Board
Regulatory Change Board holds decision rights. The Chief Compliance Officer is accountable executive, and the escalation path to the Board Risk Committee is defined and recorded.
DORA, NIS2, the AI Act, e-privacy and accessibility acts arrive on fixed statutory timelines. Every applicable obligation is mapped in the compliance register.
Risk appetite: no regulatory deadline missed. Every applicable obligation is mapped to an owner and a control at least six months before it takes effect.
Obligations span 14 jurisdictions and every digital platform. Three digital regulations take effect within 18 months, competing for the same remediation teams.
NIS2 readiness gaps persist past the transposition date. Risk assessment RA-072 v2: inherent 15, above tolerance, moving to residual 9 at moderate confidence. Risk owner: CCO. Treatment decision: mitigate.
Control objective: obligations are identified, owned and controlled before they bind. Controls: horizon scanning, obligation-to-control mapping, readiness gate per regulation. Control owner: Head of Compliance.
Monthly readiness reporting evidenced. Two NIS2 obligations lacked a mapped control at the checkpoint; finding raised, remediation due within 30 days.
Internal audit reviews the obligation-to-control map, and external counsel validates interpretations for two regimes. Finding rated medium; opinion effective with exceptions.
KCI: share of obligations mapped to controls, threshold 100%, at 94% and breached. Reported to the Regulatory Change Board; remediation resourcing approved (DR-252).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
Digital productA flawed digital journey harms customersChief Product Officer · Product Governance Committee
Product Governance Committee holds decision rights. The Chief Product Officer is accountable executive, and conduct issues escalate to the Board Conduct Committee.
Consumer-protection and conduct rules, accessibility acts and fair-pricing requirements bind digital products and journeys end to end.
Risk appetite: no product launch without an approved fairness and accessibility assessment, and zero tolerance for systematic customer detriment.
Eighty percent of sales flow through the app and web channel. Journeys are A/B tested weekly and personalization models adjust pricing and prompts in near real time.
A journey defect misprices a product for three weeks, affecting 12,000 customers. Risk assessment RA-081 v1: inherent 12, above tolerance, moving to residual 6 at moderate confidence. Risk owner: CPO. Treatment decision: mitigate.
Control objective: journeys are fair, accessible and priced as approved. Controls: pre-launch product gate, journey testing including accessibility, outcome monitoring, kill-switch. Control owner: Head of Digital Product.
Product-gate approvals evidenced for all launches. Outcome monitoring flagged a pricing anomaly in one segment; remediation and customer redress executed within SLA.
Internal audit tests the product gate on a sample of launches and the conduct regulator reviews outcome data. Finding rated low; opinion effective.
KRI: complaints per 1,000 digital journeys, threshold 2.0, at 1.6 and within threshold. Reported to the Product Governance Committee; monitoring cadence confirmed (DR-263).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
Digital workforceKey-person loss meets shadow ITCHRO and CIO (joint) · People & Capability Committee
People and Capability Committee holds decision rights. The CHRO and CIO are jointly accountable, and escalation to the Executive Committee is defined and recorded.
Labor and works-council rules govern monitoring and reskilling, regulated roles require certified competence, and software license terms bind tool usage.
Risk appetite: no critical digital capability dependent on a single person. Citizen development runs only on the sanctioned low-code platform with registered owners.
Twenty-five percent of engineering roles are vacant or contractor-filled. More than 200 citizen-developed apps exist, 40 of which feed management or regulatory reporting.
A key engineer departs and an unowned app corrupts a regulatory report. Risk assessment RA-092 v1: inherent 12, above tolerance, moving to residual 8 at low confidence. Risk owner: CIO. Treatment decision: mitigate.
Control objective: critical capability is resilient and end-user computing is governed. Controls: succession and cross-training plans, EUC register and tiering, sanctioned-platform guardrails. Control owner: Head of Digital Workforce.
EUC register refresh evidenced quarterly. Twelve critical apps were found unregistered in one division; finding raised, migration plan due within 60 days.
Internal audit tests the EUC register for completeness against network scans, and an external skills benchmark runs annually. Finding rated medium; opinion effective with exceptions.
KCI: share of critical roles with named successors, threshold 100%, at 85% and breached. Reported to the People and Capability Committee; retention program funded (DR-271).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
Emerging technologyAn unassessed pilot reaches productionCTO · Emerging Tech Review Board
Emerging Tech Review Board holds decision rights. The CTO is accountable executive, and adoption decisions above threshold escalate to the Executive Committee.
Product-safety and data rules extend to IoT devices, crypto-asset rules may capture blockchain use, and export controls bind advanced cryptography pilots.
Risk appetite: no emerging technology in production without a completed risk assessment and a named owner. Pilots are ring-fenced from core platforms.
The sandbox hosts 15 pilots across IoT, blockchain and quantum-safe cryptography. One IoT pilot already feeds live logistics decisions for two product lines.
The unassessed pilot fails, corrupts logistics data and breaches device rules. Risk assessment RA-103 v1: inherent 12, above tolerance, moving to residual 6 at low confidence. Risk owner: CTO. Treatment decision: mitigate.
Control objective: emerging technology enters production only assessed and owned. Controls: pilot registration, production gate with risk assessment, sandbox isolation, sunset reviews. Control owner: Head of Innovation.
Gate reviews evidenced for all new pilots. The legacy IoT pilot passed the gate retroactively with two conditions, both tracked to closure.
Internal audit reconciles the pilot register against network scans, and an external specialist assesses cryptography choices. Finding rated low; opinion effective.
KCI: share of production pilots with a completed risk assessment, threshold 100%, met at 100% after remediation. Reported to the Emerging Tech Review Board (DR-282).
The traceability chain end to end: obligation, appetite, asset, scenario, control, evidence, assurance, report, governance decision.
ITGCs and ITACs
What IT general and application controls cover, and the key considerations for relying on them.
IT general controls (ITGCs)
Pervasive controls over the IT environment that underpin reliable applications, data and reports.
What it is
- Controls over the entity's IT environment: applications, databases, operating systems, networks and infrastructure.
- Pervasive rather than transaction-specific. They support the consistent, reliable operation of systems over time.
- They underpin reliance on automated controls (ITACs) and on system-generated data and reports (IPE).
- Typically operated by IT, but their effectiveness is a business concern. When ITGCs fail, confidence in every dependent control weakens.
What it covers
- Access to programs and data: user provisioning and de-provisioning, authentication, privileged access management, periodic access reviews.
- Program changes: authorization, testing and approval of changes, with segregated migration into production.
- Program development: SDLC discipline, data conversion and migration, and go-live approvals for new systems.
- Computer operations: job scheduling and monitoring, incident and problem management, backup and recovery.
Key considerations
- Scope ITGCs by tracing which applications and infrastructure support key controls and financial reporting.
- Apply in layers. Application, database and operating system each need access and change discipline.
- Enforce segregation between those who develop changes and those with production access.
- For cloud and outsourced IT, rely on SOC 1 and SOC 2 reports and test complementary user entity controls.
- An ITGC deficiency rarely misstates data by itself. Assess its downstream impact on ITACs and IPE.
IT application controls (ITACs)
Automated controls embedded in applications that enforce business rules transaction by transaction.
What it is
- Automated controls embedded within business applications such as ERP, ledgers, billing and payroll systems.
- They enforce rules over how transactions are initiated, recorded, processed and reported.
- Once configured correctly they operate the same way every time, with no human judgment or fatigue.
- Their reliability depends on the surrounding ITGC environment. Access and change controls protect the logic they run on.
What it covers
- Input and validation checks: edit checks, mandatory fields, duplicate detection.
- Automated calculations: interest, depreciation, pricing, tax.
- Automated matching, for example a three-way match of order, receipt and invoice.
- Interfaces: complete and accurate data transfer between systems.
- Access and workflow enforcement: approval hierarchies, tolerance limits, segregation of duties.
- System-generated reports (IPE) used in the performance of other controls.
Key considerations
- Identify where the control logic lives. Standard configuration versus custom code carries different change risk.
- A test-once benchmarking strategy is valid only while change-management ITGCs remain effective.
- Verify the completeness and accuracy of any report or data (IPE) the control relies on.
- Re-test after upgrades, patches or configuration changes that could alter the control's behavior.
- Watch for hybrid controls: automated output that depends on manual follow-up to be effective.
Glossary
Canonical definitions for every term and object in the framework, A to Z.
AI Model & Automation
Models and automated agents that consume data and act within processes.
Domain 4 · Digital context & dependency · Related: data assets, applications & platforms
Applications & Platforms
Software systems and platforms that support digital processes and products.
Domain 4 · Digital context & dependency · Related: digital process & products, infrastructure & cloud
Assessment Confidence
How much trust to place in the residual conclusion: high, moderate, low or uncertain, which escalates. Informed by control effectiveness and evidence reliability.
Domain 5 · Risk scenario & exposure · Attribute of risk assessment · Related: control effectiveness, evidence reliability
Assurance Activity
Independent review, audit or assessment of risks and controls. May test directly, re-perform management testing, or rely on prior testing.
Domain 8 · Assurance & reliance · Related: assurance provider, assurance result
Assurance Opinion
Overall conclusion on control effectiveness, reported to governance forums.
Domain 8 · Assurance & reliance · Related: assurance result, reliance decision
Assurance Provider
Function performing the assurance activity, for example second line, internal audit or an external assessor.
Domain 8 · Assurance & reliance · Related: assurance activity, three lines model
Assurance Result
Outcome of the assurance activity, relying on evidence and test records.
Domain 8 · Assurance & reliance · Related: finding, assurance opinion
Binding & Voluntary Obligations
Requirements the enterprise must, or chooses to, meet, translated from laws and contracts.
Domain 3 · Enterprise direction & appetite · Related: law / regulation / standard, external contracts
Business Exposure
Financial, regulatory, operational or reputational impact a risk event would cause.
Domain 5 · Risk scenario & exposure · Related: risk event, risk assessment
Control Activity
The designed activity that achieves the control objective. Attributes: control type, frequency and trigger.
Domain 6 · Control design · Related: control objective, control owner, evidence requirement
Control Effect
The evidenced reduction between inherent and residual risk. Controls earn credit only when well designed and evidenced in operation; design intent alone earns none.
Risk assessment method · Related: inherent risk, residual risk, control effectiveness
Control Effectiveness
Degree to which a control achieves its objective: design effectiveness, meaning capable as designed, and operating effectiveness, meaning it operates consistently. Informed by testing and assurance.
Domain 6 · Control design · Related: test result & record, assessment confidence
Control Objective
What a control must achieve to mitigate the risk scenario it addresses.
Domain 6 · Control design · Related: risk scenario, control activity
Control Operator
Role that performs the control activity day to day. Distinct from the control owner, who is accountable; accountability is never delegated to the operator.
Roles & accountability · Related: control owner, control activity
Control Owner
Individual accountable for the control's design and its operation.
Domain 6 · Control design · Related: control activity, control operator, risk owner
Control Type
Classification of the activity: preventive, detective or corrective; manual or automated.
Domain 6 · Control design · Attribute of control activity
Corporate Objectives
Strategic goals the enterprise pursues. The anchor for risk relevance and appetite.
Domain 3 · Enterprise direction & appetite · Related: risk appetite statement, digital services & capabilities
Data Assets
Information processed and stored by applications. Carriers of value and sensitivity.
Domain 4 · Digital context & dependency · Related: applications & platforms, AI model & automation
Decision Record
Auditable log of governance decisions, approvals and accepted risks. Captures decision type, authority, rationale, conditions, expiry and linked risk or issue.
Domain 1 · Governance & stakeholders · Related: risk treatment decision, risk acceptance, reliance decision
Decision Rights
Defined authority over who may take, approve or escalate risk and control decisions.
Domain 1 · Governance & stakeholders · Related: forums, decision record
Digital Process & Products
Digitized processes and products through which the services are delivered.
Domain 4 · Digital context & dependency · Related: digital services & capabilities, applications & platforms
Digital Risk
The potential for digital dependencies, technologies, threats or failures to cause or amplify enterprise risks. A risk source and context within ERM, not a separate risk category.
Framework-wide · Related: enterprise risk management, risk scenario
Digital Services & Capabilities
Business-facing digital services. May depend on any mix of processes, applications, data, AI models, infrastructure and third parties (M:M). Carries criticality tier and recovery requirements.
Domain 4 · Digital context & dependency · Related: corporate objectives, 3rd & 4th parties
Element Types & Versioning
Every element is one of eight kinds. Relationships carry direction and cardinality, and assessments, decisions and records are versioned.
Model convention · See annexure A
Enterprise Risk Management (ERM)
The enterprise-wide discipline for managing all risks to corporate objectives. Digital risk is managed within it, not as a parallel discipline.
Framework-wide · Related: digital risk, risk appetite statement
Evidence Record
Artifact captured when the control operates, satisfying the evidence requirement.
Domain 7 · Control operation & evidence · Related: evidence requirement, test result & record
Evidence Reliability
How reliable the proof is: completeness, accuracy, timeliness, provenance and coverage of evidence.
Domain 7 · Control operation & evidence · Related: evidence record, assessment confidence
Evidence Requirement
Definition of the proof needed to show a control operated as designed. Attribute: evidence source.
Domain 7 · Control operation & evidence · Related: control activity, evidence record
Evidence Source
System or record set from which operating evidence is drawn.
Domain 7 · Control operation & evidence · Attribute of evidence requirement
External Contracts
Agreements with customers and partners that create binding commitments on the enterprise.
Domain 2 · Laws & regulation · Related: binding & voluntary obligations, SLA
Finding
Identified gap or deficiency arising from control testing, operation or assurance work.
Domain 7 · Control operation & evidence · Related: issue, remediation action, assurance result
Finding Severity & Rating
Assessed significance of findings raised by assurance work.
Domain 8 · Assurance & reliance · Attribute of assurance result
Forums
Governance bodies, such as boards and committees, where risk and control matters are reviewed and decided.
Domain 1 · Governance & stakeholders · Related: decision rights, reports
Frequency & Trigger
When, how often, or on what event the control is performed.
Domain 6 · Control design · Attribute of control activity
Incident
A declared risk event under active management, handled through the incident feedback loop and linked back to the scenario that predicted it.
Domain 5 · Risk scenario & exposure · Related: risk event, finding, issue
Infrastructure & Cloud
Compute, network and cloud foundations that applications run on.
Domain 4 · Digital context & dependency · Related: applications & platforms, 3rd & 4th parties
Inherent Risk
Risk assuming absence or baseline of controls, from likelihood and exposure. Anchors where control investment matters most.
Domain 5 · Risk scenario & exposure · Attribute of risk assessment · Related: residual risk, control effect
Issue
Logged deficiency raised from a finding and tracked with owner, action and due date until closed or formally accepted.
Domain 7 · Control operation & evidence · Related: finding, remediation action
KCI (Key Control Indicator)
Monitors whether controls are operating effectively over time.
Domain 9 · Monitoring & reporting · Related: control effectiveness, thresholds
KPI (Key Performance Indicator)
Measures the performance of digital services and processes against targets.
Domain 9 · Monitoring & reporting · Related: digital services & capabilities, thresholds
KRI (Key Risk Indicator)
Signals changes in risk exposure relative to appetite and tolerance.
Domain 9 · Monitoring & reporting · Related: risk appetite statement, thresholds
Law / Regulation / Standard
External legal acts, regulatory rules and industry standards. The source that imposes obligations, the specific requirements the enterprise must meet.
Domain 2 · Laws & regulation · Related: binding & voluntary obligations
Maturity Model
Five-level scale, initial through optimized, for scoring adoption of the framework. Scored per domain, since a single enterprise score can obscure material gaps.
Adoption & roadmap
Metric Types
KPI, KRI, KCI and SLA are metric types sharing the same threshold and escalation mechanics.
Domain 9 · Monitoring & reporting · Related: thresholds
Policy & Internal Standards
Internal rules that operationalize obligations and govern the digital environment.
Domain 3 · Enterprise direction & appetite · Related: binding & voluntary obligations, policy & standards approval
Policy & Standards Approval
Governance act of ratifying the policies and standards that direct control design.
Domain 1 · Governance & stakeholders · Related: policy & internal standards, forums
Primary Relationship
Main traceability path from obligations through risks and controls to assurance.
Model convention · Related: traceability
Principles
Enduring statements that guide digital risk decisions and shape policies and standards.
Domain 1 · Governance & stakeholders · Related: policy & internal standards
RACI
Responsibility model, meaning responsible, accountable, consulted and informed, applied per object across the three lines of the operating model.
Roles & accountability · Related: three lines model, risk owner, control owner
Reliance Decision
Formal determination of the extent to which specified assurance work, test results or control evidence may be used for a defined purpose, scope and period.
Domain 8 · Assurance & reliance · Related: assurance opinion, decision record
Remediation Action
Corrective action that resolves a finding and strengthens the control. Distinct from treatment actions, which address exposure.
Domain 7 · Control operation & evidence · Related: finding, issue
Reports
Consolidated reporting that escalates monitoring results to governance forums.
Domain 9 · Monitoring & reporting · Related: forums, thresholds
Residual Risk
Risk after considering relevant controls and their evidenced effectiveness. Accepted by the accountable risk owner.
Domain 5 · Risk scenario & exposure · Attribute of risk assessment · Related: inherent risk, control effect, risk acceptance
Risk Acceptance
Formal, recorded decision by the risk owner to accept the residual risk within appetite. Time-bound, with expiry and review date.
Domain 5 · Risk scenario & exposure · Related: risk owner, decision record
Risk Appetite Statement
Approved articulation of the amount and type of risk the enterprise is willing to take.
Domain 3 · Enterprise direction & appetite · Related: corporate objectives, tolerance & impact threshold
Risk Assessment
Point-in-time, versioned evaluation of a risk scenario. Records inherent and residual rating, methodology, assumptions and confidence.
Domain 5 · Risk scenario & exposure · Related: risk scenario, assessment confidence, risk treatment decision
Risk Domain
Thematic grouping of related risk scenarios, for example cyber, resilience, data or third party.
Domain 5 · Risk scenario & exposure · Related: risk scenario
Risk Event
Materialization of a risk scenario, including near misses. May be declared as an incident.
Domain 5 · Risk scenario & exposure · Related: risk scenario, incident, business exposure
Risk Owner
Accountable individual who owns the risk scenario and accepts residual risk. Never the control operator.
Domain 5 · Risk scenario & exposure · Related: risk acceptance, control owner
Risk Scenario
Plausible narrative of how a threat could harm the digital services the business relies on.
Domain 5 · Risk scenario & exposure · Related: threat & cause, risk event, control objective
Risk Treatment Decision
Authorized decision to accept, mitigate, transfer or avoid an assessed risk. Recorded as a documented decision record.
Domain 5 · Risk scenario & exposure · Related: risk assessment, decision record, risk acceptance
Secondary Relationship
Supporting relationship that reinforces, informs or feeds another element.
Model convention · Related: primary relationship
SLA (Service Level Agreement)
Committed service targets, monitored for breach against agreed levels.
Domain 9 · Monitoring & reporting · Related: external contracts, thresholds
System of Record
Single authoritative system where each object lives, with unique IDs, synchronization rules, ownership and version lineage. Typically a GRC platform for domains 3, 5, 6 and 7.
Tooling & adoption
Test Result & Record
Documented outcome of testing control operation against the evidence requirement.
Domain 7 · Control operation & evidence · Related: evidence requirement, finding, control effectiveness
Testing Method & Sample
Approach and sample used to test controls within an assurance activity.
Domain 8 · Assurance & reliance · Attribute of assurance activity
Third & Fourth Parties
External providers and their subcontractors that may supply or support any digital object (M:M).
Domain 4 · Digital context & dependency · Related: digital services & capabilities, external contracts
Threat & Cause
Actor, hazard or weakness capable of initiating a risk scenario.
Domain 5 · Risk scenario & exposure · Related: risk scenario
Three Lines Model
First line owns risks and operates controls, second line sets the framework and challenges, third line provides independent assurance.
Roles & accountability · Related: RACI, assurance provider
Threshold Breach
The occurrence of a metric exceeding its threshold. Escalates to the accountable forum.
Domain 9 · Monitoring & reporting · Related: thresholds, forums
Thresholds
Limits derived from tolerance that calibrate metrics and trigger escalation.
Domain 9 · Monitoring & reporting · Related: tolerance & impact threshold, KPI / KRI / KCI / SLA
Tolerance & Impact Threshold
Quantified limits that make appetite measurable and calibrate monitoring thresholds.
Domain 3 · Enterprise direction & appetite · Related: risk appetite statement, thresholds
Traceability
The unbroken chain from corporate objective through scenario, assessment, control, evidence and assurance to governance decision.
Framework-wide · Related: primary relationship, golden thread
One outcome: corporate objectives achieved, digital risk within appetite.
Reference model v3.0. Use it, adapt it, or talk to us about standing it up in your organization.