Введение

SwiftRide T+9M. Big 4 проводит первый промежуточный walkthrough перед SOX dry-run в T+15M. Senior associate Maya садится с CDO Office и спрашивает: «Покажите evidence для CTL-CDE-SWR-003-002 — ежедневная сверка между fct_driver_earnings и swiftpay.payouts. Период выборки — Q3 2026, размер выборки 30 запусков». CDO Office открывает Snowflake-таблицу audit.recon_runs, делает SELECT, экспортирует CSV. Maya: «И это весь evidence — результат SQL-запроса в Snowflake?». CDO Office: «Да, вот 90 строк». Maya: «А кто гарантирует, что эти строки не были изменены после первичной записи? Кто выступает timestamp signing authority? Откуда я могу узнать, какая версия правила применялась в августе? Где исходные input values, чтобы я могла независимо пересчитать?». CDO Office понимает — Snowflake-таблица — это operational signal, а не audit evidence.

Этот разговор открывает M7. M5.4 описал 3-уровневую структуру (objective → activity → evidence) и 6 атрибутов evidence. M7.1 раскрывает каждый атрибут детально через призму аудитора. Этот урок — мост между «у нас есть control» и «контроль защищается перед инспектором PCAOB».

PCAOB AS 1105 — фундамент

PCAOB AS 1105 ¶.02 определяет audit evidence как «вся информация, используемая аудитором для формирования заключений, на которых основано его мнение». Стандарт amended 15 December 2025 (PCAOB Release 2024-007 «Aspects of Designing and Performing Audit Procedures That Involve Technology-Assisted Analysis») — обновление прямо отражает реальность data-heavy ICFR.

Два ключевых параграфа для CDE-программы:

¶.07-.08 — релевантность и надёжность. Evidence обязан быть релевантен для тестируемого утверждения (assertion) и достаточно надёжен для вывода. Надёжность — функция источника и природы. Внешний источник (банковская выписка, regulator filing) — более надёжен, чем внутренний. Независимый внутренний источник (independent Reconciliation team) — более надёжен, чем источник самой функции.

¶.10 — IPE (Information Produced by Entity). Если аудитор полагается на информацию, произведённую entity (то есть evidence от менеджмента, а не от внешней стороны), аудитор обязан:

1. Протестировать accuracy and completeness информации, либо
2. Протестировать контроли над accuracy and completeness, и
3. Оценить, достаточно ли информация precise and detailed для целей аудитора.

Это значит, что каждый артефакт от entity (вывод DQ-прогона, лог сверки, снимок дашборда) — IPE, и аудитор обязан либо независимо его пересчитать, либо верифицировать контроли над его генерацией.

¶.10A добавлен в поправках 2025 — внешняя electronic information (например, данные крипто-биржи, банковские API-фиды) — principle-based, risk-scalable требования; здесь подробно не рассматривается, но релевантно для данных банковского партнёра SwiftPay.

6 атрибутов evidence — детальный разбор

Согласно M5.4 — 6 атрибутов. M7 раскрывает каждый через PCAOB lens.

Атрибут 1 — Timestamp

UTC ISO 8601 (2026-09-15T06:00:00Z). Критически важны три свойства.

Доверенный источник. Генерируется на системе, синхронизированной с надёжным источником времени (chrony / NTP со stratum ≤ 3). Не «локальное время сервера, которое может дрейфовать». AWS hardware time через KMS — самый сильный паттерн; локальное время docker-контейнера — слабое.

Не задним числом. Timestamp встраивается в payload evidence в момент генерации; не добавляется ретроспективно logger-пайплайном. Если пайплайн добавляет timestamp при ingest в S3 (через часы после события), аудитор спросит «как доказать, что заявленный timestamp совпадает с фактическим временем запуска?».

Гранулярность. Миллисекундная точность для высокочастотных контролей (real-time AML monitoring); секундная точность для ежедневной сверки. Sub-second precision важна, если контроли взаимодействуют (audit trail с последовательностью A → B → C).

Атрибут 2 — Версия / хеш датасета

Версия датасета — указатель на состояние входных данных на момент выполнения контроля. Паттерны:

• Snowflake Time Travel snapshot ID — select system$last_change_commit_time(table_name) или явный AT (TIMESTAMP => '...').
• dbt build manifest — снапшот manifest.json по commit SHA того прогона.
• S3 object versionId + ETag — для входных данных в виде файлов.
• Database transaction LSN (PostgreSQL log sequence number) — для CDC-based пайплайнов.

Хеш — md5 или sha-256 входного rowset (для малых входов) или манифест входов (для крупных). Обеспечивает независимый пересчёт: «вот hash входа X; пересчитайте правило и проверьте, что вывод соответствует ожидаемому».

Паттерн SwiftRide для сверки CDE-SWR-003:

{
  "control_id": "CTL-CDE-SWR-003-002",
  "timestamp": "2026-09-15T06:00:00Z",
  "input_state": {
    "snowflake_table": "DL_MARTS.FCT_DRIVER_EARNINGS",
    "snowflake_snapshot_at": "2026-09-15T05:59:00Z",
    "row_count": 1238450,
    "input_hash": "sha256:7f3a..."
  }
}

Атрибут 3 — Rule / Control ID

Стабильный идентификатор согласно M5.4 — CTL-CDE-SWR-003-NNN. Связывает evidence с каталогом контролей (M5.9 control matrix), реестром рисков (M2.7), CDE-реестром (M4.5). Без стабильного ID аудит не может проследить evidence до проектной документации; контроль может оказаться «orphan» — работающим, но не связанным с риском, который он митигирует.

Антипаттерн — evidence ссылается на контроль по имени-строке («Daily reconciliation»). Имена меняются; наблюдатель PCAOB, пытающийся отобразить evidence на risk-control matrix, не сможет ориентироваться.

Атрибут 4 — Результат + наблюдаемые значения

Не «pass / fail» в одиночку. Согласно ¶.10 «sufficiently precise and detailed»:

• Pass / fail / exception + код причины, если исключение.
• Наблюдаемые значения — фактические выходы применения правила.
• Применённые пороги — с чем сравнивалось (НЕ hard-coded — какая версия порога).
• Вычисленная delta / score — явное число, а не «в пределах допуска».

Пример для контроля сверки:

{
  "result": "pass",
  "observed": {
    "snowflake_sum_usd": 12450231.45,
    "aurora_sum_usd": 12450239.12,
    "delta_pct": 0.0000615
  },
  "thresholds": {
    "max_delta_pct": 0.0005,
    "threshold_version": "v3.2.0"
  }
}

Аудитор может верифицировать: delta_pct = (12450239.12 - 12450231.45) / 12450231.45 ≈ 0.0000615 < 0.0005 → pass подтверждён.

Антипаттерн: {"result": "pass"} — аудитор спросит «pass относительно чего?». Восстановить невозможно.

Атрибут 5 — Обработка исключений

Если результат fail — evidence обязан зафиксировать полную цепочку исключения:

• ID тикета — Jira / ServiceNow (например, DE-1547).
• Severity — назначенный уровень (SEV-1 / SEV-2 / SEV-3).
• Назначенный owner — ответственный.
• Timestamp закрытия — когда remediation верифицирована.
• Активация компенсирующего контроля — если первичный контроль упал, что его замещало.
• Ссылка на resolution evidence — указатель на лог запуска reprocess DAG + post-fix сверка.

Без обработки исключений в evidence-цепочке — аудитор видит fail без resolution → запрашивает «как исправлено? увеличить выборку fails, чтобы протестировать management response». PCAOB AS 1305 control deficiency, если fails остаются открытыми.

Атрибут 6 — Неизменяемое хранилище + подпись

Неизменяемое хранилище. Не «write-only по соглашению». Принуждается на уровне хранилища.

• S3 Object Lock — Compliance Mode — после записи с retention не может быть удалён даже root-аккаунтом. Самый сильный паттерн. Документация AWS явно указывает «Compliance mode = WORM». Дефолт для evidence SwiftRide CDE.
• S3 Object Lock — Governance Mode — root-аккаунт может обойти (s3:BypassGovernanceRetention permission). Слабее; аудитор может принять, если IAM-политики жёстко ограничивают bypass.
• AWS QLDB — append-only ledger; криптографическая верификация; избыточно для большинства паттернов, отлично для high-stakes attestation records.
• WORM bucket в отдельном AWS-аккаунте — defence-in-depth: даже при компрометации основного аккаунта evidence в безопасности.

Подпись. Два паттерна:

• Системная подпись — HMAC-SHA256 по payload evidence через KMS-ключ; доступ к ключу жёстко ограничен; политика ротации задокументирована. Верифицирует идентичность системы (то есть это запущено на системе X с ключом Y) и неизменность.
• Подпись человека — для attestation records (квартальный sign-off). DocuSign / AdobeSign / Workiva native e-sig с захватом OIDC identity. Отсканированная рукописная подпись — слабее всего (фальсифицируема).

Без подписи — аудитор не может доказать, что evidence не был изменён после записи; даже неизменяемое хранилище доказывает только «после записи не менялось», но не «кто записал».

Direct vs indirect evidence

Direct evidence — напрямую наблюдает тестируемое утверждение. Лог сверки, напрямую показывающий delta = 0.0000615% < 0.0005% threshold — direct evidence того, что значения совпадают за тестируемый период.

Indirect evidence — поддерживает вывод. Approval code review показывает, что 4-eyes review состоялся, но не показывает напрямую, что расчёт в продакшене корректен. Оба имеют ценность, но аудитор сильнее опирается на direct evidence.

Паттерн для material CDE: складывайте indirect (ITGC — change management, access controls) плюс direct (application controls — сверка, проверка полноты). Indirect без direct = «у нас есть process controls, но мы не можем доказать корректность выходов». Direct без indirect = «выходы выглядят корректно, но мы не можем доказать повторяемость процесса».

Design vs operating effectiveness — две сущности

Паттерны PCAOB inspection findings 2024-2025 — Big 4 firms часто получают претензии за смешение этих понятий.

Design effectiveness — контроль, как задизайнен, мог бы предотвратить / обнаружить material misstatement при корректной работе. Evidence — документация дизайна: записи control matrix (M5.9), risk-control mapping (M2.6), runbooks, evidence конфигурации (например, dbt contract YAML, закоммиченный в git).

Operating effectiveness — контроль действительно работал как задизайнен на протяжении отчётного периода. Evidence — операционные артефакты: 90 дней логов сверки (90 evidence-артефактов), история CI-прогонов, показывающая, что все PR-мерджи имели CODEOWNERS approval, sign-off attestation.

Аудитор сначала тестирует design (walkthrough — обычно 1 sample на контроль). Затем тестирует operating effectiveness — несколько samples на контроль (нормы выборок PCAOB: 25 для ежедневных контролей, 40+ для high-risk). Если sample fails — аудитор расширяет выборку или эскалирует менеджменту.

Импликация для SwiftRide: для каждого material CDE evidence-пайплайн производит evidence operating effectiveness ежедневно/ежечасно; design effectiveness идёт из M5.9 control matrix + записи в registry M4.5 + состояния dbt-репозитория.

Evidence от менеджмента vs от внешнего источника

Evidence менеджмента (IPE) — производится самой entity; согласно AS 1105 ¶.10 аудитор обязан тестировать accuracy/completeness.

Внешний evidence — производится независимой третьей стороной — банковские выписки, regulator filings, отчёты внешних аудиторов аналогичного scope. Более высокая надёжность (¶.07-.08).

Гибрид — производится entity, но верифицируется снаружи. Примеры: логи доступа AWS S3 (entity использует, AWS производит); CDN-логи; экспорты использования аккаунта от SaaS-вендора (Confluent, Snowflake) — генерируются вендором от имени entity.

Призма PCAOB — каждый артефакт классифицируется. Evidence CDE почти всегда IPE (производится entity); паттерн опоры — верифицировать контроли над генерацией плюс независимый пересчёт на выборке.

Иерархия надёжности

PCAOB AS 1105 ¶.07-.08 неявно упорядочивает evidence по надёжности:

1. Внешний независимый источник — банковские подтверждения, regulator filings, логи использования аккаунта вендора. Наиболее надёжный.
2. Внутренний независимый источник — Internal Audit (3-я линия) тестирование; Risk Function (2-я линия) мониторинг. Независимость от data team.
3. Внутренний источник с контролями — IPE с сильными контролями (неизменяемое хранилище, HMAC-подпись, возможность пересчёта). Аудитор тестирует контроли и принимает.
4. Внутренний источник без контролей — IPE со слабыми контролями (изменяемая Snowflake-таблица, без подписи). Аудитор обязан выполнить обширное substantive testing.
5. Только management representation — письменное заявление «мы подтверждаем, что evidence accurate». Слабее всего. PCAOB AS 1105 явно указывает, что одной management rep недостаточно для material assertions.

Практическая импликация для CDE-программы: целиться в tier 3 (IPE с сильными контролями) как базовую линию; накладывать tier 2 (тестирование Internal Audit) для material CDE; tier 1 (внешняя верификация) там, где возможно (например, сверка банковских выписок для выплат SwiftPay).

SwiftRide CDE-SWR-003 — полный evidence-пакет

Квартальный evidence-пакет Q3 2026 для driver_earnings:

Выборка аудитора — 30 ежедневных прогонов сверки (случайных из 92); 25 GE checkpoint часовых прогонов (стратифицированных по бизнес-юнитам); все 2 срабатывания исключений + цепочка закрытия. Аудитор вручную пересчитывает 5 samples (откат снапшота Snowflake + арифметика).

Тест восстановимости — аудитор вытягивает прогон за 2026-08-23 06:00:00 UTC:

-- audit.evidence_index query
SELECT s3_key, sha256, retention_expires
FROM audit.evidence_index
WHERE control_id = 'CTL-CDE-SWR-003-002'
  AND run_timestamp_utc = '2026-08-23T06:00:00Z';

Возвращает S3-ключ. Аудитор скачивает:

{
  "control_id": "CTL-CDE-SWR-003-002",
  "timestamp": "2026-08-23T06:00:00Z",
  "input_state": {
    "snowflake_snapshot_at": "2026-08-23T05:59:00Z",
    "input_hash": "sha256:a3f7b2c..."
  },
  "rule_version": "v3.2.0",
  "threshold": {"max_delta_pct": 0.0005},
  "observed": {
    "snowflake_sum_usd": 12450231.45,
    "aurora_sum_usd": 12450239.12,
    "delta_pct": 0.0000615
  },
  "result": "pass",
  "signed_by": "system:swr-recon-runner",
  "signature": "hmac-sha256:f4d2a..."
}

Аудитор верифицирует подпись через публичный ключ KMS; вручную пересчитывает delta_pct; запрашивает Snowflake at (timestamp => '2026-08-23T05:59:00Z') для повторной суммы; совпадает. Evidence-цепочка защищаема перед аудитом.

Антипаттерны

«Audit trail = evidence»

Паттерн: «У нас есть CloudTrail / Airflow logs / Snowflake QUERY_HISTORY».

Почему недостаточно: operational signal. Изменяемый (CloudTrail может сохраняться, но retention контролируется контрактом вендора); нет привязки к control_id; не подписано поэлементно; аудитор не может восстановить конкретное исполнение правила.

Исправление: структурированный per-control evidence payload отдельно от audit trails. Audit trails — вспомогательны, не первичны.

«Скриншот дашборда»

Паттерн: квартальный attestation pack включает скриншот дашборда Looker с 92 зелёными галочками.

Почему недостаточно: эфемерный (Looker запрашивает изменяемое состояние; пересборка дашборда позже может показать другой результат); без подписи; не восстановим.

Исправление: дашборд формируется из Snowflake-вью audit.evidence_index с указателями на неизменяемые S3 payload; скриншот вспомогательный.

«Только self-attestation»

Паттерн: Business Owner подписывает «Я подтверждаю, что все 92 прогона контроля прошли успешно в Q3 2026». Evidence-пакета нет.

Почему недостаточно: AS 1105 ¶.07-.08 — management representation недостаточна для material assertions; tier 5 reliability.

Исправление: attestation сопровождается полным evidence-пакетом из неизменяемого хранилища; менеджмент представляет, аудитор независимо верифицирует.

«Evidence в приватном Slack»

Паттерн: цепочка обработки инцидента в приватном канале Slack; закрытие через сообщение в Slack.

Почему недостаточно: retention Slack контрактный; изменяем; не запрашивается по control_id; идентичность не зафиксирована криптографически.

Исправление: Slack — слой operational signal; цепочка evidence через Jira/ServiceNow с полным audit log + timestamps закрытия + подписанным owner; зеркалирование в архив S3 на 7 лет.

Резюме

• PCAOB AS 1105 ¶.10 IPE — фундамент; аудитор обязан тестировать accuracy/completeness или контроли над генерацией плюс оценивать достаточную precision and detail.
• 6 атрибутов evidence: timestamp UTC, версия+хеш датасета, rule/control ID, результат+наблюдаемые+пороги, обработка исключений, неизменяемое хранилище+подпись.
• Direct evidence (утверждения наблюдаются напрямую) весомее indirect; для material CDE нужны оба.
• Design effectiveness (контроль мог бы работать) vs operating effectiveness (контроль действительно работал) — различны; аудитор тестирует оба; PCAOB inspections часто отмечают смешение.
• Иерархия надёжности: external > internal independent > internal source с сильными контролями > internal source со слабыми контролями > только management rep. Целевая базовая линия tier 3+.
• SwiftRide CDE-SWR-003 — 8 потоков evidence по 8 контролям; выборка Q3 2026 ~2200 часовых + 92 ежедневных прогона; восстановим из S3 Object Lock 7 лет + Snowflake-вью audit.evidence_index.

В M7.2 разберём end-to-end pipeline сбора: DQ engine → emitter → immutable store → attestation system → auditor view. Выбор инструментария (GE 1.17.1 / Soda 4.0 / Anomalo) и архитектурные паттерны.