Skip to content

SnowOps Compliance Engagement Guide

How to scope, sequence, and close a compliance certification engagement using SnowOps automation.

1. Which Framework Does the Client Need?

Start by understanding the driver, not the framework name. The framework usually falls out of the driver:

Driver Likely framework
Selling to US enterprises who ask "do you have a SOC 2 report?" SOC 2 Type II
Expanding into EU or enterprise deals requiring ISO certification ISO 27001
Handling ePHI for healthcare clients or covered entities HIPAA Security Rule
Azure-heavy security hardening with no formal audit yet CIS Azure Benchmark (no cert needed)
Client is a public company or preparing for an acquisition SOC 2 Type II + ISO 27001
Client needs GDPR alignment ISO 27001 + legal counsel for data processing agreements

Multiple frameworks: SOC 2 and ISO 27001 have ~70% control overlap. CIS Azure benchmark is a subset of both. If a client needs multiple frameworks, scope the engagement together — the evidence tools (Compliance Snapshot Collector (E0), Compliance Dashboard (S2), Automated Restore Drill (L4)) and access controls (H-series, Azure Resource PIM Module (B5)) all serve multiple frameworks simultaneously. See the Asset Glossary for what every asset code in this guide refers to.

2. The Engagement Flow

Step 0 — Free Discovery Audit (Discovery Audit Suite (G0–G7), ~30 min)

Run before any contract is signed. This is the SnowOps pre-sales wedge.

# Client runs this in their own Azure tenant (read-only)
node apps/discovery-auditor/dist/index.js \
  --subscription-id <their-sub-id> \
  --report-format markdown \
  --frameworks soc2,iso27001,cis_azure,hipaa \
  --out /tmp/discovery-report.md

Output: Scored posture report where every finding includes: - Severity (Critical / High / Medium / Low) - Which framework controls it maps to (soc2_cc, iso27001, cis_azure field tags) - remediation_asset_id — which SnowOps asset fixes it

This turns the discovery call into a specific, quantified conversation ("you have 12 Critical gaps for SOC 2; here's exactly what fixes them") rather than a generic pitch.

Step 1 — Gap Analysis (30 min, post-discovery)

Sort the Discovery Audit Suite (G0–G7) findings by target framework:

# Filter findings by framework
cat /tmp/discovery-report.md | grep -A3 "soc2_cc"

# Or use the S2 dashboard for a visual gap view
node apps/compliance-dashboard/dist/index.js \
  --snapshots-dir compliance/snapshots/ \
  --out /tmp/gap-dashboard/
open /tmp/gap-dashboard/index.html

Then cross-reference against the relevant control-mapping file: - SOC 2: SOC 2 Trust Services Criteria — Control Mapping - ISO 27001: ISO/IEC 27001:2022 — Control Mapping - HIPAA: HIPAA Security Rule — Control Mapping - CIS Azure: CIS Microsoft Azure Foundations Benchmark — Control Mapping

The result is a prioritized remediation backlog where each item has an asset ID, an estimated effort, and a framework-control reference.

Step 2 — Package Selection

Scenario Package Key differentiator
CIS Azure hardening only Baseline [B] No auditor required; self-service benchmark
SOC 2 Type II (first-time) Advanced [A] Adds E (full evidence), P (vendor risk), V (policies)
ISO 27001 Advanced [A] Adds V (policy mgmt), P (vendor risk), Q (HR controls)
HIPAA + SOC 2 together Advanced [A] Both served by the same control set
Already have infra; just need controls added Start with D+C quality gates on existing repos See Brownfield In-Place Strategy

Package definitions, pricing, and tiering live in Service Packages. Client-facing handover guides per package/milestone are in Client Guides.

Step 3 — Remediation Sequencing

Follow this order — each layer gates the next:

Week 1–2:   D-series + C-series quality gates (code hygiene, no cloud touches)
Week 2–4:   Identity + access foundation (F1, H1, H2, H3, H7, B5)
Week 4–6:   Logging + monitoring (J1, J2, J6, U1)
Week 6–8:   Network hardening (F2, N5, N6)
Week 8–10:  Encryption + key management (M1, M2, M3, F5)
Week 10–12: Evidence + drift + DR (E0, S1, S2, L1, L2, L4)
Week 12+:   Advanced: vendor risk (P), policies (V), HR controls (Q)

Why this order: Identity and logging must exist before everything else — you need to know who has access and what happened before you can claim controls are working. Encryption layered on top of access control; evidence and DR are the last layer that proves everything is working.

Step 4 — Evidence Wiring

Once controls are in place, wire the evidence pipeline:

# 1. E0 runs automatically after every C1 apply (or manually):
node apps/evidence-collector/dist/index.js \
  --subscription-id <sub-id> \
  --tenant-id <tenant-id> \
  --out-dir compliance/snapshots/

# 2. S2 dashboard aggregates all snapshots (run weekly or after each E0):
node apps/compliance-dashboard/dist/index.js \
  --snapshots-dir compliance/snapshots/ \
  --restore-drills-dir compliance/restore-drills/ \
  --out compliance/dashboard/

# 3. L4 restore drill (monthly cron, or trigger manually):
# Dry-run:
node apps/restore-drill/dist/index.js --dry-run --config .restore-drill.json
# Live (runs against sandbox, tags ephemeral=true):
node apps/restore-drill/dist/index.js --config .restore-drill.json

# 4. Vanta sync (E2 — if client uses Vanta):
# Vanta auto-pulls from Azure Policy + Defender for Cloud.
# Point Vanta at the subscription; it maps findings to SOC 2/ISO controls.

# 5. Evidence Sync (E5 — maps E0 snapshot + E4 resource-graph results to
#    EvidenceItem[] and pushes to Vanta/Drata via the E1 platform interface;
#    runs weekly via .github/workflows/evidence-sync.yml, or on demand):
node apps/evidence-collector/dist/sync.js --subscription-id <sub-id>

# 6. Quarterly access review (E6 — RBAC role-assignment review → CSV +
#    ticket; direct evidence for CC6.3/A.5.18/164.308(a)(4)):
node apps/access-review/dist/index.js \
  --subscription-id <sub-id> --out-dir compliance/access-reviews/ \
  --ticket-platform github

# 7. RTO/RPO objectives doc (L5 — merges L1 retention + L2 replication +
#    L4 drill evidence into one client-facing DR doc; regenerate whenever
#    L4 drill results change):
node apps/rto-rpo-doc-generator/dist/index.js \
  --drill-reports compliance/restore-drills --output compliance/dr/

# 8. Compliance scorecard (S4 — branded one-pager for client/sales reporting,
#    the non-technical counterpart to the S2 dashboard):
node apps/compliance-scorecard-generator/dist/index.js \
  --snapshot compliance/snapshots/<latest>.json \
  --client-name "<Client>" --output compliance/scorecard/ --pdf

Auto-Remediation Playbooks (S3) closes the loop Drift Detector (S1) opens: drift findings can now be remediated automatically via curated Logic App playbooks, with a structural dry-run/enforce split (modules/azure/auto-remediation-playbooks/). Enable per-playbook only after the client has reviewed and approved the remediation actions — this is an active-write capability, not passive evidence.

Step 5 — Auditor Readiness Checklist

Before engaging an auditor (CPA firm for SOC 2, CAB for ISO 27001):

  • All control-mapping items marked ✅ are live in the environment
  • All 📋 Manual items have written procedures — see the Policy Library Guide for what to draft and where (compliance/policies/)
  • At least 3 months of Compliance Snapshot Collector (E0) snapshots showing no regressions (Compliance Dashboard (S2) trend view)
  • At least 1 Automated Restore Drill (L4) run with PASS result in compliance/restore-drills/
  • Drift Detector (S1) running on a schedule with no open critical findings
  • Vanta (or equivalent) connected and green on in-scope controls
  • Policy Waiver Engine (D5) waivers reviewed — all exceptions have business justification and non-expired dates
  • HR/people controls: training records, background checks, onboarding/offboarding checklists
  • Vendor register complete with BAAs signed (HIPAA) or DPAs in place (GDPR/ISO)

3. Framework-Specific Notes

SOC 2

ISO 27001

HIPAA

CIS Azure

  • Not a certification. CIS Azure is a configuration benchmark — you achieve it, you don't get a certificate. Useful for baseline security or as evidence in a broader SOC 2 / ISO 27001 audit.
  • Assessment: Run Discovery Audit Suite (G0–G7) + Compliance Snapshot Collector (E0), then review the Compliance Dashboard (S2) against the CIS control mapping. Defender for Cloud's CIS Azure benchmark recommendation blade in the portal gives a current score.
  • Remediation: Almost all CIS Azure controls are addressed by SnowOps Baseline [B] package modules. The gaps (Entra portal settings, WAF) require manual portal configuration documented as procedures.
  • Target score: 100% of Level 1 controls (the mandatory subset) before an audit. Level 2 controls are advisory.

4. Common Questions

Q: How long does it take to get SOC 2 Type II? With a prepared environment (6 months of SnowOps controls in place) and an auditor engaged upfront: observation period is 6 months, fieldwork 4–6 weeks, report issued 2–4 weeks after fieldwork. Earliest realistic timeline: 9 months from engagement start.

Q: Can I get SOC 2 and ISO 27001 at the same time? Yes. The control overlap is ~70%. SnowOps serves both simultaneously. Engage a firm that does both (e.g., BSI for ISO + an affiliated CPA for SOC 2). Costs are lower doing them together.

Q: What does SnowOps cost for a compliance engagement? See Service Packages §3.8. Advanced [A] package is the relevant tier. Retainer maintains ongoing evidence collection and drift monitoring.

Q: My client has existing Terraform configs. Can SnowOps still help? Yes — see Brownfield In-Place Strategy for the in-place compliance strategy, and Brownfield Adoption for the client-facing handover.

Q: What if we have a policy exception (Policy Waiver Engine D5 waiver) for a finding? Document the business justification in waivers/exceptions.yaml with an expiry date. The waiver file is git-committed and reviewed at every PR via conftest. Auditors accept time-boxed waivers with documented rationale; they will ask about expired or undocumented exceptions.

Q: Where do I track gaps or staleness in these mappings? The Gap Register — e.g. G21/G22 record a recent pass that fixed stale asset-code references in these very mapping docs and queued a CI lint to catch the next round automatically.

  • Asset Glossary — what every asset code (E0, H1, L4, …) referenced throughout these mappings actually is
  • Service Packages — Baseline [B] / Advanced [A] tiering and pricing referenced in Step 2
  • Client Guides — per-package/milestone handover guides, each with its own compliance cross-reference
  • Incident Response Runbooks and Disaster Recovery Runbooks — the operational procedures behind the K1/K2 and L1/L2/L4/L5 evidence cited above
  • Gap Register and Project State — current build status of every ⏳ Roadmap (M4) item cited in the control mappings (cross-check before telling a client something is "coming soon")