SOC 2 Trust Services Criteria — SnowOps Control Mapping¶

Framework: AICPA Trust Services Criteria (2017, updated 2022) Target report: SOC 2 Type II (12-month observation period) SnowOps package: Advanced "Certification-Ready" [A] (Baseline [B] covers CC5–CC8 + CC6 foundation)

Coverage Legend¶

Symbol	Meaning
✅	Automated — SnowOps asset provides automated controls + machine-generated evidence
🔧	Partial — Asset exists; manual configuration or supplemental steps required
📋	Manual — Procedural or document-only; no SnowOps automation
⏳	Roadmap — Planned in M4 (Advanced package); not yet built
❌	Out of scope — Azure platform responsibility or external to SnowOps

Common Criteria (CC)¶

CC1 — Control Environment¶

Criteria	Description	Coverage	Asset	Evidence Source
CC1.1	Organization demonstrates commitment to integrity and ethics	📋 Manual	—	Infosec policy, code of conduct
CC1.2	Board oversight of internal controls	📋 Manual	—	Management review meeting minutes
CC1.3	Management establishes structure, authority, accountability	📋 Manual	—	Org chart, RACI
CC1.4	Commitment to competent employees	📋 Manual	—	Job descriptions, training records
CC1.5	Accountability for internal control responsibilities	🔧 Partial	Entra ID Baseline Module (`H1`)/Conditional Access Module (`H2`)	RBAC assignments from H1/H2 Terratest output

CC2 — Communication and Information¶

Criteria	Description	Coverage	Asset	Evidence Source
CC2.1	Relevant quality information obtained and used	✅	Compliance Snapshot Collector (`E0`), Drift Detector (`S1`), Compliance Dashboard (`S2`)	Compliance snapshots, drift reports in `compliance/snapshots/`
CC2.2	Internal communication of control responsibilities	📋 Manual	—	Policy acknowledgments (V-series, M4)
CC2.3	External communication of commitments	⏳ Roadmap	T-series (M4)	Trust center page

CC3 — Risk Assessment¶

Criteria	Description	Coverage	Asset	Evidence Source
CC3.1	Specifies suitable risk assessment objectives	✅	Discovery Audit Suite (`G0`–`G7`)	Discovery audit report (risk-categorized findings)
CC3.2	Identifies and analyzes risk	✅	Discovery Audit Suite (`G0`–`G7`), Compliance Dashboard (`S2`)	G2 rule-pack findings with severity + framework tags
CC3.3	Assesses fraud risk	🔧 Partial	PR Quality-Gate Workflow (`D2`), gitleaks	Gitleaks scan; financial fraud controls are manual
CC3.4	Identifies and assesses changes that could impact controls	✅	Drift Detector (`S1`)	Drift reports (schema v1.0 `DriftReport`)

CC4 — Monitoring Activities¶

Criteria	Description	Coverage	Asset	Evidence Source
CC4.1	Ongoing and separate evaluations of controls	✅	Drift Detector (`S1`), Compliance Dashboard (`S2`), Compliance Snapshot Collector (`E0`)	Scheduled drift detection + compliance dashboard
CC4.2	Evaluation and communication of deficiencies	✅	Drift Detector (`S1`), Incident Response Runbooks (`K1`)/On-Call Integration Module (`K2`)	GitHub Issues from S1 TicketPlatform; IR runbooks (K1)

CC5 — Control Activities¶

Criteria	Description	Coverage	Asset	Evidence Source
CC5.1	Selects and develops control activities over technology	✅	Terraform OPA Policy Bundle (`D3`)/Conftest Test Suite (`X3`), Kyverno AKS Policy Bundle (`D4`)/Kyverno Test Framework (`X4`)	Conftest OPA bundle; Kyverno policy tests
CC5.2	Deploys control activities through policies and procedures	✅	Pre-Commit Quality Hooks (`D1`), PR Quality-Gate Workflow (`D2`), Terraform Plan/Apply Pipeline (`C1`)–AKS Deploy Pipeline (`C3`)	Branch protection policy; CI pipeline run logs
CC5.3	Deploys controls over relevant technology	✅	Subscription Baseline Module (`B3`), Encryption Policy Module (`M1`)/TLS Policy Module (`M3`), Private Endpoint Policy Module (`N5`)/NSG Baseline Module (`N6`)	MCSB assignment; Policy deny initiative output

CC6 — Logical and Physical Access Controls¶

Criteria	Description	Coverage	Asset	Evidence Source
CC6.1	Logical access security (identity + credential)	✅	Azure Baseline Module (`F1`), Entra ID Baseline Module (`H1`), Break-Glass Account Module (`H7`)	Entra group + RBAC module outputs; break-glass module
CC6.2	Prior to issuing system credentials, users registered	✅	Entra ID Baseline Module (`H1`) (user lifecycle)	Entra group membership; module plan output
CC6.3	Role-based access with least privilege	✅	Conditional Access Module (`H2`), Azure Resource PIM Module (`B5`)	Custom role assignments; PIM eligible assignments
CC6.4	Access restricted to authorized individuals	✅	Conditional Access Module (`H2`), Entra PIM Templates Module (`H3`), Azure Resource PIM Module (`B5`)	RBAC + PIM eligible role + PIM activation policy
CC6.5	Logical access credentials removed or modified upon change	✅	Entra ID Baseline Module (`H1`) (lifecycle)	Group membership changes logged in Entra audit log
CC6.6	Physical and logical access from outside entity boundary	🔧 Partial	Network Hub Module (`F2`), Private Endpoint Policy Module (`N5`)/NSG Baseline Module (`N6`)	NSG + public-access deny; VPN is client-managed
CC6.7	Authorized users transmit/receive data securely	✅	TLS Policy Module (`M3`), Private Endpoint Policy Module (`N5`)	TLS deny policy; public-network-access deny
CC6.8	Unauthorized or malicious software prevented	✅	PR Quality-Gate Workflow (`D2`) (trivy), Kyverno AKS Policy Bundle (`D4`) (Kyverno), Container Build & Sign Pipeline (`C2`) (Grype)	Grype + Trivy scan artifacts; signed-image admission

CC7 — System Operations¶

Criteria	Description	Coverage	Asset	Evidence Source
CC7.1	Infrastructure/software detection and prevention controls	✅	Subscription Baseline Module (`B3`) (Defender), Drift Detector (`S1`)	Defender for Cloud recommendations; drift reports
CC7.2	Monitor system components for anomalies	✅	Log Analytics Module (`J1`), Budget Alert Module (`U1`)	Log Analytics workspace; budget/metric alerts
CC7.3	Evaluate security events	✅	Incident Response Runbooks (`K1`), On-Call Integration Module (`K2`), Policy Diagnostics Module (`J2`)	IR runbook library; on-call integration; diagnostic settings
CC7.4	Respond to identified security incidents	✅	Incident Response Runbooks (`K1`), On-Call Integration Module (`K2`)	Incident response runbooks; PagerDuty/Opsgenie integration
CC7.5	Identified breaches disclosed in accordance with commitments	📋 Manual	—	Customer notification procedure; legal counsel

CC8 — Change Management¶

Criteria	Description	Coverage	Asset	Evidence Source
CC8.1	Authorizes, designs, develops, configures, tests changes	✅	Pre-Commit Quality Hooks (`D1`), GitOps Branching Standard (`C4`), Terraform Plan/Apply Pipeline (`C1`)–AKS Deploy Pipeline (`C3`)	Branch protection; PR audit log; CI pipeline run history
CC8.1 (scanning)	Changes scanned for vulnerabilities before deployment	✅	PR Quality-Gate Workflow (`D2`), Container Build & Sign Pipeline (`C2`)	Checkov/tfsec/Grype CI artifacts
CC8.1 (policy gate)	Changes gated by policy before apply	✅	Terraform OPA Policy Bundle (`D3`)/Conftest Test Suite (`X3`), Policy Waiver Engine (`D5`)	Conftest OPA gate in C1; waiver audit trail

CC9 — Risk Mitigation¶

Criteria	Description	Coverage	Asset	Evidence Source
CC9.1	Identifies and selects risk mitigation strategies	✅	Discovery Audit Suite (`G0`–`G7`)	Discovery audit with `remediation_asset_id` per finding
CC9.2	Assesses and manages risks from vendors	⏳ Roadmap	P-series (M4)	Vendor risk register; questionnaire tracking

Additional Categories¶

A1 — Availability¶

Criteria	Description	Coverage	Asset	Evidence Source
A1.1	Current processing capacity and performance requirements	✅	Budget Alert Module (`U1`), Log Analytics Module (`J1`)	Budget alerts; Log Analytics metrics
A1.2	Environmental and technology changes monitored	✅	Drift Detector (`S1`), Compliance Snapshot Collector (`E0`)	Drift reports; compliance snapshot regression delta
A1.3	Recovery plan + recovery testing	✅	Azure Backup Policy Module (`L1`), Cross-Region Replication Module (`L2`), Automated Restore Drill (`L4`)	Backup policies; replication config; `RestoreDrillReport` in `compliance/restore-drills/`

C1 — Confidentiality¶

Criteria	Description	Coverage	Asset	Evidence Source
C1.1	Confidential information identified and maintained	✅	Encryption Policy Module (`M1`)/Customer-Managed Key Module (`M2`), Key Vault Module (`F5`)	Encryption deny policy; CMK key; Key Vault config
C1.2	Confidential information disposed of when no longer needed	🔧 Partial	Azure Backup Policy Module (`L1`) (retention), Audit Log Archive Module (`J6`) (WORM)	Retention policy config; WORM immutability config

PI1 — Processing Integrity¶

Criteria	Description	Coverage	Asset	Evidence Source
PI1.1–PI1.5	Complete, valid, accurate, timely, authorized processing	❌ Application layer	—	Client application controls; out of SnowOps IaC scope

P-Series — Privacy¶

All P-series criteria require a formal privacy program. SnowOps covers the technical data residency control (Data Residency Policy Module (M6) region deny); all procedural/legal privacy controls are manual or roadmap:

Criteria	Coverage	Asset
P1 (Privacy notice)	📋 Manual	—
P2 (Choice & consent)	📋 Manual	—
P3 (Collection)	📋 Manual	—
P4 (Use/retention/disposal)	🔧 Partial	Azure Backup Policy Module (`L1`) (retention), Data Residency Policy Module (`M6`) (region)
P5 (Access)	🔧 Partial	Entra ID Baseline Module (`H1`)/Conditional Access Module (`H2`) (access control)
P6 (Disclosure to third parties)	⏳ Roadmap	P-series (M4)
P7 (Quality)	📋 Manual	—
P8 (Monitoring/enforcement)	📋 Manual	—

Evidence Package for Auditors¶

Run these commands before each auditor session to produce the evidence package:

# 1. Latest compliance snapshot (E0)
ls -lt compliance/snapshots/ | head -5

# 2. Compliance dashboard (S2) — includes trend across all snapshots
node apps/compliance-dashboard/dist/index.js \
  --snapshots-dir compliance/snapshots/ \
  --restore-drills-dir compliance/restore-drills/ \
  --out compliance/audit-report/

# 3. Latest restore drill report (L4, A1.3)
ls -lt compliance/restore-drills/ | head -3

# 4. OPA policy self-test (CC5)
conftest verify --policy policy/opa/rules --policy policy/opa/tests

# 5. Active waivers with expiry (D5)
cat waivers/exceptions.yaml

What SnowOps Does NOT Automate (Manual Requirements)¶

These items are required for SOC 2 Type II but are outside SnowOps automation scope. What to do about each:

Requirement	Who	What the manual step is	Notes
Written information security policies (AUP, InfoSec, IR, BCP, Change Mgmt, Password)	Client	Draft each policy as a markdown doc (purpose, scope, statements, roles, review cadence, approval log) and commit it to `compliance/policies/` per the Policy Library Guide — that guide lists the minimum policy set, the required front-matter, and the PR-signed amendment convention	Policy Repo Template (`V1`, M4) will formalize this with a markdown library + amendment workflow + Vanta acknowledgment sync; until then the git history of `compliance/policies/` is the audit trail
Risk register and risk treatment plan	Client	Stand up a risk register (spreadsheet or GRC tool) seeded from the Discovery Audit Suite (`G0`–`G7`) findings; assign owners, scores, and treatment decisions, and review it on a fixed cadence (management-owned, minute-logged)	The G-series report gives the inputs (severity-scored, framework-tagged findings with `remediation_asset_id`); turning that into a formal, board-reviewed risk register is a management responsibility
Security awareness training + completion records	Client	Stand up a training platform (or use the client's existing LMS/HRIS), assign annual security-awareness + role-specific training, and retain completion certificates/records as evidence	HR Security & Training (`Q1`–`Q5`, M4) will automate the tracking (enrollment, completion, reminders → ticket); delivering and recording the training itself stays client-owned even after M4
Vendor due diligence and contracts (CC9.2)	Client	Build a vendor register (name, service, data accessed, risk tier), collect SOC 2/ISO reports or security questionnaires from each critical vendor, and execute DPAs/contracts with security clauses through legal counsel	Vendor & Third-Party Risk (`P1`–`P4`, M4) will automate the register + tracker + DPA workflow; the due-diligence judgment calls and contract execution remain manual — see the Policy Library Guide `vendor-management-policy.md` row
HR controls: background checks, onboarding/offboarding checklists, NDA tracking	Client	Run background checks through a vetted vendor before start date, work an onboarding/offboarding checklist (account provisioning tied to Entra ID Baseline Module (`H1`) lifecycle events), and keep signed NDAs on file	HR Security & Training (`Q1`–`Q5`, M4) automates the tracking of completion/expiry via tickets; the checks, signatures, and decisions themselves are inherently manual, human-judgment steps
Customer-facing incident notification	Client	Draft a `breach-notification-procedure.md` (who notifies whom, within what SLA, using what template) per the Policy Library Guide; when an incident triggers it, legal counsel and the designated spokesperson — not SnowOps tooling — execute the actual customer/regulator notification	The Incident Response Runbooks (`K1`) cover detection → containment → internal escalation; the outward-facing notification step is a legal/communications decision that must stay human-owned
SOC 2 Type II observation period (typically 6–12 months)	Client	Run the controls continuously for the observation window — there's nothing to configure, just elapsed time with Compliance Snapshot Collector (`E0`) snapshots accumulating evidence throughout	Purely temporal; cannot be automated or shortened — see the Compliance Engagement Guide §3 SOC 2 notes for sequencing
CPA firm engagement (must be AICPA-licensed)	Client	Source and contract an AICPA AT-C 205-licensed CPA firm before the observation period starts so they can co-design the controls with you, not just audit them after the fact	See the Compliance Engagement Guide §3 SOC 2 — "Auditor" note
Trust center / public status page	Client	Stand up a public status page and trust-center microsite (subprocessor list, security questionnaire library, uptime history) — a hosted tool (e.g. Statuspage, Trust Center SaaS) or a simple static site both work today	Trust Center & Customer-Facing (`T1`–`T4`, M4) will template and automate this; until then any client-hosted page that publishes the same information satisfies the criterion
Board/management risk acceptance sign-offs	Client	Hold periodic management-review meetings, document risk-acceptance decisions in the minutes, and have the accountable executive sign off in writing	Management-owned governance activity; SnowOps evidence (E0/S2/S4) gives the board the data to make these decisions, but the decision and sign-off must be theirs