Showing posts with label Management. Show all posts
Showing posts with label Management. Show all posts

AI Isn't Coming For GRC Jobs. It's Coming For The Manual Review Part Of Every GRC Job

 

What second line experts each need to build before their function gets automated out from under them

Here's the uncomfortable part nobody says out loud in a GRC conference room. AI is not replacing risk managers, compliance officers, auditors, cyber teams, controllers, or sustainability experts. It's replacing the manual review work that used to justify half of those job descriptions. What's left after that work disappears is judgment, and judgment is either your biggest career asset right now or the skill you never actually built because the manual work always came first.

Every one of these six professions is being pulled through the same transformation at the same time, just wearing different clothes. Risk teams are using AI to process larger volumes of exposure data faster than any analyst could by hand. Audit is automating the routine testing that used to eat most of fieldwork season. Cyber teams are automating alert triage and first-line response. Compliance is watching AI surface policy conflicts across thousands of documents in the time it used to take to review one contract. Controllers are automating reconciliations and close procedures. Sustainability teams are automating ESG data extraction and disclosure drafting.

None of that is a headcount story on its own. It becomes one for the people who don't adapt, because the professionals who can validate AI outputs, challenge exceptions, and decide where a human still has to sign off are becoming the only ones a board actually needs in the room.

Manual Review Jobs Are Becoming Judgment and Governance Jobs

Guidance on responsible AI and audit puts this plainly: building strong governance, inventories, and validation practices now means an organization can answer the hard questions with confidence when auditors ask them, with a clear account of how AI is actually being used across the enterprise. That's not a compliance platitude. It's a description of what the job becomes once the underlying manual task gets automated: you stop being the person who does the review, and you become the person who can prove the review was done correctly.

The same shift shows up in new studies on audit committees, which stresses that internal auditors still need to bring human judgment into evaluating AI outcomes for fairness, accuracy, reliability, and consistency. The AI does the first pass. The professional's value moves entirely into catching what the first pass got wrong, and knowing when to trust it versus when to escalate.

The riskiest moment in any AI-enabled function isn't when the AI makes a mistake. It's the meeting where everyone assumes someone else already checked the output.

This pattern holds across every one of the six roles, and it's worth naming what "judgment and governance" actually means in practice, because it's not a soft skill. It's validating outputs against known failure modes, challenging exceptions instead of rubber-stamping them, and deciding, explicitly and in writing, where a human still has to own the final call. Professionals who can do all three become harder to automate than the task they used to perform, because the task was never the actual value. The check was.

Redesign The Workflow, Don't Just Bolt on a Tool

The biggest mistake organizations make right now is layering an AI tool onto an unchanged process and calling it transformation. It isn't. Research on operational risk modernization is direct about this: an AI-driven framework is only as good as the data foundation underneath it, and the real opportunity is rethinking the framework itself, not just automating today's manual steps inside the old one.

That distinction matters for your career, not just your organization's efficiency numbers. If you only learn to operate a new tool inside an old workflow, you've picked up a skill that gets replaced the next time a better tool ships. If you learn to redesign the workflow itself, meaning new decision points, new escalation paths, and new control ownership, you've picked up a skill that survives every tool upgrade after this one.

Process design and control mapping are not adjacent skills to model literacy anymore. They're the load-bearing skill. Anyone can learn to prompt a tool. Far fewer people can look at a redesigned workflow and correctly identify where the old control broke, where a new one needs to exist, and who now owns it. That's the professional a board actually wants advising them, and it's a skill you build by practicing control mapping deliberately, not by waiting for it to show up as a side effect of using AI tools daily.

Every GRC Function Now Needs Its Own AI-Specific Controls

Generic "AI governance" is not a control. It's a slogan. Each of the six functions needs controls tuned to its own specific failure modes, because the way AI breaks a compliance workflow is not the way it breaks a cybersecurity workflow.

Compliance officers need to track policy and regulatory drift as a distinct, monitored risk category, not a once-a-year policy refresh. Governance Intelligence's roundup of 2026 GRC predictions captures why this matters: Diligent's governance lead expects the pace of AI regulation to stay unpredictable and increasingly demanding through the year, which means a compliance program built around annual policy review cycles is already structurally too slow for how fast the underlying regulatory landscape is moving.

Auditors need to test AI-enabled controls and the reliability of AI-generated evidence directly, not just the outputs those controls used to produce manually. Internal audit guidance frames this as a genuine fork in the road: internal audit can either lead on AI governance or scramble to catch up after a model failure, compliance breach, or public misstep has already happened. Testing evidence quality now means asking how a model was developed, deployed, validated, and monitored, not just whether the final number tied out.

Cybersecurity experts need controls built for AI-accelerated attacks and AI-driven defense at the same time, because both sides of that fight are now running on the same underlying technology. New cybersecurity surveys name this directly as a defining contradiction facing security leaders: AI is accelerating the threat landscape while simultaneously becoming a core defense capability, which creates pressure to govern adoption tightly without slowing the business down. Establishing a formal AI security and governance program with real human-in-the-loop controls for critical decisions isn't optional anymore. 

Financial controllers need to watch specifically for automation errors bleeding into reporting and approval chains, a risk made sharper by the fact that no binding regulatory standard currently governs AI use in financial reporting audits. Coverage of the 2026 compliance landscape for CFOs and audit committees is blunt about this gap: there's no PCAOB or SEC standard governing AI in audits as of mid-2026, which means the burden falls entirely on the controller's own internal governance to answer questions regulators haven't formally asked yet, questions like which reporting processes use AI, how those outputs get validated, and who signed off on the tools in the first place.

Sustainability experts need to treat AI's effect on ESG data quality and reporting integrity as a governance risk in its own right, not a side benefit of faster reporting. Legal and sustainability coverage of 2026 ESG trends notes that leading teams are already adopting agentic AI to manage compliance work and automate structured data tagging for digital filings, which introduces new governance risk that needs board-level oversight, particularly around whether AI-calculated figures such as carbon footprints or supplier risk scores can actually withstand a regulatory audit. Academic research on ESG disclosure adds a sharper warning underneath that: AI can genuinely improve consistency and scale in sustainability reporting, but it can just as easily formalize and speed up existing greenwashing and disclosure inconsistency if nobody is checking the outputs against source data. An ESG report drafted faster by AI is not automatically a more accurate ESG report. Speed and accuracy are different axes, and AI only reliably improves one of them without deliberate human validation on the other.

Data Quality And Governance Are Now Foundational Career Skills

Every one of these functions runs into the same wall eventually: AI performance is entirely dependent on the data underneath it, and weak data governance creates downstream risk across risk management, compliance, and control functions alike. Research on AI-enabled risk management states this almost as a warning label: without good data, AI is just artificial noise, and clear data governance is the foundation of any effective AI-enabled risk program.

That's not an abstract point. Researchers broader work on rebuilding data governance for the AI era describes a real structural problem showing up across organizations right now: legacy governance models built for structured, static data are struggling under the weight of unstructured inputs, AI-generated outputs, and metadata that shifts constantly, which slows adoption and quietly erodes trust in the outputs everyone's relying on.

The career implication is straightforward, even if it's not the sexy part of the AI story. Professionals who can actually improve data lineage, define clear ownership, and set real monitoring standards are becoming more valuable than professionals who only consume AI outputs and take them at face value. Data stewardship used to be a back-office function nobody wanted. It's becoming a leadership qualification, because nobody can trust an AI-generated risk score, audit finding, or ESG figure without someone accountable for the data quality underneath it.

The Career Premium Goes To Domain Experts Who Can Also Supervise AI

Here's where this gets specific and useful, rather than another generic "upskill in AI" pep talk. The premium isn't going to AI generalists. It's going to domain experts, meaning people who already understand risk, compliance, audit, cyber, financial controls, or sustainability deeply, who then add AI oversight capability on top of that existing expertise.

In cybersecurity, this shift already has names attached to it. Coverage of how agentic AI is reshaping security teams describes the classic Level 1 SOC analyst role turning into an AI supervisor role, where the human reviews agent output, tunes agent guardrails, and focuses on the nuanced investigations the agent stack can't handle on its own. Specialized roles like AI governance specialists, focused on regulatory compliance and internal audit of the AI systems themselves, and AI red teamers, focused on finding flaws through adversarial testing, are becoming distinct career tracks rather than side responsibilities bolted onto an existing security job.

Audit and compliance are moving in the same direction, just with different labels. The routine testing and checklist work is what gets automated first. What's left, and what's growing in value, is higher-order advisory and assurance work: helping the organization decide what AI governance should actually look like, not just confirming a checklist got completed.

Role-Specific Lens: What Each Function Should Actually Prioritize

Risk managers should focus on predictive risk models, response control agents, emerging exposures, faster scenario detection, and real-time monitoring rather than static, backward-looking risk registers. The shift from periodic review to continuous, risk-based monitoring is exactly what model risk research describes as the direction traditional frameworks need to move, since AI systems drift constantly rather than occasionally.

Compliance officers should focus on regulatory mapping, policy drift detection, and exception governance, treating regulatory change as a continuous input rather than an annual refresh cycle. Given how unpredictable AI-specific regulation is expected to stay, a compliance function that only reviews policy once a year is already behind by definition.

Auditors should focus on AI-enabled control testing, evidence reliability, and moving up into higher-value assurance work rather than routine transaction testing. The chief audit executive conversation happening right now, according to new audit committee guidance, is explicitly about how the internal audit function's talent strategy and skill sets need to evolve alongside the technology itself.

Cybersecurity experts should focus on AI-assisted defense, automated triage, and building resilient human oversight into every critical decision point, rather than trying to out-manual an attack surface that's now partly automated on the attacker's side too. Guidance on security management is explicit that human-in-the-loop controls for critical decisions are not optional in a mature AI security program.

Financial controllers should focus on automated close accuracy, reporting integrity, and approval chain controls, given that no binding standard yet tells them exactly how to govern this. That absence of a formal rulebook is not permission to wait. It's the reason controllers need to build their own internal governance now, ahead of whatever standard eventually arrives.

Sustainability experts should focus on data quality, ESG process integrity, and AI governance specifically inside reporting workflows, since the value of faster ESG reporting evaporates the moment a regulator or auditor finds a figure that can't be traced back to a reliable source.

Moves That Actually Build Career Resilience Across GRC Roles


Redesign roles around judgment, not task completion.
 

AI will keep absorbing routine review work. The durable skill is deciding what still needs a human, not doing every task yourself.

Build AI fluency by function, not generically. 

A generic AI training session teaches nobody anything they can use Monday morning. Risk managers, auditors, controllers, and sustainability teams each need role-specific use cases, controls, and prompts tied to their actual daily workflow.

Make control mapping a core, practiced skill. 

Every AI use case should map to a specific control, approval, piece of evidence, and named owner before it scales past a pilot. Professionals who can translate an AI use case into control language directly reduce operational and regulatory risk, which makes them structurally harder to replace.

Treat data quality as career capital, not a back-office chore. 

The people who can improve lineage, completeness, and governance are becoming the ones organizations can't function without, precisely because AI performance depends entirely on the data feeding it.

Learn to manage mixed human-AI workflows deliberately. 

The future isn't full automation. It's people validating, overriding, and coaching AI systems continuously. Knowing when to trust an output, when to challenge it, and how to document that decision is a skill you have to practice, not one that shows up automatically from using a tool daily.

Build a real specialization moat. 

Broad generalists are easier to automate than specialists who combine deep domain expertise with genuine AI oversight capability. Niches like AI risk, AI audit, AI governance, cyber AI defense, and AI-enabled ESG assurance are where the strongest career positions are opening up right now.

Track task-level exposure, not just headcount. 

If a role is losing routine tasks faster than it's gaining higher-value ones, that's a leading indicator, and leaders need to redeploy people into analysis, control, or advisory work before displacement turns into layoffs nobody saw coming.

Become the translator between the business and the AI. 

The professionals who can explain AI risk, AI value, and AI's actual limits in language executives and regulators understand are the ones who become genuinely difficult to replace, because that translation work connects a technology decision directly to accountability.

Push for internal AI champions inside every function. 

A local champion who tests tools, shares lessons, and surfaces risks quickly helps a team adopt AI safely, and gives individual employees a real path to grow into new responsibilities instead of getting overtaken by change decided somewhere else.

Tie AI adoption directly to workforce strategy. 

AI should never be treated as a separate technology program running alongside the workforce plan. Linking AI investment to reskilling, career paths, and role redesign from the start is what lets a workforce evolve with the tools instead of getting overtaken by them.

What This Actually Means for Your Next Twelve Months

None of this requires you to become a data scientist. It requires you to get specific about the same five questions in every AI-touched process you own: what is the metric, what is the threshold, who owns it, how often is it tested, and what happens when it's breached. If you can't answer all five for a control you claim to have, you don't have a control yet. You have a policy statement waiting to fail its first real test.

Start with one workflow you already own. Map where AI has entered it, name the control that used to catch problems there, and check whether that control actually survived the redesign or quietly disappeared along with the manual task it used to sit inside. That single exercise, repeated across a career instead of done once for a compliance checkbox, is the actual difference between a GRC professional AI displaces and one it makes indispensable.

If you're working through this shift in your own function and want to compare notes on what a real AI-specific control catalog looks like for your specific role, that's exactly the conversation worth having now, before the next audit cycle forces it. Subscribe below for the next piece in this series, where we build out the control catalog for each of these six functions line by line.

S/4HANA Role Redesign: Fix Segregation of Duties Before Go-Live or Pay the Audit Bill After

 

Why Privilege Creep Kills SAP Migrations Before the First Production Transaction Runs

Article 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 Thinkers360Your migration to SAP S/4HANA is six months out. The project team is focused on data migration, Fiori tile configuration, and cutover planning. Meanwhile, 847 user roles built across eight years of organizational changes, job transfers, emergency firefighter access, and M&A integrations are being lifted wholesale into the new system. Nobody has reviewed them. Nobody has mapped them against the new S/4HANA authorization model. And your external auditors are already asking for the SoD conflict report.

This is the standard failure mode. And it is expensive to fix after go-live.

Migrating unremediated ECC roles into S/4HANA production does not just inherit old access risk. It amplifies it. S/4HANA's simplified data model, new Fiori authorization objects, and transaction replacements create net-new SoD conflicts from role content that was previously clean.

This article gives you the technical remediation workflow to stop that from happening. It covers the SAP-native tools, the sequencing logic, the role design architecture that prevents re-accumulation, and the automated tooling that makes the process viable at enterprise scale.


Why S/4HANA Breaks Your Existing SoD Matrix

SAP S/4HANA fundamentally changes the authorization landscape. This is not an incremental upgrade. The SAP S/4HANA Simplification List documents thousands of transaction replacements, program removals, and process consolidations. Transactions you built roles around in ECC no longer exist, have merged into Business Partner (BP) transactions, or now trigger different authorization objects entirely.

The most visible examples: XD01 and XK01, the customer and vendor master maintenance transactions, are replaced by the SAP Business Partner transaction BP. Any role that controlled access through those old transactions now either fails to control the equivalent S/4HANA function or, worse, grants broader access than intended because the authorization check structure has changed.

SAP Community analysis of S/4HANA security landscape changes confirms that SoD matrices built for ECC become unreliable after conversion. The conflict rules reference transactions that no longer exist, miss new authorization objects introduced in S/4HANA, and fail to account for Fiori app authorizations that bypass the traditional transaction-based access model.

This is not a configuration problem. It is a design-time engineering problem.


What Privilege Creep Actually Looks Like at Migration Time

Privilege creep is the accumulation of access rights that users no longer need. It happens across three vectors in most enterprise SAP environments.

First, job transitions. When a user moves from accounts payable to controlling, they get new access. The old access rarely gets removed. After five years and three job changes, that user holds access spanning procurement, finance, and HR, a combination that violates SoD in ways no single access request ever triggered.

Second, project-based access. Implementation projects, year-end processes, and audit support cycles generate temporary elevated access. Firefighter IDs get reused. Temporary roles become permanent. Emergency access granted during a system outage in 2021 is still active in 2025.

Third, role sprawl. When role designers copy existing roles rather than build from a business capability model, each copy carries forward every transaction and authorization value from the original. Over years, roles accumulate dormant transactions that nobody uses but that still represent active access rights from a SoD perspective.

By the time an S/4HANA migration project starts, a mid-sized SAP environment typically carries hundreds of roles where 30 to 50 percent of assigned transactions have zero usage in the prior 12 months. 

Migrating roles with unused transactions into S/4HANA does not just carry old risk forward. In some cases, S/4HANA's new authorization objects cause those dormant role contents to map to broader access than they did in ECC. A transaction that was harmless in ECC may activate a wider authorization check in S/4HANA.


The SAP-Native Remediation Workflow: SU24, SUIM, and PFCG in Sequence

You do not need a third-party tool to start. SAP provides three native transactions that, used in the right sequence, give you a complete picture of your current access exposure before you touch a single production role.

Step 1: Use SUIM to Inventory Current Access

The SAP User Information System, transaction SUIM, is your starting point for understanding who has what access across the landscape. SUIM lets you query users by role, by authorization object, by transaction, and by combinations of those dimensions.

Run four reports at minimum before remediation begins. Pull all users with access to posting transactions (FB01, VF01, MIGO) combined with approval transactions in the same process area. Pull all users with access to sensitive BASIS transactions such as SU01, SU10, and SE16N. Pull all roles that include more than 150 active transactions, which is a strong indicator of over-provisioned design. And pull all user-role assignments where the last logon date is more than 90 days ago, which surfaces dormant accounts that should be disabled before migration.

SUIM does not tell you whether combinations are SoD violations. It tells you the raw access landscape. That data feeds your SoD analysis.

Step 2: Identify SoD Conflicts Against a Current Ruleset

Your SoD ruleset must reflect S/4HANA transactions, not ECC transactions. If you are using a GRC Access Control ruleset that was last updated during your ECC 6.0 implementation, it will miss conflicts introduced by S/4HANA's process changes. Update the ruleset first, then run the conflict analysis against the SUIM output.

SAP GRC Access Control provides the standard enterprise framework for this analysis. It maintains business process rule libraries, maps conflicting function pairs, and generates conflict reports by user, role, and profile. For organizations without GRC, the same analysis can be run manually using SUIM data cross-referenced against a documented SoD matrix, but at enterprise scale that is not a sustainable approach.

Research from Gutesman et al. on real-time SoD conflict detection establishes the theoretical basis for pre-runtime SoD checking: identifying violations before they are committed to production is significantly less costly than detecting and remediating them after user provisioning is complete. The same principle applies to migration projects.

Step 3: Correct Authorization Defaults in SU24

Before you rebuild roles in PFCG, fix the authorization defaults that PFCG uses as its source of truth.

Transaction SU24 maintains the default authorization objects and their proposed values for each transaction code and each Fiori application. When a role designer adds a transaction to a role in PFCG, PFCG reads SU24 to know which authorization objects to include and what default values to propose.

If SU24 defaults are incorrect, every role built from them inherits the error. In S/4HANA migrations, SU24 defaults for replaced or new transactions may not reflect your security requirements. Review SU24 for every transaction in scope, particularly for Fiori apps that were not present in your ECC system. Set proposal indicators correctly. Mark authorization objects that should always be checked. Remove defaults for authorization objects that your policy excludes.

This step is frequently skipped in migration projects under time pressure. That decision consistently produces roles where authorization checks are either missing or over-permissive, because PFCG built them from uncorrected defaults.

Step 4: Rebuild Roles in PFCG from Business Capabilities

Do not copy roles from ECC. Build them from business function definitions.

SAP's role maintenance transaction PFCG is where roles are constructed, maintained, and generated. A role built correctly in PFCG contains only the transactions and authorization objects required for a defined business function, with org-level values appropriate to the user population.

Use a three-layer architecture. Single roles contain the smallest functional unit, such as "Create Purchase Order." Composite roles bundle single roles into job profiles, such as "Procurement Clerk for Plant 1000." Derived roles replicate the design of a master role across different organizational units without duplicating the permission structure.

This architecture limits role count, simplifies audit reporting, and makes future modifications predictable. When a business function changes, you modify one single role, and the change propagates to every composite and derived role that references it.

Step 5: Validate and Test Before Cutover

After rebuilding roles, run the full SoD conflict analysis again against the new role set. Confirm that all high-priority conflicts identified in Step 2 are resolved. Then run authorization trace analysis, using SAP transaction ST01 or the authorization check framework documented in SAP's authorization evaluation documentation, to confirm that users can complete their required business processes without hitting authorization failures.

SAPinsider's analysis of go-live security sequencing makes the cost case clearly: remediating SoD conflicts before cutover costs a fraction of the effort required after production users are live and dependent on incorrect access. Post-go-live remediation also introduces operational risk, because correcting over-permissive access in production can break business processes that users have already built workarounds around.


When to Start the Role Work: A Sequencing Framework

The timing question is not primarily a technical decision. It is a resource and risk decision.

Before the S/4HANA Project Starts

For organizations with large, complex role landscapes, start role remediation before the S/4HANA project formally begins. This phase focuses on ECC cleanup: removing unused transactions, resolving existing SoD conflicts, standardizing role naming and structure, and establishing the governance model that will govern the S/4HANA design.

Starting early means the S/4HANA project inherits a cleaner baseline. It also means the project team can focus on S/4HANA-specific changes rather than simultaneously debugging both legacy role problems and new S/4HANA authorization requirements.

The main cost argument against early start is that some role work done in ECC will need to be redone when S/4HANA-specific transaction changes are applied. That is true. It is still cheaper than the alternative.

During the S/4HANA Project

Once the S/4HANA development system is available, apply the migration-specific changes. Map ECC transactions to their S/4HANA equivalents using the Simplification List. Add Fiori app authorizations. Test role content in the S/4HANA environment, because authorization behavior can differ from ECC even for transactions that exist in both systems.

This phase should address only S/4HANA-specific changes if the pre-project cleanup was done correctly. If it was not, this phase will be significantly more complex and will compete for time with every other workstream in the project.

After Go-Live

Post-go-live role work should cover edge cases, fine-tuning based on actual user behavior, and deferred items that were explicitly scoped out. It should not be the primary remediation phase. Organizations that defer SoD remediation until after go-live consistently face audit findings within the first annual review cycle.


The Non-Human Identity Problem in SAP Authorization

Role design discussions in SAP environments almost exclusively focus on human users. This is increasingly the wrong frame.

Modern SAP landscapes run significant automated workloads: interface users for middleware connections, batch users for background job execution, RFC users for system-to-system communication, and service accounts for cloud integration platforms. These non-human identities frequently hold broad authorizations granted during implementation and never reviewed since.

Research by Poreddy on non-human identity governance frameworks establishes that traditional role-based access control and HR-driven lifecycle models are structurally inadequate for managing machine identities. These accounts do not have managers who receive access review requests. They do not appear in HR offboarding workflows. They accumulate permissions across system upgrades without anyone noticing.

In S/4HANA migration projects, interface and batch accounts are typically migrated without review because the migration team is focused on human user profiles. Those accounts then exist in production with ECC-era authorizations that may map to broader S/4HANA access than was intended.

A batch user account with S_TABU_DIS access to table maintenance in ECC may, in S/4HANA, gain access to new configuration tables that did not exist in the source system. The authorization object and its values are identical. The scope of access has expanded.

The remediation approach for non-human identities follows the same SUIM-SU24-PFCG sequence used for human users, with one addition: every non-human identity should have a documented owner, a defined technical purpose, and a review cycle independent of HR processes. That governance structure is absent in most SAP environments today.


Automated Role Design: Where Authorization Architect Fits

At enterprise scale, manual role redesign is not a viable path. A large SAP environment with 2,000 or more roles, multiple system landscapes, and a six-month migration timeline needs tooling that automates the mechanical steps while maintaining human control over design decisions.

Transaction Usage Analysis as the Design Evidence Base

Authorization Architect uses Transaction Archive tool to analyze actual SAP execution history across the landscape. The recommended observation window is 13 months, long enough to capture a full annual business cycle plus overlap for month-to-month variation. This matters because role cleanup based on shorter windows risks removing access that is genuinely needed but only exercised during annual processes such as year-end close or tax reporting.

The analysis outputs a fact-based view of which transactions in each role are actually used, which are dormant, and which appear only in role definitions but have never generated an authorization check in production. This replaces assumption-based role cleanup with evidence-based redesign.

Performance: the Transaction Archive analysis typically completes in under two minutes for standard role sets, often in seconds. Present this as an operational benchmark for interactive review sessions, not as a contracted service-level commitment.


Authorization architect user dashboard

SoD Screening Before Role Creation

Authorization Architect runs SoD analysis against the proposed role design before the role is built, not after it is assigned to users. This is the architecturally correct sequence. Detecting a conflict in a role proposal costs nothing. Detecting the same conflict in a production role assigned to 200 users costs weeks of remediation effort.

The SoD check uses a functionality against either the client's existing ruleset or the default library. It covers sensitive transaction checks as well as function-pair conflicts. The result is visible to role designers before they submit the role for approval.

Basin et al.'s foundational work on dynamic enforcement of separation of duty constraints established that workflow-independent SoD policy enforcement, applied at design time rather than runtime, provides the most effective compliance architecture. Authorization Architect's pre-creation SoD check applies this principle directly to SAP role engineering.

Workflow Approvals Embedded in the Role Build Process

Authorization Architect routes role proposals through a structured approval workflow. Role operators create proposals and submit them for review. Role owners, the business stakeholders responsible for role content, receive pre-populated approval requests showing the proposed transactions, org levels, and SoD analysis results. Role approvers authorize composite roles for production deployment.

This three-tier structure, operators, owners, approvers, enforces the separation of design and approval duties that most SAP security governance frameworks require but few organizations actually enforce technically.

Automated Role Build Beyond SU24 Recommendations

When a role proposal clears the approval workflow, Authorization Architect builds the role automatically. This includes naming and description, role long text, structured role menu, org level definitions, and the full authorization object set. It generates master and derived role pairs and creates standalone maintain, display, and composite job roles as appropriate for the design.

The automation goes beyond what SU24 recommends. It applies the organization's naming standards, incorporates the corrected SU24 defaults from the remediation workflow, and produces consistent role content regardless of which team member runs the build. That consistency is critical for audit purposes and for future maintenance.

Migration Provisioning for S/4HANA Transaction Replacements

For migrations specifically, Authorization Architect's Migration Provisioning feature maps ECC transactions in existing roles to their S/4HANA equivalents using the Simplification List. Where a transaction no longer exists in S/4HANA, the tool suggests the replacement. Where a transaction remains, it flags it for testing confirmation.

This is the systematic approach to the XD01-to-BP and XK01-to-BP problem described earlier. Instead of manually tracing each transaction through the Simplification List, the tool processes the full role inventory and produces a remediation plan showing every impacted transaction and its proposed resolution.


Authorization Governance After Go-Live: Sustaining What You Built

Role redesign before go-live solves the migration problem. It does not solve the ongoing governance problem.

Access accumulates again after go-live. New projects generate emergency access. Organizational changes produce new provisioning requests. Integrations add non-human identities without formal review. Within 18 to 24 months of a well-executed migration, many organizations are back to a state of meaningful privilege creep if they have not built the governance infrastructure to prevent it.

Bhatia's research on AI-driven compliance architecture in S/4HANA transformations identifies continuous surveillance and dynamic regulatory data feeds as the structural components that prevent post-go-live compliance drift. The point is sound: compliance-by-design at migration time creates the clean baseline, but sustaining it requires automated monitoring that catches new violations before they accumulate into systemic risk.

The practical controls to build into your post-go-live governance model are direct:

Connect provisioning workflows to HR triggers. Every hire, job change, and termination should automatically generate an access review or modification request. Access that does not get reviewed on a triggered basis will not get reviewed.

Run quarterly access reviews for critical roles and high-risk users, not annual reviews. Annual reviews are too slow to catch the accumulation patterns that create material audit exposure.

Use transaction usage data from the production system, the same data that Authorization Architect analyzes at design time, as your ongoing evidence base for access review decisions. Roles with significant unused transaction populations after six months of production operation should be flagged for cleanup.

Set automated deprovisioning rules for dormant accounts. Accounts that have not logged in for 90 days should be flagged. Accounts inactive for 180 days should be disabled, pending review.

Treat non-human identity governance as a separate program, not a subset of human user access management. Document every interface user, batch user, and RFC user with an owner, a technical purpose, and a review schedule. Review those accounts on the same quarterly cycle used for privileged human users.


A Concrete Example

Procurement SoD Remediation Before Cutover

A North American manufacturing company with 4,200 SAP users and 1,800 roles began its S/4HANA migration with a SUIM-based access inventory. The analysis identified 23 users in the procurement organization who held simultaneous access to purchase requisition creation (ME51N), purchase order approval (ME29N), and goods receipt posting (MIGO). All three functions in one user profile is a textbook SoD violation covering the full procure-to-pay cycle without any compensating control.

Further analysis showed that 14 of the 23 users had accumulated this combination over time through separate access requests, each individually approved, none evaluated against the combined access picture. The remaining 9 held roles that had been copied from a prior template without SoD review.

The remediation sequence: SUIM identified the population. SoD analysis confirmed the conflict severity. Role redesign in PFCG split the three functions into separate single roles, assigned to different user populations with clear functional separation. Authorization Architect ran SoD screening against each redesigned role before build. The three composite roles were approved through the workflow process and built automatically.

Total elapsed time from analysis to production-ready roles: four weeks. The same remediation started post-go-live, with 4,200 live users dependent on their current access, would have required business sign-off on access removal for active users, parallel testing to prevent process disruption, and a change management effort to explain why users were losing access they had held for years. The post-go-live version of the same work typically takes three to five months.


Key Failure Modes to Avoid

Copying ECC roles into S/4HANA without transaction mapping. Copied roles carry every legacy transaction, including those that no longer exist or have changed authorization behavior. This produces both access gaps (missing S/4HANA functions) and access excess (dormant ECC transactions that now trigger different authorization checks).

Running SoD analysis after user provisioning, not before role creation. Post-provisioning SoD analysis identifies conflicts but requires user-level remediation, which is operationally disruptive and business-politically difficult. Pre-creation SoD analysis stops conflicts from entering the design.

Treating non-human identities as out of scope for migration role review. Interface, batch, and RFC users carry real access risk. Their authorizations should be reviewed against the S/4HANA authorization model with the same rigor applied to human user roles.

Deferring SoD remediation to post-go-live. The cost differential between pre-go-live and post-go-live remediation is not linear. Post-go-live remediation competes with operational support, requires business process testing to avoid disruption, and generates audit findings in the first review cycle if not completed quickly.

Using Authorization Architect as a role-copy factory. Automated role build accelerates execution. It does not replace design judgment. Automation run against an uncorrected business function model or a flawed SoD ruleset produces wrong roles faster.


What to Do Next

If your S/4HANA project is in planning, start the SUIM inventory now. Pull the four reports described in Step 1 of the remediation workflow. That data will tell you the scope of your remediation problem before the project schedule is locked and the role work gets compressed into the final two months before cutover.

If your project is already underway, the same analysis applies with more urgency. Get SUIM data, run SoD conflict analysis against a current ruleset, and prioritize the highest-severity conflicts for resolution before the transport to production.

If you have already gone live and the role work was deferred, build the quarterly review cadence and the non-human identity inventory program now. The clean-up will take longer than pre-go-live remediation would have. Starting immediately limits the accumulation.

The technical workflow is not complicated. The governance discipline required to execute it consistently, across teams, landscapes, and project timelines, is where most organizations struggle. That discipline starts with a clear decision that SoD is a design-time engineering responsibility, not a post-go-live audit finding.


Subscribe to Continue This Work

This publication covers SAP authorization engineering, identity governance, and the technical architecture of secure enterprise systems. Future articles will go deeper on Fiori authorization design, SAP GRC Access Control ruleset maintenance, and non-human identity governance frameworks for cloud-integrated SAP landscapes.

If you are building or fixing authorization governance in an SAP environment, subscribe now so these articles reach you directly. No generalist technology news, no vendor marketing. Just the technical depth that the people actually doing this work need.

SR 26-2 Is Here: The 2026 Model Risk Guidance That Finally Gives Validators Teeth

Article 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


On April 17, 2026, the Federal Reserve, the FDIC, and the OCC (collectively, "the agencies") issued SR Letter 26-2, which replaces prior model risk management guidance, the SR 11-7 issued in 2011. This update refines supervisory expectations regarding how banking organizations should calibrate their model risk management frameworks. The guidance is most directly applicable to institutions with total assets exceeding $30 billion, though smaller institutions with complex modeling activities are advised to consider its principles.



Scope and Applicability

The guidance formally excludes simple arithmetic calculations, deterministic rule-based processes, and notably, generative artificial intelligence and agentic artificial intelligence models from the definition of a model. However, the agencies explicitly state that traditional statistical, quantitative, and non-generative artificial intelligence models remain within scope. The primary audience is organizations with over $30 billion in assets, reflecting a tailored supervisory approach that recognizes the lower inherent risk profiles of most community banking institutions.

What Is Covered and What Is Not

SR 26-2 draws a clean line between two categories of artificial intelligence. On one side, traditional statistical models and non-generative, non-agentic AI models are fully within scope. This includes logistic regression for credit scoring, random forests for fraud detection, gradient boosting for loss forecasting, and any probabilistic model that applies statistical, economic, or financial theories to produce quantitative estimates. On the other side, generative AI such as ChatGPT-style models and agentic AI that makes autonomous decisions are explicitly excluded from the guidance. 

The agencies state these technologies are novel and rapidly evolving, so they are not covered here. Simple spreadsheet arithmetic and deterministic rule-based processes with no statistical underpinning are also excluded. For practitioners, this means the bank existing credit risk, market risk, and stress testing models remain subject to the full model risk management framework, while the internal productivity chatbots do not.

How to Treat Probabilistic and AI Models in Practice

For probabilistic models and non-generative AI, the guidance applies the same materiality-based framework as any other quantitative model. U.S. banks under scope must assess each model using two dimensions: exposure (portfolio size and financial impact) and purpose (regulatory significance or critical risk decisions). A machine learning fraud detection model affecting $50 million in transactions may require less rigor than a smaller logistic regression model used for regulatory capital calculations, if the latter serves a more critical purpose. The key operational change is that validators of AI models must now have organizational standing to effect change, not just technical expertise. 

For probabilistic models with inherent uncertainty, banks must document assumptions explicitly and monitor performance drift continuously, not annually. Vendor-supplied AI models receive no lighter treatment; proprietary black-box constraints do not excuse banks from validating conceptual soundness. If a vendor will not provide transparency into model design, development data, or assumptions, banks must either conduct independent back-testing using the internal own data or limit the model to immaterial use cases.

Main Changes and Technical Nuances

The most significant departure from prior guidance is the formal introduction of a materiality-driven framework. Rather than applying uniform rigor to all models, the agencies now require banking organizations to evaluate model risk through two distinct lenses:

  1. Model Exposure: The quantitative significance of a model's output to business decisions, typically measured by portfolio size or financial impact.

  2. Model Purpose: A qualitative assessment of whether the model supports regulatory requirements or manages critical financial risk exposures.

The interaction of exposure and purpose determines model materiality, which then dictates the depth of validation, monitoring, and governance required. Immaterial models require only identification and periodic monitoring for changes in conditions that could elevate their status. Conversely, higher materiality models warrant comprehensive and rigorous oversight throughout the lifecycle.

The guidance also introduces a more explicit expectation regarding aggregate model risk. Institutions must assess risk not only at the individual model level but also across portfolios of models. This includes evaluating dependencies, common assumptions, shared data sources, and correlated methodologies that could cause simultaneous failures. A single point of weakness in a shared data pipeline, for example, could manifest as aggregate risk across multiple high-stakes models.

Effective Challenge and Independence

The agencies reinforce the concept of effective challenge as a non-negotiable component of sound governance. Effective challenge is defined as critical analysis performed by objective experts who possess the technical competence to evaluate model risk, sufficient independence to maintain objectivity, and the organizational standing to compel changes. This elevates the requirement beyond mere peer review to a governance mechanism with teeth. Validation functions must be structured to avoid conflicts of interest, particularly misalignment of incentives between model development and validation reporting lines.



Vendor and Third-Party Products

A critical clarification addresses vendor and third-party models. The guidance states that the use of proprietary products, including those where underlying code or methodology is inaccessible, does not diminish the banking organization's risk management responsibilities. Validation of vendor models must include an assessment of conceptual soundness, design, development data, and ongoing performance. Customizations made to vendor models for specific business needs must be documented, justified, and evaluated as part of validation. The inability to inspect proprietary elements is not an acceptable basis for reducing validation rigor.

Model Development, Validation, and Monitoring

The guidance formalizes three components of validation:

  • Conceptual Soundness: Assessing model design, assumptions, qualitative judgments, and data selection.

  • Outcomes Analysis: Comparing model outputs to real-world results, including back-testing and outlier analysis.

  • Ongoing Monitoring: Evaluating performance against changing products, exposures, data relevance, and market conditions.

Notably, the guidance permits limited circumstances where a model may be used prior to completion of validation, such as an urgent business need. In such cases, the institution must apply heightened attention to model limitations, inform relevant stakeholders, and implement compensating controls including usage limits and closer performance monitoring.

Governance and Documentation

The agencies expect a comprehensive model inventory that supports risk management at both individual and aggregate levels. Documentation must be adequate to ensure continuity of operations, track recommendations and exceptions, and support remediation efforts. Internal audit functions are expected to evaluate the effectiveness of model risk management practices rather than duplicate validation activities.

Enforceability Context

While the guidance explicitly states that non-compliance will not result in supervisory criticism standing alone, the agencies preserve their authority to take action for any violations of law or unsafe or unsound practices stemming from insufficient management of model risk. Practically, this means the guidance defines the supervisory baseline. Deviations from its principles will be cited as evidence of inadequate risk management in the event of a model failure or material loss.

Implications for GRC Professionals

The 2026 guidance signals a maturation of model risk management from a technical validation exercise to an integrated governance discipline. GRC professionals should prioritize three actions: first, implementing a tiered inventory that clearly distinguishes material from immaterial models; second, assessing aggregate risk across model portfolios, particularly where shared assumptions or data sources exist; and third, reviewing vendor management agreements to ensure that contractual terms do not impede the validation and ongoing monitoring required by the agencies. The exclusion of generative and agentic artificial intelligence is temporary; the principles articulated in this guidance will likely inform future supervisory expectations as those technologies evolve.



Critical Implications of the Revised Model Risk Management Guidance (SR 26-2)


Four Critical Changes for Risk Managers


1. Redesign Model Tiering Using Dual-Axis Materiality Assessment

Risk managers must now classify all AI predictive models using both exposure (quantitative portfolio impact) and purpose (qualitative regulatory or risk significance), replacing single-dimension risk ratings. This materiality-based framework means a fraud detection AI model affecting $50M in transactions may warrant less rigor than a $10M credit decisioning model if the latter supports regulatory capital calculations. Organizations must rebuild model inventories to document both dimensions, as immaterial models by exposure may still be material by purpose. The tiering directly determines validation depth, monitoring frequency, and governance escalation pathways for each AI risk model.

2. Establish Effective Challenge with Organizational Authority

Validators of AI predictive models must now possess not only technical expertise but demonstrable organizational standing and influence to effect change, moving beyond advisory roles. Risk managers must restructure validation teams to ensure challengers can delay model deployment, escalate concerns to executive committees, and mandate remediation with teeth. This represents a fundamental shift from validation as documentation exercise to validation as governance gate, particularly critical for complex AI models where technical reviewers previously lacked business authority. Second-line model risk functions must now be empowered to override first-line deployment timelines when AI model risks are inadequately addressed.

3. Implement Rigorous Vendor Risk Model Governance

Third-party AI models for credit scoring, fraud detection, or risk forecasting no longer receive lighter treatment despite proprietary limitations, requiring the same conceptual soundness validation as internal models. Risk managers must negotiate with vendors for sufficient transparency into model design, development data, assumptions, and performance metrics to conduct meaningful validation, even when source code is unavailable. Ongoing monitoring and outcomes analysis are now explicitly required for vendor AI models, including documentation of any overlays or adjustments made to customize outputs. Where vendors cannot provide adequate validation evidence, risk managers must either conduct independent testing using the bank's own data or limit the model's application to lower-materiality use cases.

4. Deploy Continuous Model Monitoring Infrastructure

Ongoing monitoring is elevated from periodic review to continuous evaluation, requiring risk managers to implement real-time performance tracking for material AI predictive models across changing data distributions and market conditions. Monitoring frameworks must now explicitly assess whether AI models remain fit-for-purpose as products, client bases, or economic environments shift, with predefined thresholds triggering recalibration or redevelopment. Risk managers must establish outcomes analysis comparing AI model predictions to actual results (back-testing) as a standard validation component, not an optional add-on, particularly for models relying on expert judgment or alternative data. The guidance mandates documentation of model deterioration triggers and response procedures, forcing proactive governance rather than reactive remediation when AI risk models fail.

Priority Actions for SR 26-2 Compliance

1. Materiality Triage

Large U.S. banks should redesign model inventories around purpose and exposure, not a single generic risk score. The guidance is explicit that model materiality depends on the business importance of the use case and the significance of the output to decisions, including regulatory and financial risk use. For predictive AI models, credit loss, fraud, liquidity, and capital-related use cases should be tiered above internal analytics or convenience models. Common practice still overweights model complexity and underweights business consequence; that should be corrected.

2. Challenge Authority

Banks should formalize effective challenge as a control with authority, not as a review function. The guidance requires challengers to have sufficient expertise, independence, organizational standing, and influence to effect change throughout the model lifecycle. That means validation functions need documented rights to delay launch, require remediation, and escalate unresolved issues to executive governance forums. Common advice tends to treat validation as commentary; that is not defensible under this guidance.

3. Continuous Monitoring

Scoped banks should move material predictive AI models to ongoing monitoring with explicit deterioration triggers. The guidance requires monitoring for changes in products, exposures, activities, clients, data relevance, and market conditions, and it states that material deterioration may warrant overlays, adjustment, or redevelopment. Monitoring should therefore include pre-defined thresholds for drift, performance decay, and segmentation instability, not just periodic reporting. Common practice often relies on quarterly review cycles; that is too slow for models embedded in live decisioning flows.

4. Third-Party Validation

Banks should validate vendor and other third-party predictive models to the same conceptual standard applied to internally developed models. The guidance states that proprietary constraints do not remove the need to understand design, development data, assumptions, and performance. Where source code is unavailable, banks need compensating controls such as benchmarking, documented customization review, independent testing, and ongoing outcomes analysis. Common advice often treats SOC reports or vendor attestations as sufficient coverage; they are not.

5. Use Expansion Gate

Banks should treat any extension of model use as a new risk event requiring formal review. The guidance states that using a model beyond its intended purpose introduces additional uncertainty and requires additional analysis of limitations and controls. That means a predictive model approved for one portfolio, channel, or decision layer should not be repurposed without re-validation and governance sign-off. Common practice often extends models through informal business requests; that is a control weakness, not agility.

6. Aggregate Risk Map

The banks under scope should maintain a live inventory that maps individual and aggregate model risk, including shared data, assumptions, and dependencies. The guidance specifically calls out aggregate risk arising from interactions among models and from common methodologies or inputs that can fail simultaneously. For predictive AI models, that inventory should also identify upstream data feeds, shared calibration logic, and correlated override points. Common advice tends to validate models in isolation; that misses the concentration risk the guidance now makes explicit.



About the Author:

Hernan Huwyler is a risk and compliance executive who advises financial institutions on model risk management, AI governance, and control frameworks. He has led validation functions for global banks and regularly writes on the intersection of quantitative risk and regulatory compliance.

#ModelRiskManagement, #SR262, #SR117, #ModelValidation, #EffectiveChallenge, #AIModels, #RiskGovernance, #ModelRisk, #VendorRiskManagement, #FinancialRegulation, #FederalReserve, #FDIC, #OCC, #GRC, #Compliance, #RiskManagement, #AIGovernance, #ModelMateriality, #SecondLineOfDefense, #BankingRegulation


How to Stop Producing Risk Registers Nobody Uses

Article 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

The Painful Gap Between Risk Reporting and Risk-Informed Decisions

Most 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.


Core Framework: The Three Pillars of Decision-Driven ERM

Effective ERM that actually changes decisions rests on three pillars. Each one addresses a different failure mode I've seen repeatedly in organizations that mistake activity for impact.


Pillar 1: Risk-Informed Performance Management

ERM must live inside the performance management system, not alongside it. This means every major risk links to at least one strategic objective and KPI. When risk shows up in performance reviews and operating rhythms, people pay attention. When it lives in a separate portal, they don't.

The most common failure here is creating the linkage on paper but not in practice. I worked with one organization that mapped all 35 risks to strategic objectives in their GRC platform. Beautiful mapping. But the quarterly business reviews still used a completely separate slide deck with no risk content. The fix was simple but politically difficult: we added a mandatory "risk and assumption" section to the existing QBR template and made the business unit head (not the risk team) responsible for completing it. Adoption jumped from near zero to 80% within two quarters because the accountability sat with the person who owned the performance conversation.


Pillar 2: Risk Analysis Embedded in Decision Workflows

Every significant decision, from capital expenditure approvals to vendor selections to product launches, must include explicit risk reasoning. Not a generic "risk section" pasted at the end of a business case. A structured analysis of key assumptions, downside scenarios, and alignment with risk appetite.


o not try to retrofit risk analysis into existing decision workflows by adding a new form or approval gate. That creates resentment and checkbox behavior. Instead, redesign the decision paper template itself. Add three mandatory questions directly into the body of the document: "What are the top three assumptions this recommendation depends on?" "What happens if each assumption is wrong?" "How does this fit within our stated risk appetite?" When these questions sit inside the template that decision-makers already complete, risk thinking becomes part of the work rather than extra work.


Pillar 3: Distributions Replace Point Estimates

Organizations addicted to single "best guess" numbers make systematically overconfident decisions. Fighting this addiction requires replacing point estimates with ranges, scenarios, and probability distributions for all material assumptions.

Do not try to convert every number in your organization to a distribution. Start by identifying "high-leverage assumptions," the five or six variables that most affect NPV, margin, schedule, or safety in your biggest decisions. Convert those to three-point estimates (minimum, most likely, maximum) first. I made the mistake early in my career of trying to build full stochastic models for everything. The result was analysis paralysis and skepticism from leadership. Starting with just the high-leverage variables keeps the effort manageable and produces results that are visually obvious to executives who have never seen a tornado chart before.


Stage 1: Reframe ERM and Align It to the Business Cycle

The first implementation stage kills the annual risk assessment ritual and replaces it with a rolling cadence tied to how the business actually operates.

Map your organization's existing planning calendar: budgeting cycle, strategy refresh, product roadmap reviews, capital planning windows. Then attach risk input as a standard step in each of those existing processes. Risk analysis during budgeting means budget assumptions get challenged. Risk analysis during strategy refresh means strategic bets get stress-tested. Risk analysis during product roadmap reviews means launch decisions include downside scenarios.


The responsible party for each touchpoint is the business owner, not the risk function. The risk function sets the method, provides tools, and samples for quality. But the business leader presents the risk view alongside the performance view. This matters because risk ownership that sits with a central function creates a dynamic where business leaders treat risk as "someone else's job."

What to do: Collapse your risk inventory from whatever unwieldy number it has grown to (I've seen 200+) down to 10 to 20 enterprise-level risks with clear aggregation logic. Local risks roll up into enterprise themes. The board sees 15 risks, not 150. Business units manage their local registers, but reporting flows upward through defined aggregation rules.

The hardest part of this stage is getting the CEO and CFO to agree that risk content belongs in existing performance forums rather than in separate risk committee meetings. I've found the most effective argument is financial: show them a past decision where a single-point estimate led to a materially different outcome than what a range-based analysis would have predicted. One concrete example of a budget miss or project overrun that was foreseeable with basic scenario analysis does more to shift executive behavior than any amount of framework documentation. Find that example in your own organization's recent history. It exists. I guarantee it.


Stage 2: Build Risk Analysis Into Decision Templates and Workflows

This stage addresses the specific mechanics of getting risk reasoning into the documents and approval processes that govern major decisions.

Start by mapping every "decision point" where risk analysis should be mandatory. Board approvals. Capital investments above a defined threshold. Acquisitions. Large contracts. Major technology choices. Key product or market entry decisions. For each type, define a minimum level of analysis. Small decisions get a short qualitative checklist. Large, irreversible, or high-uncertainty bets get full quantitative modeling.


For every significant contract, investment, or vendor choice, attach a one to two page mini risk assessment. The template should cover: objectives, key assumptions, top five risks with likelihood and impact ratings, existing controls, residual risk rating, and proposed mitigations. This format works because it's short enough to complete in an hour but structured enough to surface real issues.


Standardize quick techniques for smaller assessments: what-if questions, simple decision trees, bow-tie diagrams, or 5x5 matrices. Reserve deeper tools like FMEA, HAZOP, or fault-tree analysis for complex technical or safety-critical decisions. Set clear thresholds (contract value, strategic impact, irreversibility, public or ESG exposure) that trigger the more advanced assessment. This way your organization runs dozens of mini-assessments per month with sensible prioritization, not bureaucratic uniformity.

Require that any recommendation comparing Option A to Option B includes risk-adjusted reasoning. Not just base-case numbers. The proposal must show what happens to each option under stress. Which option breaks first? Which option has a wider range of possible outcomes? This single requirement forces genuine analytical thinking and prevents the common dysfunction where the "highest NPV" option wins by default even when its returns depend on a single fragile assumption.

Watch out for "fake risk-based" methods. I've audited vendor and contract risk methodologies across multiple organizations and found that many rely on uncalibrated scoring, arbitrary matrices, or vague checklists that produce a number but do not actually improve the decision. The test is simple: can you show me a specific instance where this risk methodology changed the selection of a vendor, the structure of a contract, or the design of a project? If the answer requires more than 30 seconds of thought, the methodology is theater. Replace it with structured identification, explicit assumptions, harmonized scales, and wherever possible, quantification tied to financial or operational impacts.

Stage 3: Replace Point Estimates With Ranges and Simulations

This is where decision-driven ERM gets quantitatively serious. Most organizations plan using single numbers for exchange rates, commodity prices, demand volumes, system uptime, and dozens of other variables. Every experienced professional knows these numbers are wrong. But the organization plans as if they're certain, then acts surprised when reality differs.

For key drivers, require ranges or probability distributions instead of single numbers. Start with three-point estimates (minimum, most likely, maximum) because they're intuitive and fit into existing spreadsheet workflows. Show P10, P50, and P90 outcomes next to the traditional single case. Standardize a small set of "risk views" for every major item: base case, conservative (P80 to P90), aggressive (P20), and stress case. Make approval documents reference which profile management is accepting.

For large projects, site selections, portfolio decisions, and annual budgets, run Monte Carlo simulations on the combined distributions of key assumptions. Report results in terms executives can act on: probability of loss, probability of meeting budget or schedule, value at specific percentiles, and which variables contribute most to variance. Tornado charts that show "FX drives 40% of your outcome variance" focus mitigation efforts far better than a color-coded heat map ever could.

Build simple internal libraries of typical distributions for recurring drivers. FX volatility ranges. Load factor distributions. Failure rate curves. Price curve bands. When teams can reuse validated assumptions instead of inventing numbers from scratch, the quality of analysis goes up and the time required goes down. I spent months building these libraries at one organization and it cut the time to produce a quantified risk view from two weeks to three days.

The cultural shift matters more than the technical one. I watched a capital allocation committee change their decision after seeing simulation output for the first time. The "highest NPV" option had a 35% probability of delivering negative returns once you modeled realistic input ranges. The second-ranked option had lower expected returns but only a 12% probability of loss. They chose robustness over optimism. That single moment did more to establish the credibility of quantitative risk analysis than two years of framework presentations. Find your version of that moment. Run the simulation on a decision that's already been made and show leadership what they would have seen if they'd had this view at the time. The reaction will tell you whether your organization is ready.

Stage 4: Governance, Ownership, and Culture Infrastructure

Without accountability structures, everything in the previous three stages degrades within 12 months. I've seen it happen. An organization builds beautiful decision templates, runs impressive simulations, and then slowly reverts to old habits because nobody's performance goals include risk-adjusted outcomes.

Define risk ownership at the level of specific "risk objects": products, processes, portfolios, or business units. Each risk object gets a named owner. That owner's performance goals explicitly include risk-adjusted outcomes. Not just revenue. Not just volume. This connects risk management to compensation and career progression, which is the only reliable driver of sustained behavior change.

Run short monthly "risk clinics" with each business unit. These replace the annual committee meeting that tries to cover everything and covers nothing well. In a 60-minute clinic, review changes in the unit's risk profile, challenge key assumptions, and adjust plans. The risk function facilitates. The business unit leads. Keep the format consistent: what changed since last month, what are the top three risks to this quarter's objectives, what decisions are coming up that need risk input.

Build an explicit expectation that major decisions (capex approvals, acquisitions, product launches, outsourcing) must reference key risks and mitigations from the ERM system. Treat the absence of this reference as a process failure. Not a documentation gap. A process failure that gets flagged in the same way a missing financial approval would get flagged. This is a governance design choice that signals organizational seriousness.

The single most common dysfunction I see in ERM governance is the "risk owner in name only" pattern. Someone's name appears next to a risk on the register, but their actual performance review, bonus criteria, and promotion case make zero reference to how they managed that risk. The fix requires executive sponsorship from the CEO or CFO to mandate that risk-adjusted KPIs appear in performance scorecards for anyone who owns a top-20 enterprise risk. Without this, risk ownership is decorative. I failed to get this done at one organization because I tried to push it through the risk committee instead of the compensation committee. The lesson: risk ownership is a people and incentives problem, not a risk framework problem.


 Implementation Tips

These four tips apply across all stages and address the patterns that most commonly cause decision-driven ERM programs to stall or revert.

Tip 1: Maintain Method Integrity Over Time

Original implementation tip: ERM methods degrade naturally. Templates get shortened. Simulation steps get skipped when deadlines are tight. Scoring scales drift as new people join and interpret criteria differently. Schedule a semi-annual "method health check" where the risk function reviews a sample of recent decision papers, mini-assessments, and simulation outputs against the defined standards. Flag deviations. Retrain where needed. Publish a short "quality scorecard" that shows which business units are maintaining standards and which are slipping. Transparency creates peer pressure that formal compliance never matches.

Tip 2: Handle the "Risk Champion" Role Carefully

Original implementation tip: Many organizations appoint "risk champions" in each business unit to act as liaisons with the central risk function. This works when champions have genuine credibility and seniority in their unit. It fails when the role gets assigned to the most junior person available or treated as administrative overhead. Require that risk champions hold a position at least one level below the unit head. Give them explicit time allocation (minimum 10% of their role). Include champion effectiveness as a factor in their performance review. I've seen champion networks transform ERM adoption when they're staffed with respected operators. I've seen them become an excuse for everyone else to ignore risk when they're staffed with interns.

Tip 3: Document Decision Rationale, Not Just Decision Outcomes

Original implementation tip: Create a simple "decision record" template that captures: the options considered, the risk analysis for each option, the trade-offs discussed, the risk appetite alignment, and the rationale for the final choice. Store these records in a searchable repository. Review a sample annually to check whether risk information was captured, how it influenced the choice, and how outcomes compared to expectations. This feedback loop is where organizational learning happens. Most organizations skip it entirely. The ones that do it consistently develop a pattern-recognition capability that makes future decisions measurably better. One organization I worked with found that 60% of project overruns in a three-year sample traced back to the same two assumption categories that were consistently treated as deterministic when they should have been modeled as ranges.

Tip 4: Be Skeptical of Dashboard-First GRC Platforms

Original implementation tip: Before committing to any ERM or GRC platform, ask the vendor one question: "Show me three examples where your platform's output changed an actual decision at a client organization." If they can only show you dashboards, taxonomies, and workflow automations, proceed with extreme caution. The best platforms provide centralized risk repositories, standardized taxonomies, automated data feeds from incidents and audit findings, scenario analytics, and integration with the BI tools and project portfolio systems your leaders already use daily. The worst platforms produce beautiful screens that no decision-maker ever opens. Run a pilot focused on one specific decision type before scaling. Measure whether the pilot improves option selection or outcome quality, not just reporting speed.

Key References

The following standards and frameworks provide authoritative guidance for building decision-driven ERM programs:


ISO 31000:2018, Risk Management Guidelines, provides the foundational principles and process for integrating risk management into organizational governance and decision-making

COSO ERM Framework (2017), Enterprise Risk Management: Integrating with Strategy and Performance, directly addresses the linkage between risk management and strategic planning

IEC 31010:2019, Risk Assessment Techniques, catalogs and guides the selection of specific risk assessment methods (Monte Carlo, FMEA, bow-tie, fault tree, and others) matched to decision context

ISO 31022:2020, Guidelines for the Management of Legal Risk, extends risk management principles to legal and contractual decision-making

NIST Risk Management Framework (SP 800-37), while focused on information systems, provides a strong model for embedding risk analysis into system acquisition and authorization decisions

The Orange Book (HM Treasury, UK), Managing Public Money risk guidance, offers practical templates for integrating risk analysis into investment and spending decisions

IIA Three Lines Model (2020), provides the governance structure for separating risk ownership, risk oversight, and independent assurance

Closing

When ERM stays a compliance artifact, it consumes budget, absorbs staff time, and produces documents that create an illusion of control. Decisions continue to rely on single-point estimates, gut feel, and the loudest voice in the room. The risk register gets updated annually, presented quarterly, and referenced never. The organization pays the full cost of risk management and receives almost none of the benefit.

When ERM operates as a living decision system, every major choice carries an explicit view of uncertainty, a structured comparison of options under stress, and a clear statement of which risks leadership is consciously accepting. The risk register becomes a hub connected to controls, incidents, KPIs, and projects. Simulations replace single guesses. Performance conversations shift from "you missed the number" to "where did we land in the distribution, and what did we learn?" The difference between these two states determines whether your organization manages risk or merely documents it.

What's one major decision your organization made in the last year that would look completely different if someone had modeled the downside honestly?