Turning Fragmented Operational Risks into Decisive Business Action

By Prof. Hernan Huwyler, MBA CPA CAIO · Academic Director, IE Law School
Published 4 November 2026 · Last reviewed 4 November 2026

In short

• Operational risk is often assessed separately by departments using different methods, metrics and assumptions. This creates fragmented views that can hide how risks accumulate or interact across the organisation.
• A shared financial loss taxonomy provides a common language for comparing cyber, operational, safety and other risk exposures. It helps leadership understand potential losses across the business and prioritise them at portfolio level.
• Aggregation should not erase specialist knowledge. Preserve the assumptions behind each domain's assessments and make cross-domain dependencies and cascading loss scenarios visible when translating risk information into business decisions.

 

The transition from domain specific risk management to true enterprise risk quantification marks a fundamental shift in how organizations evaluate uncertainty and protect corporate value. Historically, departments have operated within isolated silos. Cybersecurity teams calculate system vulnerabilities, operational units log equipment failures, health and safety groups track physical workplace incidents, and corporate finance tracks liquidity and credit exposures. When presented to executive leadership or the board, these disparate operational domains are often aggregated into chaotic, color-coded heat maps that obscure real financial exposure.

Operational risk quantification solves this fragmentation by establishing a common currency across every corner of the business. By grounding risk analysis in a unified financial loss spectrum and consistent scenario modeling, risk leaders move away from abstract rating systems and deliver concrete decision support that protects corporate balance sheets.

 

Moving Beyond the Qualitative vs. Quantitative Risk Debate

By Prof. Hernan Huwyler, MBA CPA CAIO · Academic Director, IE Law School
Published 4 November 2026 · Last reviewed 8 November 2026

In short

• The debate between qualitative and quantitative risk assessment misses a fundamental challenge: autonomous systems make probabilistic decisions at runtime. Static heat maps alone cannot capture how their behaviour and risks change in operation.
• Risk reporting should support real decisions. Measure the business impact of verified failure modes and demonstrate whether technical safeguards, human oversight and runtime controls effectively limit those risks.

Organizations establish risk committees, draft policies, and populate registers with qualitative heat maps, yet these measures frequently create a false sense of security. When systems operate autonomously and make probabilistic decisions, static compliance frameworks break down. Moving past this paper-pushing illusion requires a fundamental shift in how teams measure exposure, evaluate runtime controls, and govern agentic behavior across production environments.

Governance must become an operating system for everyday decisions rather than a graveyard of static documents. International frameworks like the NIST AI Risk Management Framework frame governance as a continuous, cross-cutting function that embeds risk management across the entire technology lifecycle. That means pulling policies, accountability structures, third-party integrations, technical design, and corporate culture into a unified operational pattern. The EU AI Act takes a similar stance by treating high-risk systems as an ongoing lifecycle obligation. Risk management, data governance, continuous logging, technical transparency, human oversight, system robustness, cybersecurity, and post-market monitoring are living operations, not one-time compliance artifacts to file away before an audit.

 

Oversight in AI Systems From Governance Illusion to Operational Control

By Prof. Hernan Huwyler, MBA CPA CAIO · Academic Director, IE Law School
Published 8 November 2026 · Last reviewed 8 November 2026

In short

• A policy, a committee, or a risk register entry is not evidence that an AI model is safe to approve. Evidence is a dated record that a quantified assessment was done, that a named executive accepted a stated loss tolerance, and that the model was tested against acceptance criteria set before the test.
• Acceptance criteria come from the loss the organization can absorb, not from a vendor benchmark. In the worked example below, a tolerance of 5 percent probability of exceeding 1.5 million in annual fraud loss translates into a minimum recall of about 0.79, so the approval threshold is set at 0.80 and tested with a confidence interval.
• Test the controls the criteria rely on. Measure reviewer catch rates in drills, red-team the agent permissions, and rerun the quantification when drift, a new tool, or a new model version changes the assumptions.

 

An approval board reviews a payment fraud screening model on a Tuesday afternoon. The vendor slide reports 94 percent accuracy, the project team is pleased, and the chair asks who decided that 94 percent was enough. Nobody answers, because the figure came from the vendor's test set and the bar was set after the result was known. The board approves the model anyway, and the minutes record that it met expectations.

AI governance needs evidence of that decision, and evidence has a specific form. It starts with a quantified assessment of what the model could cost if it fails: how often, how much, and how likely a bad year is. An accountable executive then states a tolerance, such as the largest annual loss they accept at a stated probability. Acceptance criteria are derived from that tolerance before anyone tests the model, and the test results, the approval, and the later monitoring are stored in records a reviewer could rerun. Without that chain, a governance program produces documents that describe intent and nothing that proves control.

This guide is for Chief AI Officers, risk and compliance leaders, internal auditors, model owners, and anyone who signs an approval. It explains what counts as evidence, what a quantified AI risk assessment contains, and how to turn a loss tolerance into numerical acceptance criteria for predictive and agentic systems. It then covers testing against those criteria, measuring human oversight as a control, how the EU AI Act and the main standards point the same way, and the evidence register that ties it together.

 

 

Risk Heat Maps to Monte Carlo: Practical Guide for Risk Owners

By Prof. Hernan Huwyler, MBA CPA CAIO · Academic Director, IE Law School
Published 4 November 2026 · Last reviewed 4 November 2026

In short

• A risk heat map is a vage way to display risk, not a measure of financial exposure. It never tells decision-makers how much they could lose, how often, or which assumptions drive the result.
• Range compression and rank reversal can conceal important differences between risks, therefore, it will induce wrong decision-making. Simply multiplying frequency by impact with qualitative scales and scores is professional malpractice.
• Loss exceedance curves provide a more useful alternative. When historical data is limited or unavailable, model uncertainty explicitly instead of relying on arbitrary colour categories.

 

A risk workshop ends at four in the afternoon. Twenty people have argued for two hours about whether a vendor outage is a three or a four on likelihood, and the facilitator closes by moving a dot into a yellow cell. Everyone leaves with the feeling that something was decided. Nothing was. Nobody can say how much money the company might lose, how often, or which assumption would change the answer.

A risk heat map is a display format. It is not a risk analysis, and it cannot replace one. The replacement is a quantified model: frequency and severity estimated as ranges, combined by simulation, and reported as a loss exceedance curve that tells an executive the probability of losing more than a given amount in a year. This guide is for risk owners, fraud and cybersecurity leads, internal auditors, and AI product owners who need to defend a number in front of a board and want a method that survives questions.

The path runs in a fixed order. First you see why the matrix fails, with the research behind it. Then you replace frequency times impact with the correct combination of the two distributions, build the curve, handle missing data, add machine learning where it earns its place, and connect the output to a decision. The last section covers the politics of retiring a tool that management likes.

 

Guide for Risk Managers for DORA Compliance

By Prof. Hernan Huwyler, MBA CPA CAIO · Academic Director, IE Law School
Published 16 October 2026 · Last reviewed 16 October 2026

In short

• DORA has applied since 17 January 2025. The priority is now demonstrating that data, accountable owners and operational processes can support compliance and respond to supervisory scrutiny.
• Map critical or important functions to the ICT assets and services that support them before preparing reporting templates. This register provides the foundation for the wider DORA program.
• Build the programme around day-to-day operations, with particular attention to incident reporting deadlines and ICT third-party oversight, two areas where implementation can become difficult.

 

A quarterly operational risk report that takes four months to produce is already a DORA problem, and nobody has opened the regulation yet. By the time the report lands, two newer quarters of incidents, supplier changes and control failures have happened. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025, so the open question for most financial entities is no longer when to start. The question is whether their data, owners and processes can answer a supervisor within hours instead of months.

The short answer is to build one maintained dependency model that links each critical or important function to its information, ICT assets, providers, contracts, incidents and test results, and then run the five DORA chapters on top of it. The chapters cover ICT risk management, incident management and reporting, resilience testing, ICT third-party risk, and information sharing. Most of the effort sits in the links between those chapters. A firm that treats them as five projects ends up with five registers that disagree with each other.

This guide is for risk owners, compliance officers, internal auditors and security leads who have to turn the regulation into working procedures. It follows the order in which a program usually runs, and it separates what the regulation requires from what is a sensible implementation choice. It also corrects several statements that circulate in conference slides and vendor material, such as the idea that DORA requires threat-led penetration testing from every firm.

 

How to Plan, Govern, and Build Enterprise AI Agents and AI Architecture

By Prof. Hernan Huwyler, MBA, CPA, CAIO · Academic Director, IE Law School
Published 14 October 2026 · Last reviewed 14 October 2026

In short

• An AI pilot can perform impressively in a controlled demonstration yet fail in production when real users, operational costs, data access, permissions and unpredictable outputs enter the picture.
• Enterprise AI governance must extend beyond model selection and prompt design. It must cover the complete operating environment: data, integrations, identity, access rights, monitoring, escalation and accountability.
• AI agents need clearly defined permissions and boundaries. Their ability to call tools, retrieve information or initiate transactions should be limited to approved tasks and risk levels.
• Deterministic software controls should enforce critical business rules, security requirements and approval thresholds. Prompts and model instructions alone are not reliable enforcement mechanisms.
• Successful AI deployment requires named business and technical owners, measurable performance indicators, human intervention procedures and continuous monitoring after go-live.
• The central lesson for executives, AI architects and risk professionals: production readiness is an architecture and governance challenge, not simply a question of choosing a more powerful AI model.

 

AI governance professionals need more than policies. They need to understand how AI systems are designed, where controls belong, and what happens when agents act in the real world.

An AI pilot can look impressive in a demonstration and still fail when a company tries to put it into production. Costs grow, permissions become difficult to manage, outputs vary, and nobody knows exactly who should intervene when something goes wrong.

For risk managers, internal auditors, compliance officers, cybersecurity experts, and IT professionals, these are not abstract technology problems. They are questions of accountability, control design, operational resilience, and business value.

That is why I believe AI architecture deserves a place at the center of enterprise AI governance.

 

Essential Skills for GRC, Finance, Legal and Cyber in 2027 and 2028

This article answers one worry: if AI now drafts the policies, tests the controls, reviews the contracts and triages the alerts, what is left for a GRC, finance, legal or cyber professional to do? The answer is five human skills, ranked by how well they protect your job: professional judgment (called taste in the AI community), agency, follow-through, focus and resourcefulness. Each one sits where automation stops and accountability starts. Judgment decides which AI output is sound and defensible. Agency moves you from the person who samples 40 payments to the person who runs the agent that checks all 18,000. Follow-through makes the work land with the people who rely on it. Focus keeps you on the few exposures that matter, and resourcefulness lets you take on the unfamiliar projects others decline.

The key advice is to build these skills on one real project instead of reading about them. Pick one control you test by sampling today, write the decision it supports and who makes it, and run an agent across the whole population. Write down the rules you used to sort real exceptions from noise, because that is your judgment on paper. Keep humans on irreversible decisions, give every agent an owner, a boundary and a log, and stay with the work until the business actually uses it. Revisit the projects you ruled out, since the constraint that stopped them may be gone. Employers will pay for the professional who can show the exposure chosen, the decision supported and the person who relies on the result.

Consider a composite situation, not a real engagement. An internal auditor at a mid-sized manufacturer spends two weeks every quarter testing a sample of 40 payments out of roughly 18,000 for duplicates and approval breaches. That sample covers about 0.2 percent of the population, and everyone in the room knows it. An AI agent can now read all 18,000 payments overnight and hand the auditor a short list of exceptions by Monday morning. The two weeks of sampling are gone, and so is the part of the job that looked like work.

The question for 2027 and 2028 is what the auditor does with the other thirteen days. The short answer is five human skills, and I rank them here by how well they protect a GRC, finance, legal or cybersecurity career from displacement by automation of repetitive analysis, reporting and control reviews. In order of job-market relevance they are professional judgment, agency, follow-through, focus and resourcefulness. This article is for risk analysts, internal and external auditors, compliance officers, finance controllers, in-house lawyers and security engineers who want to know which habits employers will pay for once everyone has the same AI tools.

AI has removed the old excuses that kept capable professionals from acting on what they already understood: no time, no access, no technical skill. That makes the call to action simple. Revisit the projects you ruled out in the last three years, because the constraint that ruled them out may no longer exist. AI has expanded what is possible in risk management, auditing, compliance, cybersecurity, legal work and finance faster than most people have expanded what they are willing to attempt, and that gap is where your next promotion sits.

AI Governance Frameworks For Risk Managers

 

Corporate environments are adopting autonomous systems at a pace that outstrips traditional oversight mechanisms. Engineering teams ship automated workflows daily. Business units integrate external models into core operations without formal review. The resulting environment creates massive blind spots for risk professionals. You cannot manage what you cannot see, and you certainly cannot audit what you do not understand. The era of treating artificial intelligence as a mere productivity enhancement is over. It is now a foundational component of enterprise architecture. This shift demands a complete rethinking of control environments.

Risk managers, compliance officers, and cybersecurity experts must transition from passive observers to active architects of machine behavior. The theoretical debates about future capabilities no longer matter. The immediate reality involves managing current deployments that process sensitive data, execute financial transactions, and interact directly with customers. Professionals who master this transition will define the next decade of corporate governance. Those who fail will preside over catastrophic compliance failures and severe reputational damage.

This guide provides a direct, actionable blueprint for securing autonomous systems. We will explore five essential pillars of modern risk management. These pillars move beyond basic policy documents. They focus on the practical implementation of controls, the integration of global standards, and the strategic career positioning of governance leaders. You will learn how to validate machine outputs, secure third-party integrations, assign legal accountability, capture institutional context, and manage the hidden costs of automated code generation.

The Risk Management Blueprint: A Practitioner's Guide to Quantitative GRC

 

Risk management has a credibility problem. Not because the profession lacks talent, but because color-coded heat maps, ordinal scoring matrices, and quarterly dashboard reviews were never built to change decisions. They exist to document that a compliance process took place. Executive teams know this. They react accordingly by treating risk departments as corporate overhead instead of strategic assets.

I wrote this book to help my peers turn that dynamic around.

After 25 years leading risk functions and advising executive boards across complex multinational companies, I needed a manual that actually bridges advanced quantitative methods with the daily decisions that determine business outcomes. That drive is why The Risk Management Blueprint hit #9 among the most sold risk management books in the weeks after publishing.

At 867 pages, it gives practitioners a single unified methodology across every major risk domain, covering AI systems, cyber exposure, financial cash flows, sustainability transitions, and human behavior. The framework rests on probability theory, financial modeling, and decision science so you can swap subjective scores for numbers that stand up in the boardroom.

You can preview the first four chapters and access the book here: https://amzn.to/4ciag1F

This is not a textbook. It does not spend the majority of its pages diagnosing what is broken in the profession before gesturing toward improvement in a final chapter. More than 70 percent of the book's total length is allocated to domain applications and advanced analytical infrastructure, meaning the bulk of every page is spent on how to build, calibrate, and apply quantitative and predictive risk models across the decisions that actually shape organizational outcomes.

SOC 2 Is Not Security: A Critical Guide for GRC Managers

Let us be direct. SOC 2 is not a security certification. It is an attestation report issued under AICPA standards in which a licensed public accounting firm expresses an opinion on whether a service organization controls met the selected trust services criteria. The report does not declare that your product is safe. It does not certify that your penetration test was rigorous. It does not prove that your attack surface is small or that your customers are protected from a breach. It states that management described a system, selected criteria, asserted controls, and the auditor found those controls suitably designed and, for a Type II report, operating effectively during the specified period.

That distinction matters more than many teams are willing to admit. The report can create a polished artifact that procurement teams accept, but the underlying controls may still be thin, poorly scoped, or disconnected from the technical reality of the product. The phrase SOC 2 is the audit version of trust me bro became popular for a reason. When the PDF is stronger than the security program, the market starts rewarding documentation rather than operational resilience. As a GRC leader, your job is to reverse that sequence. Build the controls, operate them, collect evidence continuously, and let the SOC 2 report fall out as a byproduct rather than serving as the starting point.

This guide walks through the exact gaps that make SOC 2 incomplete as a security signal, how to read a report without wasting your review cycle, how to build a security-first program that makes SOC 2 the output, how to use continuous assurance strategically, and how to govern vendors that hand you a SOC 2 report and expect instant approval. The focus is practical because the risk owner in the room rarely needs another abstract debate. You need a method for using SOC 2 as one piece of evidence among many.

The article is intended for a global audience. SOC 2 is a US-origin AICPA attestation product, but it is now exchanged across borders by cloud providers, software vendors, data processors, and AI product teams. It often sits alongside ISO/IEC 27001, NIST Cybersecurity Framework, CIS Controls, GDPR, HIPAA, NIS2, and emerging AI governance obligations. That means the underlying discipline remains the same. Understand the limitations, own the controls, and never outsource your risk judgment to a report.

 

The Quantitative Revolution In Enterprise Risk Management

Traditional risk management has reached an inflection point where intuition and qualitative heat maps no longer suffice for navigating complex, interconnected business environments. The modern governance, risk, and compliance director faces a paradox: organizations generate more data than ever before, yet decision makers remain plagued by uncertainty about the very risks that could derail strategic objectives. This gap between information availability and decision quality stems from reliance on uncalibrated expert judgment, measurement of irrelevant variables, and risk models that violate fundamental mathematical principles. The solution lies not in abandoning human expertise, but in rigorously calibrating it through quantitative methods that transform subjective opinions into defensible, mathematically sound probability assessments.

Organizations that master these quantitative techniques gain a decisive competitive advantage. They allocate capital more efficiently by focusing measurement budgets on variables that actually influence decisions. They avoid catastrophic failures by identifying cascade risks and common-mode vulnerabilities before they materialize. They build organizational resilience through models that reflect physical reality rather than statistical convenience. This transformation requires risk professionals to develop new competencies in probability theory, information economics, and computational modeling. The following techniques represent the distilled wisdom of decades of research in decision science, behavioral economics, and quantitative risk analysis. Each method addresses a specific failure mode in traditional risk management, providing practical tools that GRC directors can implement immediately to elevate their organization's risk maturity from descriptive to predictive to prescriptive.

Machine Learning Predictive Risk Modeling for GRC Professionals

AI Use Cases for Risk Management

Machine learning fundamentally transforms risk management from a reactive, sample based discipline into a proactive, population wide surveillance system. The traditional operational model, where risk professionals manually review periodic samples, apply static heuristic rules, and generate retrospective reports, cannot scale to match the velocity, volume, and complexity of modern business transactions. Machine learning enabled systems continuously monitor entire populations of transactions, access requests, supplier relationships, and control events. These systems identify subtle patterns and emerging risks that consistently escape rigid rule based systems. This paradigm shift does not eliminate the need for human expertise. Rather, it repositions risk professionals from data processors to strategic decision makers who focus their judgment on exceptional cases, ambiguous signals, and high consequence approvals. Organizations that successfully implement this model achieve what was previously impossible. They gain comprehensive risk visibility without proportional increases in headcount, enabling the risk function to scale with business growth rather than becoming an operational bottleneck.

The integration of machine learning into governance, risk, and compliance frameworks aligns directly with the core principles of ISO 31000, which emphasizes that risk management must be dynamic, iterative, and responsive to change. Static controls are inherently blind to novel threats and evolving business environments. By embedding predictive analytics into the risk management lifecycle, organizations transition from merely documenting historical failures to actively preventing future exposures. This requires a fundamental rethinking of the risk operating model. The strongest operating model does not seek to replace the risk professional. Instead, it automates the predictable, prioritizes the unusual, and reserves human judgment for material, ambiguous, or consequential decisions. This symbiotic relationship between human expertise and machine scale forms the foundation of modern, resilient risk management.

  

How to Stop Producing Risk Registers Nobody Uses

Enterprise Risk Management programs fail in the same quiet way. They produce polished registers, colorful heat maps, and quarterly reports that look impressive in board packs. Then the organization makes its next major capital allocation, acquisition, or vendor choice using a single-page summary with one projected number and zero reference to the risk framework that consumed thousands of hours to build.

I've watched this pattern destroy the credibility of risk functions across industries. The risk team works hard. Stakeholders get interviewed. Likelihood and impact get scored. And none of it touches the actual decisions that determine whether the organization wins or loses. The gap between risk reporting quality and decision quality is where ERM programs go to die.

This article addresses that gap directly. It provides a stage-by-stage implementation approach for building an ERM program that changes how your organization decides, plans, and allocates resources. Every recommendation comes from field-tested practice, not theory. If your ERM program currently produces documents that live in SharePoint between annual reviews, this post shows you how to fix that.

 

Skills for Compliance Officers, Risk Managers, and Auditors

7 Career Capabilities That Will Separate Compliance Officers Who Thrive in 2026 From Those Who Get Replaced by Algorithms

ING just announced 1,250 job cuts in its compliance operations. ABN Amro plans to replace 35% of its AML division with AI. The Dutch audit office published a report questioning whether the €1.4 billion the banking sector spends annually on anti-money laundering checks actually produces effective outcomes.

Read that last sentence again. The government auditor is asking whether the entire manual compliance model works.

This is not a future scenario. This is happening now, across multiple banks, in one of Europe's most regulated markets. And it raises a question that every compliance officer, risk manager, and internal auditor should be asking themselves today: if my primary value comes from executing manual processes that AI can do faster and more consistently, what exactly is my professional future?

The answer depends entirely on skills. Not certifications. Not years of experience. Skills.

I have spent the last fifteen years working with compliance functions across financial services, industrials, and technology companies. The pattern I see repeating is consistent: the professionals who can quantify risk, challenge AI outputs, and translate regulatory complexity into financial terms the business can act on are becoming more valuable every quarter. The ones who built careers around checklist execution, manual alert processing, and qualitative risk scoring are watching their roles disappear. Sometimes gradually. Sometimes overnight.

This post identifies the seven skills that will define professional survival and advancement in compliance, risk, and audit roles through 2026 and beyond. Each one is grounded in what I see organizations actually hiring for, paying premiums for, and struggling to find.

 

Risk Workshops That Improve Decisions

Most risk workshops fail for a simple reason. They confuse documentation with decision support. Teams gather experienced people in a room, collect a long list of concerns, assign broad scores, and leave with a register that looks complete. What they often do not leave with is a sharper understanding of which uncertainties matter most, which scenarios require deeper analysis, and what management should do next. The process produces artifacts, but not always insight.

That gap matters. Risk is the effect of uncertainty on objectives, and risk management should be integrated into governance, strategy, planning, and decision-making, not treated as a separate administrative exercise. Risk management should support value creation, preservation, and realization by informing choices under uncertainty. A workshop that does not improve a decision, refine a treatment decision, or guide further analysis has limited value no matter how polished the documentation appears.

A well-run risk workshop has a narrower and more useful purpose. It helps participants identify credible risk scenarios, distinguish plausible exposures from noise, structure uncertainty around objectives, and determine where analysis will improve a management decision. It creates shared understanding before quantitative assessment, treatment planning, or escalation. In practical terms, it is a disciplined mechanism for focusing organizational attention.

That is the standard worth aiming for. Not a more colorful discussion. Not a longer register. Better judgment.

 

How to Use Large Language Models Securely in Risk Management, Compliance, Cybersecurity, and Audit

 

A compliance officer asked an LLM to analyze a vendor contract for GDPR obligations. The prompt included the full contract text. The contract contained employee names, personal email addresses, salary data from an embedded compensation schedule, and a confidential arbitration clause. All of it went into a third-party API. The compliance officer received a helpful analysis. The organization received a data privacy incident.

Nobody planned for this. The compliance officer was doing good work. The tool produced a useful output. And the organization now had regulated personal data sitting in an external system with no data processing agreement, no retention controls, and no way to request deletion.

That is the paradox of LLMs in GRC. The same capability that makes them powerful for regulatory analysis, risk assessment, and audit automation makes them dangerous when deployed without guardrails. An LLM will process whatever you feed it. It does not distinguish between public regulatory text and confidential personal data. It does not know that the regulation it cited does not exist. It does not understand that the risk score it generated was influenced by training data biases that systematically underweight emerging market vendors.

 

AI for GRC: 10 Use Cases Every Risk and Compliance Team Can Deploy in 90 Days

A compliance analyst at a mid-tier financial institution spent 14 hours last week reading regulatory updates. She flagged three items as potentially relevant to her business. She missed two others that directly affected the firm's cloud outsourcing arrangements. One of those triggered an enforcement action against a peer institution six weeks later.

That story repeats across thousands of GRC teams every week. The volume of regulatory change, vendor risk signals, control evidence, and incident data has exceeded human processing capacity. Not because the people lack skill. Because the volume is physically impossible to cover manually with the rigor the work demands.

AI changes this equation. Not by replacing human judgment, but by compressing the time between a risk signal appearing and a qualified human evaluating it. The 10 use cases in this post are not theoretical. GRC leaders at financial institutions, technology companies, and manufacturing firms are running three to five of these today, cutting manual hours by 30-60% while improving coverage across the full risk population.

Each use case includes the practical workflow, the authoritative framework it maps to, and the implementation path you can follow starting this week.

 

AI Governance Essentials

Why AI Deployment Now Requires Governance, Not Just Engineering

Artificial intelligence deployment has moved well beyond a technical exercise. What was once framed primarily as model development, application hosting, and iterative improvement now sits squarely within the remit of governance, risk management, compliance, and internal audit. That shift reflects regulatory change, market expectations, and a more mature understanding of how AI systems create both value and exposure across the enterprise.

The original draft focused heavily on product iteration, deployment mechanics, and general technology trends. Those topics matter, but in a professional GRC context they are incomplete unless anchored in accountability, risk ownership, control design, performance monitoring, and assurance. AI systems are not governed effectively merely because they are deployed through modern engineering practices such as CI/CD or MLOps. They require a structured governance model that aligns with recognized frameworks such as ISO/IEC 42001, NIST AI RMF 1.0, COSO Enterprise Risk Management, the IIA Global Internal Audit Standards, and applicable legal obligations including the EU AI Act, privacy laws, sector regulations, and financial reporting requirements where AI affects significant processes.

A practical governance perspective begins with one foundational point. AI is not a single risk category. It is a capability that can introduce, amplify, or obscure multiple risk types at once, including operational risk, model risk, legal risk, compliance risk, information security risk, privacy risk, conduct risk, third-party risk, and reputational risk. In many organizations, this is where governance breaks down. The enterprise treats AI as an innovation program when it should also be treated as a governed business capability subject to the same rigor applied to other material systems and processes.

This distinction matters because controls that are adequate for conventional software may be insufficient for AI-enabled systems. A deterministic business rule can usually be traced to fixed logic. A machine learning model may change behavior as a result of retraining, data drift, feature changes, prompt changes, or vendor model updates. A generative AI application may also produce variable outputs for the same input. For GRC professionals, that means control design must account for non-determinism, data dependency, explainability constraints, and lifecycle volatility.

Effective AI governance therefore starts with a simple but often neglected question. What decision, action, or business process is the AI system influencing, and what is the consequence if it fails or behaves unexpectedly? This framing is more useful than beginning with the underlying algorithm. It allows leaders to assess impact on customers, employees, financial reporting, safety, privacy, regulatory obligations, and organizational objectives.

 

Prof. Hernan Huwyler, MBA, CPA, CAIO: AI Governance, Risk & Compliance Executive | Speaker, Trainer & Advisor

 

I am an AI Risk Manager and Governance, Risk, and Compliance (GRC) executive dedicated to empowering business leaders to achieve strategic objectives through robust AI governance, digital compliance, and responsible AI frameworks. With over two decades of global executive experience spanning four continents, I specialize in guiding Fortune 500 organizations toward financial success and operational excellence by transforming regulatory pressure into a competitive advantage -1.

Tips and example on assurance mapping

By Prof. Hernan Huwyler, MBA CPA CAIO, AI GRC Director · Academic Director, IE Law School
Published 24 January 2017 · Last reviewed 14 March 2026

In short

• An assurance map provides a clear overview of who provides assurance, which risks and controls are covered, and where gaps or overlapping activities exist.
• Its main value is helping management and internal audit make better decisions about assurance coverage, reliance on other assurance providers, and where additional work is needed.
• A useful assurance map identifies the risks and objectives being covered, the relevant controls and assertions, the assurance provider, its level of independence, and the evidence supporting its conclusions.

Post by Prof. Hernan Huwyler, MBA, CPA, CAIO
AI GRC Director | AI Risk Manager | Quantitative Risk Lead
Speaker, Corporate Trainer and Executive Advisor

Top 10 Responsible AI and Risk Management by Thinkers360

Risk is a pervasive force across all business activities. Every strategic and operational decision depends on producing reliable information about the probability and impact of different outcomes. Assurance services exist to enhance the quality and credibility of this information, enabling leadership to make well-founded decisions with confidence.

The AICPA Special Committee on Assurance Services, commonly known as the Elliott Committee, articulated this principle in its 1997 report, establishing that assurance improves the reliability of information for decision makers. Since then, the scope of assurance has expanded well beyond statutory financial reporting to encompass ESG disclosures, cybersecurity attestations, data privacy compliance, and emerging areas such as AI governance.

The Institute of Internal Auditors defines assurance as the objective examination of evidence for the purpose of providing an independent assessment of governance, risk management, and control processes. This assessment adds credibility to both financial and non-financial information, from audited financial statements to environmental and social reports. In practical terms, assurance delivers the confidence that what needs to be controlled is actually being controlled.

Boards bear ultimate responsibility for ensuring that robust internal control arrangements exist across the entire organization, making assurance a first-order governance obligation rather than a purely operational concern.

Most corporate governance frameworks reinforce this expectation. The UK Corporate Governance Code, NYSE listing requirements, King IV in South Africa, and the EU Corporate Sustainability Reporting Directive all require the board to attest to the effectiveness of internal control and risk management systems. In the United States, SOX Section 404 specifically mandates that management assess and report on the effectiveness of internal controls over financial reporting.

Without a structured approach to coordinating assurance across these requirements, boards risk blind spots, redundant coverage, and misallocated resources. These are precisely the conditions that erode stakeholder trust and invite regulatory scrutiny.

What Is an Assurance Map and Why It Matters

An assurance map is a visual coordination tool that links assurance activities from all providers to the risks threatening organizational objectives. Structured as a matrix, it plots key risks or sequential process steps along the vertical axis against assurance activities along the horizontal axis.

The assurance activities are typically organized according to the IIA Three Lines Model, which was updated in 2020 to replace the former Three Lines of Defense terminology. Under this model, the first line consists of operational management, which owns and manages risk and controls. The second line encompasses risk management, compliance, and other oversight functions that provide expertise, monitoring, and challenge. The third line is internal audit, which delivers independent and objective assurance. Some organizations extend the framework to incorporate external audit and regulatory or board-level oversight as additional assurance layers, though these extensions fall outside the IIA formal model.

The strategic value of an assurance map lies in four dimensions. First, it provides board-level visibility through a consolidated, single-page view of risk coverage across the enterprise. Second, it promotes consistency by establishing a common methodology and language for management, oversight, and reporting. Third, it fosters cross-functional collaboration by making interdependencies between departments visible and actionable. Fourth, it drives cost efficiency by revealing redundancies and enabling reallocation of assurance resources toward areas of genuine exposure.

Keys to Making Decisions on Assurance

Assurance mapping is only as valuable as the decisions it informs. The following principles are critical to leveraging these maps effectively.

Identify Gaps and Eliminate Redundancies

The primary objective of assurance mapping is to detect areas where assurance is absent or unnecessarily duplicated across departments. A well-constructed map reveals the true level of oversight for each risk area, enabling leadership to reduce low-value and redundant efforts while strengthening coverage where it is most needed.

Standardize the Risk Methodology

For assurance mapping to deliver a coherent enterprise-wide view, the underlying risk methodology must be standardized. This includes the risk taxonomy, exposure modeling, and risk appetite thresholds. A common risk language is what enables meaningful coordination and interaction between business owners and assurance providers across all three lines. Without standardization, the map becomes a patchwork of incompatible assessments rather than a reliable decision-making tool.

Align Assurance Effort to Risk Exposure

Link the risk exposure of each process to its current assurance coverage to determine whether assurance costs are proportionate to the organization's risk tolerance. This is the practical application of the concept of reasonable assurance. When excessive assurance concentrates on a single process, leadership should investigate the root causes, such as historical incidents, regulatory mandates, or organizational inertia, before redistributing controls and responsibilities.

Update Governance Documents

When assurance programs are combined or activities reassigned, the governing documents must reflect these changes. This includes organizational policies, the internal audit charter, and departmental mandates. The assurance map is a coordination and visualization tool. It is not a policy instrument in itself and should not be treated as one.

Maintain Information Flow Across All Lines

Consolidating or reassigning assurance responsibilities does not eliminate the need for information sharing. Even when a department no longer directly assures a process, it should continue to receive relevant reporting about the reliability of related controls and the quality of associated outputs. Effective remediation depends on transparent communication of issues and action plans across all functions involved.

Leverage Technology for Continuous Assurance

Modern GRC platforms and data analytics capabilities enable real-time monitoring and continuous assurance, moving organizations beyond periodic point-in-time assessments. Integrating automated controls, exception-based reporting, and interactive dashboards into the assurance map strengthens both coverage and responsiveness. Organizations that embed technology into their assurance architecture gain a significant advantage in the speed and reliability of their risk oversight.

An Assurance Map in Practice

To illustrate the concept, consider a simplified financial month-end closing process at a company operating on SAP. The process-based map below plots process steps and their associated risks along the vertical axis against assurance providers organized by the Three Lines Model along the horizontal axis. It consolidates controls from each line to assess the extent and adequacy of coverage, designed for alignment with SOX Section 404 requirements and the COSO Internal Control Integrated Framework.

  

Each cell in the map reflects the quality and depth of evidence provided by the relevant assurance function, assessed according to three levels.

H stands for High Assurance. Assurance is detailed and performed on a recurring cycle. The depth of audit evidence reduces residual risk to an acceptable level, for example by maintaining low material misstatement risk in accounting processes. Controls are in place and adequately mitigate identified risks. Policies are documented and communicated throughout the organization. IT and business intelligence tools automate controls and flag exceptions for follow-up. Performance metrics are actively monitored by management.

M stands for Medium Assurance. Assurance is not performed on a regular cycle. Controls are not in place to cover all relevant risks. Policies are incomplete or not fully communicated to the responsible parties. Manual controls that could be automated remain in their current state, increasing the likelihood of human error.

L stands for Low Assurance. Little or no assurance is provided over the process. Significant concerns exist regarding the adequacy of controls relative to the risk profile. Few governing policies are documented or enforced.

The governance case for assurance mapping

In the United States, boards oversee risk management and internal control, while management is responsible for establishing, maintaining, and assessing those controls. This governance distinction is important. It would be inaccurate to say that boards directly operate or certify every control across the enterprise. Their role is to oversee whether the organization has an effective system of internal control and risk management, and whether that system is supported by credible reporting and challenge.

That oversight burden has grown significantly. Public companies face Sarbanes Oxley requirements for internal control over financial reporting. Regulated sectors face heightened scrutiny over operational resilience, model risk, privacy, third party dependencies, and cyber controls. Sustainability reporting is also increasing expectations around governance, controls, and attestable data. As complexity rises, boards and executive committees need a clearer and more integrated view of assurance coverage.

Recognized frameworks support this approach. The Institute of Internal Auditors Three Lines Model clarifies the roles of management, oversight functions, and internal audit. The COSO Internal Control Integrated Framework remains the leading basis for evaluating the design and effectiveness of internal control. COSO Enterprise Risk Management links risk oversight to strategy and performance. ISO 31000 provides a widely accepted foundation for risk management principles and governance. Together, these frameworks reinforce the same point. Assurance should be coordinated, risk based, and tied to decision making.

How Assurance Mapping Creates Management Value

The strongest reason to implement assurance mapping is not administrative efficiency. It is better risk oversight.

A well designed assurance map helps leadership answer questions that are often difficult to resolve through fragmented reporting. Which enterprise risks receive strong and recurring challenge. Which critical processes depend too heavily on self assessment or management judgment. Where are multiple teams reviewing the same controls with similar methods. Which material risks are supported by evidence based assurance and which rely on assumptions. Where does remediation stall because findings remain within one function instead of moving through a common governance process.

These insights matter because organizations rarely fail due to a total absence of controls. More often, they fail because risk ownership is unclear, challenge is inconsistent, and fragmented assurance gives leadership a false sense of confidence.

What a Strong Assurance Map Should Include

A useful assurance map begins with the business objectives, risk universe, and critical processes that matter most to the enterprise. The goal is not to map everything. The goal is to make visible the quality and sufficiency of assurance where failure would materially affect performance, compliance, resilience, or reporting integrity.

The structure usually starts with a defined scope such as financial reporting, cybersecurity, third party risk, privacy, revenue, procurement, product quality, or end to end operational processes. For each area, the map should identify the principal risks, the key controls or oversight mechanisms, the functions providing assurance, the nature of that assurance, the frequency of review, the degree of independence, the quality of evidence, and the current assessment of coverage.

This does not require an overly complex model. In fact, one of the most common mistakes is overengineering the framework to the point that it becomes difficult to maintain. The best assurance maps are disciplined, comparable, and practical enough to support real decisions.

 

From Assurance Mapping to Strategic Confidence

Assurance mapping is not an end in itself. It is a means of translating fragmented risk oversight into boardroom confidence and organizational resilience. When executed with disciplined methodology, standardized risk language, and genuine cross-functional commitment, it becomes one of the most powerful tools available to the GRC leader.

The goal is never to eliminate risk entirely. The goal is to ensure that the organization's assurance architecture is proportionate to its risk profile, coordinated across all lines, and transparent to the stakeholders who depend on it. In an era of expanding regulatory expectations, proliferating risk domains, and heightened scrutiny from investors and regulators alike, the organizations that master assurance coordination will be the ones that earn and sustain trust.

Get the latest in corporate governance, risk, and compliance on Twitter