IT General Controls Explained: Access, Change Management, and Operations

Why general controls matter to the business

A business may rely on an automated reconciliation, invoice calculation or access restriction. That reliance depends partly on who can change the system, how changes are approved and whether the underlying service operates reliably.

IT general controls, often called ITGCs, concern those supporting practices. They are different from an application control that performs a specific business check. The distinction helps reviewers ask whether an apparently reliable process rests on dependable technology management.

PCAOB AS 1105 discusses information reliability and the effect of relevant IT and application controls in its financial-reporting audit context.¹ That does not make every technology review a financial audit; it explains why the surrounding control environment can matter to a record's reliability.

Choose the systems before choosing the checklist

Start with the business objective and the information used. Which systems process, store or report it? Which identity, cloud and provider services support those systems? Who can administer them?

A review of invoice accuracy might include the billing application, change process and privileged access. A review of customer-file availability might emphasize recovery and operations. Do not assume the same fixed ITGC checklist fits every objective.

Record the entity, environments and period. Development, test and production can have different authority and data. A control working in test does not establish that production is covered.

Access controls: who can do what?

Access management includes how people obtain, change and lose access, and how important permissions are reviewed. Privileged roles deserve attention because they may change configuration, records or the controls themselves.

Ask who approves access, how role suitability is checked and what triggers removal. Include contractors, service accounts and outsourced administrators where relevant. A staff-only list may omit significant access routes.

A login control such as multifactor authentication addresses an important part of access security. It does not, by itself, establish that privileges are appropriate or that obsolete accounts are removed.

Change management: how does the system change?

The change process should connect a request to review, testing, authorization, implementation and appropriate verification. Match the process to the system and risks; do not add ceremonial approvals that nobody understands.

Consider application code, configuration, infrastructure and relevant data changes. A control limited to source-code pull requests can miss administrative configuration changes made directly in a console.

Ask how urgent changes are handled, who can authorize them and how retrospective review is documented. An emergency route should remain a controlled exception, rather than a permanent shortcut.

The AICPA trust-services material identifies access, system operations and change management among control topics.² That is a useful cross-reference, not a claim that an ITGC checklist establishes SOC 2 readiness or a report outcome.

Operations: can the service be maintained and recovered?

Technology operations can include job monitoring, incident handling, backups, restoration, logging and scheduled maintenance relevant to the scope. Focus on whether important exceptions are noticed and acted upon.

A successful backup job shows that a job reported success. A controlled restore exercise asks a different question: can the required information and configuration be made usable? Record the test conditions and limitations rather than claim every service is recoverable.

For monitoring, verify both delivery and ownership. An alert that reaches an unattended inbox does not establish a working response. Use authorized, labeled test signals where appropriate, and retain acknowledgement and follow-up evidence.

NIST SP 800-53 provides a flexible catalog of security and privacy controls.³ Use relevant topics as references while selecting implementation and evidence appropriate to your actual risks and obligations.

Worked example: an invoice reconciliation

This fictional company uses a billing application to compare orders and invoices. Finance reviews differences daily, but the reviewer does not know that several administrators can alter the reconciliation rules.

The daily review is a process-specific control. General controls support confidence in the system and its output, but they do not replace finance's review of exceptions.

The team discovers that one report filter changed without retained approval. It records the affected period, checks the output and investigates the change. It does not conclude that all invoices are wrong, nor ignore the issue because the report looked normal.

Describe each control with a complete sentence

Use performer, trigger, action, scope and evidence. The evidence guide explains how to retain a supportable record. For example: “After an approved privileged-access request, the system owner assigns the specified role, verifies it against the request and retains the completion record.”

Then define exception handling. What happens when approval is missing, removal is late or a change fails? Who decides whether temporary access or a workaround is acceptable, and when does it expire?

Keep design and operation separate. An approved process can be well designed while recent records reveal inconsistent implementation. Both facts belong in the review.

Check evidence coverage and provider responsibilities

Establish the population of access changes, releases or operational exceptions relevant to the period. Do not choose only successful examples and describe them as complete coverage.

When providers perform part of the work, document responsibilities and obtain evidence appropriate to the relationship. A supplier report may cover a hosted service while leaving your configuration and user access to you. Read the boundaries rather than assume responsibility has transferred.

Protect sensitive exports and logs. They may contain personal information or operational details. Authorized review access should remain narrower than general document sharing.

A practical ITGC review sequence

Identify the business process and system dependencies. Describe the scoped controls and authority. Confirm complete occurrence records. Examine relevant evidence, investigate exceptions and record limitations. Assign corrective actions and verify their completion.

Use the internal audit planning checklist when organizing a formal engagement. The result should explain which technology practices support the process and where reliance remains uncertain. It should not use “ITGCs passed” as a shortcut for every security, financial or compliance conclusion about the business.

Sources and references

1. Public Company Accounting Oversight Board. AS 1105: Audit Evidence. Audit-evidence standard for its financial-reporting context; quality principles are explained as an analogy, not applied indiscriminately to other engagements. ↩

2. AICPA. 2017 Trust Services Criteria, including March 2020 updates (2020-03). Public historical edition explains Type 1/Type 2 and readiness versus examination. Use the current 2022 revised-points-of-focus resource for an engagement. ↩

3. NIST. Security and Privacy Controls, SP 800-53 Revision 5 (2020-09). Tailorable control catalog; catalog page also records minor Release 5.2.0 in August 2025. ↩