Your external auditor now has to look at your IT. Most finance teams were not told.
Since ISA 315 was revised, auditors must identify the IT applications behind your financial reporting and test the general IT controls around them. The requests land at year end, they go to a finance team that has never seen them, and the answers sit with IT. We get you ready before that happens.
- ISA 315 revisedEffective for periods from Dec 2021
- Three IT processesAccess, change, operations
- Annual, fixed dateYour year end, not ours
- Evidence, not policyAuditors sample, they do not read
Eight things to understand before your auditor asks.
Why your auditor is asking at all
The revised standard requires the auditor to identify the IT applications and other aspects of your IT environment that are subject to risks arising from the use of IT, then identify those risks and the general IT controls that address them. This is not the auditor taking an interest in your security posture. It is a step they are required to perform in order to rely on the numbers your systems produce.
What counts as your IT environment, in the standard words
ISA 315 defines the IT environment as the IT applications and supporting IT infrastructure, plus the IT processes and personnel involved in those processes. An IT application is a program used in the initiation, processing, recording and reporting of transactions or information, and the standard notes this includes data warehouses and report writers. IT infrastructure means the network, operating systems, and databases with their related hardware and software.
The three IT processes the standard actually names
ISA 315 names them precisely: managing access to the IT environment, managing program changes or changes to the IT environment, and managing IT operations. Practice frequently teaches a four-domain model that separates program development from program change, and that is a reasonable way to organise the work. It is worth knowing which is the standard and which is convention, because your auditor works from the standard.
Access to programs and data, where most findings land
Who can reach the financial systems, how access is granted and approved, whether it is reviewed, how fast it is removed when somebody leaves, and whether anyone holds a combination of rights that would let them both create and approve a transaction. Auditors sample leavers specifically and they sample privileged users. Slow or undocumented removal is visible immediately and it is the single most common ITGC finding we see.
Change management, including the changes nobody logged
How changes to financial systems are requested, tested, approved and moved into production, and crucially whether the documented process is the one actually followed. Auditors test whether a change reached production without approval, and emergency changes are where that surfaces. A process that exists on paper while urgent fixes go straight in is a deficiency, not a nuance.
IT operations, meaning the things that keep it running
Batch job scheduling and monitoring, incident handling, and backup with evidence that a restore has actually been tested. This domain is often treated as the easy one and then produces a finding because backups are reported as successful while nobody has ever restored anything. Success reports are not restore evidence, and auditors have learned to ask the second question.
Evidence that can be sampled, not policies that can be read
This is the difference between a smooth audit and a difficult one. An auditor selects items and asks you to demonstrate the control operated for each: this leaver, that change, this access review. A policy document proves the control was designed. Only records prove it operated. Organisations that fail ITGC testing almost always have good policies and no retrievable records behind them.
A period, not a moment
Controls are tested across the financial period, so evidence has to exist for the whole year rather than for the week the auditor visits. A control implemented in month eleven cannot be evidenced for months one to ten, and the honest answer to the auditor is that it was not operating. This is why readiness work in the last quarter is worth far more than remediation during fieldwork.
IT general controls are an audit concept, not a security framework.
This sounds academic and it is intensely practical, because organisations that treat ITGC as a security exercise produce a great deal of work that does not answer the question being asked.
- The purpose is different. Your auditor is establishing whether they can rely on information produced by your systems when forming an opinion on financial statements. They are not assessing whether you would survive a ransomware attack. A control that is excellent security and irrelevant to the integrity of financial information does not help you here, and the reverse is also true.
- The scope is narrower and specific. It covers the applications involved in initiating, processing, recording and reporting transactions, and the infrastructure beneath them. Your marketing platform is almost certainly out of scope. Your ERP, your accounting system, the databases they sit on and the network and operating systems supporting them are in it, along with data warehouses and report writers if your reporting depends on them.
- The evidence bar is different too. Security assessments accept a well-designed control described credibly. Financial audit sampling does not: the auditor picks specific items and asks you to demonstrate the control operated for each one. That means retrievable records with dates and approvals, kept for the whole period, not a policy and an assurance that it is followed.
- The useful consequence is that this work is finite and predictable. It has a fixed annual timetable, a known scope and a defined set of questions. Unlike a security programme, you can genuinely finish getting ready for it, and doing so once makes every subsequent year substantially easier.
Four things that make readiness worth doing rather than enduring.
We work from the standard, not from a generic checklist
ISA 315 defines the IT environment, the IT processes and risks arising from the use of IT in specific words, and your auditor works from those. We do too, which means the scope we assess is the scope they will test rather than a broader security review that produces work nobody asked for and leaves the actual gaps open.
We translate between finance and IT
The requests arrive with finance and the answers live with IT, and the two functions frequently do not share vocabulary. A request for evidence of segregation of duties in the ERP means something specific, and it is not what an IT administrator assumes on first reading. Sitting between the two is most of the practical value in the first year.
We start before year end, because evidence is retrospective
Controls are tested across the period, so a control implemented during fieldwork cannot be evidenced for the year that has already passed. Readiness work in the quarter before your year end is worth several times the same effort spent during the audit, and we would rather tell you that than take an engagement at the wrong moment.
We build evidence that accumulates on its own
The goal is not to survive this audit. It is that next year the records exist because normal work produced them: approvals captured where the work happens, reviews on a calendar, changes recorded as they are made. Organisations that reach that state stop finding audit season stressful, and the difference is entirely in the habit rather than in the tooling.
Six situations where ITGC readiness earns its cost.
A company facing its first audit under the revised standard
The requests are new, nobody internally has seen them before, and the natural reaction is to send policies. This is the most common and the most fixable situation. Establishing what evidence is expected, and getting the scope agreed with the auditor early, converts a stressful first cycle into a manageable one.
A regulated financial firm
Here ITGC findings carry further than the management letter, because supervisors take an interest in control weaknesses and the same evidence often serves both purposes. Firms in this sector usually have better change control than average and worse access review discipline, which is a specific and correctable pattern.
A group with several entities and one audit
Multiple systems, inconsistent practices across entities, and an auditor testing a consolidated position. The work here is establishing a common minimum standard rather than harmonising everything, because the finding usually comes from the least-controlled entity and drags the group position down with it.
A business that has just migrated a financial system
A mid-year ERP migration splits the evidence in two: controls on the old system for part of the period and the new one for the rest, plus the migration itself, which auditors will look at as a change. Planning the evidence around a migration before it happens is far easier than reconstructing it afterwards, and it is rarely considered at the time.
A company with repeat findings from last year
A finding that appears twice reads very differently from one that appears once, because it says the organisation was told and did not act. Auditors check specifically whether prior year points were addressed. This is a defined, closeable piece of work with a clear finish line, and it is worth attacking well before fieldwork.
A business preparing for investment or sale
Diligence looks at the control environment, and a management letter full of IT findings is a visible, documented weakness that a buyer or investor can read. Cleaning it up ahead of a process is straightforward, and it removes a category of question that otherwise consumes attention at exactly the wrong moment.
The same audit, under three levels of preparation.
| Feature | Ready before year end | Assembled during fieldwork | Unprepared |
|---|---|---|---|
Scope agreed with the auditor in advance | |||
Access approvals retrievable on request | Some | ||
Leaver removal evidenced with dates | Reconstructed | ||
Access review completed during the period | Done late | ||
Change approvals precede deployment | Mostly | Unknown | |
Emergency changes have retrospective records | |||
A restore has been tested and recorded | Rarely | ||
Evidence spans the whole period | Partial | ||
Findings in the management letter | Few or none | Several | Many |
Senior time consumed during fieldwork | Low | High | Very high |
The typical requests, and what actually satisfies them.
| What the auditor tests | What satisfies it | |
|---|---|---|
| New user access was authorised | A dated approval from the right person, per sampled user | |
| Leaver access was removed promptly | Termination date against removal date, per sampled leaver | |
| Access is reviewed periodically | Completed reviews with reviewer, date and actions taken | |
| Privileged access is restricted | A current list, with justification per holder | |
| Segregation of duties holds | Role definitions showing conflicting rights are separated | |
| Changes were approved before production | Change records with approval preceding deployment | |
| Changes were tested | Test evidence linked to the specific change | |
| Emergency changes were controlled | Retrospective approval records, which usually do not exist | |
| Jobs and interfaces are monitored | Failure alerts and evidence somebody acted on them | |
| Backups work | A tested restore, not a backup success report | |
| Controls operated all year | Records spanning the period, not the last month |
Five stages, ideally starting a quarter before year end.
- 1
Establish scope, and agree it with the auditor
Which applications initiate, process, record or report transactions, which databases, operating systems and network components support them, and which are operated by third parties. We then agree that scope with your auditor before fieldwork, which is a short conversation that prevents an expensive disagreement later.
- 2
Assess against what will actually be tested
Access to programs and data, change management, and IT operations, assessed on the basis of whether you could produce evidence for a sampled item rather than whether a control is described in a document. The output separates controls that exist and are evidenced from controls that exist and are not, because those need very different work.
- 3
Close the evidence gaps before the period ends
Access reviews performed and recorded, change approvals captured, restore testing done and documented, privileged access justified. Prioritised by what auditors sample most, which in our experience is leavers, privileged users and emergency changes, in that order.
- 4
Prepare the pack and rehearse the requests
A structured set of evidence mapped to the likely requests, with a named owner for each, so fieldwork requests are answered in hours rather than days. Where useful we run the likely sample requests against you in advance, which finds the gaps while there is still time to do something about them.
- 5
Support fieldwork, then make next year automatic
We handle or support the auditor requests, then turn the temporary arrangements into routine: reviews on a calendar with owners, approvals captured where the work happens, change records generated as changes are made. The measure of success is that year two takes a fraction of the effort of year one.
What finance and IT teams ask about ITGC.
Fifteen checks that decide how your audit goes.
Scope, agreed early
- Which applications actually feed your financial statements?Including data warehouses and report writers, per the standard.
- Which databases, operating systems and network components support them?The standard puts infrastructure in scope explicitly.
- Have you agreed that scope with your auditor in advance?Far cheaper than discovering a disagreement during fieldwork.
- Are any of those systems run by a third party?You will need assurance over their controls, not just yours.
- Did anything material change during the year?A migration mid-period splits the evidence in two.
The evidence they will sample
- Can you produce dated approvals for new access in scope systems?For any user the auditor picks, not just a representative one.
- Can you show leaver removal dates against termination dates?The most commonly failed test.
- Has an access review actually been completed and recorded?With reviewer, date and what changed as a result.
- Do change records show approval before deployment?The sequence matters, not just the existence of both.
- Is there any evidence at all for emergency changes?Usually the gap, because urgency bypassed the process.
Stopping it recurring
- Did last year management letter contain IT findings?A repeat finding reads much worse than a first one.
- Was anything actually done about them, with evidence?Auditors check whether prior findings were addressed.
- Does evidence accumulate automatically from normal work?The single best predictor of a smooth audit.
- Is one person accountable for ITGC evidence year-round?Not assembled by whoever is free in week one of fieldwork.
- Has a restore been tested, and recorded?Backup reports are not restore evidence.
The pages around this one.
IT audit services in Dubai
The wider audit practice, including how a financial statement audit differs from a security assessment and which engagement your situation calls for.
Active Directory security audit
Where much of the access control evidence actually lives, including privileged access and leaver removal, which are the two most sampled ITGC areas.
ISO 27001 certification in the UAE
If you want a framework covering the same control ground for a different purpose, and the evidence discipline that supports both.
Pick five people who left this year and try to prove when access was removed.
That single exercise tells you most of what an ITGC assessment would, it takes an afternoon, and it is exactly what your auditor will do. If the answer is uncomfortable, the quarter before year end is the right time to fix it rather than the middle of fieldwork.
Related Services
Explore more solutions that work great with this service
Backup and Restore Audit
We test whether your backups actually restore
IT Audit Services Dubai
Assessment, technical test or certification, scoped properly
Active Directory Audit
Privilege paths, service accounts and local admin passwords
Microsoft 365 Security Audit
Tenant review, and how far back your evidence really goes
ISO 27001 Certification UAE
The 2022 edition, and whether you should certify at all
SOC 2 Readiness UAE
Type II preparation, and when ISO 27001 fits better
Virtual CISO Dubai
Security governance and accountability, not more tools
Disaster Recovery & BC
Business continuity and disaster recovery planning