Who is accountable when insider fraud happens in a shared business system?

Why This Matters for Security Teams

Accountability in a shared business system is not just a governance question. It determines whether fraud is prevented, detected, contained, and attributable. When multiple teams can approve access, change workflows, and operate the same transaction path, gaps often appear between business ownership, IAM/IGA administration, and control design. That gap matters because fraud usually exploits ordinary entitlements, not exotic compromise.

NHI Management Group has repeatedly shown how hidden access paths and weak lifecycle controls widen exposure, including the findings in the Ultimate Guide to NHIs, where 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts. Shared systems fail in similar ways: too much access, too little review, and no clear owner for the combined control outcome. Current guidance from the NIST Cybersecurity Framework 2.0 still points to explicit ownership for governance, access control, and monitoring, but it does not remove the need to assign operational accountability inside the business.

In practice, many security teams encounter accountability disputes only after a fraudulent transaction has already been executed and the audit trail proves the control model was shared, but not owned.

How It Works in Practice

The most useful way to assign accountability is to separate responsibility by control layer. The business owner is accountable for the process outcome and for deciding what the system should allow. The IAM or IGA team is accountable for how access is provisioned, reviewed, and revoked. Control owners are accountable for whether the workflow design prevents one person from initiating, approving, and concealing a fraudulent action.

That means the question is not simply “who clicked the button?” It is also “who designed the path that made abuse possible?” If a shared ERP, finance, or claims platform allows a single user to create a vendor, alter payment details, and approve the release, the control failure is structural. The same logic appears in NHI governance: the Ultimate Guide to NHIs highlights how excessive privilege and weak visibility create conditions where misuse is difficult to attribute early. Fraud in a shared business system works the same way when segregation of duties is weak.

• Define the accountable owner for each transaction path, not just for the application.
• Document segregation of duties rules so no single role can initiate and conceal the same fraud scenario.
• Review privileged access against the actual workflow, not the job title.
• Log approvals, exceptions, and override decisions with named ownership.
• Test whether a single compromised or malicious account can complete the full fraud chain.

For control mapping, the NIST Cybersecurity Framework 2.0 is useful because it ties governance, access management, and continuous monitoring into one operating model, but it does not prescribe a universal fraud-accountability split. That is left to the organisation’s control design and risk appetite. These controls tend to break down in highly customised ERP and workflow environments because local exceptions, manual overrides, and shared service accounts blur the line between access administration and business ownership.

Common Variations and Edge Cases

Tighter segregation of duties often increases operational friction, requiring organisations to balance fraud prevention against process speed and emergency access needs. That tradeoff is especially visible in smaller teams, mergers, and legacy platforms where one person may legitimately perform multiple functions. In those cases, current guidance suggests compensating controls rather than pretending the risk does not exist.

There is no universal standard for this yet, but best practice is evolving toward explicit exception handling, time-bound approvals, and post-action review when full separation is impossible. Shared systems also need clear treatment of service accounts and automated actors, because fraud can be enabled by non-human identities that carry broad permissions and outlast the people who provisioned them. NHI Management Group’s research notes that 80% of identity breaches involved compromised non-human identities, which is a reminder that accountability must cover both human and machine operators when a business process is shared. The practical lesson is simple: if the control owner cannot explain who could abuse the workflow, the accountability model is incomplete.

Related resources from NHI Mgmt Group

• Who is accountable when an AI system changes infrastructure configuration?
• Who is accountable when account takeover fraud causes downstream losses?
• How should security teams prepare for identity-system outages that affect access to core business services?
• Who is accountable when a compromised mailbox is used for fraud?