Skip to content
CyberAudit CyberAudit
 Request a proposal

Audit & Assurance

IT General Controls (ITGC) Audit

ITGC is the control layer your external auditor relies on before they will place any reliance on a system-generated report. We test it independently, document it to a standard that survives review, and tell you plainly where it fails.

What an ITGC audit actually covers

IT general controls are the controls over the IT environment as a whole, rather than over any single business transaction. If they fail, every automated control and every system-generated report sitting above them becomes unreliable. That is why external auditors test ITGC first and why a weak ITGC opinion cascades into substantive testing across the whole financial statement audit.

  • Access to programs and data — user provisioning and de-provisioning, periodic access recertification, privileged and emergency access, segregation of duties, authentication and password configuration, service and generic accounts.
  • Program change management — change request and approval, segregation between development, test and production, testing and UAT evidence, emergency change handling, migration controls and version integrity.
  • Program development and acquisition — project governance, requirements and design sign-off, data conversion and migration controls, go-live authorisation, post-implementation review.
  • Computer operations — job scheduling and monitoring, incident and problem management, backup execution and restoration testing, capacity and availability monitoring, physical and environmental controls over hosting.

Why organisations commission one

  • The external auditor has raised an ITGC deficiency and management needs it closed before the next cycle.
  • A regulator — most commonly the State Bank of Pakistan under its technology governance framework — expects a periodic independent IT audit.
  • The audit committee wants assurance that is not produced by the IT function that runs the controls.
  • An ERP has gone live and nobody has yet tested whether the control design survived the implementation.
  • The internal audit function has no IT specialist and needs the ITGC portion of its annual plan co-sourced.

The four ITGC domains

Access to programs & data Provisioning, recertification,privileged access, segregation ofduties Program change management Request, approval, testing,segregated migration to production Program development Project governance, data migration,authorised go-live Computer operations Scheduling, incidents, backup andrestore, environment
Access, change, development and operations. A failure in any one undermines every automated control above it.

Scoping: which systems are in scope

We scope by financial and regulatory relevance, not by asset inventory. That normally means the core banking or ERP platform, the operating systems and databases beneath it, the directory service that authenticates into it, any middleware moving data in or out, and the change and ticketing tooling that evidences the controls. Peripheral systems are excluded explicitly and in writing, so there is no ambiguity later about what was and was not covered.

How the engagement runs

  1. 1

    Planning and risk assessment

    Understand the IT environment, agree in-scope systems, confirm the reporting period, and set the control objectives and sample basis in an approved audit programme.

  2. 2

    Walkthroughs

    Walk each control end to end with the process owner to confirm the design before we test whether it operated.

  3. 3

    Design effectiveness

    Assess whether the control as designed would prevent or detect the risk. A control that is well-operated but wrongly designed still fails.

  4. 4

    Operating effectiveness

    Sample-test across the period using population completeness evidence, not management-prepared extracts taken on trust.

  5. 5

    Exception validation

    Every exception is put back to the control owner with the evidence attached before it becomes a finding. No surprises at closing.

  6. 6

    Reporting and closing

    Draft findings, agree management responses and target dates, then issue the final report to the audit committee.

1 Plan 2 Walkthrough 3 Design 4 Operating 5 Validate 6 Report Every exception is validated with the control owner before it becomes a finding
Design effectiveness is tested before operating effectiveness — testing how well a badly designed control operates wastes everyone's time.

What you receive

Approved audit programme with control objectives mapped to COBIT 2019 and ISACA ITAF
Working papers with evidence references for every control tested
Findings register rated on an agreed significance scale with root cause noted
Management letter with practical, sequenced remediation recommendations
Executive summary written for an audit committee, not for engineers
Closing meeting and, where useful, a follow-up review of remediated items

Frequently asked questions

For a single core platform with its supporting infrastructure, typically three to five weeks of fieldwork once evidence starts flowing. Multi-entity or multi-ERP environments take longer. The variable that moves the timeline most is how quickly complete populations can be extracted, so we send the evidence request list before fieldwork begins.

Not on the same scope. Remediating a control and then auditing it creates a self-review threat to independence, which is exactly the objection your external auditor or regulator will raise. We can advise on remediation approach, and a separate team can support implementation, but the assurance opinion and the fix do not come from the same people on the same engagement.

It is designed to. We document to ISACA ITAF standards with retained evidence, which is what an external auditor needs in order to place reliance. That said, reliance is always the external auditor's decision — we recommend introducing us to them at planning so the scope and sampling basis are agreed up front rather than debated afterwards.

None of substance. GITC — general IT controls — is the term some firms and regulators prefer, and ITGC is the more common usage. Both describe the same four control domains: access, change, operations, and development.

Related services

Information Systems Audit ERP Implementation Review IT Risk Register

Related regulatory frameworks

SBP ETGRM (Pakistan)

Need an independent view?

Tell us the scope, the regulator and the deadline. We will come back with an approach, a team and a fee estimate.

Request a proposal
Top