Who is accountable when weak access controls enable prolonged internal fraud?

Why This Matters for Security Teams

When weak access controls allow prolonged internal fraud, the issue is rarely a single bad actor and more often a control failure that spans approval, review, and monitoring. Security teams need to treat this as an accountability problem, not just an access problem. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls and the CIS Controls v8 both point to recurring duties around access review, separation of duties, and auditability, but those controls only work when business ownership is explicit.

NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for any environment that still relies on informal trust and after-the-fact discovery. The same governance gaps that affect NHIs also show up in human access paths when exceptions are tolerated for too long, especially in finance-adjacent systems and privileged workflows, as discussed in the Ultimate Guide to NHIs and the 52 NHI Breaches Analysis.

In practice, many organisations discover the accountability gap only after a fraud review exposes that nobody owned the exception process end to end.

How It Works in Practice

The practical answer is to map accountability to control points, not to job titles alone. Business owners should approve access based on defined need, managers should review exceptions on a schedule, and control functions should verify that access matches behaviour. Internal audit then tests whether the process exists and whether it is actually followed. This is consistent with the intent of OWASP Non-Human Identity Top 10, which highlights how weak lifecycle control and over-privilege create durable exposure, even when access appears formally approved.

For fraud scenarios, the key operational question is whether access can be traced from request to approval to usage. That means:

• named approvers for each sensitive system or payment path
• time-bounded access with periodic recertification
• exception logging with expiry dates and documented compensating controls
• segregation of duties so no single person can request, approve, and execute the same high-risk action
• monitoring for abnormal patterns such as repeated overrides, dormant access reuse, or access after role change

Where organisations have mixed human and machine workflows, the same discipline should apply to service accounts and automation. The Ultimate Guide to NHIs - Key Challenges and Risks shows why excessive privileges and weak rotation become durable attack paths, and those lessons transfer directly to human-access governance when teams rely on standing access instead of enforced review. These controls tend to break down when exceptions are permanent, approval chains are informal, or ownership is split across finance and IT without a single control owner.

Common Variations and Edge Cases

Tighter approval and review controls often increase operational friction, requiring organisations to balance fraud prevention against business speed. That tradeoff is real, especially in finance teams, shared service centres, and seasonal operations where temporary access is common. Current guidance suggests using short-duration exceptions and stronger logging rather than allowing standing overrides, but there is no universal standard for every business process.

In some cases, accountability is shared by design: finance may own the process, identity teams may own the tooling, and internal audit may own independent assurance. The risk appears when one of those groups assumes another is monitoring exceptions. That is why policies should name a control owner, a reviewer, and an escalation path. When the process crosses regulated payment systems, frameworks such as PCI DSS v4.0 reinforce the need for least privilege and periodic access review, even if the underlying fraud issue is internal rather than external.

A further edge case is long-dormant access that was technically valid but practically forgotten. That problem is common in legacy ERPs and shared finance platforms, where access recertification happens on paper but not in behaviour. In those environments, accountability fails when no team owns the clean-up after approval. The strongest control is a documented process that removes ambiguity before misuse becomes a pattern.

Related resources from NHI Mgmt Group

• Who is accountable when destructive access is enabled by weak internal controls?
• When should organizations review access controls?
• Who is accountable when a small business breach spreads through weak access controls?
• Who is accountable when hospitality data is exposed through weak access controls or poor redaction practices?