The Control That Exists on Paper, Not in the System

Ask a property company whether it has controls over its finances and the answer is yes, with documentation to prove it. There is a policy that says no payment over a certain amount goes out without a second approval. A rule that vendors must be verified before they are added. A requirement that journal entries above a threshold get reviewed. A statement that security deposits are kept separate from operating funds. These are written down, they were approved, and if an auditor or a lender asks, they can be produced.

Then something goes wrong, a payment that should have been stopped, a vendor that should never have been added, a fund that should have stayed separate, and the investigation reveals that the control existed entirely on paper. The policy said the thing could not happen. The system permitted it anyway. And the gap between what the policy claimed and what the system enforced was where the failure walked through, unnoticed, until it was expensive.

This gap is not an edge case. It is the normal condition of most control environments, and the reason is that a control written in a document and a control enforced by a system are different things that everyone treats as the same thing.

Auditors already have language for this

The distinction is not something this piece is inventing. It is the foundation of how professional auditors evaluate internal controls, and they separate two questions that organizations routinely collapse into one.

The first is design effectiveness: would this control, if performed exactly as described, actually prevent or detect the problem it targets? The second is operating effectiveness: did the control actually function, consistently, as designed, over a period of time? A control can pass the first test and fail the second completely. It can be beautifully designed on paper and simply not happen in practice, and auditors test the two separately precisely because a well-written control that does not reliably operate provides no protection at all.

Underneath that sits a hierarchy every auditor carries, and it is the key to this whole problem. Controls are ranked by reliability. A preventive control that stops something before it happens beats a detective control that catches it after. And an automated control enforced by the system beats a manual control that depends on a person remembering to perform it. The reason is not ideology, it is reliability: an automated preventive control operates consistently, every time, without depending on anyone's attention, while a manual control is only as reliable as the busiest, most distracted person in the chain on their worst day.

A control written in a policy but left to human discipline to carry out is, in this hierarchy, the weakest kind: manual, and often detective rather than preventive. A control built into the system's configuration so the prohibited action simply cannot occur is the strongest kind. The same stated rule, "payments over this amount need two approvers", can be implemented as either, and the two provide radically different levels of actual protection while looking identical in the policy binder.

The gap widens exactly when you would expect it to narrow

You would think that as organizations grow, add systems, and face more scrutiny, they would move controls from paper into the system, from manual into automated. The evidence suggests the opposite is happening.

KPMG's 2025 SOX survey found that automated controls actually fell as a share of total controls, from 21% in FY22 to 17% in FY24, even as the average number of in-scope systems jumped from 17 to 40 and average compliance program costs reached $2.3 million. Read that again: more systems, more cost, more scrutiny, and a smaller proportion of controls actually enforced by the systems. Organizations are adding manual, human-dependent controls faster than they are automating, which means the paper-versus-enforced gap is widening at exactly the moment complexity makes it most dangerous.

For a property company, the mechanism behind that statistic is easy to see. Each new entity, each acquisition, each additional system arrives with its own processes, and the fast way to impose control is to write a policy and tell people to follow it. Building the control into the configuration takes longer and costs more up front, so it gets deferred, and the deferral is invisible because the policy exists and looks like protection. The organization accumulates paper controls at the speed of growth and enforced controls at the speed of implementation projects, and those two speeds are not the same.

Where the paper controls hide in a property business

The gap shows up in predictable places, and they are worth naming because each one is a common point of real loss.

• Approval thresholds that are advisory, not enforced: The policy says purchases over a figure need a second signature. Whether the system actually blocks a single-approver payment above that figure, or merely recommends review, is the difference between a control and a suggestion. This is the same enforced-configuration question, approached earlier from the governance angle, of whether a threshold the system merely records is a control at all. Here the point is narrower: a threshold the system does not enforce is a paper control regardless of what the policy says.

• Segregation of duties that exists in the org chart but not in the permissions: The policy says the person who creates a vendor cannot also approve payments to it. Whether the system's roles actually make that combination impossible, or simply assume nobody would do both, is the whole control. Segregation that depends on people not doing something they are technically able to do is not segregation.

• Fund separation maintained by discipline: The requirement that trust or deposit funds stay separate from operating funds is a compliance obligation in most jurisdictions. Whether that separation is enforced by the account structure and the system, or maintained by staff remembering to keep the line, determines whether it is a control or a hope. A line held by discipline is one busy month-end away from being crossed.

• Review controls that are performed but not evidenced: The policy says a manager reviews certain entries. If the review happens but leaves no trace, it fails the auditor's operating-effectiveness test regardless of whether it occurred, because a control that cannot be evidenced cannot be relied upon. Many real controls fail here not because they do not happen but because nothing records that they did.

The honest part

Several qualifications keep this from becoming an argument that every control must be automated, which is neither achievable nor correct.

Not every control can or should be system-enforced. Some genuinely require human judgment, a review that weighs context, an approval that considers factors no rule can encode, and forcing those into rigid automation would either fail to capture the judgment or block legitimate activity. The goal is not to automate everything. It is to automate what can be automated, especially the high-consequence preventive controls, and to make the necessarily-manual controls genuinely operate and leave evidence, rather than existing only on paper.

It is also true that automated controls are not infallible. A control configured wrong enforces the wrong thing perfectly, and an automated control resting on weak IT general controls, poor access management, uncontrolled change, can be undermined without anyone noticing. Automation raises reliability only when the foundation under it is sound, so "build it into the system" is a beginning, not a guarantee. A badly configured automated control can be worse than a manual one, because people trust it more.

And a manual control that genuinely operates is far better than an automated control that was never properly implemented. The paper-versus-enforced distinction is not "manual bad, automated good" in every instance. It is that a control which depends on discipline carries a reliability cost that must be acknowledged and managed, not assumed away because the policy is well written.

The test to run

The practical move is to stop asking whether you have a control and start asking whether the system enforces it, which is a different and more uncomfortable question. For each control that actually matters, the high-consequence ones where a failure is expensive or a compliance breach, ask three things:

1. Is it preventive or detective?
   Does the system stop the prohibited action, or does something catch it afterward? Preventive is stronger, and for the highest-consequence risks it is what you want.
2. Is it automated or manual?
   Does the system enforce it regardless of anyone's attention, or does it depend on a person performing a step? If manual, it is only as reliable as execution under pressure.
3. Would it leave evidence?
   If an auditor asked you to prove this control operated every time over the last year, could you, or does its operation live only in people's memory?

The controls that come back detective, manual, and unevidenced are your paper controls, the ones that exist in the policy binder and not in the system. That is not automatically a crisis, some of them are fine as they are, but it is a list you should possess deliberately rather than discover during an incident or an audit. The single question that surfaces the whole problem: take the control you would be most embarrassed to have fail, and ask whether the system actually prevents the failure, or whether the only thing standing between you and it is that everyone has, so far, remembered to do the right thing. If it is the latter, the control was always on paper, and paper stops nothing.

FAQs

Q1. What is the difference between a control on paper and a control in the system?
A control on paper is a written policy that depends on people following it, such as a rule that large payments need a second approver. A control in the system is enforced by the configuration, so the prohibited action cannot occur, such as the payment system actually blocking a single-approver payment above the threshold. The two can describe the same rule while providing very different levels of actual protection.

Q2. How do auditors evaluate this?
They separate design effectiveness from operating effectiveness. Design asks whether the control, performed as described, would prevent or detect the problem. Operating effectiveness asks whether it actually functioned consistently over time. A control can pass the first and fail the second entirely, which is why a well-written policy that does not reliably operate provides no real assurance, and auditors test the two independently.

Q3. Why are automated controls considered stronger?
Because reliability is the whole point of a control. Auditors rank preventive controls above detective ones and automated above manual, since an automated preventive control operates every time without depending on anyone's attention, while a manual control is only as reliable as the busiest person in the chain on their worst day. The same stated rule provides very different protection depending on which type it is.

Q4. Isn't a growing company automating more of its controls?
Often the reverse. KPMG's 2025 SOX survey found automated controls fell from 21% of total controls in FY22 to 17% in FY24, even as in-scope systems more than doubled and program costs reached $2.3 million. Growth tends to add manual, policy-based controls at the speed of expansion while enforced controls arrive only at the speed of implementation projects, so the gap widens rather than closes.

Q5. Where do paper controls typically hide in a property business?
In approval thresholds the system recommends but does not enforce, in segregation of duties that exists in the org chart but not in the actual permissions, in trust or deposit fund separation maintained by staff discipline rather than by account structure, and in review controls that are performed but leave no evidence. Each is a common point of real loss precisely because the policy exists and looks like protection.

Q6. Should every control be automated then?
No. Some controls genuinely require human judgment that no rule can encode, and forcing those into automation would either lose the judgment or block legitimate activity. The aim is to automate what can be automated, especially high-consequence preventive controls, and to ensure the necessarily-manual ones actually operate and leave evidence, rather than treating automation as a universal requirement.

Q7. Are automated controls always reliable?
No. A control configured incorrectly enforces the wrong thing perfectly, and an automated control resting on weak IT general controls, such as poor access management or uncontrolled change, can be undermined silently. Automation increases reliability only when the underlying foundation is sound, and people's greater trust in automated controls can make a badly configured one more dangerous than a manual equivalent.

Q8. What is the single most useful question to ask?
Take the control you would be most embarrassed to have fail, and ask whether the system actually prevents the failure or whether the only thing preventing it is that everyone has so far remembered to act correctly. If protection depends on memory and discipline rather than enforcement, the control exists on paper, and paper does not stop the action it prohibits.