IT general controls: the foundation every application control stands on

IT general controls are the controls over the environment in which financial systems run: who can get into them, how changes reach them, how they are operated, and how the data behind them is protected. They are called general because they are not specific to any one transaction — they underpin every automated control and every report the system produces.

That is also why they matter more than their unglamorous name suggests. If anyone can change the code, or grant themselves rights, or run an unlogged data fix, then no automated control in that system can be relied upon and no report from it is evidence of anything. Weak ITGC does not produce one finding; it invalidates a whole layer of controls above it.

The four domains of IT general controls

• Access to programs and data: joiners, movers and leavers; privileged accounts; periodic recertification; authentication.
• Program change: changes requested, tested, approved and moved to production by different hands than those that wrote them.
• Program development: new systems and major implementations, including data migration and its reconciliation.
• Computer operations: job scheduling and failure handling, backups and their restoration tests, incident management.

Access is where most findings land, and within access, privileged accounts are where the serious ones land. A developer with standing production access defeats the change control domain entirely, no matter how well the change process is documented.

What testers actually ask for

1. A complete list of users with access to the system, generated by the tester or in front of them, with evidence of completeness.
2. Leaver samples: the termination date, and evidence access was removed, with the date.
3. Change samples: the request, the test evidence, the approval, and who deployed it.
4. The list of people who can move code to production, with the business reason for each.
5. Backup restoration evidence — not the backup log, the restore test.
6. Evidence that periodic access reviews were performed and their actions completed.

The single most common cause of an ITGC failure is not a missing control but an incomplete population. If you cannot demonstrate that the user list or the change list is complete, samples drawn from it prove nothing — and the tester is required to treat the control as untested rather than effective.

ITGC in a small company using SaaS

When the accounting system is somebody else's cloud service, the change and operations domains largely move to the provider, and their assurance report becomes part of your evidence. What does not move is access: you still decide who has rights in that system, you still onboard and offboard, and you still have to show that this was reviewed.

Read the provider’s report properly rather than filing it. It will list complementary user entity controls — the things the provider assumes you are doing. Those are your controls, and testers check them.

Because access is the domain that stays with you, the roles have to be explicit rather than conventional. Ettex Teams keeps permissions per workspace and per role, so producing the user list and evidencing what each role can do is a report rather than an investigation — and the segregation of duties analysis runs against the same list. Change and operations for the platform itself remain the provider’s side of the line, which is exactly what the assurance report is for.