What breaks in ICFR when the same identity can approve and execute a financial transaction?

Why ICFR breaks when one identity can both approve and execute

ICFR depends on a control design where no single identity can complete a transaction from end to end without independent review. If the same identity can approve and execute, the control stops testing challenge, not just process completion. The weakness is not only fraud risk, but also the loss of evidence that a separate approver ever exercised meaningful judgment.

That matters because approval is supposed to be a control over authority, while execution is supposed to be an act taken after authority is granted. When both sit behind one set of credentials or one role, the workflow can still look compliant on paper while the actual control objective has failed.

For organisations that want a practical model of this control separation, the Segregation of Duties (SoD) Guide is the clearest reference point, because it treats conflicting permissions as a design problem rather than a documentation problem.

Where the control failure shows up in the workflow

The break usually appears in one of three places: transaction initiation, approval, or posting and execution. If a role can sign off on its own work, the organisation no longer has an effective preventive control at the approval stage. If the same identity can also post, release, or settle the transaction, the trail no longer proves that authorisation was independent.

That creates a false sense of control completeness. A system may still log every action, but the log now records one actor performing all relevant steps. In ICFR terms, that is a process integrity problem because the evidence no longer demonstrates segregation, escalation, and review by different parties.

The right way to think about the issue is by lifecycle, not just by transaction. The NHI Lifecycle Management Guide is useful here because it frames access as something that must be provisioned, reviewed, and removed with the same discipline as any other privileged capability.

It is also worth using the Financial Services Identity Security Guide as a reminder that finance workflows often combine privileged access, third-party exposure, and audit expectations, so role design has to match the evidence standard, not just the operating convenience.

What auditors and control owners should look for first

Control owners should start with the permission model, not the transaction sample. The key question is whether approval, release, and execution are separated at the identity, role, or entitlement layer. If they are not, the issue is systemic and cannot be fixed by sampling a few clean transactions.

In practice, the strongest remediation is to separate the approval right from the execution right, then verify that compensating controls are truly independent if a temporary exception is needed. The Segregation of Duties (SoD) Guide is especially relevant to that decision because it emphasises conflict rules and compensating controls rather than assuming a workflow is safe because it is automated.

Teams also need to check for shared accounts, delegated access, and break-glass paths that silently collapse the separation. A transaction can still be approved “by policy” while the same operator, service account, or privileged workflow has enough authority to complete the payment unchallenged.

When controls span finance and technology, the best reference point is often a broader identity programme, and the Identity Security Programme Guide helps tie access ownership, governance, and review cadence back to the ICFR requirement.

Risk and Threat Considerations

When the same identity can approve and execute, the control environment becomes vulnerable to both error and abuse. A bad actor does not need to defeat two separate approvals, and an honest operator can also accidentally bypass review if the role design permits self-approval or one-click release.

Failure mechanism: The environment collapses segregation at the entitlement layer, so one set of credentials can create, authorise, and complete a financial transaction without independent challenge. That removes the main control barrier that would otherwise surface misconduct, mistakes, or unauthorised changes before posting.

Impact: The organisation increases misstatement risk, fraud exposure, and audit failure risk, because the evidence trail no longer proves that approval was independent or that the transaction was subject to meaningful review.

Practitioner Guidance

What to verify: Confirm that the approval path and the execution path are enforced by different roles or identities in the live system, not just documented in policy. If an approver can also post, release, or settle the same item, treat that as a control design defect until proven otherwise.

Common mistake: Do not rely on transaction logs alone as proof of control effectiveness. Logs show that something happened, but they do not prove that the approval was independent or that the approver lacked the ability to complete the transaction themselves.

Decision rule: If a single identity can complete the whole transaction chain, prioritise access redesign and compensating controls before you look for evidence of actual abuse. Practitioner takeaway: in ICFR, the control fails when authority and execution converge in one identity, even if the workflow still leaves a detailed audit trail.

Related resources from NHI Mgmt Group

• What breaks when one person can create and approve the same financial transaction?
• What breaks when one role can approve and execute the same transaction?
• Who is accountable when a control failure lets one identity approve and execute the same transaction?
• What breaks when the same identity can both create and approve a transaction?