Введение

M5.2 daily standup. Data engineer SwiftRide отчитывается: «Я добавил control для CDE-SWR-003 — daily check SELECT COUNT(*) FROM fct_driver_earnings WHERE date = current_date. Возвращает 12000, smoke test passes». Tech Lead спрашивает — «А что именно ты proving этим check’ом? Если row count нормальный, всё OK? Что если 12000 записей содержат wrong values?». Engineer: «Эээ… ну, проверка есть».

Это классический anti-pattern. Инженер написал SQL-запрос — это не control. Это наблюдение. Control имеет структуру: что мы хотим (control objective) — как мы достигаем (control activity) — как доказываем, что работает (evidence requirement). Без всех трёх уровней SELECT COUNT(*) всего лишь говорит, что пайплайн ran, не что control achieves anything.

В M2.6 вы видели intro к этой структуре. M5.4 раскрывает деталь: на material CDE собирается 1-3 control objectives; на objective — 1-2 activities; на activity — 1 evidence stream. Полная декомпозиция для driver_earnings — 4 objectives × ~2 activities = 8 activities × 8 evidence streams. Audit-defensible — каждый уровень прямо traceable к risk register, к регуляторной цитате SOX/BCBS/GDPR/AML и к operational implementation.

Три уровня

Уровень 1 — Control objective

Определение: заявленный outcome, который организация должна достичь, чтобы смягчить риск. Сформулирован как желаемое состояние, не как действие.

Формат: «[CDE / процесс / данные] is/produces/maintains [quality attribute] [в пределах толеранса / времени / периметра]».

Примеры (хорошие):

• «Расчёт commission driver earnings производит accurate values per documented formula; любая systematic error обнаруживается в течение 24 часов».
• «Revenue aggregates fct_revenue_daily reconcile с source-of-truth trip records в пределах delta 0.05% за любой отчётный период».
• «KYC profile data integrity сохраняется во время ingestion — нет corruption PII, нет потери biometric match score».

Примеры (плохие — типичные ошибки):

• «Run dbt tests» (это activity, не objective).
• «Daily reconciliation» (activity).
• «Make sure data is correct» (расплывчато — что значит «correct»? какой толеранс?).

Control objectives derive из risk register (M2). Каждый идентифицированный material risk → 1-3 control objectives. Risk = «commission calculation error» → Objectives = «accuracy с delta ±0.05%», «integrity — formula неизменна без approval», «timeliness — payouts в течение 24h после завершения trip».

Стабильный идентификатор per objective: OBJ-{cde-id}-{NN}. SwiftRide: OBJ-CDE-SWR-003-01 через OBJ-CDE-SWR-003-04.

Уровень 2 — Control activity

Определение: конкретный operational механизм, реализующий objective. Сформулирован как verb-first.

Формат: «[Частота] [система / актор] [глагол] [target] [толеранс/критерии] → [результирующее действие]».

Примеры:

• «Daily Airflow DAG reconciles commission_outputs против driver_payouts_ledger; delta больше 0.05% → PagerDuty Sev-1 + ServiceNow ticket в течение 4h».
• «На каждом PR, модифицирующем fct_driver_earnings.sql, CI gating запускает dbt model contract check; column drop or type mutation → build fails; Finance Lead approval required для merge».
• «Hourly GE Core 1.17.1 expectation suite на fct_driver_earnings.gross_earnings_usd > 0 AND в ожидаемом диапазоне per БЮ; fail → PagerDuty Sev-2».

Каждый objective обычно требует 1-2 activities — defense-in-depth (M5.1). Один activity = single point of failure. Стабильный identifier: CTL-{cde-id}-{NN}. SwiftRide: CTL-CDE-SWR-003-001 через CTL-CDE-SWR-003-008.

Уровень 3 — Evidence requirement

Определение: артефакт, доказывающий, что activity действительно выполнен И произвёл ожидаемый outcome.

Обязательные атрибуты per evidence:

1. Timestamp — когда activity executed.
2. Immutable storage — нельзя ретроактивно модифицировать.
3. Signed / authenticated — актор (система или человек) верифицируем.
4. Outcome captured — pass / fail / exception, со specifics.
5. Retention — соответствие regulatory requirement (SOX 7y, GDPR per Art. 30, FATF 5-7y, и т.д.).
6. Queryable — аудитор может retrieve by date / control_id / CDE.

Примеры:

• Reconciliation log entry: {timestamp: 2026-05-11T06:00:00Z, control_id: CTL-CDE-SWR-003-003, snowflake_sum: 12450231.45, aurora_sum: 12450239.12, delta_pct: 0.000635, status: pass, signed_by: system, signature_alg: HMAC-SHA256}. Хранится в S3 bucket с object lock (compliance mode), retention 7y.
• dbt run artifact + GitHub PR + CODEOWNERS approval: PR commit SHA, dbt manifest.json, run_results.json — всё archived в S3 7y; GitHub immutable commit chain.
• GE Data Docs HTML + validation result JSON — публикуется в S3 bucket после каждого запуска; immutable; queryable by control_id + date.

Типичная ошибка — control = SELECT COUNT(*)

Паттерн: инженер пишет SQL-запрос, задаёт расписание, объявляет «у нас есть control».

-- Это НЕ control
SELECT COUNT(*) FROM fct_driver_earnings WHERE date = current_date;

Почему это не control:

1. Нет objective. Что значит «count > 0» = success? Почему? Что если count = 11800 вместо 12000 — что это значит business-wise? Без objective нельзя интерпретировать результат.
2. Activity без specifics. Что происходит, если count breaches? Где залогировано? Кто notified?
3. Нет evidence. Query result — эфемерный; нет immutable artifact; нет retention; нет audit trail.

Fix — декомпозиция во все три уровня:

Objective (OBJ-CDE-SWR-003-04): «Daily computation driver earnings успешно завершается и производит ожидаемый объём output, согласованный с trip volume».

Activity (CTL-CDE-SWR-003-007): «Daily в T+1 06:00 UTC Airflow DAG выполняет completeness check: row count fct_driver_earnings за prior day против ожидаемого (= count активных drivers per БЮ × 1.0 ±5% толеранс). Out-of-range → PagerDuty Sev-2 + ServiceNow ticket; auto-triggers reprocess_driver_earnings DAG».

Evidence: Airflow run log + check_result JSON в S3 object lock; ServiceNow ticket trail; PagerDuty incident; retention 7y SOX-grade.

Это трио — actual control. SQL-запрос — это implementation detail Activity.

Evidence requirement — детально

Immutable storage

Evidence должен быть устойчив к after-the-fact модификации.

Варианты:

• S3 object lock (compliance mode) — после написания не может быть удалён или модифицирован до истечения retention period. Даже root-аккаунт не может delete. Используется SwiftRide для evidence material CDE.
• Snowflake Time Travel / Fail-safe — ограничен 90+7 дней; не подходит для 7y SOX.
• Append-only ledger — например, AWS QLDB, Hyperledger Fabric. Избыточно для большинства случаев.
• Git — immutable commit chain, signed commits (gpg-signed); хорошо для evidence PR / config.

Signed / authenticated

Либо system-signed (HMAC, JWT, signed artifact), либо human-signed (cryptographic signature, attestation form с identity proof).

Паттерны SwiftRide:

• Система: Airflow DAG run logs + HMAC-SHA256 signature на output JSON; key management через AWS KMS.
• Человек: attestation через Saviynt / Workiva — accountable manager подписывает digitally; OIDC identity captured.
• Код: PR commits gpg-signed; GitHub branch protection требует signed commits на main.

Retention

Regulatory baselines:

Консервативная практика: 7 лет как baseline для CDE evidence; больше per specific regulatory mandate.

Queryable

Evidence должен быть retrievable по:

• Диапазону дат
• Control ID
• CDE ID
• Исходу (pass / fail / exception)
• Актору (система / пользователь)

Реализация SwiftRide: evidence index в Snowflake audit.evidence_index table — pointers к S3 keys; queryable view; доступ RBAC ограничен до audit + compliance.

Шаблон per CDE — 1-3 objectives, 1-2 activities per objective, 1 evidence per activity

Типичная декомпозиция для material CDE:

CDE-SWR-XXX
├── OBJ-CDE-SWR-XXX-01 (например, accuracy)
│   ├── CTL-XXX-001 (preventive automated)
│   │   └── Поток evidence 1
│   └── CTL-XXX-002 (detective automated)
│       └── Поток evidence 2
├── OBJ-CDE-SWR-XXX-02 (например, integrity)
│   ├── CTL-XXX-003 (preventive manual)
│   │   └── Поток evidence 3
│   └── CTL-XXX-004 (detective automated)
│       └── Поток evidence 4
└── OBJ-CDE-SWR-XXX-03 (например, timeliness)
    └── CTL-XXX-005 (detective automated)
        └── Поток evidence 5

Material CDE — 3 objectives × ~2 activities = ~6 controls + 6 evidence streams типично. Driver_earnings (высокая сложность) — 4 objectives × ~2 = 8 activities. Простые CDE (reference data, slow-changing) — 1-2 objectives × 1-2 activities = 2-4 controls.

Driver_earnings SwiftRide — полная декомпозиция

CDE-SWR-003 driver_earnings_ledger. Полная декомпозиция controls:

Каждый поток evidence имеет structured artefact + retention. Аудитор может запросить «evidence для CDE-SWR-003 OBJ-01 за Q3 2026» — Snowflake audit.evidence_index возвращает 90 entries (daily reconciliation logs); аудитор открывает любые 25 в выборку, верифицирует поля, прослеживает к ServiceNow exception tickets, если delta больше threshold occurred.

Regulatory baselines retention evidence

PCAOB AS 1105 — требования audit evidence retention. SOX 404 — 7 лет с даты закрытия audit period. Следствие: каждый evidence для material CDE control — минимум 7y retention. Если control fires daily через 90 reporting periods = 90 evidence artefacts per control; 8 controls = 720 evidence artefacts; умножено на 7 лет × 90 = 630 reporting cycles = тысячи артефактов per CDE.

GDPR Art. 30 требует retention за длительность processing + per retention policy организации. PII-related evidence (KYC, biometric, PII access logs) — retention привязан к GDPR retention period; типично 6 месяцев — 5 лет в зависимости от юрисдикции.

Multi-regulator CDE (driver_earnings — SOX + GDPR + IRS 1099 + labor) — побеждает most-restrictive retention. 7y SOX обычно доминирует.

Anti-patterns

Control = наблюдение

Паттерн: «У нас есть daily query, который проверяет X. Это наш control».

Почему плохо: наблюдение говорит вам state, не обеспечивает его. Control = механизм для prevention/detection плюс evidence trail.

Fix: декомпозиция в objective + activity + evidence (все три).

Evidence в mutable storage

Паттерн: control-логи в Snowflake table; инженер уверяет «retention 7y сконфигурирован».

Почему плохо: Snowflake table mutable — DBA / privileged actor может удалить или модифицировать ретроактивно. Не SOX-grade.

Fix: append-only storage (S3 object lock compliance mode, AWS QLDB, blockchain). Snowflake table — нормально для query index, не для primary evidence.

Generic evidence «check passed»

Паттерн: log entry: {timestamp: ..., result: pass}. Аудитор: «pass на чём?». Никаких specifics.

Почему плохо: реконструкция невозможна. Если аудитор запрашивает за прошлый год, не может реконструировать, какие values passed against which thresholds.

Fix: structured evidence с полным state — input values, threshold, computed delta, signed_by, version of rule applied. Реконструируемо годы спустя.

Retention не соответствует регуляции

Паттерн: 90 дней retention для CDE evidence; инженер говорит «достаточно для operational use».

Почему плохо: SOX 7y обязателен; аудитор запрашивает evidence за 2 года назад — недоступно.

Fix: согласовать retention с most-restrictive applicable regulation. Задокументировать retention policy per CDE в registry (M4.5).

Резюме

• Control = 3-уровневая структура: Objective (что мы хотим) → Activity (как мы это делаем) → Evidence (как мы доказываем). Без всех трёх — это observation, не control.
• На material CDE: 1-3 objectives, 1-2 activities per objective, 1 evidence stream per activity. Material CDE типично — 3-4 objectives × ~2 activities = 6-8 controls + потоков evidence.
• Evidence requirements: timestamp, immutable storage, signed/authenticated, outcome captured, retention regulatory-aligned, queryable.
• Retention baselines: SOX 7y, GDPR per Art. 30, AMLR/FATF 5-7y, EU AI Act 10y. Multi-regulator CDE — побеждает most-restrictive.
• Типичная ошибка — SELECT COUNT(*) = наблюдение, не control. Fix: явно определить objective, activity с конкретной outcome chain, evidence с immutability + retention + queryability.
• SwiftRide CDE-SWR-003 driver_earnings — 4 objectives × 8 activities × 8 потоков evidence. Стабильные ID OBJ-CDE-SWR-003-{NN}, CTL-CDE-SWR-003-{NNN}; evidence в S3 object lock + GitHub commit chain.

В M5.5 разберём, как 6 DQ dimensions мапятся к controls (completeness, accuracy, consistency, timeliness, uniqueness, validity), плюс mapping к regulatory needs (BCBS 239 Principles 3-4, GDPR Art. 5, IFRS 13 reliability).