Введение

SwiftRide T+6M — CDO Office приходит к Big 4 senior manager с черновиком каталога контролей SwiftPay: 17 контролей на CDE-SWR-003 (driver_earnings_ledger). Manager листает три страницы и говорит: «У вас 14 detective controls и 3 preventive. Это значит, что в 14 случаях вы узнаёте о проблеме после того, как она уже на проде. Соотношение должно быть обратным». CDO защищается: «Мы автоматизировали reconciliation, ежедневный DQ, ежемесячный drift detection». Manager — «правильно, но это всё ловит на выходе, а не на входе. Где gating preventive?». Это типичная асимметрия начинающей CDE-программы.

В M2.6 вы освоили вертикальную декомпозицию: риск → control objective → control activity → evidence. Этот урок раскрывает горизонтальную классификацию: каждый control activity располагается в кубе из трёх осей — timing × execution × domain. Понимание куба определяет, какие контроли набирать, чтобы покрыть CDE без избытка и без пробелов.

Три оси таксономии

Ось 1 — Timing относительно risk event

Когда контроль вступает в действие относительно момента возникновения риска.

• Preventive — действует до того, как risk-event произошёл. Цель — не допустить. Примеры: schema-enforcement в пайплайне (блокирует bad data на входе), SoD enforcement (запрещает self-deploy), input validation (отбрасывает invalid records до того, как они попадут в SoT).
• Detective — действует после того, как risk-event произошёл, чтобы обнаружить. Примеры: reconciliation между системами, anomaly detection, разбор audit logs, DQ-проверки по расписанию.
• Corrective — действует после обнаружения, чтобы восстановить состояние или ограничить ущерб. Примеры: automated rollback, процедура restatement, runbook реагирования на инциденты, восстановление из backup.

В кубе timing — самая важная ось. COSO IC 2013 COSO IC Principle 10 требует, чтобы организация подбирала control activities с учётом риска, а не просто наклеивала «контроли любого типа».

Ось 2 — Execution

Кто или что выполняет контроль.

• Manual — действие выполняет человек (sign-off, review, walkthrough). Плюсы: гибкость, judgement; минусы: медленно, evidence слабее (что именно делал reviewer — не реконструируемо), дорого при масштабе.
• Automated — действие выполняет код, пайплайн, система. Плюсы: детерминизм, immutable evidence (логи), масштабируется к тысячам записей без линейного роста затрат; минусы: стоимость реализации, требует поддержки, реагирует только на известные паттерны.

PCAOB AS 2201 ¶.47 прямо говорит: «information technology general controls effective → automated application controls generally lower risk». То есть automated control при крепких ITGC — audit-favourite.

Ось 3 — Domain

К какому слою относится контроль.

• IT (ITGC — IT General Controls) — контроли над инфраструктурой и средой, на которой работают application controls. 4 классических домена: access management, change management, computer operations, system development (см. M5.2). ITGC не привязан к одному CDE; покрывает множество.
• Business / Application — контроли внутри конкретного бизнес-процесса или пайплайна, привязанные к конкретному CDE или семейству CDE. Input validation, processing controls, output reconciliation (см. M5.3).

Критическая связка: при хорошем ITGC automated application controls сужают периметр audit testing (sampling меньше, reliance больше). При слабом ITGC даже идеальный application control не убеждает аудитора — потому что инфраструктура, на которой он работает, может быть compromised.

Куб 3 × 2 × 2 = 12 ячеек

Каждая из 12 ячеек куба — отдельный архетип контроля с собственными компромиссами. Разберём ключевые комбинации.

Preventive × Automated × IT — gold standard

Snowflake RBAC + Okta SSO + JIT access — пример из верхнего левого угла куба. Невозможно прочитать driver_earnings_ledger без явного grant; PIM-flow требует 2-eyes approval; access_history записывает каждую попытку, fail или success.

Латентность — sub-second (гейт в момент SQL-compile). Качество evidence — высокое (Okta logs + Snowflake access_history — immutable, queryable). Стоимость — средняя (начальный setup тяжёлый, runtime — почти 0).

Для material CDE это default-цель. Если вы не можете указать automated preventive ITGC на CDE — это первое место для инвестиций.

Detective × Automated × Business — workhorse SOX

Daily reconciliation commission_outputs ↔ driver_payouts_ledger, delta больше 0.05% → PagerDuty + ServiceNow Sev-2. dbt audit_helper + Python; запись reconciliation log в S3 object lock; immutable; queryable. Reconciliation log — это evidence artifact #1 для material weakness audit; аудитор открывает reconciliation log за 12 месяцев, видит signed entries каждый день, видит обработанные exceptions — контроли работают.

Латентность — 24h (daily batch). Стоимость — низкая (одна Python-функция). Качество evidence — высокое.

Detective × Manual × Anything — последний резерв

Manual detective controls — наименее предпочтительный архетип. Security Lead «раз в месяц просматривает Snowflake LOGIN_HISTORY на аномалии» — что именно он искал? Что он нашёл? Был ли systematic review или просмотр 5 минут? Reconstructable evidence невозможна.

PCAOB inspection 2024 spotlight прямо называет это top deficiency: «manual ITGC reviews — signing without actual control execution». Если автоматизация возможна (Splunk-запрос), делаем automated. Manual detective — только для creativity-driven анализа (например, fraud investigation), который алгоритмы пока не могут.

Preventive × Manual × Business — необходимый, но хрупкий

Sign-off CFO на formula change в commission engine до того, как PR мерджится. PR template содержит «CFO approved YYYY-MM-DD». Это manual preventive — критическая защита от unauthorised logic changes.

Риск — rubber-stamp. CFO смотрит 14 PR в неделю, подписывает все. Если бы он thoroughly review, какой минимум времени бы потребовался? 30 минут на PR? CFO физически не может. Поэтому ВСЕГДА дополняем detective (C-003 reconciliation) — если sign-off механический, reconciliation поймает результат.

Когда какой тип оптимален — три критерия выбора

Cost-benefit

Preventive control в момент реализации дороже detective (gating требует продумывания всех failure modes заранее), но в operational mode дешевле detective (нет стоимости восстановления). Detective дёшево внедрить (одна Python-функция), но каждый пойманный defect инициирует реагирование на инцидент — sunk cost.

Правило большого пальца: для high-frequency CDE (real-time пайплайны, большой объём данных) preventive окупается за месяцы. Для low-frequency CDE (квартальные агрегаты, малый объём) detective достаточно.

Latency tolerance

Если business impact ошибки начинается сразу — preventive обязателен. Driver earnings — payout день в день; bad commission_pct мгновенно бьёт по drivers. Preventive (input validation) ловит на upstream; detective (daily reconciliation) — медленно, ловит ретроспективно, наносит ущерб в $$$ до catch.

Если impact задержанный — 1099 export раз в год — detective достаточно, корректировка возможна до actual filing.

Качество evidence

Аудитор доверяет evidence в порядке: automated logs (immutable) > automated logs (mutable, но signed) > manual signed reviews > manual unsigned reviews. SOX-grade evidence требует immutability как минимум. PCAOB AS 1305 — control deficiency = control «that does not allow management or employees… to prevent or detect misstatements on a timely basis». Если evidence нельзя реконструировать — control failed test, deficiency по определению.

Типичная ошибка — чрезмерная опора на detective

Паттерн: команда внедряет dbt tests, GE expectations, anomaly detection, reconciliation jobs — десятки detective controls. Это понятно: detective дёшево, видно в дашбордах, ощущается как progress.

Подводные камни:

1. Latency leak: каждый detective control имеет latency window, во время которого bad data flows downstream. Reconciliation = 24h. Anomaly detection = 1-15 мин. Schema test на PR — 1 час. Для real-time CDE (SwiftPay payments, IRS regulator filings, real-time pricing) даже минуты — material exposure.
2. Restatement cost: каждый пойманный defect требует rollback, reprocessing, communication. Если preventive поймал bad commit на CI — 0 стоимость. Detective на prod — инцидент, post-mortem, customer comms, уведомление совета директоров.
3. Audit narrative: «у нас 14 detective controls» звучит хорошо, пока не появляется первый material misstatement. Тогда вопрос аудитора: «почему вы решили оставлять риск до detect-time?».

Defense-in-depth fix: на каждом material CDE дублируем типы. 1-2 preventive (schema enforcement в dbt contract, SoD на logic changes, input validation) + 2-3 detective (reconciliation, DQ checks, anomaly detection) + 1 corrective (reprocessing DAG, restatement runbook).

Defense in depth — минимум 1 preventive + 1 detective на каждый CDE

Принцип закодирован в COSO IC 2013 Principle 10 («selects and develops control activities») и явно требуется ECB RDARR Guide May 2024 (для G-SIBs и euro-area significant institutions): для CDE banks обязаны maintain «adequately designed and operating control framework — both preventive and detective».

Практический шаблон для material CDE:

6 контролей, 4 разных архетипа куба. Каждый слой защищает от отдельного failure mode предыдущего. Single-cell coverage (всё preventive automated business, например) = single point of failure: одна реализация-баг → весь CDE без защиты.

Примеры SwiftRide по ячейкам — резюме

Каждая ячейка ControlTaxonomyCube выше показывает конкретный пример SwiftRide. Прокликайте все 12 — заметите паттерн:

• Preventive × Automated × IT — Snowflake RBAC + JIT — gold standard.
• Preventive × Automated × Business — dbt contract — дёшево, встроено.
• Detective × Automated × Business — daily reconciliation — workhorse.
• Corrective × Automated × Business — reprocessing DAG — дорого, но необходимо.
• Manual × Detective × Anything — последний резерв; избегаем, если автоматизируемо.

Цель CDE controls design — заполнить достаточно ячеек, чтобы defense-in-depth выполнялся (минимум 1 preventive + 1 detective + желательно 1 corrective), при минимизации manual-ячеек.

Anti-patterns

«Один control, два типа»

Паттерн: команда называет daily reconciliation «и preventive, и detective». Логика: «потому что после её внедрения инженеры перестали пушить bad commits».

Почему плохо: timing matters. Reconciliation работает после event; behavioural shift — это побочный эффект, не control mechanism. Аудитор классифицирует по механизму, не по эффекту. Reconciliation — detective.

Fix: размечать механизм честно. Если хотите preventive effect — внедрите schema enforcement в CI (это уже отдельный preventive control).

Detective-only покрытие с обоснованием «у нас все на одной волне»

Паттерн: «наши инженеры взрослые, не пушат bad commits; preventive не нужен — добавит friction».

Почему плохо: SOX framework предполагает, что individual judgement fallible. Preventive существует не потому что инженеры плохие, а потому что accident, fatigue, malicious insider, mistake возможны. PCAOB AS 1305 не предполагает «trust» как control.

Fix: внедрите preventive с минимальным friction — schema contracts в CI fail fast, не блокируют innovation. Инженеры быстро привыкают.

Размазывание ITGC по всем CDE

Паттерн: одна Snowflake RBAC policy упоминается как control на 24 CDE.

Почему плохо: ITGC покрывает инфраструктуру, не CDE-specific. Аудитор смотрит — «ок, это ITGC, оно покрывает access, но что preventive именно для commission calculation accuracy»? И обнаруживает 0.

Fix: ITGC — это базовая линия. На вершине нужны application controls per material CDE.

Резюме

• Каждый control activity классифицируется по 3 осям: timing (preventive / detective / corrective) × execution (manual / automated) × domain (IT / business). 12 ячеек, разные компромиссы.
• Preventive × Automated × IT — gold standard для CDE (Snowflake RBAC + Okta JIT). Preventive × Automated × Business — встроено в пайплайн (dbt contracts). Detective × Automated × Business — daily reconciliation, workhorse SOX evidence.
• Manual detective controls — последний резерв. PCAOB inspection 2024 — top deficiency. Автоматизируем где возможно.
• Defense-in-depth для material CDE: минимум 1 preventive + 1 detective + желательно corrective. Single-cell coverage = red flag.
• PCAOB AS 2201 ¶.47 — effective ITGC снижает риск для automated application controls. Сначала строим крепкий ITGC; затем накладываем application controls сверху.

В M5.2 разберём слой ITGC подробно — 4 классических домена применительно к data systems (access, change, ops, SDLC).