What types of compliance documents can ComplianceIQ generate?

ComplianceIQ generates privacy policies, terms of service, employee handbooks, data handling policies, OSHA compliance documents, acceptable use policies, HIPAA compliance docs, information security policies, and more — all tailored to your industry.

Are the generated documents legally valid?

ComplianceIQ generates comprehensive, industry-standard compliance documents informed by current regulations. While they provide an excellent foundation, we recommend having critical documents reviewed by legal counsel for your specific jurisdiction.

How does ComplianceIQ stay current with regulations?

Our AI models are continuously updated with the latest regulatory frameworks including GDPR, CCPA, HIPAA, SOC 2, OSHA, and more. Pro and Enterprise plans include regulatory update alerts.

← All risk registers

SOC 2 · 28 ROWS · 5×5 SCORING

SOC 2 Risk Register — 28 Risks Mapped to TSC CC1–CC9

TSC criterion CC3.1 explicitly requires the entity to identify and analyse risks to objectives. SOC 2 audits routinely fail this control because companies show a one-page risk summary instead of an actual register. This 28-row register covers every CC criterion, scores inherent and residual risk on a 5×5 scale, and is ready to use as evidence for CC3.1, CC3.2, CC3.4, and CC9.1.

Who this is for

Series A/B SaaS companies preparing for first SOC 2 Type II
CTOs / VPs of Engineering owning the audit but lacking a security team
Existing Type I holders preparing for the longer Type II observation window

Methodology

Likelihood × Impact on a 1–5 scale (5×5 matrix). 15+ = treat now, 8–14 = treat per plan, ≤7 = accept w/ monitoring. AICPA permits any documented methodology — auditors just need to see it consistently applied.

Control Environment

ID	Threat	Vulnerability	Inherent	Control	Residual	Treatment	Owner	Reference
R-01	Tone-from-the-top deficiency	Leadership doesn't reinforce security in all-hands / Slack	3×4=12	Documented information-security policy signed by CEO, quarterly all-hands security update.	2×3=6	Mitigate	CEO	CC1.1
R-02	Undocumented org structure	Unclear reporting lines for security function	3×3=9	Org chart in handbook; security function reports to CTO/CISO with board visibility.	2×2=4	Mitigate	CEO	CC1.3
R-03	Background check failure	New hire with disqualifying history granted access	2×4=8	Pre-employment background check via Checkr or equivalent for all staff w/ data access.	1×3=3	Mitigate	HR	CC1.4

Communication

ID	Threat	Vulnerability	Inherent	Control	Residual	Treatment	Owner	Reference
R-04	Customers unaware of security commitments	No public security/trust page	3×3=9	Trust page (security.<domain>.com) with policy summary, sub-processor list, status page.	2×2=4	Mitigate	Marketing	CC2.3
R-05	Internal staff unaware of policies	Policies stored in inaccessible folder	4×3=12	Policies in handbook (Notion/Confluence), annual acknowledgement w/ HRIS log.	2×2=4	Mitigate	HR	CC2.2

Risk Assessment

ID	Threat	Vulnerability	Inherent	Control	Residual	Treatment	Owner	Reference
R-06	Material risks not identified	No formal risk-assessment cadence	4×5=20	Quarterly risk-assessment workshop; risk register reviewed by management.	2×4=8	Mitigate	CISO	CC3.1 / CC3.2
R-07	Fraud risk not considered	Procurement / payroll fraud potential ignored	2×4=8	Annual fraud-risk assessment, segregation-of-duties matrix for finance.	1×3=3	Mitigate	CFO	CC3.3
R-08	Significant change not assessed	New product launch deployed without security review	4×4=16	Change-management policy requires security review for material changes; ticket evidence.	2×3=6	Mitigate	Engineering	CC3.4

Monitoring

ID	Threat	Vulnerability	Inherent	Control	Residual	Treatment	Owner	Reference
R-09	Policy non-compliance undetected	No control-effectiveness testing	4×4=16	Continuous-control monitoring tool (Vanta/Drata/Secureframe); monthly evidence review.	2×3=6	Mitigate	Security	CC4.1
R-10	Deficiencies not remediated	Findings sit open beyond SLA	3×4=12	Tracked CAP w/ owner + due date; >30d overdue escalates to CISO.	2×3=6	Mitigate	CISO	CC4.2

Control Activities

ID	Threat	Vulnerability	Inherent	Control	Residual	Treatment	Owner	Reference
R-11	Logical access excessive	Default share-everything; no role-based controls	5×5=25	RBAC by role, least privilege, JIT for production, quarterly access reviews.	2×4=8	Mitigate	IT	CC6.1 / CC6.3
R-12	Authentication weakness	Password-only access to sensitive systems	5×5=25	MFA required (FIDO2 preferred) for all production + admin systems; SSO via Okta/Google.	2×4=8	Mitigate	IT	CC6.1
R-13	Access not deprovisioned timely	Departing staff retain access for days	4×5=20	SCIM-driven deprovisioning < 24h of HRIS termination event; quarterly attestation.	2×3=6	Mitigate	IT	CC6.2 / CC6.3
R-14	Physical access to data	Office laptops left unlocked	3×3=9	Auto-lock 5 min idle, full-disk encryption, MDM-enforced.	2×2=4	Mitigate	IT	CC6.4
R-15	Data not encrypted at rest	Backups in clear text	3×5=15	AES-256 at rest across all stores; KMS-managed keys; backup encryption mandatory.	1×3=3	Mitigate	SRE	CC6.7
R-16	Data not encrypted in transit	Internal services on HTTP	3×4=12	TLS 1.2+ for all service-to-service traffic; mTLS in production VPC.	1×3=3	Mitigate	SRE	CC6.7
R-17	Malware on endpoints	No EDR; consumer AV only	4×4=16	EDR (CrowdStrike/SentinelOne) on all endpoints; managed via MDM.	2×3=6	Mitigate	IT	CC6.8

System Operations

ID	Threat	Vulnerability	Inherent	Control	Residual	Treatment	Owner	Reference
R-18	Production incident undetected	No alerting on critical services	4×5=20	24/7 monitoring (Datadog/Grafana), paging on SLO breach, runbook per service.	2×4=8	Mitigate	SRE	CC7.1 / CC7.2
R-19	Vulnerabilities un-remediated	Patch SLAs not defined	4×5=20	30/60/90 day patch SLA by severity; weekly authenticated vuln scans; SLA dashboard.	2×4=8	Mitigate	IT	CC7.1
R-20	Incident response inconsistent	No documented IR plan	4×5=20	IR plan w/ severity matrix, on-call rota, annual tabletop exercise.	2×4=8	Mitigate	CISO	CC7.3 / CC7.4
R-21	Backup failure	Backups never tested	3×5=15	Quarterly test-restore w/ evidence; immutable / cross-region backups.	1×3=3	Mitigate	SRE	CC7.5

Change Management

ID	Threat	Vulnerability	Inherent	Control	Residual	Treatment	Owner	Reference
R-22	Unauthorised production change	Direct DB access; no PR review	4×5=20	All changes via PR + ≥1 reviewer; CI runs tests + SAST; audited deploy logs.	2×4=8	Mitigate	Engineering	CC8.1
R-23	Untested release breaks production	No staging environment	4×4=16	Mandatory staging deployment + smoke tests before prod; change ticket per release.	2×3=6	Mitigate	Engineering	CC8.1

Risk Mitigation

ID	Threat	Vulnerability	Inherent	Control	Residual	Treatment	Owner	Reference
R-24	Vendor breach impacts customers	No vendor risk programme	3×5=15	TPRM: SIG/CAIQ + SOC 2 review pre-onboarding; annual recertification.	2×4=8	Mitigate	Security	CC9.2
R-25	Business interruption	No tested BC/DR plan	3×5=15	Documented BCP/DRP, annual tabletop, RPO 1h / RTO 4h tested.	2×4=8	Mitigate	SRE	CC9.1 / A1.2

Privacy (P)

ID	Threat	Vulnerability	Inherent	Control	Residual	Treatment	Owner	Reference
R-26	Data subject request unhandled	No DSR pipeline; missed deadlines	3×4=12	DSR intake form + 30-day SLA; centralised PII inventory; automated deletion.	2×3=6	Mitigate	DPO / Legal	P5.0

Confidentiality (C)

ID	Threat	Vulnerability	Inherent	Control	Residual	Treatment	Owner	Reference
R-27	Customer data leakage	Engineers query prod for debugging using real PII	3×4=12	Prod PII access via approved tickets only; production data not allowed in lower envs.	2×3=6	Mitigate	Engineering	C1.1

ID	Threat	Vulnerability	Inherent	Control	Residual	Treatment	Owner	Reference
R-28	Single point of failure	Single AZ deployment	3×5=15	Multi-AZ minimum; multi-region for tier-1 services; chaos testing.	2×4=8	Mitigate	SRE	A1.2

Common pitfalls auditors flag

Recycling a Vanta-style 'master risk list' without trimming to your real environment — auditors notice.
No risk owner or 'Security' as the owner — owners must be named accountable individuals or specific roles.
Skipping CC3.4 (significant changes) — auditors love testing this and it's almost always the deficiency.
Risk register dated more than 12 months ago — Type II auditor flags this immediately.
Marking risks 'Accept' without management approval and a documented expiry/review date.

FAQ

Does AICPA require a specific risk-scoring methodology?

No. CC3.1 requires you to identify and analyse risks but the scoring approach (qualitative L×I, quantitative ALE, FAIR) is your choice. Document whichever you use in a 'Risk Methodology' section so the auditor can validate consistency.

Do I need separate registers per Trust Services Category?

No. One register covers Security (mandatory) and any additional categories (Availability, Confidentiality, Processing Integrity, Privacy) you've scoped. Use a 'Category' tag per row.

How often must we review the register?

AICPA expects review on a defined cadence (most companies do quarterly) plus on any 'significant change' (CC3.4) — new product, new vendor, new region, post-incident.

Will this pass the AICPA peer-reviewed audit firms?

It's a credible starting point that passes most CPA firms' baseline expectations. Customise to your environment and have your auditor review it during the readiness/Stage 1 walkthrough — that's free feedback.

Now run a free SOC 2 audit on your existing policy

Drop your current policy or describe your environment — ComplianceIQ scores every clause against the framework and tells you which register rows are actually mitigated.

Start free SOC 2 audit