Server room lights representing systems behind manual controls

Field guide

IT-dependent manual controls

The bridge where a system produces information and a person still decides, posts, clears, or signs — and why that distinction matters for finance teams and auditors in Korea.

What we mean by the bridge

An IT-dependent manual control uses application output, configuration, or workflow state — but still requires a human to apply criteria. Classic examples: reviewing an ERP aging report and clearing exceptions, approving a journal after system validation, or signing a spreadsheet reconciliation fed by a system extract.

If the person is optional, it is not this control type. If the system is optional, call it purely manual. Mislabeling either way confuses testing and overstates assurance.

Laptop on desk representing the finance system interface

Failure modes we see often

Population drift when the report filter changes quietly. Criteria that live only in someone’s head. Sign-offs that never record which version of the export was reviewed. Exception queues that clear tickets without retaining why. Access reviews that rubber-stamp IT extracts without business residual ownership.

Training cannot invent missing ITGC monitoring — but it can stop finance from claiming automation that is not there.

Code and systems metaphor for IT dependency

When to escalate to ITGC owners

01

Configuration claims without evidence

If management says “the system blocks this,” ask for the rule, the environment, and who can override. That is ITGC and application territory.

02

Unstable extracts

When report logic changes between periods without change tickets, finance cannot honestly claim a stable population — escalate rather than invent compensating theater.

03

Privileged paths around the bridge

If privileged users can post around the approval queue, document the residual and involve ITGC — do not hide it inside a manual control description.