Введение

PCAOB 2024 Spotlight (March 2025) — самый важный data point для понимания текущего состояния SOX-аудитов по данным: отказы ITGC по logical access и change management — top deficiency cause. Aggregate Part I.A deficiency rate — 39% (снизилось с 46% в 2023, но всё ещё треть аудитов). Big Four — 20% (снизилось с 26%). И в каждом из этих случаев логически — слабые ITGC означают, что на automated application controls нельзя полагаться, что означает расширенное тестирование, расширенную стоимость аудита, расширенные находки.

Для SwiftRide на T+4M это означает: remediation ITGC — приоритет №1 в pre-IPO playbook. CDO ставит ITGC-матрицу первым артефактом для review Big 4. Этот урок — глубокий разбор ITGC: 4 домена, контроли, deficiencies, требования к evidence и как complement frameworks (COBIT 2019, ITIL 4, NIST SP 800-53) кооперируют.

Что такое ITGC

ITGC = IT General Controls. Контроли общего IT-уровня, обеспечивающие надёжность всех application controls + automated controls + IT-dependent manual controls. Если ITGC ломаются — на automated application control нельзя полагаться, потому что нельзя доверять подлежащему IT environment.

Нет единого регуляторного ITGC standard. В US SOX practice — 4 домена, выведенные из COSO 2013 Principle 11 + PCAOB PCAOB AS 2201 ¶.36-.47:

Домен 1 — Access Management

Типичные контроли:

• Процесс joiner / mover / leaver: формальный provisioning с manager approval, role-based access, периодический access review.
• SLA на deprovisioning: ≤24 ч. после уведомления (зрелый уровень) или ≤72 ч. (приемлемо).
• Privileged access management (PAM): elevated access через just-in-time механизм (CyberArk, BeyondTrust, Okta Privileged); запись сессий.
• Quarterly user-access review (UAR): manager подтверждает, что users + roles по-прежнему appropriate; задокументированные exceptions remediated.
• Segregation of Duties (SoD): conflict-of-interest matrix; тот же человек не provisions и approves; не codes и deploys.

Типичные deficiencies:

• Manual provisioning через email → audit trail неполный.
• SLA deprovisioning >7 дней → high-risk gap (бывшие сотрудники сохраняют доступ).
• UAR проведён, но нет задокументированного sign-off или remediation actions.
• Обход PAM — «break glass» accounts без post-use review.
• SoD-конфликты существуют, но не tracked и не mitigated.

Требования к evidence:

• Provisioning ticket, связанный с JML event.
• Quarterly UAR report с подписями manager + remediation log.
• PAM session logs (immutable, retention 7+ лет для SOX).
• SoD conflict matrix + exceptions register.

Применение в SwiftRide: доступ к Snowflake — сейчас manual provisioning. Цель remediation T+6M: Okta + SCIM auto-provisioning; deprovisioning <24 ч.; PAM через Okta Privileged для ролей SECURITYADMIN + ACCOUNTADMIN; quarterly UAR через Veza (или аналогичный IGA-инструмент); SoD-матрица data engineer ≠ analytics engineer ≠ analyst.

Домен 2 — Change Management

Типичные контроли:

• Change Advisory Board (CAB) или эквивалент gatekeeping для production changes.
• Сегрегация окружений dev / test / prod; одинаковые credentials никогда не переиспользуются между окружениями.
• Требования к code review / PR approval (≥1 reviewer для standard, ≥2 для critical paths).
• Automated testing gates: unit tests, integration tests, security scans.
• Авторизация deployment: отделение deployer от approver (SoD).
• Процедура emergency change: задокументированный exception process; post-implementation review (PIR).

Типичные deficiencies (top cause PCAOB 2024):

• PR одобрен тем же человеком, который писал код (нет SoD).
• Production deployment без ссылки на CAB ticket.
• Emergency changes не задокументированы ретроактивно.
• Деплои dbt models не подвержены formal change control.
• Schema changes деплоятся напрямую в prod через DBA console — обход контроля.

Требования к evidence:

• Запись GitHub PR с reviewer ≠ author.
• Change ticket (ServiceNow / Jira) со стадиями: requested → approved → deployed → verified.
• Evidence выполнения тестов (CI logs).
• Запись production deployment (CI/CD pipeline log).
• PIR для emergency change.

Применение в SwiftRide: деплои dbt — сейчас нет formal gate. Remediation T+6M: GitHub CODEOWNERS, требующий approval data-platform-lead для models/finance/**; CI tests (dbt build + tests pass); ServiceNow change ticket автоматически создаётся через GitHub webhook; deployment log связан обратно с change ticket; протокол emergency change задокументирован.

Домен 3 — Computer Operations

Типичные контроли:

• Job scheduling: monitored, alerting на failure / late execution.
• Backup / recovery: scheduled backups, периодические restore tests.
• Incident management: создание ticket, классификация severity, escalation, RCA.
• Monitoring: infrastructure monitoring, application monitoring, log aggregation.

Типичные deficiencies:

• Backup создаётся, но никогда не тестируется на восстановление.
• Job failures retried silently без создания ticket.
• Monitoring покрывает инфраструктуру, но не data quality.
• Записи об инциденте есть, но RCA не задокументирована.

Требования к evidence:

• Runbook docs.
• Backup logs + quarterly evidence restore-теста.
• Incident ticket trail с RCA + remediation actions.
• Скриншоты monitoring dashboard или log extracts.

Применение в SwiftRide: Snowflake — managed backups через Snowflake (Time Travel + Fail-safe); routine restore-теста — сейчас ad-hoc, remediation T+6M: quarterly automated restore test (например, восстановить вчерашние данные в staging, проверить row count + checksum). Confluent Cloud — managed service; обязательства по backup на стороне Confluent через SOC 2 report. Airflow — правило эскалации инцидентов: SLA miss > 30 мин → PagerDuty → ticket.

Домен 4 — System Development / SDLC

Типичные контроли:

• Requirements задокументированы (BRD / PRD).
• Design review с architecture board.
• Test plan + evidence выполнения (UAT sign-off).
• Контроли data conversion / migration (reconciliation).
• Go-live approval (Production Readiness Review — PRR).
• Post-implementation review (PIR).

Типичные deficiencies:

• Requirements не задокументированы для мелких фич.
• UAT проведён разработчиком, не business user.
• Data migration валидирована только по row count, не по содержимому.
• Нет PRR для «minor» releases.
• PIR не проведена; lessons не captured.

Требования к evidence:

• BRD / PRD с version control.
• Записи UAT sign-off.
• Отчёты reconciliation для data-migration.
• PRR checklist с sign-offs.
• PIR document для каждого material release.

Применение в SwiftRide: деплой новой ECL-модели SwiftCapital — SDLC controls критичны. Per AS 1305 — без надлежащего SDLC деплой новой модели создаёт control deficiency. Remediation T+12M: PRR checklist для деплоев ML-моделей (data lineage задокументирован, model validation report приложен, monitoring plan определён, rollback plan задокументирован).

Complement frameworks — COBIT 2019, ITIL 4, NIST SP 800-53

ITGC = SOX-driven категория. Complement frameworks дают структуру для построения контролей:

COBIT 2019

ISACA COBIT — релиз Nov 2018 (волна публикаций 2019). 40 governance / management objectives в 5 доменах:

• EDM (Evaluate, Direct, Monitor) — домен governance
• APO (Align, Plan, Organize) — стратегический менеджмент
• BAI (Build, Acquire, Implement) — change-related
• DSS (Deliver, Service, Support) — operations
• MEA (Monitor, Evaluate, Assess) — assurance

Маппинг ITGC: APO + BAI → Change management; DSS → Computer operations; DSS05 → Access management; BAI03 → SDLC.

ITIL 4

AXELOS / PeopleCert. Текущая редакция — Feb 2019. Service Value System (SVS) с 34 practices.

Маппинг ITGC: «Change Enablement» → Change management ITGC; «Information Security Management» + «Service Configuration Management» → Access management ITGC; «Deployment Management» → SDLC.

NIST SP 800-53 Rev 5.2.0

NIST CSRC. Initial Sep 2020; Update 1 Dec 2020; Rev. 5.2.0 released 27 Aug 2025 (administrative update). 20 семейств контролей:

• AC (Access Control) → Access management ITGC
• CM (Configuration Management) → Change management ITGC
• CP (Contingency Planning) → Computer operations (backup / DR)
• SA (System and Services Acquisition) → SDLC ITGC
• AU (Audit and Accountability) → Evidence + retention
• PM (Program Management) — новое в Rev 5
• PT (PII Processing and Transparency) — новое в Rev 5
• SR (Supply Chain Risk Management) — новое в Rev 5

NIST 800-53 — comprehensive baseline; ITGC = SOX-applicable subset. Federal contractors работают под full 800-53; commercial SOX = mapped subset.

SOC reports — какой нужен для SOX

AICPA Auditing Standards Board. SSAE 18 effective 1 May 2017; SSAE 21 (2020) реорганизован; поправки SSAE 22 / 23.

Правило решения:

• SOC 1 — системы, влияющие на финансовую отчётность клиента (например, ADP payroll service, custody system, fund administrator). Pre-IPO SwiftRide — получает SOC 1 от bank-partner (SwiftPay processing), от Stripe (если payments routed), от любого SaaS, обрабатывающего driver payouts.
• SOC 2 — security / operational assurance для SaaS / data systems. SwiftRide получает SOC 2 (Type 2) от Snowflake, Databricks, Confluent Cloud, AWS, Okta, dbt Cloud. Каждый — ежегодно.
• SOC 3 — general-use только маркетинг. Недостаточно для audit reliance, но полезно как vendor first-pass screening.

SwiftRide как service provider: после IPO, если SwiftRide хостит SaaS-компоненты, используемые enterprise-клиентами (B2B SwiftAds или fleet APIs), SwiftRide производит собственный SOC 2 (annual Type 2). До этого — N/A.

ITGC-матрица SwiftRide для топ-3 платформ

Это target state на T+12M. T0 baseline в каждой ячейке примерно 40–60% — заметные пробелы.

Anti-patterns в ITGC

1. «ITGC = security audit» — НЕТ. ITGC = entity-level enabler для FS-assertion reliance. Security audit может пересекаться, но имеет другой scope (CIA triad vs FS reliability).
2. «Мы можем полагаться на SOC 2 Snowflake» — да для контролей Snowflake-as-vendor, но не для контролей SwiftRide поверх Snowflake (provisioning, RBAC config, change management). User entity controls — обязательны, даже если vendor SOC 2 сильный.
3. «Сертификация COBIT = compliance ITGC» — не автоматически. COBIT — framework для построения; ITGC = список категорий. Нужен маппинг; сертификация не заменяет тестирование.
4. «Backup создан = control computer operations» — backup должен быть протестирован. Untested backup = significant deficiency.

Резюме

• 4 домена ITGC: Access (joiner-mover-leaver, UAR, PAM, SoD); Change (CAB, dev/test/prod, PR approval, emergency change); Operations (jobs, backup, incident, monitoring); SDLC (requirements, UAT, migration, PRR, PIR).
• PCAOB 2024 inspection — top cause: отказы logical access + change management. 39% aggregate Part I.A rate; Big Four 20%.
• Complement frameworks: COBIT 2019 (40 objectives, 5 доменов); ITIL 4 (SVS, 34 practices); NIST SP 800-53 Rev. 5.2.0 (20 семейств).
• SOC reports: SOC 1 — ICFR-relevant outsourced services; SOC 2 — security / availability и т.д. для cloud / SaaS; SOC 3 — public summary, только маркетинг.
• SwiftRide T0 → T+12M: remediation ITGC — pre-IPO приоритет №1. Каждая платформа (Snowflake, Databricks, Confluent Cloud) — определённая matrix по доменам.
• Per AS 2201 ¶.47: сильные ITGC сокращают scope тестирования application controls; слабые ITGC расширяют тестирование. Аргумент RoI для pre-IPO инвестиции.