By Khalil El Aouadi
Segregation of Duties can look fully compliant on dashboards, yet the most critical risks are often the ones that remain invisible. In this piece, Khalil El Aouadi draws on hands-on experience across organizations to show how silent SoD conflicts emerge when accountability is unclear and monitoring relies solely on system outputs. By connecting real-world observations with ISO/IEC 27005 and COSO ERM principles, the article argues that effective SoD governance requires business ownership grounded in operational reality, not just IT controls or formal reviews.
There is a well-known saying, often referred to as Sod’s Law (or Murphy’s Law, depending on which side of the Atlantic you are on): Anything that can go wrong, will eventually go wrong.
After several years working on Segregation of Duties (SoD)¹ topics, I have started to think that SoD follows a similar, unwritten rule of its own. I tend to call it SoD’s law (pun intended):
When accountability is unclear, SoD will eventually fail, no matter how strong the controls are.
When Everything Looks Compliant, But Something is Off
On one particular engagement, the setup looked solid at first sight. The SoD matrix² had been reviewed and formally approved. The incompatible business functions were clearly documented. SAP GRC Access Risk Analysis (ARA) tool was in place, producing accurate reports. From a governance perspective, everything seemed to be under control.
And yet, when spending time with the business and looking more closely at how work was actually performed, it became clear that certain users were effectively carrying out two incompatible business activities. Not because the risk was ignored or misunderstood, but because the technical ruleset translating the SoD matrix into SAP authorization logic was not exhaustive. Some combinations simply did not generate conflicts.
The risk existed conceptually and it existed in documentation. But it did not exist in the system, and therefore it did not exist in reporting or decision-making.
This creates a dangerous governance void. When a risk is invisible to monitoring tools, it isn’t just a technical oversight; it is an open window that remains undetected for a long period. In the world of internal control, this is called a “Dwell Time“³. Because the system stays silent, these risks act like long-term parasites, draining the organization long before the first red flag appears, as the Association of Certified Fraud Examiners’ report to the nations (2024) shows:
The Most Dangerous SoD Risks are the Silent Ones
In SoD, a risk that generates conflicts will eventually be discussed. It will be remediated, mitigated, accepted, or escalated. At the very least, it enters the governance process.
But a risk that generates no conflicts (also called as a false negative) follows a very different path though. It produces no alerts and doesn’t reflect on KPIs. Over time, this creates a quiet form of comfort: dashboards remain green, reviews remain superficial and naturally no one considers himself responsible for challenging what is not visible.
Reliable data from the ACFE Report to the Nations (2024) confirms that formal audits, the very tools we often trust most to find these issues, trail significantly behind human intervention. This is because formal audits often lack the vital operational proximity required to spot the nuance of a bypass, Instead, the data reveals that human detection through proximity remains the most powerful defensive layer:
This shift fundamentally changes how applications behave in production, enabling performance, scalability, and maintainability that monolithic designs cannot achieve.
What ISO 27005 brings to the table, and where it stops
ISO/IEC 27005:2022 is an information security risk management standard. Its purpose is to structure how organizations identify risks, assign accountability, decide on treatment options, and accept residual risk. It strictly defines the Risk Owner as the “person or entity with the accountability and authority to manage a risk.”
However, the standard remains flexible, and perhaps too vague, about who this person should be. It states that “Top management, the security committee, process owners, functional owners, department managers and asset owners can be the risk owners.”
In my case, the organization chose a high-level manager as the owner. They had the authority, but they lacked the proximity. They relied on the assumption that if a risk existed, a report would tell them. When the system stayed silent and the SoD risk did not generate conflicts, they couldn’t exercise their authority because the “signal” never reached them.
Why COSO ERM Suddenly Becomes Relevant
This is why we must overlay COSO ERM (2017) onto the ISO structure.
COSO ERM (2017) is a governance framework that looks at how organizations identify and manage risks across the business, not as a separate control exercise, but as something embedded in day-to-day operations.
COSO doesn’t just look at “controls”; it looks at integration. It defines Enterprise Risk Management not as a function, but as “the culture, capabilities, and practices, integrated with strategy-setting and performance.”
Crucially, COSO warns against the exact failure I witnessed. It states that “risks originating at a transactional level may prove to be as disruptive as those identified at an entity level.”
Principle 10 of the framework⁴ provides the “how” to fix this blind spot. It requires that the organization identifies risks that impact the performance of strategy and business objectives.
From a COSO perspective, the failure wasn’t a “tooling bug.” It was a failure to integrate risk awareness into day-to-day operations. The organization assumed: “If a risk exists then the tool will spot it.” COSO reminds us that risks do not disappear just because they are not reported.
Who Could Realistically Have Noticed?
The only people who could notice were those close enough to the process to see that “Standard Operating Procedure” had drifted away from “System Design.”
One thing is important: This is not about creating new roles or adding complexity. It is simply an acknowledgement that some risks cannot be detected by systems alone. They require a dual detection built on human observation, proximity to operations, and a basic understanding of why the risk exists in the first place.
We need to stop relying on single-source detection. My thesis is simple:
- ISO 27005 creates the empty seat for the Risk Owner.
- COSO ERM argues that the person sitting in that seat must be close to the “transactional level” to see the reality that GRC reports and dashboards might miss.
In practice, Segregation of Duties risks should therefore be owned by the business manager accountable for the process, for example a Procure-to-Pay or Order-to-Cash lead, but that ownership only works if it is informed by people close enough to the operations to see when reality drifts away from control design.
The industry trend supports this urgency. While general control environments are stabilizing, specific weaknesses in SoD are actually rising, as the KPMG’s 2024 Material Weakness Study, covering annual filings released by SEC-registered public companies for FY 2024, shows:
Segregation of Duties rarely fails because frameworks are wrong. More often, it fails when we trust green dashboards more than the reality of operational frontline. And when that happens, Segregation of Duties quietly follows its own law.
About the Author
An experienced Senior Consultant specialised in SAP Security & Authorizations, SAP GRC, and Segregation of Duties, he helps global organizations strengthen risk management while supporting business performance. He has worked on large international projects for leading companies across the luxury, pharmaceutical, and industrial sectors.
In addition to SAP security and access governance, he has delivered internal control and SOX-related missions, providing a broad view of risk, compliance, and operations. A certified ISO 27001 Lead Implementer, he combines technical expertise with business understanding to support CIOs, CFOs, and Audit & Compliance teams on critical initiatives.
¹ SoD is the fundamental internal control principle that involves dividing tasks and responsibilities among different individuals to reduce the risk of errors, fraud, and unauthorized actions.
² A control mapping tool used to identify and visualize incompatible business functions. It intersects different roles or permissions to flag combinations that, if held by a single user, would violate the principle of segregated duties.
³ The period between the first occurrence of a violation and its eventual discovery.
⁴ Identifies risk.