Тестирование контролей для аудита SOX
Подсказывает, как выбирать выборку, документировать проверки контролей и классифицировать недостатки перед аудитом.
- Что делает
- Подсказывает, как выбирать выборку, документировать проверки контролей и классифицировать недостатки перед аудитом.
- Когда брать
- При подготовке рабочих документов SOX 404, выборе аудиторской выборки или оценке недостатков контролей.
- Когда не брать
- Не заменяет аудитора и юриста; под российское право и стандарты не рассчитан.
- Пример запроса
- Подготовь методику тестирования контроля по согласованию платежей: какую выборку взять и что записать в рабочий документ.
Входит в плагин finance. В Cowork и Claude Code можно поставить плагин целиком.
Как включить
- Нажмите «Скачать на русском» и сохраните архив.
- В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
- Включите скилл переключателем.
Для терминала
Распакуйте архив и положите папку audit-support в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.
Текст
---
name: audit-support
description: Поддержка соответствия SOX 404: методология тестирования контролей, выбор выборки и стандарты документирования. Используй при подготовке рабочих документов по тестированию, выборе аудиторских выборок, классификации недостатков контролей, а также при подготовке к внутренним и внешним аудитам.
user-invocable: false
---
Поддержка аудита
Важно: этот скилл помогает в рабочих процессах по соответствию SOX, но не даёт аудиторских или юридических консультаций. Все рабочие документы по тестированию и оценки должны проверяться квалифицированными специалистами по финансам. «Значимость» и «существенность» — понятия, зависящие от контекста, и в итоге их оценивают аудиторы; этот скилл призван помогать специалистам создавать и оценивать эффективный внутренний контроль и документацию для аудитов.
Методология тестирования контролей SOX 404, подходы к выбору выборки, стандарты документирования тестов, классификация недостатков контролей и распространённые типы контролей.
Методология тестирования контролей SOX 404
Обзор
Раздел 404 закона SOX требует, чтобы руководство оценивало эффективность внутреннего контроля над финансовой отчётностью (ICFR). Это включает:
- Определение охвата: выявить значимые счета и релевантные предпосылки
- Оценка рисков: оценить риск существенного искажения по каждому значимому счёту
- Выявление контролей: задокументировать контроли, которые закрывают каждый риск
- Тестирование: проверить разработку и операционную эффективность ключевых контролей
- Оценка: определить, есть ли недостатки и насколько они серьёзны
- Отчётность: задокументировать оценку и все существенные слабости
Определение значимых счетов
Счёт значим, если вероятность того, что он содержит существенное искажение (по отдельности или в совокупности), выше отдалённой.
Количественные факторы:
- Остаток по счёту превышает порог существенности (как правило, 3–5 % от ключевого базового показателя)
- Большой объём операций, что повышает риск ошибки
- Счёт зависит от значимых оценок или суждений
Качественные факторы:
- В счёте используется сложный учёт (признание выручки, деривативы, пенсионные обязательства)
- Счёт подвержен мошенничеству (денежные средства, выручка, операции со связанными сторонами)
- По счёту ранее были искажения или корректировки аудиторов
- Счёт связан со значимыми суждениями или оценками руководства
- Новый счёт или существенно изменившийся процесс
Релевантные предпосылки по типам счетов
| Тип счёта | Ключевые предпосылки |
|---|---|
| Выручка | Возникновение, Полнота, Точность, Разграничение периодов (cut-off) |
| Дебиторская задолженность | Существование, Оценка (резерв), Права |
| Запасы | Существование, Оценка, Полнота |
| Основные средства | Существование, Оценка, Полнота, Права |
| Кредиторская задолженность | Полнота, Точность, Существование |
| Начисленные обязательства | Полнота, Оценка, Точность |
| Капитал | Полнота, Точность, Представление |
| Закрытие периода и отчётность | Представление, Точность, Полнота |
Эффективность разработки и операционная эффективность
Эффективность разработки: правильно ли спроектирован контроль, чтобы предотвращать или выявлять существенное искажение по соответствующей предпосылке?
- Оценивается сквозной проверкой (walkthrough: проследить операцию от начала до конца по всему процессу)
- Убедись, что контроль стоит в правильной точке процесса
- Убедись, что контроль закрывает выявленный риск
- Проводится не реже раза в год или при изменении процессов
Операционная эффективность: действительно ли контроль работал так, как задумано, на протяжении всего периода тестирования?
- Оценивается тестированием (инспектирование, наблюдение, повторное выполнение, опрос)
- Требует достаточного размера выборки, чтобы обосновать вывод
- Должна охватывать весь период, на который опирается оценка
Подходы к выбору выборки
Случайная выборка
Когда применять: метод по умолчанию для контролей на уровне операций при большой генеральной совокупности.
Метод:
- Определи генеральную совокупность (все операции, подпадающие под контроль за период)
- Пронумеруй все элементы совокупности по порядку
- Выбери элементы выборки генератором случайных чисел
- Исключи смещение при выборе (у всех элементов равная вероятность)
Преимущества: статистически обоснована, защищаема, нет смещения отбора Недостатки: может пропустить элементы высокого риска, требует полного перечня совокупности
Целевая (суждения аудитора) выборка
Когда применять: как дополнение к случайной выборке при тестировании по рискам; основной метод, когда совокупность мала или очень разнородна.
Метод:
- Выдели элементы с особыми признаками риска:
- Крупные суммы (выше заданного порога)
- Необычные или нестандартные операции
- Операции на конец периода (риск разграничения периодов)
- Операции со связанными сторонами
- Ручные операции и операции в обход правил
- Операции с новыми поставщиками или клиентами
- Отбери элементы, подходящие под критерии риска
- Задокументируй обоснование каждого целевого отбора
Преимущества: сосредоточена на самых рискованных элементах, эффективно расходует усилия на тестирование Недостатки: статистически не репрезентативна, может завысить долю отдельных рисков
Произвольная выборка
Когда применять: когда случайный отбор неосуществим (нет последовательного перечня совокупности), а совокупность относительно однородна.
Метод:
- Отбирай элементы без какой-либо закономерности и смещения
- Следи, чтобы выбранные элементы были распределены по всему периоду совокупности
- Избегай неосознанного смещения (не бери всегда элементы из начала списка, круглые суммы и т. п.)
Преимущества: проста, не требует технологий Недостатки: статистически необоснована, подвержена неосознанному смещению
Систематическая выборка
Когда применять: когда совокупность упорядочена и нужно равномерное покрытие по всему периоду.
Метод:
- Рассчитай интервал выборки: размер совокупности / размер выборки
- Выбери случайную начальную точку в пределах первого интервала
- Отбирай каждый 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 |
Факторы, увеличивающие размер выборки:
- Более высокий неотъемлемый риск по счёту или процессу
- Контроль — единственный, закрывающий значимый риск (нет дублирования)
- В прошлом периоде был выявлен недостаток контроля
- Новый контроль (в прошлых периодах не тестировался)
- Внешний аудитор опирается на тестирование, проведённое руководством
Стандарты документирования тестов
Требования к рабочим документам
Каждый тест контроля должен быть задокументирован с указанием:
- Идентификация контроля:
- Номер или код контроля
- Описание контроля (что делается, кем, как часто)
- Тип контроля (ручной, автоматизированный, ручной с зависимостью от ИТ)
- Периодичность контроля
- Риск и предпосылка, которые он закрывает
- Дизайн теста:
- Цель теста (что именно нужно выяснить)
- Процедуры теста (пошаговые инструкции)
- Ожидаемые свидетельства (что ожидается увидеть, если контроль эффективен)
- Методика выбора выборки и её обоснование
- Выполнение теста:
- Описание и размер совокупности
- Детали отбора выборки (метод, выбранные элементы)
- Результаты по каждому элементу выборки (пройден или не пройден, с указанием конкретных изученных свидетельств)
- Выявленные исключения с полным описанием
- Вывод:
- Общая оценка (эффективен / недостаток / значительный недостаток / существенная слабость)
- Основание вывода
- Оценка влияния любых исключений
- Рассмотренные компенсирующие контроли (если есть)
- Подписи:
- Имя тестировщика и дата
- Имя проверяющего и дата
Стандарты свидетельств
Достаточные свидетельства включают:
- Скриншоты, показывающие контроли, реализованные системой
- Подписанные или завизированные документы об одобрении
- Одобрения по электронной почте с идентифицируемым одобрившим лицом и датой
- Системные журналы аудита, показывающие, кто и когда выполнил действие
- Повторно выполненные расчёты с совпадающими результатами
- Записи наблюдений (с датой, местом и наблюдателем)
Недостаточные свидетельства:
- Одни устные подтверждения (их нужно подкреплять)
- Документы без даты
- Свидетельства, в которых нельзя определить исполнителя или одобрившего
- Типовые системные отчёты без отметок даты и времени
- «По итогам обсуждения с [имя]» без подтверждающей документации
Организация рабочих документов
Организуй файлы тестирования по областям контроля:
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
Классификация недостатков контролей
Недостаток
Недостаток внутреннего контроля существует, когда разработка или работа контроля не позволяет руководству или сотрудникам в ходе обычного выполнения своих обязанностей своевременно предотвращать или выявлять искажения.
Факторы оценки:
- Какова вероятность, что сбой контроля приведёт к искажению?
- Каков масштаб возможного искажения?
- Есть ли компенсирующий контроль, который снижает последствия недостатка?
Значительный недостаток
Недостаток или сочетание недостатков, менее серьёзные, чем существенная слабость, но достаточно важные, чтобы заслуживать внимания лиц, отвечающих за корпоративное управление.
Признаки:
- Недостаток может привести к искажению, которое более чем незначительно, но менее чем существенно
- Вероятность существенного искажения выше отдалённой (но ниже обоснованно возможной)
- Контроль является ключевым, а недостаток не полностью снимается компенсирующими контролями
- Сочетание отдельных мелких недостатков, которые вместе вызывают серьёзное беспокойство
Существенная слабость
Недостаток или сочетание недостатков, при которых существует обоснованная возможность того, что существенное искажение финансовой отчётности не будет вовремя предотвращено или выявлено.
Признаки:
- Выявление мошенничества со стороны высшего руководства (любого масштаба)
- Пересмотр ранее выпущенной финансовой отчётности для исправления существенной ошибки
- Выявление аудитором существенного искажения, которое контроли компании не выявили бы
- Неэффективный надзор комитета по аудиту за финансовой отчётностью
- Недостаток во всеобъемлющем контроле (уровня организации, общий ИТ-контроль), затрагивающий несколько процессов
Агрегирование недостатков
Недостатки, не значимые по отдельности, в совокупности могут быть значимыми:
- Выяви все недостатки в одном процессе или влияющие на одну предпосылку
- Оцени, может ли их совместный эффект привести к существенному искажению
- Учти, не усугубляют ли недостатки компенсирующих контролей другие недостатки
- Задокументируй анализ агрегирования и вывод
Устранение
По каждому выявленному недостатку:
- Анализ первопричины: почему контроль не сработал? (пробел в разработке, сбой исполнения, кадры, обучение, проблема системы)
- План устранения: конкретные действия для исправления контроля (переработка, дополнительное обучение, доработка системы, дополнительная проверка)
- Сроки: целевая дата завершения устранения
- Ответственный: человек, отвечающий за внедрение исправления
- Проверка: как и когда исправленный контроль будет протестирован повторно для подтверждения эффективности
Распространённые типы контролей
Общие ИТ-контроли (ITGC)
Контроли над ИТ-средой, которые обеспечивают надёжную работу прикладных контролей и автоматизированных процессов.
Контроль доступа:
- Предоставление доступа пользователям (новые запросы на доступ требуют одобрения)
- Отзыв доступа (уволенные пользователи удаляются своевременно)
- Управление привилегированным доступом (доступ администраторов ограничен и отслеживается)
- Периодические проверки доступа (права пользователей подтверждаются по графику)
- Политики паролей (сложность, смена, блокировка)
- Обеспечение разделения обязанностей (конфликтующий доступ исключён)
Управление изменениями:
- Запросы на изменения документируются и одобряются до внедрения
- Изменения тестируются в непроизводственной среде перед переносом
- Разделение сред разработки и производства
- Процедуры экстренных изменений (документируются, одобряются после внедрения)
- Проверка изменений и валидация после внедрения
ИТ-эксплуатация:
- Мониторинг пакетных заданий и обработка исключений
- Процедуры резервного копирования и восстановления (регулярные копии, проверенное восстановление)
- Мониторинг доступности и производительности систем
- Управление инцидентами и процедуры эскалации
- Планирование и тестирование аварийного восстановления
Ручные контроли
Контроли, выполняемые людьми на основе суждения, как правило, связанные с проверкой и одобрением.
Примеры:
- Проверка руководством финансовой отчётности и ключевых показателей
- Одобрение руководителем проводок выше порога
- Проверка трёхстороннего сопоставления (заказ, поступление, счёт)
- Подготовка и проверка сверок счетов
- Наблюдение за физической инвентаризацией и пересчётом
- Одобрение изменений в мастер-данных поставщиков
- Одобрение кредита клиенту
Ключевые признаки для тестирования:
- Выполнил ли контроль нужный человек (надлежащие полномочия)?
- Выполнен ли он вовремя (в требуемый срок)?
- Есть ли свидетельство проверки (подпись, инициалы, письмо, системный журнал)?
- Хватало ли проверяющему информации для эффективной проверки?
- Выявлены ли исключения и обработаны ли они должным образом?
Автоматизированные контроли
Контроли, реализованные ИТ-системами без участия человека.
Примеры:
- Рабочие процессы одобрения, обеспеченные системой (нельзя продолжить без нужных одобрений)
- Автоматизированное трёхстороннее сопоставление (система блокирует платёж, если заказ, поступление и счёт не совпадают)
- Обнаружение повторных платежей (система помечает или блокирует дубликаты счетов)
- Контроль кредитного лимита (система не пропускает заказы сверх лимита)
- Автоматические расчёты (амортизация, проценты, налоги)
- Разделение обязанностей на уровне системы (конфликтующие роли исключены)
- Контроли проверки ввода (обязательные поля, проверка формата, проверка диапазона)
- Автоматическое сопоставление при сверке
Подход к тестированию:
- Тест разработки: убедись, что конфигурация системы обеспечивает контроль так, как задумано
- Тест операционной эффективности: для автоматизированных контролей, если конфигурация системы не менялась, обычно достаточно одного теста контроля на период (в дополнение к тестированию ITGC по управлению изменениями)
- Проверь эффективность ITGC по управлению изменениями (если система менялась, протестируй контроль повторно)
Ручные контроли, зависящие от ИТ
Ручные контроли, опирающиеся на полноту и точность информации, сформированной системой.
Примеры:
- Проверка руководством сформированного системой отчёта об исключениях
- Проверка руководителем сформированного системой отчёта по срокам задолженности для оценки резервов
- Сверка с использованием данных оборотно-сальдовой ведомости, сформированной системой
- Одобрение операций, выявленных рабочим процессом системы
Подход к тестированию:
- Протестируй сам ручной контроль (проверку, одобрение, работу с исключениями)
- И протестируй полноту и точность исходного отчёта или данных (IPE — информация, подготовленная организацией)
- Тестирование IPE подтверждает, что данные, на которые опирался проверяющий, были полными и точными
Контроли уровня организации
Широкие контроли, работающие на уровне организации и влияющие на несколько процессов.
Примеры:
- Этическая атмосфера в руководстве (tone at the top) и кодекс поведения
- Процесс оценки рисков
- Надзор комитета по аудиту за финансовой отчётностью
- Функция и деятельность внутреннего аудита
- Оценка риска мошенничества и антимошеннические программы
- Горячая линия для сообщений о нарушениях и этических вопросах
- Мониторинг руководством эффективности контролей
- Компетентность в финансовой отчётности (штат, обучение, квалификация)
- Процесс подготовки периодической финансовой отчётности (процедуры закрытия, проверки соответствия GAAP)
Значение:
- Контроли уровня организации могут смягчать риски, но, как правило, не заменяют контроли уровня процессов
- Неэффективные контроли уровня организации (особенно надзор комитета по аудиту и этическая атмосфера в руководстве) — сильные признаки существенной слабости
- Эффективные контроли уровня организации могут уменьшить объём тестирования контролей уровня процессов
Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/finance/skills/audit-support, лицензия Apache-2.0. Изменения: перевод на русский язык.
Оригинал на английском
--- 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
Источник: anthropics/knowledge-work-plugins / finance / audit-support ↗. Ссылка проверена 2026-10-10.