Compliance Frameworks

Я регулярно вижу две крайности в отношении compliance. Первая — «compliance это бумажки для аудита, нам как инженерам это не нужно»: команда узнаёт о SOC 2 за две недели до аудита, в панике собирает evidence руками, проходит audit, забывает до следующего года. Вторая — «у нас SOC 2 Type II, значит мы secure»: чек прошёл, контролы зелёные, в это же время Capital One теряет 100 миллионов записей через misconfigured WAF, имея SOC 2 в порядке. Compliance — это доказательство соответствия externally-defined requirements, а не security. Грамотный SRE использует compliance как драйвер для требований, которые всё равно нужно делать (Access Control & IAM, Vulnerability Management, Backup & Restore, audit trail во всех системах), и автоматизирует evidence collection до уровня «непрерывно», а не «раз в год вручную».

Что должен уметь

Главный навык на уровне L5 — mapping контролов на технические практики. SOC 2 CC6.1 («logical access controls») — это не «напишем policy документ», это IAM модель + принцип наименьших привилегий + audit log + access review cadence. PCI-DSS Requirement 8 — это MFA + password policy + session management. Когда compliance трактуется как «техническая работа, которую всё равно нужно делать», audits проходят без героизма. Когда compliance трактуется как «отдельная работа поверх инженерии» — рождается compliance theater.

Знает, какие compliance-фреймворки применяются к продукту команды (SOC 2 / PCI-DSS / HIPAA / FedRAMP / GDPR), и понимает, какие части кода/инфраструктуры в scope.
Понимает разницу regulation (закон, GDPR / HIPAA — обязательны при условии applicable) vs framework (стандарт сертификации, SOC 2 / ISO 27001 / PCI-DSS — добровольны, но требуются клиентами).

Mapping компонентов системы на конкретные контролы; знает, какой control покрывается каким техническим артефактом (IaC модулем, IAM policy, runbook’ом, дашбордом).
Автоматизирует evidence collection — снимок IAM state, screenshot patch SLA дашборда, IaC diff history, audit log export — через cron / event-driven hooks в GRC platform, а не вручную перед аудитом.
Различает SOC 2 Type I (control design в момент аудита) и Type II (operational effectiveness за период 3–12 месяцев); Type II требует доказательств за весь период, что меняет всё в evidence collection.

Проектирует control framework команды/org — выбор фреймворков по клиентскому спросу, scope definition, control catalogue, ownership matrix (кто ответствен за каждый control), audit cadence.
Внедряет compliance-as-code — policy через OPA / Sentinel / Cloud Custodian, automated drift detection, continuous control testing. «Контроль зелёный» = «automated check прошёл в последние 24 часа», не «policy документ написан год назад».
Координирует с external auditors — scoping, evidence requests, walkthroughs, finding remediation. Понимает, что auditor может принять compensating control (альтернативу) — это переговоры, не команда сверху.

L6+

Дизайнит strategy на уровне org: какие certifications нужны (SOC 2 Type II baseline + ISO 27001 если EU enterprise + HITRUST если healthcare), inheritance модель (parent org аудит покрывает subsidiary), budget audit вендоров vs внутреннее content, board reporting.
Использует compliance как leverage для приоритизации security investment, который без external pressure не получает support — «PCI-DSS требует, иначе теряем merchant agreement» работает лучше, чем «это правильная security practice».

Материалы

Книги

Eric Schlesinger, Sloane Cohen — The SOC 2 Compliance Handbook (Self-published, 2023). Прикладная книга про SOC 2: scoping, evidence, common gotchas. Не academic, читается за выходные.
Alan Calder — Nine Steps to Success: An ISO 27001:2022 Implementation Overview (ITGP, 4th ed., 2023). Канонический guide по ISO 27001 implementation; сжато, без воды.

Стандарты и регуляции

AICPA Trust Services Criteria (AICPA). Источник истины для SOC 2 — Security, Availability, Processing Integrity, Confidentiality, Privacy. Главный документ для compliance team; для инженеров полезен Security section.
ISO/IEC 27001:2022 (ISO, 2022). Платный стандарт, но контролы (Annex A, 93 controls) — публично доступны и используются как чеклист.
PCI DSS v4.0 (PCI SSC, 2022). Если работаете с card data — обязательно. Стандарт жёстче и конкретнее, чем SOC 2: явные требования, не «design appropriate controls».
NIST Cybersecurity Framework 2.0 (NIST, 2024). Не сертификация, а meta-framework — Identify / Protect / Detect / Respond / Recover. Полезен для structuring подхода даже если не нужен formal cert.
FedRAMP Authorization (GSA). Для SaaS, продающего в US федеральные agencies. Высокий barrier (Low / Moderate / High baselines на базе NIST SP 800-53). Если не продаёте в US gov — не нужно.
GDPR + California CCPA/CPRA. Privacy regulations, не security frameworks; но GDPR требует security controls (Art. 32) — пересекается с SOC 2/ISO 27001.

Статьи и доклады

Krebs on Security — Capital One 2019 breach. Главный кейс про «SOC 2 compliant + breached». Полезно как иллюстрация для команды, которая считает, что прохождение аудита = безопасность.
OneTrust DataGuidance Comparison Tool. Удобный matrix для сравнения privacy regulations по jurisdictions.
Cloud Security Alliance — Cloud Controls Matrix (CCM). Mapping между cloud security controls и ~20 фреймворками (SOC 2, ISO 27001, PCI-DSS, HIPAA, NIST 800-53 и др.). Сильно сокращает effort при multi-framework compliance.

Инструменты

GRC platforms (automated compliance): Vanta, Drata, Secureframe, Hyperproof, Sprinto, OneTrust (enterprise). По моим наблюдениям, Vanta и Drata доминируют в startup-сегменте для первого SOC 2; OneTrust чаще выбирают крупные orgs со сложным privacy scope.
Cloud-native compliance: AWS Audit Manager, AWS Security Hub, GCP Compliance Reports Manager, Azure Compliance Manager. Полезны если 90% инфраструктуры в одном cloud; для multi-cloud — недостаточно.
Policy as code: Open Policy Agent (OPA) + Conftest, HashiCorp Sentinel, Cloud Custodian, Checkov, Kyverno. Continuous compliance test на каждый IaC PR; Checkov часто берут на старт за низкий barrier.
Evidence collection automation: Vanta/Drata integrations + custom скрипты (boto3 / gcloud / kubectl → JSON snapshots в S3 bucket с retention). По моим наблюдениям, разница между «compliance каторгой» и «compliance в фоне» — именно в этом слое.
Vendor risk management: Whistic, SecurityScorecard, BitSight. Для управления third-party риском (PCI-DSS req 12.8, SOC 2 CC9.2).

Best practices

Главный публичный кейс — Capital One 2019 breach (CVE никогда не было; misconfigured WAF). 100+ миллионов записей утекли через SSRF на AWS metadata endpoint. У Capital One был активный SOC 2, активные internal security audits, активный vulnerability management. Что не сработало — control над configuration drift в WAF rules: одна misconfiguration на одном WAF не была отловлена ни одним audit-control, потому что аудит проверял «WAF существует и настроен» в момент времени, не «WAF configuration соответствует policy непрерывно». Урок для меня: compliant ≠ secure; audit моментом времени ≠ continuous compliance. Это второй по силе аргумент в пользу compliance-as-code (первый — снижение audit pain).

Короткие правила:

Compliance — driver требований, не самостоятельная цель. Каждый control mapped на техническую практику, которую всё равно нужно делать. Если control порождает работу только ради аудита и нигде больше не используется — это compliance theater; либо driver слабый, либо технический эквивалент уже есть и control дублирует. Перепроверять scoping раз в год.
Automate evidence collection с первого дня сертификации. Manual evidence collection накануне аудита — самая трудозатратная и самая хрупкая часть compliance. По моим наблюдениям, команды, которые автоматизировали evidence на старте, тратят на следующий аудит ≤ 20% времени относительно первого. Команды, которые «соберём руками, потом подумаем», застревают в этом режиме на годы.
SOC 2 Type II — это период, не момент. Контролы должны работать весь observation period (обычно 6–12 месяцев). Если IAM access review был проведён один раз перед аудитом, но не каждый квартал по policy — это finding. Cadence policy = cadence реальной практики, иначе recipe для qualified opinion от auditor.

Подробнее:

Choose your frameworks по клиентскому спросу, не по «полнее — лучше». Я регулярно вижу startup’ы, которые в первый год хотят SOC 2 Type II + ISO 27001 + HIPAA + PCI-DSS «на будущее». Стоимость — половина security headcount на год, ROI — минимальный, потому что клиенты не просят. Сначала клиентский спрос (sales pipeline застревает на «у вас SOC 2?»), потом сертификация. Исключения — regulated industries (healthcare → HIPAA сразу, payments → PCI-DSS сразу).

Inheritance model — серьёзная экономия в multi-product / multi-subsidiary orgs. Если parent org сертифицирован по SOC 2, subsidiary могут inherit infrastructure controls (data center physical security, network segmentation), и аудит subsidiary становится дешевле и быстрее. Cloud providers (AWS, GCP, Azure) публикуют SOC reports — их inheritance покрывает часть infra-control’ов для всех клиентов. Это надо явно использовать в scoping; auditor сам не предложит.

Continuous control testing > point-in-time evidence. OPA/Sentinel policy в pipeline → каждый PR с IaC проверяется против compliance rules → continuous evidence «control действует на дату X-Y-Z». Это не только дешевле, чем manual evidence, это обнаруживает drift на следующий PR, а не через год. Тот же principle что в GitOps drift detection, только применённый к security/compliance policy.

Read auditor’s findings carefully — они полезны независимо от рейтинга. Qualified opinion (есть findings) не катастрофа: auditor подсветил реальную проблему, которая может вырасти в incident. Unqualified opinion с zero findings часто означает, что либо аудит был поверхностный, либо вы переплатили за compliance theater. Я читаю findings не как «что закрыть до next audit», а как «где security gap, который мы пропустили».

Связанные листья

Vulnerability Management — patch SLA per severity напрямую следует из SOC 2 CC7.1 / PCI-DSS Req 6 / ISO 27001 A.8.8. Compliance даёт numerical baseline; VM реализует.
Secrets Management — encryption at rest / in transit, key management, access controls — pervasive требования во всех frameworks.
Threat Modeling — SOC 2 CC3.x / ISO 27001 A.5.7 требуют risk assessment; threat model — наиболее операциональная форма.
Access Control & IAM — SOC 2 CC6.x — большой блок про logical access; IAM лист даёт техническую реализацию.
Supply Chain Security — vendor risk management (SOC 2 CC9.2), third-party assessments, SBOM как evidence.
Backup & Restore — SOC 2 Availability category + ISO 27001 A.8.13 требуют tested backups; RPO/RTO — фиксированная часть evidence.
Incident Response — SOC 2 CC7.3 / GDPR Art. 33 (72-hour notification) / HIPAA Breach Notification — incident process с timelines требуется явно.
Change Governance — SOC 2 CC8.1 / ISO 27001 A.8.32 — change management process с approvals, testing, rollback.
GitOps — git history как audit trail; continuous reconciliation как evidence для CC6 (access) и CC8 (change).
Service Ownership — control ownership matrix маппится на service ownership; без явных owners большая часть controls — orphan.
DR Policy & Stakeholders — SOC 2 Availability / PCI-DSS Req 12.10 / ISO 22301 требуют документированную DR / BCP с evidence of testing. DR Policy — mandatory audit artifact в regulated industries.

Открытые вопросы

HITRUST CSF — стоит ли отдельный лист для healthcare-специфики или это под-секция Compliance Frameworks? Мне кажется, под-секция, но не уверен.
Continuous Controls Monitoring (CCM) как отдельная практика — рынок tooling (Drata Trust Center, Vanta Vendor Risk) растёт быстро; возможно, через 1–2 года это будет отдельный лист.
Compliance-Driven Change Management (TBD) — отдельный лист про change governance в SOX/PCI scope, где каждое change требует formal approval + evidence. Сейчас в L1 Change Management, потенциально пересекается.
Я не разбирался глубоко с SOC 1 (financial reporting controls) — это другой класс аудита, и в SRE-командах он редкий. Если в вашей команде SOC 1 в scope — расскажите PR’ом, как живёте.
GRC platform selection — нет публичной модели сравнения Vanta vs Drata vs Secureframe для конкретного use case. Вендорские demo дают одностороннюю картину. Если у вас была migration между ними — был бы интересен опыт.