What IT General Controls Actually Are

What IT General Controls actually are. Most people meet ITGC as a list, access management, change management, backups, physical security. The list is accurate and almost completely useless, because it tells you what to test without telling you why any of it matters. Here is the version that actually helps.

Imagine you are auditing a company’s revenue. The system automatically matches every invoice against a purchase order and a goods receipt, and rejects anything that does not line up. You test it. It works. Perfectly, every time. Can you rely on it?

Not yet. You have proven the control works today, on the version of the system running right now. You have proven nothing at all about the other three hundred and sixty-four days in the period. And that gap is exactly where I-T-G-C lives.

There are two kinds of control in any system, and confusing them is the most common beginner mistake. Application controls are rules inside the business process. The invoice must match the purchase order. The credit limit must be checked before the order is accepted. Journal entries need a cost centre. These controls do specific work on specific transactions.

IT general controls govern the environment those rules live in. Who can change the matching logic. Who can access the database underneath it. Whether the change was tested and approved. Whether you could recover the system if it failed.

And the relationship between them is one-directional. It is the single most important idea in IT audit. An application control is only as reliable as the general controls surrounding it. If a developer can quietly alter that matching logic on a Tuesday afternoon with no approval and no record, then your perfect test result means nothing. You did not test a control. You tested a configuration that happened to be in place while you were looking.

Once you internalise that dependency, audit strategy follows from it. When general controls are strong, you can test an automated application control once and rely on it for the whole period, because the system cannot have changed underneath you without leaving a trace. When they are weak, that efficiency disappears, you fall back to testing individual transactions in volume, which costs far more and gives you less assurance. This is also why weak governance is called pervasive. It does not produce one finding in one place. It removes the foundation every other conclusion was resting on.

So stop thinking of I-T-G-C as a security checklist. Think of it as the answer to one question an auditor is always asking: can I trust that this system behaved the same way all year? Every control group is a different way of asking it. Governance asks whether anyone owns the answer. Access management asks who could have changed things. Change management asks whether changes were controlled. Business continuity asks whether the record survives. Physical security asks whether someone could bypass all of it by walking into a room. Hold that question in your head, and the framework stops being a list to memorise. It becomes a structure that makes sense.