A change management audit over financial systems tests three distinct controls for every change in the sample or population: that the change was authorised before development began, by someone with the authority to approve it and independent of the person requesting it; that the change was tested, with documented test results, before being moved into the production environment where it affects live financial data; and that the person who moved the change into production is different from the person who developed it, so that an unauthorised or untested change cannot be self-deployed by its own developer.
Why each control needs separate evidence
These three controls fail independently of each other, which is why testing only the change ticket's final approval status misses most of the risk. A change can be properly authorised on paper and still be deployed without adequate testing. It can be thoroughly tested and still be deployed by the same developer who wrote it, bypassing the segregation that catches an error or a deliberately inserted unauthorised function. Evidence for each needs to be checked on its own terms.
| Control | Evidence to obtain | What it catches |
|---|---|---|
| Authorisation before development | Change request with approval timestamp preceding the development start date | Development started before approval, or approval backdated after the fact |
| Testing before production deployment | Test case documentation, test results, sign-off, dated before the deployment timestamp | Changes deployed with no test evidence, or test evidence dated after deployment |
| Developer-deployer segregation | User ID of the developer versus the user ID who executed the production deployment | The same person who wrote the code also pushing it live, with no independent check |
| Emergency change process | Separate emergency-change log with post-implementation review evidence | Normal change controls bypassed under an emergency label for changes that were not actually emergencies |
Emergency changes need their own test
- Confirm the entity has a defined emergency change process, separate from the normal process, with its own criteria for what qualifies as an emergency.
- For every change logged as an emergency, check whether it genuinely met the entity's own criteria, or whether the emergency route was used to bypass normal authorisation and testing for a change that could have waited.
- Confirm every emergency change received a post-implementation review — the control for an emergency change is not the absence of prior review, it is prior review being replaced by a documented review immediately after.
A high proportion of changes logged through the emergency route, relative to the normal route, is itself worth investigating — it often means the normal process is too slow or too bureaucratic for the business to tolerate, and staff are routing around it rather than following it.
This is practical guidance written for audit teams, not an authoritative statement of any standard or statute. Standards, forms and timelines change. Check the current text issued by the ICAI and the relevant authority before relying on anything here in an audit file.
Related resources
- Internal audit & IFCIFC testing: internal financial controls over financial reportingHow IFC testing differs from a substantive statutory audit, what design versus operating effectiveness testing actually means in practice, and what the file needs to show for each.
- Technology, data & AI in auditThe audit trail rule: what accounting software must doThe feature is usually present in the software and switched off, not missing. How to actually test which one is true before relying on it.
- Internal audit & IFCTesting segregation of duties: a practical approachThe classic SoD conflicts, how to test for them in a small finance team where perfect separation is not realistic, and how to document the compensating controls that stand in.
- Internal audit & IFCControl walkthrough documentation: what belongs in the fileWhat a control walkthrough has to establish beyond description, narrative versus flowchart formats, and the shortfalls that recur most often on file inspection.
Free tools, no signup
Each one reads a file entirely in your browser — or, for two of them, just answers a few questions — and nothing is ever uploaded.
- Purchase register checkDuplicate payments, round-sum amounts, weekend-dated invoices, incomplete records.
- GSTR-2B reconcilerMatches your purchase register against GSTR-2B — missing invoices either side, amount mismatches.
- Bank reconciliation checkerMatches your cash book against a bank statement — what's outstanding on each side.
- Fixed asset register checkDuplicate asset codes, missing location or useful life, negative net book value.
- Payroll red-flag scannerBank accounts shared across employees, and records missing an ID, PAN or salary.
- CARO applicability checkerAnswer a few questions about the company and see which CARO 2020 clauses likely apply.
- MSME payment delay checkerMSME-flagged invoices paid — or still unpaid — beyond the 45-day Section 22 limit.
- Related-party transaction screenerTransactions above a threshold you set with no approval reference, grouped by counterparty.
- Depreciation useful life checkerCompares a useful life in use against the Schedule II, Part C indicative figure.
- Materiality calculatorOverall and performance materiality against PBT, revenue, assets or equity, with reasoning shown.
- Sample size calculatorStatistical sample size for a test of controls or a substantive test of detail.