Documenting the Client's IT Environment Under SAS 145: What the File Must Show

"Client uses QuickBooks" is not an understanding of the IT environment. SAS No. 145 turned the auditor's work on IT into a sequence with defined terms, a trigger and documentation requirements. Our SAS 145 overview covers the whole standard, and the ITGC program guide covers testing. This article covers what to write down, and why.

SAS 145 is effective for audits of periods ending on or after December 15, 2023.

The defined terms

SAS 145 defines the vocabulary the file should use:

• IT environment: the IT applications and supporting IT infrastructure, plus the IT processes and personnel involved in those processes, that an entity uses to support business operations and achieve business strategies.
• IT application: a program or set of programs used in the initiation, processing, recording and reporting of transactions or information. It includes data warehouses and report writers.
• IT processes: the entity's processes to manage access to the IT environment, manage program changes or changes to the IT environment, and manage IT operations.
• Risks arising from the use of IT: susceptibility of information-processing controls to ineffective design or operation, or risks to the integrity of information in the information system, due to ineffective design or operation of controls in the entity's IT processes.
• General IT controls: controls over the entity's IT processes that support the continued proper operation of the IT environment, including the continued effective functioning of information-processing controls and the integrity of information in the information system.

The sequence the standard requires

Two separate steps are easy to blur.

Step 1: Understand the information system, including the IT environment relevant to it. The information system includes the entity's resources, including the IT environment, relevant to the flows of transactions and the financial reporting process. The understanding focuses on identifying the nature and number of the specific IT applications and other aspects of the IT environment relevant to those flows and may be done together with understanding how significant classes of transactions flow through the system. The purpose is to find where IT may give rise to risks.

Step 2: Identify what is subject to risks from IT, and the general IT controls that address them. Starting from the controls identified, the auditor:

1. identifies the IT applications and other aspects of the IT environment subject to risks arising from the use of IT;
2. identifies the related risks and the entity's general IT controls that address them; and
3. for each identified control and each general IT control, evaluates whether it is designed effectively and determines whether it has been implemented.

The controls that trigger step 2 are those addressing significant risks, controls over journal entries and other adjustments, controls the auditor plans to test for operating effectiveness, and other controls the auditor considers appropriate.

The trigger matters. General IT controls need not be identified for every IT process. They are identified based on the risks arising from the use of IT (Appendix F).

What the documentation requirement covers

The standard requires documentation of:

• the key elements of the understanding of the information system, the sources of information from which the understanding was obtained, and the risk assessment procedures performed;
• the evaluation of the design of identified controls and the determination of whether they have been implemented, which includes the general IT controls identified; and
• the identified and assessed risks of material misstatement and the rationale for significant judgments.

A workable file layout has five headings: inventory, flow, risks, general IT controls and conclusion.

A worked example: client on commercial accounting software

SAS 145 states that understanding is more easily accomplished for a less complex entity that uses commercial software and has no access to the source code to make program changes (Appendix E). The same appendix lists matters the auditor may consider about a commercial accounting package that is the single IT application:

• how well established the software is and its reputation for reliability;
• whether the entity can modify source code, add modules or make direct changes to data;
• the nature and extent of modifications, recognizing that configuration such as reporting parameters is not source code modification but affects the information produced; and
• whether data can be accessed directly without going through the application, and the volume processed.

Consider a client with a commercial cloud accounting package, a payroll provider, a bank portal and spreadsheets for fixed assets and a lease schedule. The file could read:

The entries are an illustration of format. For service organization reliance, see SOC 1 reports under AU-C 402, and for the accounting platform itself, see auditing a client on QuickBooks Online.

SAS 145's scalability examples support this brevity. An entity using commercial software with no source code access is unlikely to have a program change process, but may have procedures to configure the software and a designated individual with administrative access. It is unlikely to have formalized general IT controls. The file records what exists, not what a larger entity would have.

System-generated reports and spreadsheets

Reports the auditor intends to use as evidence, such as an AR aging or inventory valuation, are a common point of IT documentation. SAS 145 allows two approaches (Appendix E):

• Test the inputs and outputs of the report-generating process. The application may then not be identified as subject to risks arising from the use of IT for that purpose.
• Test controls over the report's preparation and maintenance, in which case the application is likely to be subject to risks arising from IT, and the auditor may also test general IT controls over unauthorized program or data changes to the report.

Document the approach for each report, because it determines whether the application enters step 2.

Linking to journal entries and fraud work

SAS 145 requires identification of controls over journal entries and other adjustments. SAS No. 151, issued in October 2026 and effective for audits of periods ending on or after December 15, 2028, revises the auditor's responsibilities relating to fraud. The same IT environment documentation supports journal entry testing. See SAS 151.

Frequently asked questions

Does SAS 145 require testing general IT controls?

No. It requires identification of general IT controls for applications subject to risks from IT, and evaluation of their design and determination of implementation. Operating effectiveness testing occurs when the auditor plans to rely on them.

Can the auditor identify no IT applications as subject to risks from IT?

Yes. When management is not relying on automated controls or general IT controls to support complete and accurate processing, and the auditor has identified no automated or other information-processing controls that depend on them, the auditor may plan to test information produced by the entity directly.

Sources

• AICPA, Statement on Auditing Standards No. 145, Understanding the Entity and Its Environment and Assessing the Risks of Material Misstatement (October 2021), including Appendices E and F
• AICPA, Statement on Auditing Standards No. 151, The Auditor's Responsibilities Relating to Fraud in an Audit of Financial Statements (October 2026)

CORAA prepares ready-to-review audit files for US CPA firms from client books; you review and sign. See /us.

AU-C references are to AICPA Professional Standards, paraphrased here; read the standard itself before relying on a requirement. This page is guidance, not professional advice. Report an error