What auditors actually test in IT general controls

Short answer: IT general controls are examined under four headings — who can get into the system and what they can do, how changes to it are approved, how new systems are implemented, and how it is operated day to day. If those are weak, the automated controls inside the system and the reports it produces cannot be relied on, so the auditor has to fall back to substantive testing.

If your auditor has started asking for user lists, change approvals and backup logs, this is what sits behind those requests.

Why these controls come first

There is a dependency chain that explains the whole exercise.

Accounting records are produced by a system. Inside that system sit application controls — an approval limit, a three-way match, a duplicate-invoice check. An auditor would like to rely on those, because a configured control that runs on every transaction is stronger evidence than testing a sample by hand.

But a configured control is only as good as the controls stopping someone from reconfiguring it. If a user can quietly raise their own approval limit, or edit a posted entry without trace, then the automated control proves nothing. That is what IT general controls establish: whether the environment around the application is trustworthy enough for anything inside it to be relied on.

Get this wrong and the consequence is not a minor observation. The auditor cannot rely on system-generated evidence, testing expands substantially, and the audit becomes slower and more intrusive.

The four domains

Access to programs and data

Usually the largest source of findings, and the one management can fix fastest.

What is examined: whether every user has a named account rather than a shared one; whether joiners are provisioned on approval and — far more commonly missed — whether leavers are actually deprovisioned; who holds administrator or superuser rights and why; whether password and session settings are enforced by the system rather than by policy; and whether someone reviews the user list periodically instead of it accumulating for years.

Underneath all of it sits segregation of duties: whether the same person can create a vendor and approve a payment to it, or post an entry and approve it. Segregation on an org chart means nothing if the system permits both actions under one login.

The recurring finding in mid-size Indian companies is a shared administrator account, often known to the accounts team and the software vendor alike. It cannot be attributed to a person, so it undermines both segregation of duties and the evidentiary value of the audit trail. It is also usually fixed within a week by issuing named accounts.

Change management

What is examined: whether changes and customisations are requested and approved before being made, whether they are tested before going to production, and whether the person who writes a change is different from the person who deploys it.

Smaller companies frequently have no change register at all — the ERP partner makes changes over email or a call. That is a genuine weakness rather than a formality, because an undocumented change to a tax rate, an approval matrix or a posting rule can misstate accounts for months before anyone notices.

Program development

Relevant in a year where a new system went live or a major module was added. What is examined: whether the implementation was approved, whether users tested it before go-live, and — most importantly for audit — whether opening balances migrated from the old system were reconciled to it. Migration reconciliation is where the real audit risk sits, and where evidence is often thin.

Computer operations

What is examined: whether scheduled jobs run and failures are noticed, whether backups run and have actually been restored in a test, and whether incidents are recorded and resolved.

Backups deserve a specific note. Almost every company has backups. A materially smaller number has ever restored one to confirm it works. An untested backup is an assumption, not a control.

The India-specific piece: the audit trail rule

This is where Indian ITGC diverges from the global template, and it applies to companies of every size.

The proviso to Rule 3(1) of the Companies (Accounts) Rules 2014 requires every company using accounting software for its books to use software that:

• records an audit trail of each and every transaction;
• creates an edit log of each change made in the books, with the date of change; and
• ensures the audit trail cannot be disabled.

It applies from the financial year commencing 1 April 2023, after being deferred twice from its original 2021 date. There is no turnover, capital or size threshold — unlike the IFC reporting exemption, which does have thresholds. A small private company using an accounting package is squarely within it.

Correspondingly, Rule 11(g) of the Companies (Audit and Auditors) Rules 2014 requires the auditor to report on whether:

1. the software has the audit trail (edit log) feature;
2. it operated throughout the year for all transactions recorded;
3. the feature was not tampered with; and
4. the audit trail has been preserved per statutory record-retention requirements.

Four practical consequences follow, and each catches companies out:

• "Throughout the year" is a real test. Enabling the feature in February does not satisfy a full-year assertion, and the auditor is expected to say so.
• Preservation runs long. The audit trail is part of the books, and Section 128(5) requires books and vouchers to be kept for not less than eight financial years preceding the relevant year. A company switching accounting software cannot simply decommission the old one — the trail has to stay retrievable.
• Version matters. Older versions of common packages either lack the feature or allow it to be switched off. Being on a licensed product is not the same as being compliant; the specific version and its configuration is what counts.
• It is a reportable item, not an internal matter. Non-compliance surfaces in the auditor's report, where lenders, investors and acquirers read it.

ICAI has issued an Implementation Guide on reporting under Rule 11(g), which is the reference point for how auditors are expected to approach it.

Application controls and the reports you hand over

Two things sit alongside ITGC and are worth anticipating.

Application controls are the configured checks inside the system — approval hierarchies, three-way matching, duplicate-invoice blocks, credit limits, mandatory-field rules. Where these operate and ITGC is sound, an auditor can rely on them, which reduces sample sizes.

Information produced by the entity is the one people rarely expect. When you export a report from the system and hand it to the auditor as evidence — an ageing analysis, a stock summary, a fixed-asset register — the auditor has to satisfy themselves the report is complete and accurate, not just that it is on letterhead. That means understanding the parameters and filters used to generate it and, where relevant, reconciling it to the ledger. Reports assembled in Excel from a system extract get the most scrutiny, because a filter or a stale pivot is invisible on the printed page.

What tends to get found

In owner-managed and mid-size companies, the same handful recur:

1. A shared or generic administrator login.
2. Ex-employee accounts still active, sometimes years later.
3. Audit trail absent, disabled, or enabled part-way through the year.
4. No record of who approved an ERP customisation.
5. Backups taken but never restore-tested.
6. The same user able to both post and approve.
7. Excel-based reports given as audit evidence with no support for completeness.

None of these are exotic, and most are inexpensive to fix — but they are far cheaper to fix before the audit than to explain during it.

If you want to get ahead of it

Pull your user list and check every account against a current employee. Confirm your accounting software version has the audit trail feature, that it is on, and that it cannot be turned off. Start a simple change register even if it is a spreadsheet. Restore one backup and keep the evidence. Those four steps address most of what is commonly found.

The scope of a full review — documentation, testing and remediation — is set out on the internal financial controls and IS audit page.

The same user lists and access logs an auditor asks for are also the evidence that a data-protection obligation is being met, and the two reviews are worth running together rather than a year apart — see what the DPDP Rules require, and from when.

This note describes the general approach to IT general controls under Indian requirements. What applies to a particular company depends on its systems, size and audit scope, and should be confirmed against them.