AI Agent Segregation of Duties Guide for GRC and SOX Compliance

 

Finance leaders are under constant pressure to cut costs, and automation is the fastest lever available. IT teams are asked to hand AI agents more autonomy every quarter, and in many workflows that autonomy now stretches across the full transaction lifecycle: an agent reads customer or financial data, produces a recommendation, approves it, executes the action through an API, and writes the log entry that documents what happened.

No serious organization would hand a single employee that combination of powers without a control wrapped around every step. Yet that is precisely the architecture some companies are building today, one agent deployment at a time, often without anyone deciding to do so on purpose. This piece walks through why that pattern is a genuine segregation of duties problem, what Sarbanes-Oxley actually requires when an agent touches a financially relevant process, and what a control owner can do about it in practice.

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.

 

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.

 

How to Build a Control-Conscious SAP S/4HANA Implementation

Every T-Code, Table, and Design Technique You Need Before Go-Live

The most expensive SAP S/4HANA audit findings are the ones discovered after go-live. Every one of them.

I have watched organizations spend $200,000 remediating a segregation of duties problem that would have cost $5,000 to configure correctly during the explore phase. I have seen a chart of accounts redesign triggered by a post-implementation audit finding that required a partial reimplementation. And I have seen implementations where the system integrator delivered exactly what was specified, but the specifications never included internal controls, so the organization went live with a perfectly built system that had no preventive controls over vendor payments.

These situations are avoidable. Every single one.

This post walks through the complete methodology for building controls into your SAP S/4HANA implementation from day one. It covers the control-conscious implementation team structure, the control design framework with specific T-codes and table references, the audit involvement model, and the SDLC controls that protect the implementation itself. If your implementation is already underway, skip to the section covering your current phase. If you are planning your next implementation, read everything.

 

The 100 most critical and common segregation of duties conflicts in SAP

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

 
The most visited post in my blog covers the 20 most critical conflicts that you may find in SAP auditing, SOX testing and user security controls. After several years of fine-tuning  the user conflict matrix and having SAP HANA released, I expand this post by listing the 100 most critical and frequent segregation of duties incompatibilities.  This list helps in simplifying the user reviews by internal auditors, functional roles and access security professionals while explaining the risk which may result in operational fraud.


This is the list which you are welcome to get as a MS Excel file,

VA01 Create Sales Order and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
F.80 Mass reversal of documents and F-60 Maintain Table: Posting Periods are incompatible since the user may open accounting periods previously closed and make postings after month end.
VA01 Create Sales Order and VD01 Create Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and VD02 Change Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and FD02 Change Customer (FI) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and FD01 Create Customer (FI) are incompatible since assets may be disposed at less than the true value.
VA02 Change Sales Order and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and F-30 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
F.80 Mass reversal of documents and OB52 C FI Maintain Table T001B are incompatible since the user may open accounting periods previously closed and make postings after month end.
VL02N Change outbound delivery and F-22 Enter customer invoice are incompatible since the user may create/change a delivery and create/change an invoice.
XK01 Create Vendor (Centrally) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD01 Create customer (centrally) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VA02 Change Sales Order and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and VL02N Change outbound delivery are incompatible since the user may create/change sales orders and deliveries to hide the misappropriation of goods.
VF01 Create Billing Document and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VL01N Create outbound delivery with order ref and F-22 Enter customer invoice are incompatible since the user may create/change a delivery and create/change an invoice.
VA01 Create sales order and F-32 Clear customer are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
XK01 Create Vendor (Centrally) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD02 Change customer (centrally) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
MIGO Goods Movement and MM01 Create Material are incompatible since the user could create or change a fictitious receipt and create/change a material document to hide the deception.

Why SAP Segregation Of Duties Still Matters

Segregation of duties remains one of the most fundamental control disciplines in SAP environments. Despite advances in ERP architecture, workflow automation, analytics, and access governance tools, the underlying risk has not changed. When a single user can initiate, modify, approve, and complete incompatible activities across a transaction flow, the organization increases its exposure to fraud, error, financial misstatement, unauthorized transactions, and control override.

This is especially relevant in SAP environments that support core business processes such as order to cash, procure to pay, record to report, treasury, inventory management, and master data administration. In these processes, poorly designed access can allow users to create fictitious counterparties, manipulate transaction records, bypass approvals, conceal unauthorized activity, or distort financial reporting.

For internal audit, SOX teams, and SAP security professionals, the challenge is not simply identifying technical access overlaps. It is determining which combinations create meaningful business risk and which should be prioritized for remediation, monitoring, or compensating controls.

Why Many SoD Matrices Are Too Large To Be Useful

One of the recurring issues in SAP access reviews is that segregation of duties matrices become too broad, too technical, or too disconnected from real business risk. Some organizations maintain thousands of rule combinations, many of which are theoretically incompatible but operationally low risk. The result is predictable. Access reviews become difficult to explain, remediation efforts lose focus, and the business begins to treat SoD alerts as administrative noise rather than control signals.

A more effective approach is to focus on critical and frequent conflicts that create a credible path to unauthorized transactions, concealment, asset misappropriation, or financial reporting distortion. This does not mean reducing rigor. It means prioritizing conflicts that matter most.

That is why a curated list of critical incompatibilities can be so valuable. It helps internal auditors, role owners, access governance teams, and control testers simplify reviews and focus attention on combinations that are both common in practice and meaningful from a fraud and controls perspective.

What Makes An SAP SoD Conflict Truly Critical

Not every incompatible transaction pair carries the same risk. A conflict becomes especially important when it allows a user to control multiple points in a process where one action can create or modify the object and a later action can approve, settle, invoice, receive, clear, or conceal it.

In practice, the highest risk conflicts often involve one or more of the following conditions. The user can create or change master data and then execute transactions against that data. The user can initiate a commercial or accounting transaction and then post, clear, reverse, or conceal the financial result. The user can create operational activity and then generate the related billing, payment, or inventory movement. The user can reopen periods, reverse postings, or alter records after normal controls should have locked the transaction history.

This is the lens that matters. The risk is not the transaction code itself. The risk is the business capability created when incompatible access is combined in one user profile.

Why SAP HANA Does Not Eliminate SoD Risk

The move to SAP HANA and more modern SAP landscapes has improved reporting speed, data access, and system capability, but it has not removed segregation of duties risk. In fact, transformation programs can sometimes increase access risk temporarily because role redesign, migration pressure, emergency access, and hybrid landscapes create new complexity.

This is an important point for audit and controls teams. SoD risk is not a legacy SAP ECC issue only. It remains relevant across modern SAP environments, including S4HANA, especially where organizations have not fully redesigned business roles, cleaned up inherited access, or integrated SoD governance into transformation.

How To Use A Critical Conflict List Properly

A list of critical incompatibilities should be used as a prioritization tool, not as a substitute for process understanding. The same conflict can present different levels of risk depending on workflow design, approval automation, system configuration, organizational structure, and the presence of compensating controls.

For example, a conflict involving customer master maintenance and order processing may be highly sensitive in a decentralized commercial model with weak approval evidence, but less severe where master data changes are tightly workflow controlled, monitored, and independently reviewed. Likewise, a transaction pair involving invoice entry and goods movement may be materially more dangerous in a high volume manual environment than in one with embedded three way match controls and exception reporting.

This is why the best SoD programs do not stop at identifying conflicts. They assess business context, user activity, role necessity, mitigating controls, and whether the access creates a realistic fraud or error scenario.

Detailed Explanation Of Critical And Frequent SAP SoD Incompatibilities

Below is a refined sample of the types of conflicts that commonly warrant close attention in SAP access reviews. The wording has been adjusted to better reflect the underlying business risk.

VA01 Create Sales Order and XD01 Create Customer Centrally should generally be segregated because a user who can create both customer master data and sales orders may be able to establish a fictitious or inappropriate customer and initiate unauthorized sales transactions. The risk is not simply disposal of assets below true value. It also includes fictitious sales activity, misdirection of goods, and concealment of unauthorized commercial arrangements.

VA01 Create Sales Order and XD02 Change Customer Centrally should generally be segregated because the user may alter customer master data and then create sales orders using manipulated terms, addresses, or related customer attributes. This can enable unauthorized transactions, diversion schemes, or improper pricing arrangements.

VA01 Create Sales Order and VD01 Create Customer Sales And Distribution should generally be segregated because a user with both capabilities may create a customer in the sales domain and then process sales transactions against that customer without sufficient independent review.

VA01 Create Sales Order and VD02 Change Customer Sales And Distribution should generally be segregated because changing customer sales data and creating orders can allow the user to manipulate commercial terms, shipping attributes, or controls relevant to the sale.

VA01 Create Sales Order and FD01 Create Customer Finance should generally be segregated because customer creation in finance combined with order processing can enable unauthorized sales and downstream receivable activity tied to improperly established customers.

VA01 Create Sales Order and FD02 Change Customer Finance should generally be segregated because the combination can allow manipulation of finance relevant customer attributes and subsequent order activity that may not reflect legitimate commercial intent.

VA02 Change Sales Order and XD01 Create Customer Centrally should generally be segregated because a user may create customer records and then modify sales orders in ways that obscure unauthorized transactions or alter commercial terms after initiation.

VA02 Change Sales Order and XD02 Change Customer Centrally should generally be segregated because control over both customer master updates and sales order changes creates a broader ability to manipulate the transaction lifecycle.

VA01 Create Sales Order and VL02N Change Outbound Delivery should generally be segregated because a user who controls both order initiation and outbound delivery changes may be able to divert goods, conceal shipment irregularities, or manipulate fulfillment records.

VL02N Change Outbound Delivery and F 22 Enter Customer Invoice should generally be segregated because the user may control both shipment related activity and customer invoicing, creating a risk of unsupported billing, duplicate billing, or concealment of unauthorized deliveries.

VL01N Create Outbound Delivery With Order Reference and F 22 Enter Customer Invoice should generally be segregated because control over both delivery creation and invoice entry creates a risk that sales fulfillment and billing records can be manipulated without independent challenge.

VF01 Create Billing Document and XD01 Create Customer Centrally should generally be segregated because a user may establish customer master data and generate billing against that customer, increasing the risk of fictitious receivables or unauthorized billing activity.

XD01 Create Customer Centrally and F 30 Post With Clearing should generally be segregated because the user may create customer records and then post and clear incoming payments, which can facilitate concealment of unauthorized transactions or manipulation of receivable balances.

XD02 Change Customer Centrally and F 30 Post With Clearing should generally be segregated because a user may alter customer data and then apply or clear payments in a way that obscures the true nature of receivable activity.

VA01 Create Sales Order and F 30 Post With Clearing should generally be segregated because the user may initiate sales activity and then influence how cash is posted or cleared, creating risk in the order to cash cycle.

VA01 Create Sales Order and F 32 Clear Customer should generally be segregated because a user may create or influence sales transactions and later clear customer items, increasing the risk of concealment of collection issues or receivable manipulation.

XK01 Create Vendor Centrally and XD01 Create Customer Centrally should generally be segregated because the same user should not normally be able to create both vendors and customers without oversight. This may allow related party style schemes, circular transactions, or use of fictitious entities on both sides of the ledger.

XK01 Create Vendor Centrally and XD02 Change Customer Centrally should generally be segregated because the ability to create vendors and alter customers can support fictitious or manipulative counterparty structures that are difficult to detect through ordinary transaction review.

MIGO Goods Movement and MM01 Create Material should generally be segregated because a user may create or maintain material records and then process goods movements that support fictitious inventory activity, conceal shrinkage, or distort stock records.

F 80 Mass Reversal Of Documents and OB52 Maintain Posting Periods should generally be segregated because a user may reopen accounting periods and reverse postings after close, which increases the risk of unauthorized post close adjustments and financial reporting manipulation.

The original post referred to F 60 Maintain Table Posting Periods in one example. That wording is inaccurate. F 60 is generally used for entering vendor invoices, while posting period control is more appropriately associated with OB52 or related configuration level access. Correct transaction references matter because weak technical precision can undermine the usefulness of an SoD rule set.

How To Use This Reference

This list identifies the most critical and frequently encountered segregation of duties conflicts across core SAP business processes, organized by process area and risk category. For each conflict, the incompatible transaction code pair is identified along with a description of the specific fraud or error risk that the combination creates.

The complete list of 100 conflicts is available for download as a structured spreadsheet for integration into access review programs, GRC platform rulesets, and audit work papers.

The conflicts in this reference should be treated as a starting point rather than a definitive and universal ruleset. Every organization must tailor its SoD matrix to its specific business processes, organizational structure, industry, and risk appetite. A conflict that is critical in one operating environment may be mitigated in another through compensating controls, organizational design, or process-specific safeguards.

 

Why Business Risk Descriptions Matter More Than Transaction Pairing Alone

A common weakness in SAP SoD documentation is that the stated risk is too generic, too narrow, or simply wrong. For example, saying that creating a customer and creating a sales order means assets may be disposed at less than true value captures only one possible scenario and not the most likely one in many environments.

The business risk description should explain the realistic control failure that the combination enables. Depending on the process, that may include fictitious counterparties, unauthorized sales, duplicate billing, diversion of inventory, unsupported payments, inaccurate financial reporting, manipulation of period end results, or concealment of exceptions.

This matters because the quality of the risk narrative determines whether business owners, auditors, and control committees will take the conflict seriously. Technical access rules alone rarely drive remediation. Business relevant risk articulation does.

How Internal Audit And SOX Teams Should Prioritize Review

For internal audit and SOX testing, high value SoD review should focus first on combinations that affect financially significant processes, master data integrity, period end financial controls, payment authority, and inventory movement. It should also consider whether the user actually executed both sides of the conflict, whether emergency or firefighter access was involved, whether the conflict is concentrated in sensitive populations, and whether compensating controls are formal, evidence based, and consistently performed.

This is also where analytics can improve assurance. Access risk should be connected to usage data, transactional evidence, exception history, and post close activity rather than assessed only through static role design.

What A Mature SAP Access Risk Program Looks Like

A mature SAP access risk program does not treat segregation of duties as a one time remediation project. It treats SoD as part of a wider access governance model that includes role design, provisioning controls, emergency access management, periodic access review, transaction level monitoring, and alignment with financial control objectives.

It also recognizes that some conflicts may be unavoidable in smaller populations or specialized roles. In those cases, the key question becomes whether the risk is transparent, approved, monitored, and mitigated through credible compensating controls.

Additional SAP Segregation of Duties Conflicts

Expanded Critical Conflict List

The following conflicts are organized by business process area. Each entry identifies the incompatible transaction code pair by its full SAP name, describes the specific business risk the combination creates, and explains why the access should generally not be assigned to the same user. These conflicts supplement the 21 already published and are drawn from practices documented in SAP GRC Access Control standard rule sets, ISACA SAP audit programs, and widely applied internal control frameworks.

---

Procure to Pay

This process area consistently produces the highest concentration of critical SoD conflicts because it involves the creation of counterparties, the commitment of organizational funds, the confirmation of goods or services received, the entry of invoices, and the release of payments. A single user with access across multiple steps in this chain can create fictitious vendors, generate unauthorized purchase commitments, confirm goods never received, enter unsupported invoices, and direct payments to accounts they control.

22. ME21N Create Purchase Order and XK01 Create Vendor (Centrally) should generally be segregated because a user who can create vendor master data and issue purchase orders may establish a fictitious vendor and direct procurement spend to that entity without independent verification.

23. ME21N Create Purchase Order and XK02 Change Vendor (Centrally) should generally be segregated because the user may alter vendor master attributes such as bank details, payment terms, or pricing agreements and then create purchase orders that exploit those changes.

24. ME21N Create Purchase Order and FK01 Create Vendor (Accounting) should generally be segregated because creating a vendor in financial accounting and issuing purchase orders against that vendor combines counterparty creation with procurement commitment in a way that bypasses standard approval separation.

25. ME21N Create Purchase Order and FK02 Change Vendor (Accounting) should generally be segregated because changing vendor financial attributes such as bank routing information and then processing purchase commitments creates a path to payment diversion.

26. ME21N Create Purchase Order and MK01 Create Vendor (Purchasing) should generally be segregated because creating a vendor in the purchasing view and issuing orders against that vendor allows a single user to control both counterparty setup and procurement activity.

27. ME21N Create Purchase Order and MK02 Change Vendor (Purchasing) should generally be segregated because a user may modify vendor purchasing data such as order currency, incoterms, or planned delivery time and then create orders that benefit from those modifications.

28. ME21N Create Purchase Order and MIRO Enter Incoming Invoice (Logistics Invoice Verification) should generally be segregated because a user who can both commit the organization to a purchase and approve the related invoice controls two of the three elements in the standard three-way match, weakening the control over unauthorized or fictitious procurement.

29. ME21N Create Purchase Order and MIGO Goods Movement should generally be segregated because a user may create a purchase order and then confirm receipt of goods or services without independent verification, enabling fictitious receipt schemes.

30. ME21N Create Purchase Order and F-53 Post Outgoing Payments (Vendor) should generally be segregated because the user may create a procurement commitment and directly process payment, bypassing invoice verification and payment approval controls.

31. ME21N Create Purchase Order and F110 Automatic Payment Program (Parameters) should generally be segregated because a user who can create purchase commitments and configure or execute automatic payment runs may direct funds to unauthorized vendors or accelerate payments outside normal processing cycles.

32. ME51N Create Purchase Requisition and ME21N Create Purchase Order should generally be segregated because a user who can both request and approve a purchase bypasses the core separation between demand origination and procurement commitment.

33. ME21N Create Purchase Order and ME29N Release Purchase Order should generally be segregated because a user who can both create and release a purchase order effectively self-approves procurement transactions, eliminating the independent review that purchase order release is designed to provide.

34. MIRO Enter Incoming Invoice (Logistics Invoice Verification) and F-53 Post Outgoing Payments (Vendor) should generally be segregated because a user who can enter vendor invoices and process payments may create and pay fictitious or inflated invoices without independent review.

35. MIRO Enter Incoming Invoice (Logistics Invoice Verification) and F110 Automatic Payment Program (Parameters) should generally be segregated because the user may enter invoices and then configure or trigger payment runs that process those invoices automatically, bypassing payment approval workflows.

36. XK01 Create Vendor (Centrally) and MIRO Enter Incoming Invoice (Logistics Invoice Verification) should generally be segregated because a user may create a vendor and immediately enter invoices against it, supporting a fictitious vendor and invoice scheme.

37. XK01 Create Vendor (Centrally) and F-53 Post Outgoing Payments (Vendor) should generally be segregated because the user may create a fictitious vendor and directly process payments to it.

38. XK01 Create Vendor (Centrally) and F110 Automatic Payment Program (Parameters) should generally be segregated because a user who can create vendors and configure or execute automatic payments may establish fictitious payees and trigger disbursement without manual intervention.

39. FK01 Create Vendor (Accounting) and F-53 Post Outgoing Payments (Vendor) should generally be segregated because the combination allows vendor creation in the accounting view and direct payment processing, bypassing procurement and invoice verification entirely.

40. FK01 Create Vendor (Accounting) and F110 Automatic Payment Program (Parameters) should generally be segregated because a user may create vendor accounting records with specific bank details and then process automatic payments directed to those accounts.

41. MIGO Goods Movement and MIRO Enter Incoming Invoice (Logistics Invoice Verification) should generally be segregated because a user who can confirm goods receipt and approve the related invoice controls two verification points in the procurement cycle, weakening the control that independent confirmation is designed to provide.

42. ME22N Change Purchase Order and MIGO Goods Movement should generally be segregated because a user may modify purchase order quantities, prices, or delivery terms and then confirm receipt against the altered order, concealing discrepancies.

43. MR8M Cancel Invoice Document and MIRO Enter Incoming Invoice (Logistics Invoice Verification) should generally be segregated because a user who can cancel and reenter invoices may manipulate invoice records to alter amounts, redirect payments, or conceal duplicate processing.

44. XK02 Change Vendor (Centrally) and F-53 Post Outgoing Payments (Vendor) should generally be segregated because the user may change vendor bank details and then process payments to the revised account, enabling payment diversion fraud.

45. XK02 Change Vendor (Centrally) and F110 Automatic Payment Program (Parameters) should generally be segregated because changing vendor payment attributes and triggering automatic payments creates a risk of undetected payment redirection.

46. ME22N Change Purchase Order and MIRO Enter Incoming Invoice (Logistics Invoice Verification) should generally be segregated because a user may alter purchase order terms and then enter invoices that match the revised terms, concealing unauthorized modifications to procurement commitments.

---

Record to Report and Financial Accounting

Financial accounting conflicts create risk when a user can both generate accounting entries and control the infrastructure that governs how those entries are processed, reversed, reclassified, or reported. Period management, document reversal, and general ledger master data maintenance are among the most sensitive capabilities in SAP financial accounting.

47. FB01 Post Document and FB08 Reverse Document should generally be segregated because a user who can both post and reverse accounting entries may create and then conceal unauthorized transactions, manipulate account balances, or alter the financial record after the fact.

48. FB01 Post Document and FS00 Edit G/L Account Centrally should generally be segregated because a user who can create or modify general ledger accounts and post journal entries may establish accounts designed to hide unauthorized activity or misclassify transactions.

49. F-02 Enter G/L Account Posting and FB08 Reverse Document should generally be segregated because the combination allows a user to post and reverse general ledger entries, creating the ability to manipulate balances temporarily or permanently.

50. F-02 Enter G/L Account Posting and FS00 Edit G/L Account Centrally should generally be segregated because the user may modify the chart of accounts structure and then post entries that exploit those modifications.

51. FB01 Post Document and OB52 Maintain Posting Period Variants should generally be segregated because a user who controls both posting capability and period access may reopen closed periods and make unauthorized post-close entries that affect financial reporting.

52. F-02 Enter G/L Account Posting and OB52 Maintain Posting Period Variants should generally be segregated because the combination creates the same period manipulation risk as the previous conflict, applied to manual general ledger postings.

53. FB50 Enter G/L Account Document and OB52 Maintain Posting Period Variants should generally be segregated because the simplified posting transaction combined with period control allows unauthorized entries into periods that should be locked.

54. F-43 Enter Vendor Invoice and F-53 Post Outgoing Payments (Vendor) should generally be segregated because a user who can enter vendor invoices directly in financial accounting and process payments controls both sides of the disbursement process.

55. F-43 Enter Vendor Invoice and F110 Automatic Payment Program (Parameters) should generally be segregated because the user may enter invoices and then trigger automatic payment processing, bypassing manual payment review.

56. FK01 Create Vendor (Accounting) and F-43 Enter Vendor Invoice should generally be segregated because a user may create a vendor in financial accounting and immediately enter invoices against it without procurement involvement.

57. F-44 Clear Vendor and F-43 Enter Vendor Invoice should generally be segregated because the user may enter vendor invoices and clear open items in a way that conceals discrepancies, duplicate payments, or unauthorized charges.

58. F-28 Post Incoming Payments and FD01 Create Customer (Accounting) should generally be segregated because a user who can create customer records and post incoming payments may manipulate receivable balances or misapply cash receipts.

59. F-28 Post Incoming Payments and FD02 Change Customer (Accounting) should generally be segregated because changing customer financial attributes and posting payments creates a path to receivable manipulation and misapplied collections.

60. FB08 Reverse Document and OB52 Maintain Posting Period Variants should generally be segregated because a user may reopen accounting periods and reverse previously posted documents, directly undermining period-end financial controls and the integrity of closed-period financial statements.

61. FB01 Post Document and F.80 Mass Reversal of Documents should generally be segregated because a user who can post accounting documents and perform mass reversals may systematically alter financial records at scale, creating significant financial reporting risk.

---

Asset Management

Asset accounting conflicts create risk when a single user can control the creation of asset master records and the transactions that acquire, transfer, revalue, or retire those assets. The primary concern is that assets may be created fictitiously, retired prematurely, transferred without authorization, or disposed of at manipulated values.

62. AS01 Create Asset Master Record and ABAVN Asset Retirement by Scrapping should generally be segregated because a user who can create asset records and retire assets by scrapping may record fictitious assets and then write them off, or prematurely retire legitimate assets to conceal misappropriation.

63. AS01 Create Asset Master Record and ABAON Asset Retirement from Sale with Customer should generally be segregated because the user may create asset records and process asset sales, creating a path to dispose of assets at manipulated values or to fictitious buyers.

64. AS02 Change Asset Master Record and ABAVN Asset Retirement by Scrapping should generally be segregated because modifying asset master attributes and then retiring assets allows manipulation of asset values, useful life, or location data to conceal unauthorized disposals.

65. AS01 Create Asset Master Record and AB01 Create Asset Transaction (Post Asset Transaction) should generally be segregated because a user who can create asset records and post asset transactions may record fictitious acquisitions, transfers, or revaluations.

66. AS02 Change Asset Master Record and ABAON Asset Retirement from Sale with Customer should generally be segregated because the user may alter asset values or categorization and then process asset sales that do not reflect the true condition or worth of the asset.

67. AS01 Create Asset Master Record and F-90 Acquisition from Purchase with Vendor (Asset Posting from Purchasing) should generally be segregated because the user may create asset records and post acquisition transactions tied to vendor invoices, enabling fictitious asset capitalization.

---

Order to Cash Additional Conflicts

The existing list covers many core order-to-cash conflicts. The following additional combinations address billing manipulation, cancellation and re-creation schemes, and payment processing risks that are commonly encountered in sales environments.

68. VA01 Create Sales Order and VF01 Create Billing Document should generally be segregated because a user who controls both order initiation and billing document creation may generate invoices that do not correspond to legitimate sales activity or that reflect manipulated terms.

69. VA02 Change Sales Order and VL02N Change Outbound Delivery should generally be segregated because a user who can modify both sales orders and deliveries may alter quantities, delivery addresses, or terms across both documents to conceal diversion or unauthorized shipments.

70. VF01 Create Billing Document and F-28 Post Incoming Payments should generally be segregated because a user who controls both billing and cash receipt posting may generate invoices and apply payments in ways that conceal collection issues or misapply customer funds.

71. VF01 Create Billing Document and F-30 Post with Clearing should generally be segregated because the user may bill customers and then clear the resulting receivable items, concealing the true status of collections or manipulating aging reports.

72. VF01 Create Billing Document and VD01 Create Customer (Sales and Distribution) should generally be segregated because a user may create customers in the sales domain and generate billing documents against them, supporting fictitious revenue schemes.

73. VF01 Create Billing Document and VD02 Change Customer (Sales and Distribution) should generally be segregated because the user may modify customer sales data and then create billing documents that exploit those modifications.

74. VF01 Create Billing Document and FD01 Create Customer (Accounting) should generally be segregated because combining billing authority with customer financial master creation increases the risk of fictitious receivable activity.

75. VF01 Create Billing Document and FD02 Change Customer (Accounting) should generally be segregated because the user may alter customer financial terms and generate billing that reflects those altered conditions.

76. VF11 Cancel Billing Document and VF01 Create Billing Document should generally be segregated because a user who can cancel and recreate billing documents may manipulate invoice records, alter billing amounts, or conceal credit and rebilling activity.

77. VF02 Change Billing Document and F-28 Post Incoming Payments should generally be segregated because the user may modify billing records and then apply payments in a manner that conceals the changes or misrepresents the collection status.

---

Inventory and Warehouse Management

Inventory and warehouse transaction conflicts are especially important in manufacturing, distribution, and retail environments where physical goods movement represents a significant portion of organizational assets and cost of goods sold.

78. MB1A Goods Issue and MB1C Other Goods Receipts should generally be segregated because a user who can issue goods out of inventory and record goods receipts may manipulate stock balances, conceal shrinkage, or create fictitious inventory movements.

79. MB1A Goods Issue and MM02 Change Material (Master) should generally be segregated because the user may alter material master attributes such as valuation class, price, or unit of measure and then issue goods using the manipulated data.

80. MIGO Goods Movement and MM02 Change Material (Master) should generally be segregated because modifying material master records and processing goods movements creates a risk of inventory valuation manipulation and concealment of unauthorized stock changes.

81. MB1B Transfer Posting and MM01 Create Material (Master) should generally be segregated because a user may create material records and then process transfer postings to move inventory between locations or valuation areas without proper authorization.

82. MB1A Goods Issue and MIGO Goods Movement should generally be segregated in environments where MIGO is used for goods receipt because a user who can both issue and receive goods may execute circular inventory movements to conceal shortages or misappropriation.

---

Human Resources and Payroll

Human resources and payroll conflicts are among the most sensitive in any organization because they directly involve employee compensation. A user who can modify employee master data and influence payroll processing may create ghost employees, alter compensation, redirect payments, or manipulate tax and benefit deductions.

83. PA30 Maintain HR Master Data and the country-specific payroll transaction (such as PC00_M10_CALC Run Payroll for the United States or the equivalent for other country versions) should generally be segregated because a user who can change employee bank details, pay rates, or tax data and also run payroll calculations may alter compensation and process payments without independent review.

84. PA40 Personnel Actions and the country-specific payroll transaction should generally be segregated because a user who can execute personnel actions such as hiring, termination, or organizational reassignment and also process payroll may create or terminate employees and manipulate the related payroll activity.

85. PA30 Maintain HR Master Data and F110 Automatic Payment Program (Parameters) should generally be segregated because a user who can modify employee bank account information in HR master data and also configure or execute automatic payment processing may redirect payroll disbursements.

86. PA30 Maintain HR Master Data and PU00 Delete Payroll Results should generally be segregated because a user who can alter employee data and delete payroll calculation results may conceal evidence of unauthorized compensation changes.

87. PA30 Maintain HR Master Data and FB01 Post Document should generally be segregated because combining HR master data maintenance with general ledger posting capability may enable a user to create or alter employee records and post related accounting entries without separation between the HR and finance functions.

---

Basis and Security Administration

Basis and security conflicts are fundamentally different from business process conflicts because they involve access to the infrastructure that controls all other access. A user with combined basis and security capabilities may grant themselves or others unauthorized access, modify system behavior, alter data directly at the table level, or undermine the integrity of the authorization framework itself. These conflicts are relevant to IT general controls under SOX and to the access governance requirements of virtually every audit and compliance framework.

88. SU01 Maintain Users (User Maintenance) and PFCG Role Maintenance should generally be segregated because a user who can both create or modify user accounts and design or assign authorization roles can effectively grant any level of access to any user, including themselves, without independent review.

89. SU01 Maintain Users (User Maintenance) and SE16 Data Browser should generally be segregated because a user who can modify user accounts and directly browse database tables may access sensitive data across the entire system without application-level authorization controls.

90. SU01 Maintain Users (User Maintenance) and SM30 Maintain Table Views (Call View Maintenance) should generally be segregated because the combination allows a user to modify access controls and directly alter configuration or master data at the table level, bypassing all transaction-level controls.

91. SU01 Maintain Users (User Maintenance) and SA38 Execute ABAP Reporting (ABAP Reporting) should generally be segregated because a user who can maintain user accounts and execute ABAP programs may run reports or utilities that bypass standard authorization checks.

92. SU01 Maintain Users (User Maintenance) and SE38 ABAP Editor should generally be segregated because the combination allows a user to modify user access and alter program code, creating a path to embed unauthorized logic or bypass controls within the system.

93. SE38 ABAP Editor and SA38 Execute ABAP Reporting (ABAP Reporting) should generally be segregated because a user who can modify programs and immediately execute them may alter system behavior, extract data, or bypass controls without detection.

94. PFCG Role Maintenance and SU10 Mass User Maintenance (User Mass Maintenance) should generally be segregated because a user who can design roles and assign them in bulk may grant widespread unauthorized access rapidly, undermining the entire authorization model.

95. SE16 Data Browser and SM30 Maintain Table Views (Call View Maintenance) should generally be segregated because a user who can both view and modify table data directly has the ability to alter virtually any system record — including financial data, master data, and configuration — without using controlled transactions.

96. SU01 Maintain Users (User Maintenance) and SCC4 Client Administration should generally be segregated because a user who controls user access and client-level settings may modify client parameters that affect system behavior across the entire environment.

97. STMS Transport Management System and SE38 ABAP Editor should generally be segregated because a user who can modify program code and transport changes into production may introduce unauthorized system changes without independent technical review.

98. SM37 Background Job Overview (Job Overview) and SA38 Execute ABAP Reporting (ABAP Reporting) should generally be segregated because a user who can schedule and manage background jobs and execute programs may run unauthorized processes outside of normal business hours or monitoring visibility.

99. SE16N General Table Display and SU01 Maintain Users (User Maintenance) should generally be segregated because SE16N in some system configurations permits data modification at the table level, and combining this with user maintenance creates the same infrastructure-level risk as SE16 combined with SU01.

100. SU01 Maintain Users (User Maintenance) and SM21 System Log Analysis should generally be segregated because a user who can modify user accounts and access or manage system logs may alter access and then suppress or manipulate the log evidence that would normally detect the change. While SM21 is primarily a display transaction, in some configurations and when combined with other basis access, it can be part of a broader pattern of evidence management risk.

---

Technical References and Authoritative Sources

The following references support the conflict identification and risk descriptions in this list. Organizations building or validating their own SoD rule sets should consult these sources for detailed technical guidance.

SAP GRC Access Control Rule Set. SAP delivers a standard segregation of duties rule set with its GRC Access Control product. This rule set contains predefined risk definitions, functions, and conflict rules organized by business process. It serves as the baseline for most SAP SoD programs and is documented in the SAP Help Portal under SAP GRC Access Control configuration guides. Organizations should review and tailor this rule set to their specific environment, as the standard rules may not reflect all organization-specific risks.

SAP Security and Authorizations (SAP Press). The SAP Press publication on SAP security provides detailed guidance on authorization object design, role construction, user administration, and segregation of duties. It is widely used by SAP security teams and auditors as a technical reference for understanding how SAP authorization checks operate and how access conflicts arise at the authorization object level, not just the transaction code level.

SAP Help Portal — Transaction Code Documentation. SAP maintains official documentation for each transaction code, including its purpose, associated authorization objects, and configuration prerequisites. This documentation is the authoritative source for confirming the correct full name of each transaction code and understanding its functional scope. It is accessible through the SAP Help Portal and through transaction SE93 (Maintain Transaction Codes) within the SAP system itself.

ISACA — IT Audit Framework and SAP Audit Programs. ISACA publishes audit and assurance programs for ERP environments, including SAP-specific guidance on access controls, segregation of duties, and IT general controls. These programs are widely referenced by internal audit functions and external auditors performing SOX testing and operational audits of SAP environments.

COSO — Internal Control — Integrated Framework (2013). The COSO framework establishes the foundational principles for internal control design, including the principle that organizations should segregate incompatible duties or implement alternative controls where segregation is not practicable. This framework provides the conceptual basis for SoD requirements and is referenced by the SEC and PCAOB in the context of internal control over financial reporting.

PCAOB Auditing Standard AS 2201 — An Audit of Internal Control Over Financial Reporting. AS 2201 requires auditors to evaluate the design and operating effectiveness of internal controls, including IT general controls and application controls in ERP systems. Segregation of duties is a core component of this evaluation, particularly for financially significant processes and systems such as SAP.

IIA Global Technology Audit Guides (GTAGs). The Institute of Internal Auditors publishes technology audit guides that address IT governance, access management, and application controls. GTAG 8 on auditing application controls and GTAG 1 on information technology risk and controls are directly relevant to SAP SoD assessments.

SAP Note References. SAP publishes notes and knowledge base articles that address specific authorization risks, critical authorization objects, and recommended segregation practices. Key notes related to critical authorizations include SAP Note manufacturers publish security notes and authorization guides that should be reviewed as part of SoD program maintenance. The SAP Security Notes index and the SAP Community Wiki on GRC best practices provide additional practitioner-contributed guidance.

 

Final Perspective

The most effective SAP SoD matrices are not the largest. They are the ones that best translate technical access conflicts into meaningful business risk. For internal auditors, SOX teams, and SAP security professionals, the goal should be to identify the combinations that create the clearest path to fraud, error, or reporting distortion and to focus remediation where it matters most.

A refined list of critical and frequent conflicts can be a powerful tool for that purpose, but only when it is maintained carefully, technically accurate, and grounded in real process risk rather than generic access theory.

If useful, this list can also be structured into an Excel based conflict matrix for review, rule maintenance, and testing support.

References

AP Help Portal: official transaction, process, and authorization documentation for SAP ECC and SAP S/4HANA
SAP GRC Access Control documentation: ruleset and access risk analysis concepts
SAP PRESS publications on SAP Security, Authorizations, and GRC Access Control
COSO Internal Control – Integrated Framework for segregation of duties and control design principles
Institute of Internal Auditors (IIA) guidance on fraud risk and internal controls
ISACA guidance on access governance, SoD, and control monitoring
PCAOB and SOX internal control expectations relevant to financial reporting and access risks
Internal SAP system analysis using SUIM, PFCG, SU24, STAUTHTRACE, and transaction usage reviewSAP transaction and authorization design practices relevant to SoD and access governance

Institute of Internal Auditors guidance on internal controls and fraud risk

Committee of Sponsoring Organizations of the Treadway Commission. Internal Control Integrated Framework

US Securities and Exchange Commission and PCAOB expectations relevant to internal control over financial reporting under SOX

Access governance and SoD practices commonly used in SAP security and audit programs

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

XD01 Create customer (centrally) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
XD01 Create customer (centrally) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
VA01 Create sales order and VL01N Create outbound delivery with order ref are incompatible since the user may create/change sales orders and deliveries to hide the misappropriation of goods.
VF01 Create Billing Document and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA02 Change Sales Order and VD01 Create Customer (SD) are incompatible since assets may be disposed at less than the true value.
FK01 Create Vendor (FI) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VA02 Change Sales Order and VD02 Change Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and F-26 Incoming payments fast entry are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
VA02 Change Sales Order and FD02 Change Customer (FI) are incompatible since assets may be disposed at less than the true value.
XD01 Create customer (centrally) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
XD02 Change customer (centrally) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
XK01 Create Vendor (Centrally) and VD01 Create Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD01 Create customer (centrally) and F-29 Post customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated.  If the same person can process both items, unauthorized changes could be made and possibly not detected.  Th.
XD02 Change customer (centrally) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
VD01 Create customer (sales) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
FK02 Change Vendor (FI) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XK01 Create Vendor (Centrally) and VD02 Change Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD01 Create customer (centrally) and F-26 Incoming payments fast entry are incompatible since the user may create a customer and then post payments against the customer.
XK01 Create Vendor (Centrally) and FD02 Change Customer (FI) are incompatible since assets may be sold to non-existent or fraudulent customers.
VD02 Change customer (sales) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
FD02 Change customer (accounting) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VA02 Change Sales Order and FD01 Create Customer (FI) are incompatible since assets may be disposed at less than the true value.
MK01 Create Vendor (MM) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
FK01 Create Vendor (FI) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VF01 Create Billing Document and VD01 Create Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA02 Change sales order and F-30 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
XD02 Change customer (centrally) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
ME21N Access to Create Purchase Order and ABAA Unplanned Depreciation are incompatible since assets may be acquired at an overvalued or undervalued price and then depreciated.  Unplanned depreciation, manual depreciation, and asset value write-ups are processed incorrectly or without authority to proceed.
MK02 Change Vendor (MM) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VF01 Create Billing Document and VD02 Change Customer (SD) are incompatible since assets may be disposed at less than the true value.
VF01 Create Billing Document and FD02 Change Customer (FI) are incompatible since assets may be disposed at less than the true value.
XD02 Change customer (centrally) and F-29 Post customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated.  If the same person can process both items, unauthorized changes could be made and possibly not detected.
XK01 Create Vendor (Centrally) and FD01 Create Customer (FI) are incompatible since assets may be sold to non-existent or fraudulent customers.
VA01 Create sales order and F-51 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
FK02 Change Vendor (FI) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XK02 Change Vendor (Centrally) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
F.80 Mass reversal of documents and SCMA Schedule Manager: Scheduler are incompatible since the user may open accounting periods previously closed and make postings after month end.
XD02 Change customer (centrally) and F-26 Incoming payments fast entry are incompatible since the user may create a customer and then post payments against the customer.
FD01 Create customer (accounting) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VD01 Create customer (sales) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VF02 Change Billing Document and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VD02 Change customer (sales) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
MK01 Create Vendor (MM) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VD01 Create customer (sales) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
FD02 Change customer (accounting) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
ME21N Access to Create Purchase Order and ABZU Write-up are incompatible since assets may be acquired at an overvalued or undervalued price and then depreciated.  Unplanned depreciation, manual depreciation, and asset value write-ups are processed incorrectly or without authority to proceed.
XD01 Create customer (centrally) and F-51 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VD02 Change customer (sales) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
MK02 Change Vendor (MM) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VF01 Create Billing Document and FD01 Create Customer (FI) are incompatible since assets may be disposed at less than the true value.
FD02 Change customer (accounting) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
VA02 Change sales order and VL02N Change outbound delivery are incompatible since the user may create/change sales orders and deliveries to hid the misappropriation of goods.
FK01 Create Vendor (FI) and VD01 Create Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD01 Create customer (centrally) and F-39 Clear customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated.  If the same person can process both items, unauthorized changes could be made and possibly not detected.  Th.
VA01 Create sales order and FBCJ Cash journal are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
XK02 Change Vendor (Centrally) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
ME21N Access to Create Purchase Order and ABMA Manual Depreciation are incompatible since assets may be acquired at an overvalued or undervalued price and then depreciated.  Unplanned depreciation, manual depreciation, and asset value write-ups are processed incorrectly or without authority to proceed.
VA02 Change sales order and F-32 Clear customer are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
FK01 Create Vendor (FI) and VD02 Change Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
VD01 Create customer (sales) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VF02 Change Billing Document and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and F-52 Post incoming payments are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
FK01 Create Vendor (FI) and FD02 Change Customer (FI) are incompatible since assets may be sold to non-existent or fraudulent customers.
FD01 Create customer (accounting) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VA01 Create sales order and FF/4 Interface for check deposit data entered externally are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
VD02 Change customer (sales) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VA01 Create sales order and F-04 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
VD01 Create customer (sales) and F-29 Post customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated.  If the same person can process both items, unauthorized changes could be made and possibly not detected.  Th.
FD02 Change customer (accounting) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VA01 Create sales order and FB05 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
VA01 Create sales order and FF/5 Post check deposit data entered externally are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
FK02 Change Vendor (FI) and VD01 Create Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
VL02N Change outbound delivery and F-30 Post with clearing are incompatible since the user may create fictitious/incorrect delivery and enter payments against these, potentially misappropriating goods.
FD01 Create customer (accounting) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
VD01 Create customer (sales) and F-26 Incoming payments fast entry are incompatible since the user may create a customer and then post payments against the customer.
XD01 Create customer (centrally) and FBCJ Cash journal are incompatible since the user may create a customer and then post payments against the customer.
XD02 Change customer (centrally) and F-51 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VD02 Change customer (sales) and F-29 Post customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated.  If the same person can process both items, unauthorized changes could be made and possibly not detected.

A risk-based approach to SAP segregation of duties        The top 100 most critical segregation of duties conflicts in SAP        Segregation of Duties Fraud Risks & Solutions
Security SOD Segregation of Duties        SOD Conflicts and Role Based Authorization in SAP        SAP Segregation of Duties SOX 404 and Risks

Strategic Risk Management

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

Strategic Risk Management: Integrating Strategy And Risk To Protect And Create Stakeholder Value

The Historical Context: Risk Management Has Always Been Strategic

Organizations have managed risk in pursuit of commercial objectives for centuries. The maritime insurance markets of medieval Italy, the joint-stock trading companies of the mercantile era, and the commodity exchanges that emerged in the eighteenth and nineteenth centuries all represented structured approaches to identifying, pricing, and distributing risk in the service of strategic commercial goals. Risk management, in this fundamental sense, is as old as organized commerce itself.

What is comparatively recent is the development of enterprise-wide frameworks that integrate risk management across organizational functions, link risk assessment to strategic objectives, and establish governance structures for overseeing the organization's aggregate risk profile. The COSO Enterprise Risk Management Integrated Framework, published in 2004, was the first comprehensive attempt to codify this integration. It defined enterprise risk management as a process designed to identify potential events that may affect the entity, manage risk to be within its risk appetite, and provide reasonable assurance regarding the achievement of entity objectives.

The 2004 COSO framework represented a significant advance, but its implementation revealed a persistent gap. Organizations adopted the framework's methodology for operational, financial, and compliance risks with reasonable effectiveness, but the integration of strategic risk, meaning the risks that arise from the organization's strategic choices and that threaten its ability to achieve its strategic objectives, remained underdeveloped. Risk management functions focused predominantly on the risks within existing strategies rather than on the risks of the strategies themselves.

The COSO Enterprise Risk Management Integrating with Strategy and Performance framework, published in 2017, addressed this gap directly. The updated framework repositioned enterprise risk management as a discipline that must be embedded in the organization's strategy-setting and performance management processes. Its five components, Governance and Culture, Strategy and Objective-Setting, Performance, Review and Revision, and Information Communication and Reporting, explicitly integrate risk considerations into the formulation, execution, and monitoring of strategy. The 2017 framework's central thesis is that risk management cannot be effective if it operates downstream of strategy, evaluating risks only after strategic decisions have been made. It must be an integral part of the strategic decision-making process itself.

ISO 31000:2018 reinforces this integration. The standard establishes in Clause 5.2 that risk management must be integrated into all organizational activities, and in Clause 5.4.1 that the purpose of risk assessment is to support decisions, including strategic decisions. The standard's emphasis on understanding the organization's external and internal context (Clause 6.3) directly supports strategic risk identification by requiring the organization to systematically evaluate the factors that could affect its ability to achieve its objectives.

What Strategic Risk Management Encompasses

Strategic risk management is the identification, assessment, and management of the risks that arise from or affect the organization's strategic choices, competitive position, and ability to achieve its long-term objectives. It addresses a fundamentally different category of uncertainty than operational, financial, or compliance risk management, though it interacts with all of these disciplines.

The distinguishing characteristic of strategic risk is its origin. Strategic risks do not arise from the failure of existing processes or controls. They arise from the assumptions, decisions, and external conditions that determine whether the organization's chosen strategy will succeed. They include the risk that the strategy itself is flawed, that the assumptions underlying the strategy are incorrect, that the competitive environment will evolve in ways the strategy does not anticipate, that the organization lacks the capabilities to execute the strategy, and that external events will disrupt the conditions upon which the strategy depends.

Strategic risk management operates at the intersection of governance, strategy, and enterprise risk management. It is fundamentally a concern of the board, the chief executive officer, and the executive management team, because strategic decisions are made at the governance and executive level, and the consequences of strategic risk materialization affect the organization as a whole rather than individual business units or functional areas.

The GRC framework should integrate strategic risk management to ensure that governance oversight, risk assessment, and compliance obligations are aligned with the organization's strategic direction. Enterprise risk management should include the prioritization processes necessary to identify the key risks that have the potential to affect strategic objectives, recognizing that the most significant risks to the organization may not be the most operationally visible ones but rather the strategic assumptions and environmental conditions that the organization has taken for granted.

Why Strategic Risk Management Has Been Historically Underdeveloped

Despite its importance, strategic risk management has been historically underdeveloped relative to other domains of enterprise risk management. Several factors explain this gap.

Institutional separation of strategy and risk functions. In most organizations, strategy is formulated by the executive team and the board, while risk management is executed by a dedicated risk function, internal audit, or compliance team. These functions operate with different reporting lines, different methodologies, different professional vocabularies, and different time horizons. The strategy function thinks in terms of growth, market position, and competitive advantage. The risk function thinks in terms of loss prevention, control effectiveness, and regulatory compliance. Neither function has traditionally been designed or equipped to integrate the other's perspective into its own work.

The difficulty of quantifying strategic risk. Operational and financial risks can often be quantified using historical loss data, actuarial models, or financial modeling techniques. Strategic risks, by contrast, involve uncertainties that are often unique, unprecedented, or dependent on complex interactions between multiple variables. The probability that a competitor will introduce a disruptive technology, that a regulatory regime will change fundamentally, or that a macroeconomic shift will invalidate the organization's market assumptions cannot be estimated with the same confidence as the probability that a financial control will fail. This quantification difficulty has led many organizations to treat strategic risk as a qualitative or discussion-level topic rather than as a rigorous analytical discipline.

The cognitive biases of strategic decision-makers. The executives and board members responsible for strategic decisions are subject to cognitive biases that can impede effective strategic risk assessment. Confirmation bias leads decision-makers to seek and interpret information in ways that confirm their existing strategic beliefs. Overconfidence bias leads them to overestimate the probability of success and underestimate the magnitude and likelihood of adverse outcomes. Anchoring leads them to rely disproportionately on early information when making strategic judgments. Groupthink in boardroom and executive committee discussions can suppress dissenting views and unconventional risk perspectives. These biases, documented extensively in the behavioral economics and organizational behavior literature beginning with the foundational work of Kahneman and Tversky, make it psychologically difficult for strategic decision-makers to subject their own strategies to rigorous risk analysis.

The absence of organizational incentives for strategic risk identification. In many organizations, the individuals responsible for developing and advocating strategic initiatives have strong personal and professional incentives to emphasize the potential benefits and minimize the potential risks. Executives whose careers depend on the approval and successful execution of strategic proposals may resist the introduction of formal risk assessment processes that could delay, modify, or reject their initiatives. Unless the organization creates countervailing incentives and governance mechanisms that reward the identification of strategic risks, the cultural pressure to present optimistic projections will overwhelm the analytical discipline required for effective strategic risk management.

The Consequences Of Strategic Risk Management Failure

The consequences of failing to integrate risk management with strategic decision-making have been demonstrated repeatedly and with catastrophic effect across industries and geographies. The cases that have generated the most significant stakeholder losses are overwhelmingly strategic risk failures rather than operational or compliance control failures, although the two categories frequently interact.

The 2008 global financial crisis provides the most consequential example at the systemic level. Institutions that failed to align their debt management, investment portfolio composition, and leverage strategies with realistic assessments of market risk, counterparty risk, and liquidity risk experienced losses that threatened not only their own survival but the stability of the global financial system. The Senior Supervisors Group report of 2009 identified the failure to integrate risk management with business strategy as a distinguishing factor between institutions that managed through the crisis and those that did not. The Financial Stability Board's subsequent work on risk culture, risk appetite frameworks, and governance practices was a direct response to the recognition that strategic risk management failures, not merely operational control deficiencies, were the root cause of the crisis.

Beyond the financial sector, strategic risk management failures are evident in cases involving the failure to anticipate and prepare for technological disruption that rendered established business models obsolete, the failure to diversify geographic or customer concentration that left organizations fatally exposed to adverse developments in a single market, the failure to assess the risk implications of aggressive growth strategies funded by unsustainable leverage, the failure to evaluate the strategic risks of entering regulated markets without adequate compliance infrastructure, and the failure to anticipate the cost and reputational consequences of environmental, social, and governance failures that were predictable given the organization's operating practices.

In each of these categories, the losses resulted not from the failure of an individual control but from the failure to identify, assess, and respond to risks that were inherent in the organization's strategic choices. The risk management function may have been highly effective at monitoring operational metrics, testing financial controls, and ensuring compliance with existing regulations, while simultaneously failing to address the strategic assumptions that determined whether the organization would survive the next market cycle.

Building A Strategic Risk Management Capability

Developing an effective strategic risk management capability requires action across several dimensions.

Integration Into The Strategy-Setting Process

Strategic risk assessment must be embedded in the process through which the organization formulates, evaluates, and approves its strategic plans. As established in the earlier post on when risk assessment must happen, this assessment must occur before strategic decisions are made, not after they have been approved and communicated. The board and executive management should not approve any significant strategic initiative, major investment, market entry, acquisition, or organizational transformation without a formal assessment of the risks that the initiative creates or is exposed to.

The COSO ERM 2017 framework structures this integration through its Strategy and Objective-Setting component, which requires the organization to consider risk in the context of establishing its business strategy and objectives. Under this framework, the organization's risk appetite is defined as part of the strategy-setting process, ensuring that the level of risk the organization is willing to accept is calibrated to the strategic objectives it is pursuing and the value it expects to create.

Risk Appetite Alignment

Strategic risk management requires a clearly defined and operationalized risk appetite that is directly linked to the organization's strategic objectives. The risk appetite statement must go beyond generic declarations of risk tolerance to specify the types and levels of risk the organization is willing to accept across different strategic dimensions, including growth risk, concentration risk, leverage risk, innovation risk, market risk, and reputational risk.

When the organization's actual risk profile, as revealed through strategic risk assessment, diverges from its stated risk appetite, this divergence must be escalated to the board and executive management for resolution. Either the risk profile must be adjusted through risk treatment actions, or the risk appetite must be revised to reflect a deliberate decision to accept the higher level of exposure. What cannot be tolerated is an unrecognized or unacknowledged divergence between the risks the organization has accepted through its strategic choices and the risks the board has authorized through its risk appetite framework.

Top Risk Identification And Prioritization

Strategic risk management requires a disciplined process for identifying and prioritizing the top risks that could affect the organization's ability to achieve its strategic objectives. This process should draw on multiple information sources, including the enterprise risk assessment, environmental scanning and horizon analysis, competitive intelligence, regulatory trend analysis, stakeholder feedback, and the professional judgment of the board and executive management.

The identification process should explicitly address risks that conventional operational risk assessments may not capture, including risks arising from the organization's strategic assumptions, risks arising from the external environment and competitive dynamics, risks arising from the pace and magnitude of change in the organization's industry, and risks arising from the interdependencies between the organization's strategic initiatives.

The output of this process should be a strategic risk profile that presents the organization's most significant risks in the context of its strategic objectives, with clear identification of the risk owners, the current treatments, the residual exposure, and the key risk indicators that will be monitored to detect changes in the risk profile.

Board-Level Oversight And Governance

Strategic risk management is fundamentally a governance activity that requires active board engagement. The board's role is not to manage strategic risks directly but to ensure that management has identified the most significant strategic risks, that the risk appetite is appropriately defined and aligned with the strategy, that management's risk treatment plans are adequate and proportionate, and that the organization maintains the capabilities and resources required to monitor and respond to changes in its strategic risk profile.

The IIA Global Internal Audit Standards, effective January 2025, require the internal audit function to evaluate the effectiveness of risk management processes, including the processes through which the organization identifies and manages strategic risks. Internal audit's role in strategic risk management is to provide independent assurance that the strategic risk management process is functioning as intended, that the information reaching the board is complete and accurate, and that management is responding appropriately to identified strategic risks.

The board should receive strategic risk reporting on at least a quarterly basis, though the frequency should be increased during periods of significant strategic change, market volatility, or external disruption. The reporting should present the organization's top strategic risks, the status of treatments and mitigation efforts, any changes in the strategic risk profile since the prior reporting period, and any emerging risks that have been identified through environmental scanning or early warning indicators.

Cross-Functional Collaboration

Strategic risk management cannot be effective if it is confined to the risk management function or delegated to a single executive. It requires collaboration across the strategy, finance, operations, technology, legal, compliance, and risk management functions, because strategic risks by definition span organizational boundaries and affect the organization as a whole.

The GRC framework provides the natural integration point for this collaboration. By aligning governance oversight, risk assessment, and compliance monitoring with the organization's strategic direction, the GRC framework ensures that the different functions responsible for managing different dimensions of strategic risk are working within a common framework, using a common risk language, and reporting to a common governance structure.

Scenario Analysis And Stress Testing

Strategic risk assessment should employ scenario analysis and stress testing as core analytical methodologies. As discussed in the earlier posts on risk analysis for business plans and on risk assessment in changing environments, scenario analysis constructs alternative versions of the organization's operating environment and evaluates the strategy's resilience under each scenario. Stress testing pushes assumptions to their extreme values to determine the conditions under which the strategy would fail.

These techniques are particularly important for strategic risk because they reveal the sensitivity of the strategy to changes in its underlying assumptions. A strategy that produces acceptable results across a wide range of scenarios is more robust than one that depends on a narrow set of conditions remaining favorable. Strategic risk management should identify the assumptions upon which the strategy is most dependent, subject those assumptions to rigorous scenario and stress testing, and ensure that contingency plans exist for the scenarios in which those assumptions prove incorrect.

Emerging Risk Identification

Strategic risk management must include systematic processes for identifying emerging risks that are not yet fully developed but that could materially affect the organization's strategic position over the medium to long term. Emerging risks include technological disruptions, demographic shifts, climate-related developments, evolving social expectations, regulatory trends, and geopolitical realignments that may not yet manifest in the organization's current risk indicators but that could fundamentally change the environment in which the organization operates.

The identification of emerging risks requires horizon scanning across multiple domains, including technology, regulation, geopolitics, demographics, environment, and social trends. It also requires the willingness to consider scenarios that challenge the organization's established strategic assumptions, including scenarios in which the organization's current business model becomes unviable. This is psychologically difficult for the leadership teams that developed and advocate the current strategy, which is why the board's independent perspective and the internal audit function's objective assessment are particularly valuable in this domain.

The Relationship Between Strategic Risk And Operational Risk

Strategic risk and operational risk are distinct categories, but they interact in ways that make their separation analytically challenging and practically important.

Operational risks, when they materialize with sufficient severity or frequency, can escalate into strategic risks. A series of operational failures in a critical process may reveal a fundamental capability gap that threatens the organization's competitive position. A cybersecurity incident may damage customer trust to the point where the organization's market strategy becomes unviable. A compliance failure may result in regulatory sanctions that constrain the organization's ability to pursue its growth strategy in a particular market.

Conversely, strategic choices create the operational risk profile that the organization must manage. A decision to enter a new geographic market creates operational risks related to supply chain, regulatory compliance, talent acquisition, and cultural adaptation that did not exist before the strategic decision was made. A decision to pursue aggressive growth through acquisition creates integration risks, culture risks, and financial risks that are consequences of the strategic choice.

This bidirectional relationship means that effective strategic risk management requires visibility into the operational risk landscape, and effective operational risk management requires understanding of the strategic context within which operational risks are being generated and managed. The GRC framework, and the enterprise risk management methodology that operates within it, must provide this integrated view.

From Risk Silos To Strategic Integration

The historical underdevelopment of strategic risk management is not primarily a failure of frameworks. The frameworks now exist and are comprehensive. The COSO ERM 2017 framework explicitly integrates risk with strategy. ISO 31000:2018 requires risk management to be embedded in all organizational activities, including strategic planning and decision-making. The IIA Standards require internal audit to evaluate strategic risk management processes.

The gap is in implementation. Organizations that have adopted ERM frameworks for operational and compliance purposes but have not extended them to strategic risk assessment, that conduct risk assessments after strategic decisions have been made rather than before, that define risk appetite generically without linking it to specific strategic dimensions, that lack the governance structures for board-level strategic risk oversight, and that do not invest in the scenario analysis, stress testing, and emerging risk identification capabilities required for strategic risk assessment are organizations whose risk management frameworks are incomplete regardless of how mature their operational risk processes appear.

Closing this implementation gap is not optional in an environment characterized by accelerating technological change, geopolitical uncertainty, climate-related disruption, evolving stakeholder expectations, and competitive dynamics that can transform industry structures within years rather than decades. The organizations that master strategic risk management will be the ones that consistently align their strategies with their risk appetites, detect environmental changes before they become crises, and maintain the adaptive capacity to modify their strategic direction when the assumptions underlying their plans prove incorrect.

The organizations that do not will continue to experience what their boards describe as unexpected events but what a mature strategic risk management capability would have identified as predictable consequences of unexamined strategic assumptions.

What A More Mature Strategic Risk Process Looks Like

A mature strategic risk process should be embedded into strategy formulation, capital planning, major investment review, and performance monitoring. It should not begin only after the strategy has already been approved.

This means management should identify the assumptions underlying strategic choices, test how sensitive those assumptions are, evaluate downside and upside scenarios, assess execution dependencies, and determine whether the expected return justifies the uncertainty within the company’s appetite and capacity.

It also means prioritization matters. Not every enterprise risk is strategic, and not every strategic risk deserves the same level of board time. The process should identify which risks could materially affect strategic objectives, business model viability, or major investment outcomes.

This is where the original draft’s point about prioritization can be sharpened. The objective is not simply to use ERM to identify key risks and then treat those as strategic. The objective is to determine which risks are material to strategy and to ensure they are discussed in a way that influences strategic choices.

Why Strategic Risk Management Should Be Integrated With GRC

A strong GRC model should support strategic risk management rather than sit below it as an administrative structure. Governance defines oversight, accountability, and decision rights. Risk management assesses uncertainty, appetite, and exposure. Compliance and control functions provide discipline, transparency, and evidence. Together, they should help align business activity to strategic objectives within accepted boundaries.

This integrated view matters because strategic failure is rarely caused by strategy in isolation. It is often caused by weak governance over assumptions, poor information flow, unclear accountability, control failures in critical execution areas, or inability to adapt when conditions change. Strategic risk management therefore needs support from across the broader GRC model.

Why External Stakeholders Care More Than Many Companies Realize

Strategic risk management is not only a board concern. Investors, lenders, rating agencies, insurers, regulators, and major counterparties increasingly care about whether the organization can identify and manage risks to its business model and strategic plans. They may not use the same language, but they are all assessing resilience.

This is especially visible in periods of macroeconomic stress, digital disruption, geopolitical volatility, and heightened scrutiny of operational resilience. Stakeholders want confidence that management is not only executing a plan, but also challenging whether the plan remains credible under changing conditions.

That is why strategic risk management has direct implications for valuation, access to capital, reputation, and stakeholder trust.

How Strategic Risk Management Connects To Current Frameworks

The original draft referred to ISO 31000 and Return Driven Strategy, which was directionally useful. Today, the most widely recognized governance references for this discussion remain COSO ERM and ISO 31000.

COSO ERM is especially relevant because it explicitly connects risk with strategy setting and performance. It emphasizes governance, culture, objective setting, performance, review, and revision in a way that is highly applicable to strategic decision making.

ISO 31000 remains useful for its principles based view that risk management should be integrated, structured, customized, inclusive, dynamic, and part of decision making. That is directly relevant to strategic planning.

The stronger message is that the frameworks exist. The real challenge is implementation. Most companies do not fail at strategic risk management because the theory is unavailable. They fail because the process is not embedded deeply enough in how strategy is approved, challenged, and adjusted.

Final Perspective

Strategic risk management is one of the clearest tests of governance maturity. It reveals whether an organization is simply monitoring risks around the edges of the business or whether it is using risk discipline to improve the quality of strategic decisions.

In the current environment, that distinction matters. Markets move faster, capital is less forgiving, disruption travels more quickly, and stakeholder expectations are higher. Companies cannot afford to treat strategic risk as an abstract concept discussed once a year in a planning deck.

The organizations that will outperform over time are not the ones that eliminate uncertainty. They are the ones that understand which uncertainties matter most to the strategy, challenge them before committing, and adapt before those assumptions fail in the market.

References

Committee of Sponsoring Organizations of the Treadway Commission. Enterprise Risk Management Integrating With Strategy And Performance

International Organization for Standardization. ISO 31000 Risk Management Guidelines

Leading market practice in strategic planning, scenario analysis, board risk oversight, and enterprise resilience

Public commentary and investor expectations related to resilience, capital allocation, and strategic governance