Введение

PCAOB Spotlight on 2024 Inspection Activities (March 2025) — Big Four aggregate Part I.A deficiency rate 20% (с 26%). Самая частая ошибка: «deficiencies in firms’ testing of ITGCs over logical access and change management, resulting in insufficient testing of whether IT automated application controls and IT-dependent manual controls were effective». То есть: ITGC настолько фундаментальны, что когда они проваливаются, все automated controls сверху автоматически становятся непротестированными.

SwiftRide T+3M — оценка готовности Big 4 по data-периметру выдала 11 замечаний, 7 из которых — ITGC: 4 access management (privileged accounts на Snowflake без квартального review, Confluent service accounts shared, Aurora superuser passwords ротируются только по инциденту), 2 change management (schema migrations через ad-hoc PR без CI gating, emergency change без формального процесса), 1 SDLC (дата-пайплайн не проходит pre-prod review). Эта концентрация — типичный паттерн в data-организациях до формальной CDE-программы.

Этот урок развивает M5.1 в IT-направлении куба: что собой представляет каждый из 4 доменов ITGC применительно к data systems, какие audit-tested вопросы нужно уметь ответить, и какие реализации специфичны для SwiftRide.

Домен 1 — Access management

Цель: обеспечить, чтобы только authorised индивиды и сервисы имели доступ к data systems, на необходимом уровне privilege, на необходимое время.

Provisioning / deprovisioning

PCAOB-tested вопросы:

• Как создаётся новый аккаунт на Snowflake / Databricks / Confluent / Aurora? Кто approve? Задокументированный workflow?
• Когда сотрудник увольняется — в какие сроки account disabled? Evidence?
• Service accounts — кто owns? Кто approves новый service account?

Реализация SwiftRide:

• Okta — primary IdP; SSO к Snowflake, Databricks, Confluent Cloud, AWS, Looker.
• Workato — автоматический provisioning от HR-системы (BambooHR) при hire/termination.
• Termination workflow: HR triggers Workato → Okta disable → каскад к Snowflake / Databricks / Confluent / GitHub.
• Service accounts — Terraform-managed; владельцы в service-accounts.yaml репозитории; квартальный review.

Типичный gap: service accounts создаются ad-hoc через UI, не через Terraform → нет owner record → orphan accounts. Замечание Big 4 в SwiftRide T+3M: 47 orphan service accounts в Confluent Cloud, owner определялся через git-blame по usage.

Privileged access management (PAM)

PCAOB-tested вопросы:

• Кто имеет admin-level доступ? Обосновано job function?
• Privileged sessions мониторятся? Логируются?
• Just-in-time access (JIT) для elevation, не standing privilege?

Реализация SwiftRide:

• Snowflake ACCOUNTADMIN — 3 named accounts (CISO, Snowflake admin, break-glass). Стандартная privilege-роль DATA_ENGINEER — без DDL на production schemas.
• Aurora superuser — Sealed Secret в HashiCorp Vault; доступ через ServiceNow-тикет; auto-rotation 90 дней.
• Confluent Cloud Cluster Admin — Okta group kafka-admins (5 named accounts).
• JIT — Saviynt PIM 7.x для временной elevation; max session 4h; auto-revoke.

Периодические user-access reviews (UAR)

PCAOB-tested:

• Частота — минимум квартально для material-систем.
• Reviewer — accountable manager (не auditee).
• Evidence — signed UAR report + тикеты ремедиации.
• Sample testing — аудитор выбирает 25-50 аккаунтов, прослеживает обратно к UAR-документации.

Реализация SwiftRide: Saviynt scheduled campaigns квартально per system; manager attestation через Saviynt UI; signed entries + Jira-тикеты для exceptions; архив 7 лет.

PCAOB 2024 Spotlight ITGC logical access — недостаточное тестирование UAR это default-замечание.

Segregation of Duties (SoD)

SoD — пересечение access management и application logic. Подробно покрыт в M5.7. С точки зрения ITGC: обеспечить, чтобы комбинации access не позволяли одному актору end-to-end критический процесс (initiate + execute + approve + monitor).

Домен 2 — Change management

Цель: обеспечить, чтобы изменения в production data systems были авторизованы, протестированы, задокументированы и обратимы.

Change request / approval flow

PCAOB-tested:

• Каждое prod-изменение имеет задокументированный запрос?
• Approval по типу: low-impact / standard / high-impact?
• Emergency changes — отдельный flow с retrospective approval?

Реализация SwiftRide:

• GitHub PR + ServiceNow Change Request для material CDE pipelines.
• CODEOWNERS gating: dbt models на fct_driver_earnings требуют Finance Lead approval.
• Шаблон ServiceNow CR для production deploys: бизнес-обоснование, rollback plan, test evidence, security review.
• Emergency CR — окно retro-approval 24h; CSO signature.

Сегрегация dev / test / prod

PCAOB-tested:

• Код и данные текут только в одном направлении (prod → test для refresh OK; test → prod НЕТ)?
• Promotion gates — automated tests pass + manual approval?

Реализация SwiftRide:

• Snowflake databases: swiftride_dev, swiftride_stg, swiftride_prod — отдельные роли.
• dbt — отдельные профили; деплой через GitHub Actions; merge to main → stg run → manual approval → prod run.
• Production refresh данных тестового окружения через masked clone (PII токенизированы).

Schema migrations (специфика данных)

Schema migrations — особый случай change management. Data systems имеют уникальный риск: schema change downstream может молча сломать десятки consumers.

PCAOB-tested:

• Schema changes на material CDE — отдельный gating?
• Impact analysis (lineage) до merge?
• Backward compatibility поддерживается по контракту?

Реализация SwiftRide:

Emergency change

Реальный мир: production-инцидент в 2 AM, нужен hot-fix. Процесс должен это accommodate без ломания ITGC framework.

Flow SwiftRide:

• On-call инженер применяет hot-fix branch напрямую к prod (bypass CI).
• В течение 24h: retro PR с полным review + retro ServiceNow CR + post-mortem.
• CSO sign-off на еженедельном дайджесте emergency changes.

Типичное замечание Big 4: emergency changes накапливаются без retro-PR; «временное» становится permanent; control gap.

Домен 3 — Computer operations

Цель: обеспечить надёжное функционирование data systems на 24/7 basis с recovery capability.

Backup и recovery

PCAOB-tested:

• Частота backup per system задокументирована? RPO/RTO определены?

• Recovery procedures протестированы периодически?

• Backup retention соответствует regulatory requirements (SOX 7y)?

Реализация SwiftRide:

• Snowflake — Time Travel 90 дней + Fail-safe 7 дней (встроено); cross-region replication для DR (3 региона).
• Aurora — automated backups + PITR; cross-region replica.
• S3 (data lake) — versioning + object lock для CDE; replication во вторичный регион.
• Backup recovery test — квартальный drill per critical system; результаты в квартальном DR report.

Monitoring / alerting

PCAOB-tested:

• Critical jobs / пайплайны мониторятся? SLA определён?
• Алерты идут к accountable команде (не на generic distribution list)?
• Alert response time отслеживается?

Реализация SwiftRide:

• Datadog для инфры; Airflow native monitoring для пайплайнов.
• PagerDuty rotation per service.
• Критические CDE-пайплайны (fct_driver_earnings, fct_revenue_daily) — отдельная alert policy; Sev-1 при SLA breach больше 2h.

Job scheduling

PCAOB-tested:

• Production-джобы запускаются по расписанию? Failures captured + escalated?
• Запуски джоб вручную задокументированы?

Реализация SwiftRide:

• Airflow на Kubernetes — DAG-as-code, version-controlled.
• Failures → PagerDuty + Datadog incident.
• Manual job triggers логируются + подписываются триггерящим инженером.

Управление инцидентами

PCAOB-tested:

• Процесс реагирования на инциденты задокументирован? Severity tiers определены?
• Post-mortem обязателен для Sev-1/Sev-2?
• Trending incidents reviewed?

Реализация SwiftRide:

• PagerDuty + ServiceNow IRM.
• Sev-1/Sev-2 — post-mortem в течение 5 рабочих дней.
• Ежемесячный incident review — Data Platform Lead + CDO Office.

Домен 4 — System development / SDLC

Цель: обеспечить, чтобы новые дата-пайплайны, ETL-процессы и data products проходили правильный development lifecycle с testing + sign-off.

Requirements / design

PCAOB-tested:

• Новый пайплайн инициирован с бизнес-обоснованием?
• Data Owner вовлечён при design?
• Privacy / security review при design (DPIA если PII)?

Реализация SwiftRide:

• RFC template в Confluence; требуется для новых CDE-пайплайнов.
• Data Owner + Steward sign-off на business definition (M4.5 registry entry).
• DPIA через OneTrust для данных в periметре GDPR.

Testing

PCAOB-tested:

• Unit tests? Integration tests? Data quality tests?
• Test evidence сохраняется?

Реализация SwiftRide:

• dbt tests (цель 90% покрытия на CDE-моделях).
• GE Core 1.17.1 expectation suites на CDE outputs.
• Pull request CI artifacts сохраняются 30 дней в GitHub + key runs в S3 audit bucket 7y.

Data conversion (migration testing)

При re-platforming / смене источника — data conversion testing критично для сохранения CDE integrity.

PCAOB-tested:

• Сравнение pre/post задокументировано? Reconciliation evidence?
• Стратегия sample-based против full reconciliation обоснована?

Реализация SwiftRide:

• Aurora → Snowflake initial load: полная reconciliation на CDE tables; sample-based на non-CDE.
• Migration runbook в Confluence; результаты в Big 4 evidence binder.

Go-live approval

PCAOB-tested:

• Формальный go-live gate? Approvers per role?
• Production readiness checklist (мониторинг, alerts, runbook, backups)?

Реализация SwiftRide:

• Production Readiness Review (PRR) checklist в Confluence.
• Требуются 4 approvers: Data Platform Lead, Security Lead, Data Owner, Steward.
• Sign-off в Jira PRR ticket; архив 7y.

Матрица ITGC × платформа SwiftRide

Жёлтые ячейки — gaps T+3M; цель — все зелёные к T+9M (M7 evidence gate).

PCAOB 2024 inspection — top deficiency

PCAOB Spotlight 2024 Inspections — top finding 2024: «deficiencies in firms’ testing of ITGCs over logical access and change management».

Причинно-следственная цепочка:

1. Audit firm тестирует ITGC over Snowflake logical access.
2. Находит: privileged access reviews не квартально, как задокументировано; 6 аккаунтов elevated больше 12 месяцев без review.
3. ITGC over access признан не operating effectively.
4. Каскад: automated application controls, опирающиеся на Snowflake (например, GE expectation suites на CDE tables, dbt contracts) — аудитор не может полагаться как на «lower risk» под AS 2201 ¶.47.
5. Размеры выборок увеличиваются материально (с sample-based к extended testing).
6. Audit cost +30-50%; возможное material weakness disclosure если аудитор приходит к заключению о severe deficiency.

Практическое следствие: инвестиции в ITGC дают накопительный эффект. Сильный ITGC снижает audit scope для application controls. Слабый ITGC раздувает периметр даже для well-designed application controls.

Anti-patterns

«У нас есть Okta — доступом управляем»

Паттерн: команда показывает Okta deployment как proof of access management ITGC.

Почему плохо: Okta — это инструмент; control = процесс вокруг инструмента. PCAOB-tested вопросы — provisioning workflow задокументирован, deprovisioning timeframe определён, UAR квартально выполнен, evidence сохранены. Инструмент без процесса — не control.

Fix: задокументированные PCAOB-grade workflows: «provisioning через Workato auto-trigger от BambooHR; deprovisioning в течение 24h после termination, evidence в Okta audit log сохраняется 7y; квартальный UAR через Saviynt с manager attestation, exceptions ticketed».

Change management только на код, не на schemas/configs

Паттерн: code changes идут через GitHub PR + CI; но Snowflake task creation / Kafka topic creation / Airflow connection setup — через UI ad-hoc.

Почему плохо: data systems имеют широкий surface area; schema changes / config changes напрямую влияют на CDE без code-level review.

Fix: terraform-managed configs (database objects, Kafka topics, Airflow connections); UI-доступ read-only; emergency UI changes — отдельный flow с retro Terraform import.

SDLC только для production-кода, не для analytics/dbt

Паттерн: software engineering team имеет PRR; data team — нет. Dbt model запускается без review.

Почему плохо: dbt models создают CDE tables; материальный финансовый impact. SDLC должен покрывать все CDE-producing пайплайны.

Fix: PRR адаптирован для analytics — Data Owner + Steward + Platform Lead approval перед production deploy material CDE model.

Резюме

• 4 ITGC-домена: access management (provisioning, PAM, UAR, SoD), change management (request flow, dev/test/prod, schema migrations, emergency), computer operations (backup, monitoring, scheduling, incidents), system development (requirements, testing, conversion, go-live).
• PCAOB 2024 inspection top deficiency — ITGC over logical access + change management. Big Four 20% deficiency rate в значительной мере driven этими доменами.
• Сильный ITGC даёт PCAOB AS 2201 ¶.47 «lower risk» классификацию для automated application controls. Слабый ITGC раздувает audit scope даже для well-designed application controls.
• Замечания Big 4 для SwiftRide T+3M — 7 из 11 ITGC. Дорожная карта ремедиации T+6M к T+9M через access tightening (Okta + Saviynt PIM), change gating (dbt CI + CODEOWNERS + ServiceNow CR), schema migrations (data contracts + Schema Registry compatibility check), формализацию SDLC (PRR checklist + 4 approvers).
• ITGC — базовая линия. Application controls (M5.3) — наслаиваются сверху per material CDE.

В M5.3 разберём application controls — input / processing / output — и их компромиссы относительно ITGC.