Skill 寫法圖鑑

audit-support

Anthropic | 商業與營運 | 原文 | Apache-2.0

SOX 404 控制測試方法、樣本選取、工作底稿和缺失分類

中文翻譯

---
name: audit-support
description: 以控制測試方法論、樣本選取和文件標準支援 SOX 404 合規。適用於產生測試工作底稿、選取稽核樣本、分類控制缺失,或準備內部或外部稽核。
user-invocable: false
---

# 稽核支援

**重要**:這個 skill 協助 SOX 合規的工作流程,但不提供稽核或法律建議。所有測試工作底稿和評估,都應由合格的財務專業人員審閱。雖然「重大性(significance)」和「重要性(materiality)」是取決於具體情境的概念,最終由稽核人員評估,但這個 skill 的用意是協助專業人員建立有效的內部控制和稽核文件,並評估其有效性。

涵蓋 SOX 404 控制測試方法論、樣本選取方法、測試文件標準、控制缺失分類,以及常見的控制類型。

## SOX 404 控制測試方法論

### 概述

SOX 第 404 條要求管理層評估財務報導內部控制(ICFR)的有效性。這包括:

1. **範圍界定:** 找出重大科目和相關的聲明(assertion)
2. **風險評估:** 評估每個重大科目發生重大不實表達的風險
3. **控制辨識:** 記錄處理每項風險的控制
4. **測試:** 測試關鍵控制的設計和運作有效性
5. **評價:** 評估是否存在缺失以及其嚴重程度
6. **報告:** 記錄評估結果和任何重大缺失(material weakness)

### 界定重大科目的範圍

一個科目如果有超過「微乎其微(remote)」的可能性包含重大(個別或合計)的不實表達,就是重大科目。

**量化因素:**
- 科目餘額超過重要性門檻(通常是關鍵基準的 3-5%)
- 交易量大,增加出錯風險
- 科目涉及重大的估計或判斷

**質化因素:**
- 科目涉及複雜的會計處理(收入認列、衍生工具、退休金)
- 科目容易發生舞弊(現金、收入、關係人交易)
- 科目過去有不實表達或稽核調整
- 科目涉及管理層重大的判斷或估計
- 新的科目或有重大變更的流程

### 各科目類型的相關聲明

| 科目類型 | 關鍵聲明 |
|-------------|---------------|
| 收入 | 發生、完整性、正確性、截止 |
| 應收帳款 | 存在、評價(備抵)、權利 |
| 存貨 | 存在、評價、完整性 |
| 固定資產 | 存在、評價、完整性、權利 |
| 應付帳款 | 完整性、正確性、存在 |
| 應計負債 | 完整性、評價、正確性 |
| 權益 | 完整性、正確性、表達 |
| 財務結帳/報導 | 表達、正確性、完整性 |

### 設計有效性 vs 運作有效性

**設計有效性:** 這個控制的設計,是否能適當地預防或偵測相關聲明中的重大不實表達?
- 透過穿行測試(walkthrough)評估(沿著流程從頭到尾追蹤一筆交易)
- 確認控制放在流程中正確的位置
- 確認控制處理了已辨識的風險
- 至少每年執行一次,或在流程變更時執行

**運作有效性:** 在整個測試期間,這個控制是否確實依設計運作?
- 透過測試評估(檢查、觀察、重新執行、詢問)
- 需要足夠的樣本數來支持結論
- 必須涵蓋整個倚賴期間

## 樣本選取方法

### 隨機選取

**何時使用:** 母體龐大的交易層級控制的預設方法。

**方法:**
1. 定義母體(期間內適用該控制的所有交易)
2. 為母體中的每個項目依序編號
3. 使用亂數產生器選出樣本項目
4. 確保選取沒有偏誤(所有項目被選中的機率相等)

**優點:** 統計上有效、站得住腳、沒有選取偏誤
**缺點:** 可能漏掉高風險項目,需要完整的母體清單

### 目標式(判斷式)選取

**何時使用:** 作為隨機選取的補充,進行以風險為基礎的測試;母體很小或差異很大時為主要方法。

**方法:**
1. 找出有特定風險特徵的項目:
   - 金額高(超過定義的門檻)
   - 不尋常或非標準的交易
   - 期末交易(截止風險)
   - 關係人交易
   - 手動或覆寫(override)的交易
   - 新廠商/客戶的交易
2. 選出符合風險條件的項目
3. 記錄每個目標式選取的理由

**優點:** 聚焦在風險最高的項目,有效運用測試的力氣
**缺點:** 在統計上不具代表性,可能過度代表某些風險

### 隨意選取(Haphazard)

**何時使用:** 隨機選取不可行(沒有依序的母體清單)且母體相對同質時。

**方法:**
1. 在沒有任何特定模式或偏誤的情況下選取項目
2. 確保選取的項目分散在整個母體期間
3. 避免無意識的偏誤(不要總是挑最上面的項目、整數等)

**優點:** 簡單,不需要技術
**缺點:** 統計上無效,容易受無意識偏誤影響

### 系統性選取

**何時使用:** 母體是有順序的,而且你想要涵蓋整個期間時。

**方法:**
1. 計算抽樣間隔:母體大小 / 樣本大小
2. 在第一個間隔內隨機選一個起點
3. 從起點開始,每隔 N 個選一個項目

**範例:** 母體 1,000、樣本 25 → 間隔 40。隨機起點:第 17 項。選取第 17、57、97、137、... 項

**優點:** 平均涵蓋整個母體,執行簡單
**缺點:** 母體中的週期性模式可能使結果產生偏誤

### 樣本大小指引

| 控制頻率 | 預期母體 | 低風險樣本 | 中風險樣本 | 高風險樣本 |
|------------------|--------------------|-----------------|--------------------|-----------------|
| 每年 | 1 | 1 | 1 | 1 |
| 每季 | 4 | 2 | 2 | 3 |
| 每月 | 12 | 2 | 3 | 4 |
| 每週 | 52 | 5 | 8 | 15 |
| 每日 | ~250 | 20 | 30 | 40 |
| 每筆交易(小母體) | < 250 | 20 | 30 | 40 |
| 每筆交易(大母體) | 250+ | 25 | 40 | 60 |

**會增加樣本大小的因素:**
- 科目/流程的固有風險較高
- 該控制是處理重大風險的唯一控制(沒有備援)
- 前期發現過控制缺失
- 新的控制(前期沒測試過)
- 外部稽核人員倚賴管理層的測試

## 測試文件標準

### 工作底稿要求

每個控制測試都應記錄:

1. **控制辨識:**
   - 控制編號/ID
   - 控制描述(做什麼、由誰做、多久做一次)
   - 控制類型(手動、自動、IT 依賴的手動)
   - 控制頻率
   - 處理的風險和聲明

2. **測試設計:**
   - 測試目標(你想確定什麼)
   - 測試程序(逐步說明)
   - 預期證據(如果控制有效,你預期會看到什麼)
   - 樣本選取方法和理由

3. **測試執行:**
   - 母體描述和大小
   - 樣本選取細節(方法、選出的項目)
   - 每個樣本項目的結果(通過/未通過,附上檢查過的具體證據)
   - 記錄的例外及完整描述

4. **結論:**
   - 整體評估(有效/缺失/重大缺陷(significant deficiency)/重大缺失(material weakness))
   - 結論的依據
   - 任何例外的影響評估
   - 考慮過的補償性控制(如適用)

5. **簽核:**
   - 測試人員姓名和日期
   - 審閱人員姓名和日期

### 證據標準

**足夠的證據包括:**
- 顯示系統強制執行控制的截圖
- 簽名/簽註縮寫的核准文件
- 可辨識核准人和日期的電子郵件核准
- 顯示誰在何時執行該動作的系統稽核日誌
- 重新執行的計算且結果吻合
- 觀察記錄(含日期、地點、觀察者)

**不足的證據:**
- 單獨的口頭確認(必須有佐證)
- 沒有日期的文件
- 無法辨識執行者/核准者的證據
- 沒有日期/時間戳記的一般系統報表
- 沒有佐證文件的 "Per discussion with [name]"

### 工作底稿的組織

依控制領域組織測試檔案:

```
SOX Testing/
├── [Year]/
│   ├── Scoping and Risk Assessment/
│   ├── Revenue Cycle/
│   │   ├── Control Matrix
│   │   ├── Walkthrough Documentation
│   │   ├── Test Workpapers (one per control)
│   │   └── Supporting Evidence
│   ├── Procure to Pay/
│   ├── Payroll/
│   ├── Financial Close/
│   ├── Treasury/
│   ├── Fixed Assets/
│   ├── IT General Controls/
│   ├── Entity Level Controls/
│   └── Summary and Conclusions/
│       ├── Deficiency Evaluation
│       └── Management Assessment
```

## 控制缺失分類

### 缺失(Deficiency)

當控制的設計或運作,使管理層或員工在執行被指派的職務的正常過程中,無法及時預防或偵測不實表達時,就存在內部控制缺失。

**評估因素:**
- 控制失效導致不實表達的可能性有多高?
- 潛在不實表達的金額有多大?
- 有沒有能減輕這個缺失的補償性控制?

### 重大缺陷(Significant Deficiency)

嚴重程度低於重大缺失(material weakness),但重要到值得治理單位(those charged with governance)注意的缺失,或缺失的組合。

**指標:**
- 這個缺失可能導致超過微不足道、但未達重大的不實表達
- 發生重大不實表達的可能性超過微乎其微(remote),但未達合理可能(reasonably possible)
- 該控制是關鍵控制,而且缺失沒有被補償性控制完全減輕
- 個別輕微的缺失加在一起,構成重大的疑慮

### 重大缺失(Material Weakness)

存在合理可能性,使財務報表的重大不實表達無法被及時預防或偵測的缺失,或缺失的組合。

**指標:**
- 發現高階管理層舞弊(不論金額)
- 為更正重大錯誤而重編先前已發布的財務報表
- 稽核人員發現公司的控制無法偵測到的重大不實表達
- 審計委員會對財務報導的監督無效
- 影響多個流程的普遍性控制(實體層級、IT 一般控制)出現缺失

### 缺失彙總

個別來看不重大的缺失,合在一起可能就很重大:

1. 找出同一個流程中或影響同一個聲明的所有缺失
2. 評估合併的影響是否可能導致重大不實表達
3. 考慮補償性控制的缺失是否會加劇其他缺失
4. 記錄彙總分析和結論

### 改善

對每個已辨識的缺失:

1. **根因分析:** 這個控制為什麼失效?(設計缺口、執行失誤、人力、訓練、系統問題)
2. **改善計畫:** 修正控制的具體行動(重新設計、額外訓練、系統強化、增加覆核)
3. **時程:** 完成改善的目標日期
4. **負責人:** 負責執行改善的人
5. **驗證:** 改善後的控制將如何、何時重新測試以確認有效性

## 常見的控制類型

### IT 一般控制(ITGC)

針對 IT 環境的控制,支持應用控制和自動化流程能可靠運作。

**存取控制:**
- 使用者存取權限的授予(新的存取申請需要核准)
- 使用者存取權限的撤銷(離職使用者及時移除)
- 特權存取管理(管理員/超級使用者存取受限並受監控)
- 定期存取權限審查(依既定時程重新認證使用者存取權限)
- 密碼政策(複雜度、輪替、鎖定)
- 職責分離的落實(防止衝突的存取權限)

**變更管理:**
- 變更申請在實施前已記錄並核准
- 變更在升級之前先在非正式環境測試
- 開發環境和正式環境分離
- 緊急變更程序(記錄在案、實施後核准)
- 變更審查和實施後驗證

**IT 營運:**
- 批次作業監控和例外處理
- 備份與復原程序(定期備份、測試還原)
- 系統可用性和效能監控
- 事件管理和升級程序
- 災難復原規劃和測試

### 手動控制

由人運用判斷來執行的控制,通常涉及審查和核准。

**範例:**
- 管理層對財務報表和關鍵指標的覆核
- 主管對超過門檻的日記帳分錄的核准
- 三方比對驗證(PO、收貨、發票)
- 科目調節表的編製與覆核
- 實地盤點的觀察與計數
- 廠商主檔資料變更的核准
- 客戶信用核准

**要測試的關鍵屬性:**
- 這個控制是不是由正確的人(有適當的授權)執行?
- 是否及時執行(在要求的時間內)?
- 有沒有覆核的證據(簽名、簽註縮寫、電子郵件、系統日誌)?
- 覆核人員有沒有足夠的資訊來執行有效的覆核?
- 例外是否被辨識出來並適當處理?

### 自動控制

由 IT 系統在沒有人為介入下強制執行的控制。

**範例:**
- 系統強制的核准工作流程(沒有必要的核准就無法繼續)
- 三方比對自動化(PO/收貨/發票不吻合時,系統阻擋付款)
- 重複付款偵測(系統標記或阻擋重複的發票)
- 信用額度控管(系統防止超過信用額度的訂單)
- 自動計算(折舊、攤銷、利息、稅)
- 系統強制的職責分離(防止衝突的角色)
- 輸入驗證控制(必填欄位、格式檢查、範圍檢查)
- 自動對帳比對

**測試方法:**
- 測試設計:確認系統設定如預期地強制執行該控制
- 測試運作有效性:對自動控制而言,如果系統設定沒有變更,通常該期間對控制測試一次就足夠(再搭配對變更管理的 ITGC 測試作為補充)
- 驗證變更管理的 ITGC 有效(如果系統有變更,要重新測試該控制)

### IT 依賴的手動控制

倚賴系統產生的資訊是否完整正確的手動控制。

**範例:**
- 管理層對系統產生的例外報表的覆核
- 主管對系統產生的帳齡報表的覆核,以評估準備金
- 用系統產生的試算表資料做的調節
- 對系統產生的工作流程所辨識出的交易做的核准

**測試方法:**
- 測試手動控制(覆核、核准、對例外的追蹤處理)
- 「而且」測試底層報表/資料的完整性和正確性(IPE,Information Produced by the Entity,由受查單位產生的資訊)
- IPE 測試確認覆核人員所倚賴的資料是完整且正確的

### 實體層級控制

在組織層級運作、影響多個流程的廣泛控制。

**範例:**
- 高層的基調(tone at the top)/行為準則
- 風險評估流程
- 審計委員會對財務報導的監督
- 內部稽核功能和活動
- 舞弊風險評估和反舞弊計畫
- 吹哨者/倫理熱線
- 管理層對控制有效性的監控
- 財務報導的能力(人力、訓練、資格)
- 期末財務報導流程(結帳程序、GAAP 遵循覆核)

**重要性:**
- 實體層級控制可以減輕風險,但通常無法取代流程層級的控制
- 無效的實體層級控制(特別是審計委員會監督和高層的基調)是重大缺失的強烈指標
- 有效的實體層級控制,可能減少流程層級控制所需的測試範圍

英文原文

---
name: audit-support
description: Support SOX 404 compliance with control testing methodology, sample selection, and documentation standards. Use when generating testing workpapers, selecting audit samples, classifying control deficiencies, or preparing for internal or external audits.
user-invocable: false
---

# Audit Support

**Important**: This skill assists with SOX compliance workflows but does not provide audit or legal advice. All testing workpapers and assessments should be reviewed by qualified financial professionals. While "significance" and "materiality" are context-specific concepts that are ultimately assessed by auditors, this skill is intended to assist professionals in the creation and evaluation of effective internal controls and documentation for audits.

SOX 404 control testing methodology, sample selection approaches, testing documentation standards, control deficiency classification, and common control types.

## SOX 404 Control Testing Methodology

### Overview

SOX Section 404 requires management to assess the effectiveness of internal controls over financial reporting (ICFR). This involves:

1. **Scoping:** Identify significant accounts and relevant assertions
2. **Risk assessment:** Evaluate the risk of material misstatement for each significant account
3. **Control identification:** Document the controls that address each risk
4. **Testing:** Test the design and operating effectiveness of key controls
5. **Evaluation:** Assess whether any deficiencies exist and their severity
6. **Reporting:** Document the assessment and any material weaknesses

### Scoping Significant Accounts

An account is significant if there is more than a remote likelihood that it could contain a misstatement that is material (individually or in aggregate).

**Quantitative factors:**
- Account balance exceeds materiality threshold (typically 3-5% of a key benchmark)
- Transaction volume is high, increasing the risk of error
- Account is subject to significant estimates or judgment

**Qualitative factors:**
- Account involves complex accounting (revenue recognition, derivatives, pensions)
- Account is susceptible to fraud (cash, revenue, related-party transactions)
- Account has had prior misstatements or audit adjustments
- Account involves significant management judgment or estimates
- New account or significantly changed process

### Relevant Assertions by Account Type

| Account Type | Key Assertions |
|-------------|---------------|
| Revenue | Occurrence, Completeness, Accuracy, Cut-off |
| Accounts Receivable | Existence, Valuation (allowance), Rights |
| Inventory | Existence, Valuation, Completeness |
| Fixed Assets | Existence, Valuation, Completeness, Rights |
| Accounts Payable | Completeness, Accuracy, Existence |
| Accrued Liabilities | Completeness, Valuation, Accuracy |
| Equity | Completeness, Accuracy, Presentation |
| Financial Close/Reporting | Presentation, Accuracy, Completeness |

### Design Effectiveness vs Operating Effectiveness

**Design effectiveness:** Is the control properly designed to prevent or detect a material misstatement in the relevant assertion?
- Evaluated through walkthroughs (trace a transaction end-to-end through the process)
- Confirm the control is placed at the right point in the process
- Confirm the control addresses the identified risk
- Performed at least annually, or when processes change

**Operating effectiveness:** Did the control actually operate as designed throughout the testing period?
- Evaluated through testing (inspection, observation, re-performance, inquiry)
- Requires sufficient sample sizes to support a conclusion
- Must cover the full period of reliance

## Sample Selection Approaches

### Random Selection

**When to use:** Default method for transaction-level controls with large populations.

**Method:**
1. Define the population (all transactions subject to the control during the period)
2. Number each item in the population sequentially
3. Use a random number generator to select sample items
4. Ensure no bias in selection (all items have equal probability)

**Advantages:** Statistically valid, defensible, no selection bias
**Disadvantages:** May miss high-risk items, requires complete population listing

### Targeted (Judgmental) Selection

**When to use:** Supplement to random selection for risk-based testing; primary method when population is small or highly varied.

**Method:**
1. Identify items with specific risk characteristics:
   - High dollar amount (above a defined threshold)
   - Unusual or non-standard transactions
   - Period-end transactions (cut-off risk)
   - Related-party transactions
   - Manual or override transactions
   - New vendor/customer transactions
2. Select items matching risk criteria
3. Document rationale for each targeted selection

**Advantages:** Focuses on highest-risk items, efficient use of testing effort
**Disadvantages:** Not statistically representative, may over-represent certain risks

### Haphazard Selection

**When to use:** When random selection is impractical (no sequential population listing) and population is relatively homogeneous.

**Method:**
1. Select items without any specific pattern or bias
2. Ensure selections are spread across the full population period
3. Avoid unconscious bias (don't always pick items at the top, round numbers, etc.)

**Advantages:** Simple, no technology required
**Disadvantages:** Not statistically valid, susceptible to unconscious bias

### Systematic Selection

**When to use:** When population is sequential and you want even coverage across the period.

**Method:**
1. Calculate the sampling interval: Population size / Sample size
2. Select a random starting point within the first interval
3. Select every Nth item from the starting point

**Example:** Population of 1,000, sample of 25 → interval of 40. Random start: item 17. Select items 17, 57, 97, 137, ...

**Advantages:** Even coverage across population, simple to execute
**Disadvantages:** Periodic patterns in the population could bias results

### Sample Size Guidance

| Control Frequency | Expected Population | Low Risk Sample | Moderate Risk Sample | High Risk Sample |
|------------------|--------------------|-----------------|--------------------|-----------------|
| Annual | 1 | 1 | 1 | 1 |
| Quarterly | 4 | 2 | 2 | 3 |
| Monthly | 12 | 2 | 3 | 4 |
| Weekly | 52 | 5 | 8 | 15 |
| Daily | ~250 | 20 | 30 | 40 |
| Per-transaction (small pop.) | < 250 | 20 | 30 | 40 |
| Per-transaction (large pop.) | 250+ | 25 | 40 | 60 |

**Factors increasing sample size:**
- Higher inherent risk in the account/process
- Control is the sole control addressing a significant risk (no redundancy)
- Prior period control deficiency identified
- New control (not tested in prior periods)
- External auditor reliance on management testing

## Testing Documentation Standards

### Workpaper Requirements

Every control test should be documented with:

1. **Control identification:**
   - Control number/ID
   - Control description (what is done, by whom, how often)
   - Control type (manual, automated, IT-dependent manual)
   - Control frequency
   - Risk and assertion addressed

2. **Test design:**
   - Test objective (what you are trying to determine)
   - Test procedures (step-by-step instructions)
   - Expected evidence (what you expect to see if the control is effective)
   - Sample selection methodology and rationale

3. **Test execution:**
   - Population description and size
   - Sample selection details (method, items selected)
   - Results for each sample item (pass/fail with specific evidence examined)
   - Exceptions noted with full description

4. **Conclusion:**
   - Overall assessment (effective / deficiency / significant deficiency / material weakness)
   - Basis for conclusion
   - Impact assessment for any exceptions
   - Compensating controls considered (if applicable)

5. **Sign-off:**
   - Tester name and date
   - Reviewer name and date

### Evidence Standards

**Sufficient evidence includes:**
- Screenshots showing system-enforced controls
- Signed/initialed approval documents
- Email approvals with identifiable approver and date
- System audit logs showing who performed the action and when
- Re-performed calculations with matching results
- Observation notes (with date, location, observer)

**Insufficient evidence:**
- Verbal confirmations alone (must be corroborated)
- Undated documents
- Evidence without identifiable performer/approver
- Generic system reports without date/time stamps
- "Per discussion with [name]" without corroborating documentation

### Working Paper Organization

Organize testing files by control area:

```
SOX Testing/
├── [Year]/
│   ├── Scoping and Risk Assessment/
│   ├── Revenue Cycle/
│   │   ├── Control Matrix
│   │   ├── Walkthrough Documentation
│   │   ├── Test Workpapers (one per control)
│   │   └── Supporting Evidence
│   ├── Procure to Pay/
│   ├── Payroll/
│   ├── Financial Close/
│   ├── Treasury/
│   ├── Fixed Assets/
│   ├── IT General Controls/
│   ├── Entity Level Controls/
│   └── Summary and Conclusions/
│       ├── Deficiency Evaluation
│       └── Management Assessment
```

## Control Deficiency Classification

### Deficiency

A deficiency in internal control exists when the design or operation of a control does not allow management or employees, in the normal course of performing their assigned functions, to prevent or detect misstatements on a timely basis.

**Evaluation factors:**
- What is the likelihood that the control failure could result in a misstatement?
- What is the magnitude of the potential misstatement?
- Is there a compensating control that mitigates the deficiency?

### Significant Deficiency

A deficiency, or combination of deficiencies, that is less severe than a material weakness yet important enough to merit attention by those charged with governance.

**Indicators:**
- The deficiency could result in a misstatement that is more than inconsequential but less than material
- There is more than a remote (but less than reasonably possible) likelihood of a material misstatement
- The control is a key control and the deficiency is not fully mitigated by compensating controls
- Combination of individually minor deficiencies that together represent a significant concern

### Material Weakness

A deficiency, or combination of deficiencies, such that there is a reasonable possibility that a material misstatement of the financial statements will not be prevented or detected on a timely basis.

**Indicators:**
- Identification of fraud by senior management (any magnitude)
- Restatement of previously issued financial statements to correct a material error
- Identification by the auditor of a material misstatement that would not have been detected by the company's controls
- Ineffective oversight of financial reporting by the audit committee
- Deficiency in a pervasive control (entity-level, IT general control) affecting multiple processes

### Deficiency Aggregation

Individual deficiencies that are not significant individually may be significant in combination:

1. Identify all deficiencies in the same process or affecting the same assertion
2. Evaluate whether the combined effect could result in a material misstatement
3. Consider whether deficiencies in compensating controls exacerbate other deficiencies
4. Document the aggregation analysis and conclusion

### Remediation

For each identified deficiency:

1. **Root cause analysis:** Why did the control fail? (design gap, execution failure, staffing, training, system issue)
2. **Remediation plan:** Specific actions to fix the control (redesign, additional training, system enhancement, added review)
3. **Timeline:** Target date for remediation completion
4. **Owner:** Person responsible for implementing the remediation
5. **Validation:** How and when the remediated control will be re-tested to confirm effectiveness

## Common Control Types

### IT General Controls (ITGCs)

Controls over the IT environment that support the reliable functioning of application controls and automated processes.

**Access Controls:**
- User access provisioning (new access requests require approval)
- User access de-provisioning (terminated users removed timely)
- Privileged access management (admin/superuser access restricted and monitored)
- Periodic access reviews (user access recertified on a defined schedule)
- Password policies (complexity, rotation, lockout)
- Segregation of duties enforcement (conflicting access prevented)

**Change Management:**
- Change requests documented and approved before implementation
- Changes tested in a non-production environment before promotion
- Separation of development and production environments
- Emergency change procedures (documented, approved post-implementation)
- Change review and post-implementation validation

**IT Operations:**
- Batch job monitoring and exception handling
- Backup and recovery procedures (regular backups, tested restores)
- System availability and performance monitoring
- Incident management and escalation procedures
- Disaster recovery planning and testing

### Manual Controls

Controls performed by people using judgment, typically involving review and approval.

**Examples:**
- Management review of financial statements and key metrics
- Supervisory approval of journal entries above a threshold
- Three-way match verification (PO, receipt, invoice)
- Account reconciliation preparation and review
- Physical inventory observation and count
- Vendor master data change approval
- Customer credit approval

**Key attributes to test:**
- Was the control performed by the right person (proper authority)?
- Was it performed timely (within the required timeframe)?
- Is there evidence of the review (signature, initials, email, system log)?
- Did the reviewer have sufficient information to perform an effective review?
- Were exceptions identified and appropriately addressed?

### Automated Controls

Controls enforced by IT systems without human intervention.

**Examples:**
- System-enforced approval workflows (cannot proceed without required approvals)
- Three-way match automation (system blocks payment if PO/receipt/invoice don't match)
- Duplicate payment detection (system flags or blocks duplicate invoices)
- Credit limit enforcement (system prevents orders exceeding credit limit)
- Automated calculations (depreciation, amortization, interest, tax)
- System-enforced segregation of duties (conflicting roles prevented)
- Input validation controls (required fields, format checks, range checks)
- Automated reconciliation matching

**Testing approach:**
- Test design: Confirm the system configuration enforces the control as intended
- Test operating effectiveness: For automated controls, if the system configuration has not changed, one test of the control is typically sufficient for the period (supplemented by ITGC testing of change management)
- Verify change management ITGCs are effective (if system changed, re-test the control)

### IT-Dependent Manual Controls

Manual controls that rely on the completeness and accuracy of system-generated information.

**Examples:**
- Management review of a system-generated exception report
- Supervisor review of a system-generated aging report to assess reserves
- Reconciliation using system-generated trial balance data
- Approval of transactions identified by a system-generated workflow

**Testing approach:**
- Test the manual control (review, approval, follow-up on exceptions)
- AND test the completeness and accuracy of the underlying report/data (IPE — Information Produced by the Entity)
- IPE testing confirms the data the reviewer relied on was complete and accurate

### Entity-Level Controls

Broad controls that operate at the organizational level and affect multiple processes.

**Examples:**
- Tone at the top / code of conduct
- Risk assessment process
- Audit committee oversight of financial reporting
- Internal audit function and activities
- Fraud risk assessment and anti-fraud programs
- Whistleblower/ethics hotline
- Management monitoring of control effectiveness
- Financial reporting competence (staffing, training, qualifications)
- Period-end financial reporting process (close procedures, GAAP compliance reviews)

**Significance:**
- Entity-level controls can mitigate but typically cannot replace process-level controls
- Ineffective entity-level controls (especially audit committee oversight and tone at the top) are strong indicators of a material weakness
- Effective entity-level controls may reduce the extent of testing needed for process-level controls