Where establishing internal controls, policies and procedures usually breaks

This process usually breaks where a decision made at the top has to become a system setting or a daily habit further down. Risk tolerances, role assignments and control documents drift away from what staff actually do. The gap surfaces later as audit findings, manual overrides and repeated rework.

Risk objectives that never reach the control owner

Risks get defined in a workshop. Business process objectives get written up and approved. Then the document goes to a shared folder, and the person who approves invoices or sets up vendors never sees it.

The break is the handoff from risk definition to control design. Controls end up built around what the system already does. They are not built around what could go wrong.

How to tell: ask a control performer which risk their check addresses. If they describe the task and cannot name the risk, the link was never made. Another sign is a risk register with entries that map to no control at all.

Roles assigned on paper and not in the system

A responsibility matrix names who prepares, who reviews and who approves. System access is granted by a different team, often from a request form that predates the matrix. The two drift apart quietly.

Segregation of duties fails here more than anywhere else. The same person can create a payee record and release a payment to it. Someone who changed roles still holds approval rights in the old area.

How to tell: compare the access listing for the general ledger, payee master data and funds control tables against the documented roles. Mismatches are the evidence. So is a reviewer who signs off on work they have no system ability to see.

Tolerances set in policy and configured differently

Entity and unit risk tolerances are agreed by leadership. Someone then has to translate them into thresholds: how far an obligation may differ from its commitment, or an expenditure from its obligation, before the system stops it. That translation is often done once, by a configuration analyst, from memory or from an old setting.

When policy changes, the configuration rarely follows. Funds control rules keep allowing what the policy now forbids, or block what it now permits. Staff learn the workaround.

How to tell: pull the current tolerance values and overspending controls straight from the system and set them beside the approved policy. Frequent requests to temporarily lift a limit point the same way. Those requests mean the setting no longer fits how the work runs.

Exceptions handled outside the control

Every control produces exceptions. A vendor record lacks a required attribute. A cost center that should be closed still receives charges. A transaction fails the funds check at the end of a reporting cycle.

The documented procedure says route it for approval. In practice it goes to an inbox, gets fixed by whoever knows how, and leaves no trail. Auditors later find the correction and no record of who allowed it.

How to tell: look for spreadsheets kept beside the system to track holds, overrides or pending fixes. Look for journal entries posted with vague descriptions near close. Ask how many people know the override process; if the answer is a single name, that person is the control.

Documentation that describes an older process

Cycle memos and procedure narratives are written to satisfy an audit. They then sit untouched while systems are upgraded and teams reorganize. When the next round of auditor requests arrives, staff rebuild evidence under pressure and discover the memo no longer matches the steps.

How to tell: the walkthrough with an auditor takes far longer than expected. Preparers ask each other what a memo means. Sample documentation has to be recreated from emails because the system report named in the procedure was retired.

Audit findings that stop at the adjustment

A finding leads to a correcting entry. The entry gets booked, the finding is marked resolved, and the control that let the error through stays exactly as it was. The same finding returns in the next review with a different sample.

How to tell: read findings side by side across audit cycles. Repeat themes mean the fix went to the ledger and never to the design.

An ethics code nobody consults

The code of ethics gets signed at onboarding and filed. When a staff member sees pressure to bypass a control, the code offers no clear route for raising it, and the audit committee hears only summarized results. Warning signs reach oversight late or not at all.

How to tell: ask staff where they would report a concern about an override. Hesitation is the answer. Audit committee minutes that never record a control exception also suggest information is being filtered.

Questions to ask the people who run the process

• When the system blocks a transaction, what happens next, and who decides?
• Which checks are done on paper or in a spreadsheet because the system cannot do them?
• Has anyone been asked to approve something outside their usual area to keep work moving?
• What gets fixed quietly before an audit sample is pulled?
• Which procedure document does the team actually open, and which ones have never been read?
• When a policy changes, how does the new rule get into the system settings, and who confirms it did?
• Who would be missed most if they left tomorrow, and what would stop working?
• What did the last audit finding change in how the work is done, beyond the correcting entry?

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.