Showing posts with label Sox. Show all posts

Compliance Theater Is Hiding Your Biggest Security Risks

Consider an illustrative scenario, a composite of patterns that repeat across security programs. A payments processor presents its quarterly security report to the audit committee. Every scheduled vulnerability scan ran on time. Nearly all employees finished security training, the certification renewed without a gap, and every audit finding from the prior year is closed. Three weeks later an attacker enters through a server that never appeared on a scan target list, because the team built it after the list was last updated. The report was accurate on every line, and it still told the committee nothing about whether the company was getting safer.

Compliance is a byproduct of security. When an organization knows its threats, protects the assets that matter, tests its controls, and fixes weaknesses until a retest confirms the fix, most of its compliance evidence becomes a record of work already done to reduce risk. When the sequence runs the other way, the organization collects evidence first and hopes protection follows. That gap is where false confidence grows, and decision-makers stop asking hard questions at the moment they most need to ask them. This article is for CISOs and compliance officers who want to report outcomes instead of activity, and it ends with seven metrics you can start swapping in this quarter.

The argument covers the obligations most teams already carry. GDPR, NIS2, HIPAA, SOX, PCI DSS, ISO/IEC 27001, and SOC 2 each ask, in different words, whether controls work and whether you can show it. Compliance stays a legal and contractual duty with its own deadlines, and nothing here argues for skipping it. The point concerns order and evidence. Security work comes first, and the records that work produces earn the compliance claim. The sections below cover what each obligation requires, how checkbox reporting goes wrong, which metrics replace it, and how to make the evidence trail a normal output of operations.

Agentic AI in Internal Audit, What to Automate, What to Keep

Consider an illustrative scenario, not a real engagement. A mid-sized distributor connects an audit agent to its ERP, its document repository and its ticketing tool. Within a week the agent has pulled invoices, receipts and approvals for 240 purchase orders and produced a tidy memo saying the procure-to-pay control passed. The audit manager reads it, likes it, and asks the only question that matters: which records did the agent open? Nobody can answer.

The short answer to the sequencing problem is this. Agentic AI should first take bounded, repeatable, evidence-based work: a finite set of documents, stable rules, and output you can check against a known result. It must not decide audit scope, judge whether evidence is sufficient, conclude that a control works, rate a finding, or close an issue. Those decisions belong to accountable auditors, and an agent can only prepare the ground for them.

This article is for internal auditors, chief audit executives and the managers and audit committee members who oversee them. After reading it you will be able to sort audit tasks into automate now, automate with review gates, and keep human. You will also have a short list of access rules, evidence requirements and escalation triggers to put in place before any agent touches a workpaper. The question to ask is not whether AI can replace internal auditors. Ask which audit activities are bounded enough to automate safely, and which decisions need independent professional judgment and a named person who answers for them.

Agentic AI can cut audit hours, but only if you start in the right place. This guide shows internal auditors which evidence tasks to automate first, which decisions never leave human hands, and how to set access limits, audit trails and escalation rules. It includes a three-way match example, a ninety day rollout plan and questions for your audit committee. I assumed the reader is an internal auditor or chief audit executive, and the platform is Blogger (GRC). The article has 9 sections, a first-wave automation table, a worked three-way match example and a ninety-day rollout. It also has audit committee questions and red flags.

SOX Controls Over AI

Consider a composite situation, not a real engagement. A controller opens the monthly bank reconciliation, and the matching tool shows 1,250 unmatched items out of 18,400 bank lines. The accounting manager reviewed every item and approved the package. The external auditor asks which version of the matching logic produced that list, whether the bank file was complete when the tool ran, and what the reviewer saw on screen. Nobody can answer. The matching feature arrived in an ERP update that the supplier switched on, and the SOX risk and control matrix still describes a spreadsheet.

If AI influences financial reporting, your organization must be able to show five things: where the AI is used, how it works, that its inputs and outputs are reliable, that changes to it are controlled, and that a human exercised oversight and left evidence of it. Each of those five becomes an auditor question, and this article takes them in the order a SOX program would address them. Treat the five questions as a practical synthesis of current auditor concerns. No official PCAOB or SEC checklist with five questions exists, and I would be wary of anyone who presents one. The article is written for controllers, SOX control owners, and internal auditors who need working answers before fieldwork starts.

You do not need a separate AI compliance program to get there. COSO released guidance on internal control over generative AI in February 2026 that applies its Internal Control Integrated Framework to generative AI, and it names the risks that matter most to financial reporting: prompt-based manipulation, opaque reasoning, model drift, and frequent configuration changes. SEC staff remarks at the December 2025 AICPA and CIMA conference, as summarized in an EY compendium, pointed the same way, with attention on model design, data, human oversight, and the way AI changes IT general controls. What follows turns that direction into an inventory, a control narrative standard, a validation plan, a change register, and a failure path you can build this quarter.

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.

The Risk Management Blueprint for Quantitative and Predictive Models by Prof. Hernan Huwyler, MBA CPA CAIO | Quantitative Risk Management, Predictive Analytics, Probabilistic Risk Models, Monte Carlo Simulation, Financial Risk Modeling, Enterprise Risk Management, Operational Risk, Cyber Risk, AI Risk Management, Risk Analytics, Loss Distributions, Value at Risk, Expected Shortfall, Risk Exposure, Risk-Adjusted Decision Making, Automated Risk Controls and Agentic AI

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.

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 Hernan Huwyler

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

Governance, Risk Management and Compliance

Pages