Soc2 Compliance

Name: Soc2 Compliance
Author: alirezarezvani

alirezarezvani/claude-skills

625 installs
23.5k repo stars
Updated July 17, 2026
alirezarezvani/claude-skills

soc2-compliance is a Claude Code skill that collects and organizes SOC 2 Type I and Type II audit evidence with defined quality criteria for developers preparing SaaS compliance documentation before security reviews.

About

soc2-compliance is a practical evidence-collection guide for SOC 2 Type I and Type II engagements from alirezarezvani/claude-skills. It explains what auditors evaluate: existence of documented controls, design effectiveness against Trust Services Criteria for both audit types, and operating effectiveness over the observation period for Type II only. Evidence must meet four quality criteria—relevant, reliable, timely, and sufficient—with enough samples to demonstrate consistent control operation. The skill covers evidence types, automation strategies, and documentation requirements so engineering teams can gather screenshots, logs, policies, and system-generated proof instead of ad-hoc spreadsheets. Developers reach for soc2-compliance when enterprise prospects request SOC 2 readiness or an audit window is approaching.

Covers existence, design effectiveness, and operating effectiveness expectations auditors use
Five evidence quality criteria: relevant, reliable, timely, sufficient, complete
Four evidence types: inquiry, observation, inspection, re-performance
Practical automation and documentation guidance for maintaining audit-ready artifacts

Soc2 Compliance by the numbers

625 all-time installs (skills.sh)
Ranked #468 of 2,203 Security skills by installs in the Skillselion catalog
Security screen: HIGH risk (skills.sh audit)
Data as of Jul 31, 2026 (Skillselion catalog sync)

npx skills add https://github.com/alirezarezvani/claude-skills --skill soc2-compliance

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/alirezarezvani/claude-skills/soc2-compliance.svg)](https://skillselion.com/skills/alirezarezvani/claude-skills/soc2-compliance)

Installs	625
repo stars	★ 23.5k
Security audit	2 / 3 scanners passed
Last updated	July 17, 2026
Repository	alirezarezvani/claude-skills ↗

How do you collect SOC 2 Type II audit evidence?

Collect and organize SOC 2 Type I/II audit evidence with clear quality criteria and evidence types.

Who is it for?

Engineering and security leads at SaaS companies preparing SOC 2 Type I or Type II audits who need structured evidence workflows rather than last-minute screenshots.

Skip if: Teams pursuing ISO 27001 only, PCI DSS, or HIPAA without SOC 2 scope should use framework-specific compliance guides instead.

When should I use this skill?

The user asks to gather SOC 2 evidence, prepare for a Type I or Type II audit, or organize compliance documentation for Trust Services Criteria.

What you get

Organized evidence folders, control-to-artifact mapping, sample sets, and documentation meeting SOC 2 quality criteria.

Evidence inventory
Control-to-artifact mapping
Audit-ready documentation set

By the numbers

Defines 4 evidence quality criteria: relevant, reliable, timely, sufficient
Covers 3 auditor evaluation areas: existence, design effectiveness, operating effectiveness

Files

SKILL.mdMarkdownGitHub ↗

SOC 2 Compliance

SOC 2 Type I and Type II compliance preparation for SaaS companies. Covers Trust Service Criteria mapping, control matrix generation, evidence collection, gap analysis, and audit readiness assessment.

Overview
Trust Service Criteria
Control Matrix Generation
Gap Analysis Workflow
Evidence Collection
Audit Readiness Checklist
Vendor Management
Continuous Compliance
Anti-Patterns
Tools
References
Cross-References

---

Overview

What Is SOC 2?

SOC 2 (System and Organization Controls 2) is an auditing framework developed by the AICPA that evaluates how a service organization manages customer data. It applies to any technology company that stores, processes, or transmits customer information — primarily SaaS, cloud infrastructure, and managed service providers.

Type I vs Type II

Aspect	Type I	Type II
Scope	Design of controls at a point in time	Design AND operating effectiveness over a period
Duration	Snapshot (single date)	Observation window (3-12 months, typically 6)
Evidence	Control descriptions, policies	Control descriptions + operating evidence (logs, tickets, screenshots)
Cost	$20K-$50K (audit fees)	$30K-$100K+ (audit fees)
Timeline	1-2 months (audit phase)	6-12 months (observation + audit)
Best For	First-time compliance, rapid market need	Mature organizations, enterprise customers

Who Needs SOC 2?

SaaS companies selling to enterprise customers
Cloud infrastructure providers handling customer workloads
Data processors managing PII, PHI, or financial data
Managed service providers with access to client systems
Any vendor whose customers require third-party assurance

Typical Journey

Gap Assessment → Remediation → Type I Audit → Observation Period → Type II Audit → Annual Renewal
    (4-8 wk)      (8-16 wk)     (4-6 wk)       (6-12 mo)          (4-6 wk)       (ongoing)

---

Trust Service Criteria

SOC 2 is organized around five Trust Service Criteria (TSC) categories. Security is required for every SOC 2 report; the remaining four are optional and selected based on business need.

Security (Common Criteria CC1-CC9) — Required

The foundation of every SOC 2 report. Maps to COSO 2013 principles.

Criteria	Domain	Key Controls
CC1	Control Environment	Integrity/ethics, board oversight, org structure, competence, accountability
CC2	Communication & Information	Internal/external communication, information quality
CC3	Risk Assessment	Risk identification, fraud risk, change impact analysis
CC4	Monitoring Activities	Ongoing monitoring, deficiency evaluation, corrective actions
CC5	Control Activities	Policies/procedures, technology controls, deployment through policies
CC6	Logical & Physical Access	Access provisioning, authentication, encryption, physical restrictions
CC7	System Operations	Vulnerability management, anomaly detection, incident response
CC8	Change Management	Change authorization, testing, approval, emergency changes
CC9	Risk Mitigation	Vendor/business partner risk management

Availability (A1) — Optional

Criteria	Focus	Key Controls
A1.1	Capacity management	Infrastructure scaling, resource monitoring, capacity planning
A1.2	Recovery operations	Backup procedures, disaster recovery, BCP testing
A1.3	Recovery testing	DR drills, failover testing, RTO/RPO validation

Select when: Customers depend on your uptime; you have SLAs; downtime causes direct business impact.

Confidentiality (C1) — Optional

Criteria	Focus	Key Controls
C1.1	Identification	Data classification policy, confidential data inventory
C1.2	Protection	Encryption at rest and in transit, DLP, access restrictions
C1.3	Disposal	Secure deletion procedures, media sanitization, retention enforcement

Select when: You handle trade secrets, proprietary data, or contractually confidential information.

Processing Integrity (PI1) — Optional

Criteria	Focus	Key Controls
PI1.1	Accuracy	Input validation, processing checks, output verification
PI1.2	Completeness	Transaction monitoring, reconciliation, error handling
PI1.3	Timeliness	SLA monitoring, processing delay alerts, batch job monitoring
PI1.4	Authorization	Processing authorization controls, segregation of duties

Select when: Data accuracy is critical (financial processing, healthcare records, analytics platforms).

Privacy (P1-P8) — Optional

Criteria	Focus	Key Controls
P1	Notice	Privacy policy, data collection notice, purpose limitation
P2	Choice & Consent	Opt-in/opt-out, consent management, preference tracking
P3	Collection	Minimal collection, lawful basis, purpose specification
P4	Use, Retention, Disposal	Purpose limitation, retention schedules, secure disposal
P5	Access	Data subject access requests, correction rights
P6	Disclosure & Notification	Third-party sharing, breach notification
P7	Quality	Data accuracy verification, correction mechanisms
P8	Monitoring & Enforcement	Privacy program monitoring, complaint handling

Select when: You process PII and customers expect privacy assurance (complements GDPR compliance).

---

Control Matrix Generation

A control matrix maps each TSC criterion to specific controls, owners, evidence, and testing procedures.

Matrix Structure

Field	Description
Control ID	Unique identifier (e.g., SEC-001, AVL-003)
TSC Mapping	Which criteria the control addresses (e.g., CC6.1, A1.2)
Control Description	What the control does
Control Type	Preventive, Detective, or Corrective
Owner	Responsible person/team
Frequency	Continuous, Daily, Weekly, Monthly, Quarterly, Annual
Evidence Type	Screenshot, Log, Policy, Config, Ticket
Testing Procedure	How the auditor verifies the control

Control Naming Convention

{CATEGORY}-{NUMBER}
SEC-001 through SEC-NNN  → Security
AVL-001 through AVL-NNN  → Availability
CON-001 through CON-NNN  → Confidentiality
PRI-001 through PRI-NNN  → Processing Integrity
PRV-001 through PRV-NNN  → Privacy

Workflow

1. Select applicable TSC categories based on business needs 2. Run control_matrix_builder.py to generate the baseline matrix 3. Customize controls to match your actual environment 4. Assign owners and evidence requirements 5. Validate coverage — every selected TSC criterion must have at least one control

---

Gap Analysis Workflow

Phase 1: Current State Assessment

1. Document existing controls — inventory all security policies, procedures, and technical controls 2. Map to TSC — align existing controls to Trust Service Criteria 3. Collect evidence samples — gather proof that controls exist and operate 4. Interview control owners — verify understanding and execution

Phase 2: Gap Identification

Run gap_analyzer.py against your current controls to identify:

Missing controls — TSC criteria with no corresponding control
Partially implemented — Control exists but lacks evidence or consistency
Design gaps — Control designed but does not adequately address the criteria
Operating gaps (Type II only) — Control designed correctly but not operating effectively

Phase 3: Remediation Planning

For each gap, define:

Field	Description
Gap ID	Reference identifier
TSC Criteria	Affected criteria
Gap Description	What is missing or insufficient
Remediation Action	Specific steps to close the gap
Owner	Person responsible for remediation
Priority	Critical / High / Medium / Low
Target Date	Completion deadline
Dependencies	Other gaps or projects that must complete first

Phase 4: Timeline Planning

Priority	Target Remediation
Critical	2-4 weeks
High	4-8 weeks
Medium	8-12 weeks
Low	12-16 weeks

---

Evidence Collection

Evidence Types by Control Category

Control Area	Primary Evidence	Secondary Evidence
Access Management	User access reviews, provisioning tickets	Role matrix, access logs
Change Management	Change tickets, approval records	Deployment logs, test results
Incident Response	Incident tickets, postmortems	Runbooks, escalation records
Vulnerability Management	Scan reports, patch records	Remediation timelines
Encryption	Configuration screenshots, certificate inventory	Key rotation logs
Backup & Recovery	Backup logs, DR test results	Recovery time measurements
Monitoring	Alert configurations, dashboard screenshots	On-call schedules, escalation records
Policy Management	Signed policies, version history	Training completion records
Vendor Management	Vendor assessments, SOC 2 reports	Contract reviews, risk registers

Automation Opportunities

Area	Automation Approach
Access reviews	Integrate IAM with ticketing (automatic quarterly review triggers)
Configuration evidence	Infrastructure-as-code snapshots, compliance-as-code tools
Vulnerability scans	Scheduled scanning with auto-generated reports
Change management	Git-based audit trail (commits, PRs, approvals)
Uptime monitoring	Automated SLA dashboards with historical data
Backup verification	Automated restore tests with success/failure logging

Continuous Monitoring

Move from point-in-time evidence collection to continuous compliance:

1. Automated evidence gathering — scripts that pull evidence on schedule 2. Control dashboards — real-time visibility into control status 3. Alert-based monitoring — notify when a control drifts out of compliance 4. Evidence repository — centralized, timestamped evidence storage

---

Audit Readiness Checklist

Pre-Audit Preparation (4-6 Weeks Before)

[ ] All controls documented with descriptions, owners, and frequencies
[ ] Evidence collected for the entire observation period (Type II)
[ ] Control matrix reviewed and gaps remediated
[ ] Policies signed and distributed within the last 12 months
[ ] Access reviews completed within the required frequency
[ ] Vulnerability scans current (no critical/high unpatched > SLA)
[ ] Incident response plan tested within the last 12 months
[ ] Vendor risk assessments current for all subservice organizations
[ ] DR/BCP tested and documented within the last 12 months
[ ] Employee security training completed for all staff

Readiness Scoring

Score	Rating	Meaning
90-100%	Audit Ready	Proceed with confidence
75-89%	Minor Gaps	Address before scheduling audit
50-74%	Significant Gaps	Remediation required
< 50%	Not Ready	Major program build-out needed

Common Audit Findings

Finding	Root Cause	Prevention
Incomplete access reviews	Manual process, no reminders	Automate quarterly review triggers
Missing change approvals	Emergency changes bypass process	Define emergency change procedure with post-hoc approval
Stale vulnerability scans	Scanner misconfigured	Automated weekly scans with alerting
Policy not acknowledged	No tracking mechanism	Annual e-signature workflow
Missing vendor assessments	No vendor inventory	Maintain vendor register with review schedule

---

Vendor Management

Third-Party Risk Assessment

Every vendor that accesses, stores, or processes customer data must be assessed:

1. Vendor inventory — maintain a register of all service providers 2. Risk classification — categorize vendors by data access level 3. Due diligence — collect SOC 2 reports, security questionnaires, certifications 4. Contractual protections — ensure DPAs, security requirements, breach notification clauses 5. Ongoing monitoring — annual reassessment, continuous news monitoring

Vendor Risk Tiers

Tier	Data Access	Assessment Frequency	Requirements
Critical	Processes/stores customer data	Annual + continuous monitoring	SOC 2 Type II, penetration test, security review
High	Accesses customer environment	Annual	SOC 2 Type II or equivalent, questionnaire
Medium	Indirect access, support tools	Annual questionnaire	Security certifications, questionnaire
Low	No data access	Biennial questionnaire	Basic security questionnaire

Subservice Organizations

When your SOC 2 report relies on controls at a subservice organization (e.g., AWS, GCP, Azure):

Inclusive method — your report covers the subservice org's controls (requires their cooperation)
Carve-out method — your report excludes their controls but references their SOC 2 report
Most companies use carve-out and include complementary user entity controls (CUECs)

---

Continuous Compliance

From Point-in-Time to Continuous

Aspect	Point-in-Time	Continuous
Evidence collection	Manual, before audit	Automated, ongoing
Control monitoring	Periodic review	Real-time dashboards
Drift detection	Found during audit	Alert-based, immediate
Remediation	Reactive	Proactive
Audit preparation	4-8 week scramble	Always ready

Implementation Steps

1. Automate evidence gathering — cron jobs, API integrations, IaC snapshots 2. Build control dashboards — aggregate control status into a single view 3. Configure drift alerts — notify when controls fall out of compliance 4. Establish review cadence — weekly control owner check-ins, monthly steering 5. Maintain evidence repository — centralized, timestamped, auditor-accessible

Annual Re-Assessment Cycle

Quarter	Activities
Q1	Annual risk assessment, policy refresh, vendor reassessment launch
Q2	Internal control testing, remediation of findings
Q3	Pre-audit readiness review, evidence completeness check
Q4	External audit, management assertion, report distribution

---

Anti-Patterns

Anti-Pattern	Why It Fails	Better Approach
Point-in-time compliance	Controls degrade between audits; gaps found during audit	Implement continuous monitoring and automated evidence
Manual evidence collection	Time-consuming, inconsistent, error-prone	Automate with scripts, IaC, and compliance platforms
Missing vendor assessments	Auditors flag incomplete vendor due diligence	Maintain vendor register with risk-tiered assessment schedule
Copy-paste policies	Generic policies don't match actual operations	Tailor policies to your actual environment and technology stack
Security theater	Controls exist on paper but aren't followed	Verify operating effectiveness; build controls into workflows
Skipping Type I	Jumping to Type II without foundational readiness	Start with Type I to validate control design before observation
Over-scoping TSC	Including all 5 categories when only Security is needed	Select categories based on actual customer/business requirements
Treating audit as a project	Compliance degrades after the report is issued	Build compliance into daily operations and engineering culture

---

Tools

Control Matrix Builder

Generates a SOC 2 control matrix from selected TSC categories.

# Generate full security matrix in markdown
python scripts/control_matrix_builder.py --categories security --format md

# Generate matrix for multiple categories as JSON
python scripts/control_matrix_builder.py --categories security,availability,confidentiality --format json

# All categories, CSV output
python scripts/control_matrix_builder.py --categories security,availability,confidentiality,processing-integrity,privacy --format csv

Evidence Tracker

Tracks evidence collection status per control.

# Check evidence status from a control matrix
python scripts/evidence_tracker.py --matrix controls.json --status

# JSON output for integration
python scripts/evidence_tracker.py --matrix controls.json --status --json

Gap Analyzer

Analyzes current controls against SOC 2 requirements and identifies gaps.

# Type I gap analysis
python scripts/gap_analyzer.py --controls current_controls.json --type type1

# Type II gap analysis (includes operating effectiveness)
python scripts/gap_analyzer.py --controls current_controls.json --type type2 --json

---

References

Trust Service Criteria Reference — All 5 TSC categories with sub-criteria, control objectives, and evidence examples
Evidence Collection Guide — Evidence types per control, automation tools, documentation requirements
Type I vs Type II Comparison — Detailed comparison, timeline, cost analysis, and upgrade path

---

Cross-References

[gdpr-dsgvo-expert](../gdpr-dsgvo-expert/SKILL.md) — SOC 2 Privacy criteria overlaps significantly with GDPR requirements; use together when processing EU personal data
[information-security-manager-iso27001](../information-security-manager-iso27001/SKILL.md) — ISO 27001 Annex A controls map closely to SOC 2 Security criteria; organizations pursuing both can share evidence
[isms-audit-expert](../isms-audit-expert/SKILL.md) — Audit methodology and finding management patterns transfer directly to SOC 2 audit preparation

SOC 2 Evidence Collection Guide

Practical guide for collecting, organizing, and maintaining audit evidence for SOC 2 Type I and Type II engagements. Covers evidence types, automation strategies, and documentation requirements.

---

Evidence Fundamentals

What Auditors Look For

1. Existence — The control is documented and exists 2. Design effectiveness — The control is designed to address the TSC criterion (Type I + Type II) 3. Operating effectiveness — The control operates consistently over the observation period (Type II only)

Evidence Quality Criteria

Criterion	Description
Relevant	Directly demonstrates the control's operation
Reliable	Generated by systems or independent parties (not self-reported)
Timely	Falls within the audit/observation period
Sufficient	Enough samples to demonstrate consistency
Complete	Covers the full population or a representative sample

Evidence Types

Type	Description	Examples
Inquiry	Verbal or written descriptions from personnel	Interview notes, written responses
Observation	Auditor witnesses control in operation	Process walkthroughs, live demonstrations
Inspection	Review of documents, records, or configurations	Policy documents, system screenshots, logs
Re-performance	Auditor re-executes the control to verify results	Access review validation, configuration checks

---

Evidence by Control Area

Access Management

Control	Type I Evidence	Type II Evidence
Access provisioning	Provisioning policy, role matrix	Sample provisioning tickets with approvals (full period)
Access removal	Termination checklist, deprovisioning SOP	Sample termination events with access removal timestamps
Access reviews	Review policy, review template	Completed quarterly access review reports with sign-offs
MFA enforcement	MFA policy, configuration screenshot	MFA enrollment report showing 100% coverage
Privileged access	Privileged access policy, admin list	Quarterly privileged access reviews, admin activity logs

Change Management

Control	Type I Evidence	Type II Evidence
Change authorization	Change management policy, workflow description	Sample change tickets with approvals, peer reviews
Testing requirements	Testing policy, test plan template	Test results for sampled changes, QA sign-offs
Emergency changes	Emergency change procedure	Emergency change tickets with post-hoc approvals
Deployment process	CI/CD documentation, deployment runbook	Deployment logs, rollback records
Code review	Code review policy	Pull request histories showing reviewer approvals

Incident Response

Control	Type I Evidence	Type II Evidence
IR plan	Incident response plan document	Plan review/update records, version history
IR testing	Tabletop exercise schedule	Tabletop exercise reports, lessons learned
Incident handling	Triage procedures, classification criteria	Incident tickets with timestamps, escalation records
Postmortems	Postmortem template, review process	Completed postmortem documents, follow-up actions
Communication	Communication plan, stakeholder list	Notification records, status page updates

Vulnerability Management

Control	Type I Evidence	Type II Evidence
Scanning	Scanning schedule, tool configuration	Scan reports covering the full period (weekly/monthly)
Remediation SLAs	Remediation policy with SLA definitions	Remediation tracking showing SLA compliance rates
Patch management	Patching policy, schedule	Patch records, before/after scan comparisons
Penetration testing	Pentest policy, scope definition	Pentest reports (annual), remediation records

Encryption and Data Protection

Control	Type I Evidence	Type II Evidence
Encryption at rest	Encryption policy, configuration docs	Configuration screenshots, encryption audit reports
Encryption in transit	TLS policy, minimum version requirements	TLS scan results, certificate inventory
Key management	Key management policy, rotation schedule	Key rotation logs, access records for key stores
DLP	DLP policy, tool configuration	DLP alert logs, incident records, exception approvals

Backup and Recovery

Control	Type I Evidence	Type II Evidence
Backup procedures	Backup policy, schedule, retention rules	Backup success/failure logs (daily), retention compliance
DR planning	DR plan, recovery procedures	DR plan review records, update history
DR testing	DR test schedule, test plan	DR test reports with RTO/RPO measurements
BCP	BCP document, communication tree	BCP review records, test results

Monitoring and Logging

Control	Type I Evidence	Type II Evidence
SIEM/logging	Logging policy, SIEM configuration	Log retention evidence, alert samples, dashboard screenshots
Alert management	Alert rules, escalation procedures	Alert trigger samples, response records
Uptime monitoring	Monitoring tool configuration, SLA definitions	Uptime reports covering the full period
Anomaly detection	Detection rules, baseline configuration	Detection events, investigation records

Policy and Governance

Control	Type I Evidence	Type II Evidence
Security policies	Policy library, version control	Policy acknowledgment records, annual review evidence
Security training	Training program description, content	Training completion records (all employees)
Risk assessment	Risk assessment methodology	Annual risk assessment report, risk register updates
Board oversight	Committee charter, reporting schedule	Board meeting minutes, security reports to leadership

Vendor Management

Control	Type I Evidence	Type II Evidence
Vendor inventory	Vendor register, classification criteria	Current vendor register with risk tiers
Vendor assessment	Assessment questionnaire, criteria	Completed assessments, vendor SOC reports collected
Contractual controls	DPA template, security requirements	Signed DPAs, contract review records
Ongoing monitoring	Monitoring schedule, reassessment triggers	Reassessment records, monitoring reports

---

Evidence Automation

Automated Evidence Sources

Evidence	Automation Approach	Tools
Access reviews	Scheduled IAM exports, automated review workflows	Okta, Azure AD, AWS IAM + Jira/ServiceNow
Configuration compliance	Infrastructure-as-code, policy-as-code scanning	Terraform, OPA, AWS Config, Azure Policy
Vulnerability scans	Scheduled scanning with report auto-generation	Nessus, Qualys, Snyk, Dependabot
Change management	Git-based audit trails (commits, PRs, approvals)	GitHub, GitLab, Bitbucket
Uptime monitoring	Continuous synthetic monitoring with SLA dashboards	Datadog, New Relic, PagerDuty, Pingdom
Backup verification	Automated backup validation and restore tests	AWS Backup, Veeam, custom scripts
Training completion	LMS with automated tracking and reminders	KnowBe4, Curricula, custom LMS
Policy acknowledgment	Digital signature workflows with tracking	DocuSign, HelloSign, internal tools

Evidence Collection Script Pattern

1. Define evidence requirements per control
2. Map each requirement to a data source (API, log, screenshot)
3. Schedule automated collection (daily/weekly/monthly)
4. Store evidence with timestamps in a central repository
5. Generate collection status dashboard
6. Alert on missing or overdue evidence

Evidence Repository Structure

evidence/
├── {year}-{audit-period}/
│   ├── access-management/
│   │   ├── quarterly-access-review-Q1.pdf
│   │   ├── quarterly-access-review-Q2.pdf
│   │   ├── mfa-enrollment-report-2025-03.png
│   │   └── provisioning-samples/
│   ├── change-management/
│   │   ├── change-ticket-samples/
│   │   └── deployment-logs/
│   ├── incident-response/
│   │   ├── ir-plan-v3.2.pdf
│   │   ├── tabletop-exercise-2025-06.pdf
│   │   └── incident-tickets/
│   ├── vulnerability-management/
│   │   ├── scan-reports/
│   │   └── pentest-report-2025.pdf
│   ├── policies/
│   │   ├── information-security-policy-v4.pdf
│   │   └── acknowledgment-records/
│   └── vendor-management/
│       ├── vendor-register.csv
│       └── vendor-assessments/

---

Sampling Methodology

Auditors use sampling to test operating effectiveness. Understanding the methodology helps you prepare the right volume of evidence.

Sample Sizes by Control Frequency

Control Frequency	Population Size (per period)	Typical Sample Size
Annual	1	1 (all items)
Quarterly	4	2-4
Monthly	6-12	2-5
Weekly	26-52	5-15
Daily	180-365	20-40
Continuous/per-event	Varies	25-60

Key Sampling Rules

1. Higher frequency = larger sample — more occurrences mean more samples needed 2. Automated controls — typically only 1 sample needed if the system is validated 3. Exceptions must be explained — any deviation in a sample requires documentation 4. Population completeness — you must provide the full population for the auditor to select from

---

Type I vs Type II Evidence Differences

Aspect	Type I	Type II
Time scope	Single point in time	Entire observation period (3-12 months)
Volume	Lower — policies and configurations	Higher — ongoing logs, tickets, reports
Focus	"Is the control designed properly?"	"Did the control operate effectively?"
Exceptions	N/A	Must document and explain every exception
Owner sign-off	Policy approval records	Ongoing review sign-offs throughout the period

---

Common Evidence Pitfalls

Pitfall	Impact	Prevention
Screenshots without timestamps	Auditor cannot verify timing	Always include system clock or date stamps
Policies without version control	Cannot prove current vs outdated	Use document management with version tracking
Access reviews without sign-off	Cannot prove review was completed	Require digital approval/sign-off on every review
Gaps in monitoring data	Suggests control was not operating	Ensure logging continuity; document any outages
Evidence from wrong period	Does not cover the observation window	Verify date ranges before submission
Redacted evidence without explanation	Auditor may question completeness	Provide redaction rationale and methodology
Self-generated evidence only	Lower reliability in auditor's assessment	Include system-generated and third-party evidence
Missing exception documentation	Auditor flags as control failure	Document every exception with root cause and remediation

SOC 2 Type II Audit Playbook

This reference answers exactly one decision: how do we prepare for and operate the SOC 2 Type II examination cycle — the 6-12 month observation period that produces the bound SOC 2 report?

Pair with this skill's Python tools (control_matrix_builder.py, evidence_tracker.py, gap_analyzer.py) and compliance-os/scripts/audit_simulator.py for mock-audit preparation.

Key Difference from ISO Audits

SOC 2 is an AICPA attestation, not an ISO certification. Implications:

Performed by a licensed CPA firm (not a certification body)
Type I: design effectiveness at a point in time (snapshot)
Type II: operating effectiveness over a period (typically 6-12 months) — the report enterprise buyers actually want
Output: bound report distributed under NDA, not a public certificate
Renewed annually (continuous Type II reports rather than 3-year cert cycle)
The customer (your buyer) cares about the report's "no exceptions" verdict on the Trust Services Criteria

SOC 2 is heavily about evidence sampling over the observation period — your control must operate consistently for the full period, not just on audit day.

When to Use This Playbook

Type I readiness (point-in-time snapshot before first Type II)
Type II readiness (annual; observation period typically 6-12 months)
Pre-bid response to enterprise procurement asking for "SOC 2 Type II"
Audit firm scoping discussion
Quarterly internal pre-audit during Type II observation period
New control implementation during observation period (timing impacts report)

The Five Trust Services Criteria (TSC)

SOC 2 uses the 2017 TSC as updated in 2022. Always-included is Security; the other 4 are elective based on customer requirements:

TSC	Always required?	What it covers
Security (Common Criteria CC1-CC9)	YES — always	Common criteria across all TSC categories
Availability (A1)	Optional	System available for operation + use as committed
Processing Integrity (PI1)	Optional	System processing complete + valid + accurate + timely + authorized
Confidentiality (C1)	Optional	Information designated as confidential is protected
Privacy (P1-P8)	Optional	Personal information collected + used + retained + disclosed per privacy notice

Common scoping:

Pure infrastructure SaaS: Security + Availability + Confidentiality
SaaS handling consumer data: + Privacy
SaaS processing financial / sensitive data: + Processing Integrity
B2B SaaS with no consumer data: typically Security + Availability + Confidentiality

The Type II Workflow (12-month cycle)

[ Month 0: Type I if needed ] -> [ Month 1-2: Pre-observation prep ]
                                            |
                                            v
[ Month 3-9: Observation period (audit firm samples evidence) ]
                                            |
                                            v
[ Month 10: Field testing + walkthroughs ] -> [ Month 11: Report draft + management response ]
                                            |
                                            v
[ Month 12: Final report issued ]

Pre-Observation Phase (Months 1-2)

Critical setup work. Audit firm walks through:

Scoping decisions (which TSC, which systems, which entities)
Description of system per AICPA AT-C 205 — narrative + boundaries + components
Mapping each in-scope control to TSC criteria
Defining sampling approach + frequency

Tip: if you're implementing new controls during this phase, do so BEFORE the observation period starts. New controls mid-observation create gaps in the "operated consistently" assertion.

Observation Period (Months 3-9)

The audit firm samples evidence from this period. You operate normally; evidence is captured and preserved.

Critical disciplines:

1. Don't change controls mid-period without documented change management 2. Don't skip controls even for one cycle (quarterly access review skipped one quarter = a likely exception in the report) 3. Capture evidence in real-time — not assembled retrospectively at audit time 4. Document every exception — exceptions are not death sentences if management remediation is documented

Field Testing (Month 10)

The audit firm pulls samples:

For each control, pulls samples from the observation period
Typically sample size: 30-40 samples for high-population controls (logs, tickets); 100% for low-population controls (annual training, quarterly reviews)
Walkthrough interviews for design verification
Tests of operating effectiveness for Type II assertion

Report (Months 11-12)

The SOC 2 Type II report contains:

Section 1: Auditor's opinion (the page the customer reads first)
Section 2: Management assertion
Section 3: System description
Section 4: Trust services criteria + controls + test results + exceptions

A "clean" opinion = unmodified opinion = no exceptions material to overall conclusion. Customer expects clean. Even one or two exceptions trigger customer questions.

Most Common SOC 2 Type II Exceptions

Based on practitioner reports of common Type II exceptions:

1. Quarterly access review not completed for one quarter during observation period 2. Vulnerability scan results not remediated within stated SLA on N of M samples 3. Background check evidence missing for one or two employees hired during period 4. Annual training not 100% complete by stated deadline (someone always misses) 5. Change ticket without complete documentation (testing evidence or approval missing) 6. Logging gap detected (e.g., 3 hours of missing logs on one date) 7. Encryption configuration not validated for one or two new resources spun up during period 8. Vendor security review not refreshed during observation period for one or two critical vendors 9. Incident response not documented within stated SLA for one or two minor incidents 10. Customer notification delayed past committed timeline for one event

Strategy: even one exception is OK if remediated and documented. The auditor cares about whether the exception is material — meaning the control "operates" in aggregate.

Type II vs Type I Discipline Delta

Aspect	Type I	Type II
Evidence required	Point-in-time	Continuous over observation period
Sampling	Limited	Statistically meaningful samples per control
Cost	Lower (months 1-3)	Higher (months 1-12)
Customer trust	Limited	Strong
Renewal	Build-once	Annual recurring

Most enterprise customers will not accept Type I beyond first year. Type I is a stepping-stone, not a steady state.

ISO 27001 ↔ SOC 2 Reuse

The highest-leverage cross-framework pair. ~75% of ISO 27001:2022 Annex A controls map to SOC 2 TSC. Pattern:

If you have mature ISO 27001 → adding SOC 2 takes ~3 months incremental work
If you have mature SOC 2 → adding ISO 27001 takes ~3-6 months (ISO requires additional management-system formality: scope statement, internal audit programme, formal management review)

Same controls; different formatting. See compliance-os/references/cross_framework_overlap.md for the merged-control catalogue.

Privacy TSC + GDPR Overlap

If Privacy (P-series) is in scope:

P1.1 (Notice) ↔ GDPR Articles 13-14
P2.1 (Choice + consent) ↔ GDPR Article 7 + 8
P3.1 (Collection) ↔ GDPR Article 5 minimization
P4 (Use, retention, disposal) ↔ GDPR Article 5(1)(c)-(e)
P5 (Access) ↔ GDPR Article 15
P6.1 (Disclosure) ↔ GDPR Article 13/14 + DPA agreements
P7 (Quality) ↔ GDPR Article 5(1)(d)
P8 (Monitoring + enforcement) ↔ GDPR Article 24 (accountability)

If both apply, build evidence to GDPR specification (which is more prescriptive) and report against SOC 2 TSC.

Cross-Framework Reuse

SOC 2 audit work supports:

ISO 27001 — primary cross-walk (~75% control reuse)
PCI DSS — overlap on access control, encryption, logging, vulnerability mgmt
HITRUST — overlap on security controls
NIST CSF — common control vocabulary

Pair with compliance-os/references/multi_framework_audit_playbook.md.

When This Reference Doesn't Help

SOC 1 (financial reporting controls) — different scope; engage financial-audit-focused firm
SOC 3 (general use report) — different distribution rules; less common
HITRUST CSF certification — separate framework
Vendor risk vs SOC 2 report consumption — different perspective; downstream activity

---

Source authorities (non-exhaustive):

AICPA AT-C 105 + AT-C 205 — Attestation engagement standards
AICPA AU-C 240 — Auditor's responsibilities relating to fraud (conceptually applied)
AICPA Trust Services Criteria (2017 + 2022 update) — TSC text
AICPA SOC 2 Reporting Guide (continuously updated)
ISACA CISA Review Manual — IS audit methodology overlap
PCAOB standards — for audit-firm methodology context
NIST SP 800-53A Rev 5 — for assessment procedure precedent
ISO/IEC 27001:2022 + Annex A — the primary cross-walk standard
Industry retrospectives — published reports from major audit firms (Big 4 + Schellman + Coalfire + A-LIGN) on common SOC 2 exceptions
The Open Group + IIA — internal audit methodology informing pre-engagement work

SOC 2 Trust Service Criteria Reference

Comprehensive reference for all five AICPA Trust Service Criteria (TSC) categories. Each criterion includes its objective, sub-criteria, typical controls, and evidence examples.

---

1. Security (Common Criteria) — Required

The Security category is mandatory for every SOC 2 engagement. It maps to the 17 COSO 2013 internal control principles organized into nine groups (CC1-CC9).

CC1 — Control Environment

Establishes the foundation for all other components of internal control.

Criterion	Objective	Typical Controls	Evidence
CC1.1	Demonstrate commitment to integrity and ethical values	Code of conduct, ethics hotline, background checks	Signed code of conduct, hotline reports, screening records
CC1.2	Board exercises oversight of internal control	Independent board/committee, regular reporting	Board meeting minutes, committee charters, oversight reports
CC1.3	Management establishes structure and reporting lines	Organizational charts, role definitions, RACI matrices	Org charts, job descriptions, authority matrices
CC1.4	Commitment to attract, develop, and retain competent individuals	Training programs, competency assessments, career development	Training completion records, skills assessments, HR policies
CC1.5	Hold individuals accountable for internal control responsibilities	Performance evaluations, disciplinary procedures	Performance review records, accountability documentation

CC2 — Communication and Information

Ensures relevant, quality information flows internally and externally.

Criterion	Objective	Typical Controls	Evidence
CC2.1	Obtain and generate relevant quality information	Data classification, information quality standards	Classification policy, data quality reports
CC2.2	Internally communicate information and responsibilities	Internal newsletters, policy distribution, security awareness	Communication logs, training materials, acknowledgment records
CC2.3	Communicate with external parties	Customer notifications, vendor communications, incident notices	External communication policy, notification records, status pages

CC3 — Risk Assessment

Identifies and assesses risks that may prevent achievement of objectives.

Criterion	Objective	Typical Controls	Evidence
CC3.1	Specify objectives to identify and assess risks	Risk management framework, risk appetite statement	Risk methodology document, risk appetite approval
CC3.2	Identify and analyze risks	Risk assessments, threat modeling, vulnerability analysis	Risk register, threat models, assessment reports
CC3.3	Consider potential for fraud	Fraud risk assessment, segregation of duties	Fraud risk report, SoD matrix, anti-fraud controls
CC3.4	Identify and assess changes impacting internal control	Change impact analysis, environmental scanning	Change assessments, business impact analyses

CC4 — Monitoring Activities

Ongoing evaluations to verify internal controls are present and functioning.

Criterion	Objective	Typical Controls	Evidence
CC4.1	Select and perform ongoing and separate evaluations	Continuous monitoring, internal audits, control testing	Monitoring dashboards, audit reports, testing results
CC4.2	Evaluate and communicate deficiencies	Deficiency tracking, remediation management, management reporting	Deficiency logs, remediation plans, management reports

CC5 — Control Activities

Policies and procedures that ensure management directives are carried out.

Criterion	Objective	Typical Controls	Evidence
CC5.1	Select and develop control activities that mitigate risks	Risk-based control selection, control design documentation	Control matrix, risk treatment plans
CC5.2	Select and develop technology controls	IT general controls, automated controls, technology governance	ITGC documentation, technology policies, automated control configs
CC5.3	Deploy control activities through policies and procedures	Policy library, procedure documentation, acknowledgment tracking	Policy repository, version history, signed acknowledgments

CC6 — Logical and Physical Access Controls

Restrict logical and physical access to information assets.

Criterion	Objective	Typical Controls	Evidence
CC6.1	Logical access security over protected assets	IAM platform, SSO, MFA enforcement	IAM configuration, SSO settings, MFA enrollment reports
CC6.2	Access provisioning based on role and need	Role-based access, provisioning workflows, approval chains	Provisioning tickets, role matrix, approval records
CC6.3	Access removal on termination or role change	Offboarding checklists, automated deprovisioning	Deprovisioning tickets, termination checklists, access removal logs
CC6.4	Periodic access reviews	Quarterly user access reviews, entitlement validation	Access review reports, entitlement listings, sign-off records
CC6.5	Physical access restrictions	Badge systems, visitor management, secure areas	Badge access logs, visitor logs, physical access policies
CC6.6	Encryption of data in transit and at rest	TLS enforcement, disk encryption, key management	TLS configuration, encryption settings, key rotation records
CC6.7	Data transmission and movement restrictions	DLP tools, network segmentation, firewall rules	DLP configuration, network diagrams, firewall rule sets
CC6.8	Prevention/detection of unauthorized software	Endpoint protection, application whitelisting, malware scanning	EDR configuration, whitelist policies, scan reports

CC7 — System Operations

Detect and mitigate security events and anomalies.

Criterion	Objective	Typical Controls	Evidence
CC7.1	Vulnerability identification and management	Vulnerability scanning, patch management, remediation SLAs	Scan reports, patch records, SLA compliance metrics
CC7.2	Monitor for anomalies and security events	SIEM, IDS/IPS, behavioral analytics	SIEM dashboards, alert rules, detection logs
CC7.3	Security event evaluation and classification	Incident classification criteria, triage procedures	Classification matrix, triage logs, escalation records
CC7.4	Incident response execution	Incident response plan, response team, communication procedures	IR plan, incident tickets, communication records
CC7.5	Incident recovery and lessons learned	Recovery procedures, post-incident reviews, plan updates	Recovery records, postmortem reports, plan revision history

CC8 — Change Management

Authorize, design, develop, test, and implement changes to infrastructure and software.

Criterion	Objective	Typical Controls	Evidence
CC8.1	Change authorization, testing, and approval	Change management process, approval workflows, testing requirements	Change tickets, approval records, test results, deployment logs

CC9 — Risk Mitigation

Manage risks associated with business disruption, vendors, and partners.

Criterion	Objective	Typical Controls	Evidence
CC9.1	Vendor and business partner risk management	Vendor assessment program, third-party risk management	Vendor risk assessments, vendor register, vendor SOC reports
CC9.2	Risk mitigation through transfer mechanisms	Cyber insurance, contractual protections	Insurance certificates, contract provisions

---

2. Availability (A1) — Optional

Addresses system uptime, performance, and recoverability commitments.

Criterion	Objective	Typical Controls	Evidence
A1.1	Capacity and performance management	Auto-scaling, resource monitoring, capacity planning	Capacity dashboards, scaling policies, resource utilization trends
A1.2	Recovery operations	Backup procedures, DR planning, BCP documentation	Backup logs, DR plan, BCP documentation, recovery procedures
A1.3	Recovery testing	DR drills, failover tests, RTO/RPO validation	DR test reports, failover results, RTO/RPO measurements

When to Include Availability

Your customers depend on your service uptime
You have SLAs with financial penalties for downtime
Your service is in the critical path of customer operations
You provide infrastructure or platform services

Key Metrics

Metric	Description	Typical Target
RTO	Recovery Time Objective — max acceptable downtime	1-4 hours
RPO	Recovery Point Objective — max acceptable data loss	1-24 hours
SLA	Service Level Agreement — uptime commitment	99.9%-99.99%
MTTR	Mean Time to Recovery — average recovery duration	< 1 hour

---

3. Confidentiality (C1) — Optional

Protects information designated as confidential throughout its lifecycle.

Criterion	Objective	Typical Controls	Evidence
C1.1	Identification of confidential information	Data classification scheme, confidential data inventory	Classification policy, data inventory, labeling standards
C1.2	Protection of confidential information	Encryption, access restrictions, DLP, secure transmission	Encryption configs, ACLs, DLP rules, secure transfer logs
C1.3	Disposal of confidential information	Secure deletion, media sanitization, retention enforcement	Disposal procedures, sanitization certificates, deletion logs

When to Include Confidentiality

You handle trade secrets or proprietary business information
Contracts require confidentiality assurance
You process data classified above "public" in your classification scheme
Customers share confidential data for processing

Data Classification Levels

Level	Description	Handling Requirements
Public	No restrictions	No special controls
Internal	Business use only	Access controls, basic encryption
Confidential	Restricted access	Strong encryption, DLP, access reviews
Highly Confidential	Strictly controlled	Strongest encryption, MFA, audit logging, need-to-know

---

4. Processing Integrity (PI1) — Optional

Ensures system processing is complete, valid, accurate, timely, and authorized.

Criterion	Objective	Typical Controls	Evidence
PI1.1	Processing accuracy	Input validation, data integrity checks, output verification	Validation rules, integrity check logs, reconciliation reports
PI1.2	Processing completeness	Transaction monitoring, completeness checks, reconciliation	Transaction logs, batch processing reports, reconciliation records
PI1.3	Processing timeliness	SLA monitoring, batch job scheduling, processing alerts	SLA reports, job schedules, processing time metrics
PI1.4	Processing authorization	Authorization controls, segregation of duties, approval workflows	Authorization matrix, SoD analysis, approval records

When to Include Processing Integrity

You perform financial calculations or transactions
Data accuracy is critical to customer operations
You provide analytics or reporting that drives business decisions
Regulatory requirements demand processing accuracy (e.g., healthcare, finance)

Validation Checkpoints

Stage	Validation	Method
Input	Data format, range, completeness	Automated validation rules
Processing	Calculation accuracy, transformation correctness	Unit tests, reconciliation
Output	Report accuracy, data completeness	Cross-checks, manual review, checksums
Transfer	Transmission integrity, completeness	Hash verification, acknowledgment protocols

---

5. Privacy (P1-P8) — Optional

Governs the collection, use, retention, disclosure, and disposal of personal information. Closely aligns with GDPR, CCPA, and other privacy regulations.

Criterion	Objective	Typical Controls	Evidence
P1.1	Notice — inform data subjects about data practices	Privacy policy, collection notices, purpose statements	Published privacy policy, collection banners, purpose documentation
P2.1	Choice and consent — provide opt-in/opt-out mechanisms	Consent management, preference centers, granular consent	Consent records, preference logs, opt-out mechanisms
P3.1	Collection — collect only necessary personal information	Data minimization, lawful basis documentation, purpose specification	Collection audits, lawful basis records, data flow diagrams
P4.1	Use, retention, and disposal — limit use and enforce retention	Purpose limitation, retention schedules, automated deletion	Use restriction controls, retention policies, deletion logs
P4.2	Disposal — secure disposal when no longer needed	Secure deletion, media sanitization	Disposal certificates, sanitization records
P5.1	Access — provide data subjects access to their data	DSAR processing, data portability, access portals	DSAR logs, response timelines, export capabilities
P5.2	Correction — allow data subjects to correct their data	Correction request processing, data update mechanisms	Correction logs, update records
P6.1	Disclosure — control third-party data sharing	Data sharing agreements, third-party inventory, DPAs	DPAs, sharing agreements, third-party register
P6.2	Notification — notify of breaches affecting personal data	Breach notification procedures, regulatory reporting	Breach response plan, notification records, reporting logs
P7.1	Quality — maintain accurate personal information	Data quality checks, accuracy verification, correction mechanisms	Quality reports, accuracy audits, correction records
P8.1	Monitoring — monitor privacy program effectiveness	Privacy audits, compliance reviews, complaint tracking	Audit reports, compliance dashboards, complaint logs

When to Include Privacy

You process personal information (PII) of end users or customers
You operate in jurisdictions with privacy regulations (GDPR, CCPA, LGPD)
Customers request privacy assurance as part of vendor assessment
Your service involves health, financial, or other sensitive personal data

Privacy Criteria Overlap with GDPR

SOC 2 Privacy	GDPR Article	Alignment
P1 (Notice)	Art. 13-14	Direct — transparency requirements
P2 (Consent)	Art. 6-7	Direct — lawful basis and consent
P3 (Collection)	Art. 5(1)(b-c)	Direct — purpose limitation, minimization
P4 (Retention)	Art. 5(1)(e)	Direct — storage limitation
P5 (Access)	Art. 15-16	Direct — data subject rights
P6 (Disclosure)	Art. 33-34	Direct — breach notification
P7 (Quality)	Art. 5(1)(d)	Direct — accuracy principle
P8 (Monitoring)	Art. 5(2)	Direct — accountability principle

---

TSC Selection Guide

Question	If Yes, Include
Do you store/process customer data?	Security (required)
Do customers depend on your uptime?	Availability
Do you handle confidential business data?	Confidentiality
Is data accuracy critical to your service?	Processing Integrity
Do you process personal information?	Privacy

Common Combinations

Company Type	Typical TSC Selection
SaaS platform	Security + Availability
Data analytics	Security + Processing Integrity + Confidentiality
Healthcare SaaS	Security + Availability + Privacy + Confidentiality
Financial services	Security + Availability + Processing Integrity + Confidentiality
Infrastructure/PaaS	Security + Availability
HR/Payroll SaaS	Security + Availability + Privacy

---

Mapping to Other Frameworks

SOC 2 Criteria	ISO 27001	NIST CSF	HIPAA	PCI DSS
CC1 (Control Environment)	A.5 (Policies)	ID.GV	Administrative Safeguards	Req 12
CC2 (Communication)	A.5.1 (Policies)	ID.GV	Administrative Safeguards	Req 12
CC3 (Risk Assessment)	A.8.2 (Risk)	ID.RA	Risk Analysis	Req 12.2
CC4 (Monitoring)	A.8.34 (Monitoring)	DE.CM	Audit Controls	Req 10
CC5 (Control Activities)	A.5-A.8	PR	All Safeguards	Multiple
CC6 (Logical/Physical Access)	A.5.15, A.7	PR.AC	Access Controls	Req 7-9
CC7 (System Operations)	A.8.8, A.8.15	DE, RS	Technical Safeguards	Req 5-6, 11
CC8 (Change Management)	A.8.32	PR.IP	Change Management	Req 6.4
CC9 (Risk Mitigation)	A.5.19-5.22	ID.SC	Business Associate Agreements	Req 12.8
A1 (Availability)	A.8.13-14	PR.IP	Contingency Plan	Req 12.10
C1 (Confidentiality)	A.5.13-14, A.8.10-12	PR.DS	Access Controls	Req 3-4
PI1 (Processing Integrity)	A.8.24-25	PR.DS	Integrity Controls	Req 6.5
P1-P8 (Privacy)	A.5.34 (Privacy)	PR.PT	Privacy Rule	N/A

SOC 2 Type I vs Type II Comparison

Detailed guide for understanding the differences between SOC 2 Type I and Type II reports, selecting the right starting point, planning timelines, and managing the upgrade path.

---

Overview

Dimension	Type I	Type II
Full Name	SOC 2 Type I Report	SOC 2 Type II Report
What It Tests	Design of controls at a specific point in time	Design AND operating effectiveness over a period
Observation Period	None — single date	3-12 months (6 months typical)
Auditor Opinion	"Controls are suitably designed as of [date]"	"Controls are suitably designed and operating effectively for the period [start] to [end]"
Evidence Volume	Lower — policies, configs, descriptions	Higher — ongoing logs, tickets, samples across the period
Timeline to Complete	1-3 months (prep + audit)	6-15 months (prep + observation + audit)
Audit Fee Range	$20K-$50K	$30K-$100K+
Internal Cost	$50K-$150K (implementation + audit)	$100K-$300K+ (implementation + monitoring + audit)
Market Perception	"They have controls"	"Their controls actually work"
Validity	Snapshot — stale quickly	Covers a defined period; renewed annually

---

When to Start with Type I

Type I is the right starting point when:

1. First SOC 2 engagement — You need to validate control design before investing in a full observation period 2. Rapid market need — A customer or deal requires SOC 2 assurance within 3 months 3. Building the program — Your compliance program is new and you want a structured assessment 4. Budget constraints — Type I costs significantly less and helps justify future Type II investment 5. Control maturity is low — You are still implementing controls and need a milestone before Type II

Type I Limitations

Short shelf life — Enterprise customers often ask "When is your Type II coming?"
No operating proof — Does not demonstrate that controls work consistently
Annual deals may require Type II — Many procurement teams mandate Type II for contracts above a threshold
Repeated cost — If you plan to go Type II anyway, Type I is an additional expense

---

When to Go Directly to Type II

Skip Type I and go directly to Type II when:

1. Controls are already mature — You have been operating security controls for 6+ months 2. Customer requirements — Your target customers explicitly require Type II 3. Competitive pressure — Competitors already have Type II reports 4. Existing framework — You already have ISO 27001 or similar, and controls are mapped 5. Budget allows it — You can absorb the longer timeline and higher cost

---

Timeline Comparison

Type I Timeline (Typical: 3-4 Months)

Month 1-2: Gap Assessment + Remediation
├── Assess current controls against TSC
├── Implement missing controls
├── Document policies and procedures
└── Assign control owners

Month 3: Audit Execution
├── Auditor reviews control descriptions
├── Auditor inspects configurations and policies
├── Management provides representation letter
└── Report issued

Type II Timeline (Typical: 9-15 Months)

Month 1-3: Gap Assessment + Remediation
├── Assess current controls against TSC
├── Implement missing controls
├── Document policies and procedures
├── Set up evidence collection processes
└── Assign control owners

Month 4-9: Observation Period (6 months minimum)
├── Controls operate normally
├── Evidence is collected continuously
├── Periodic internal reviews
├── Address any control failures
└── Maintain documentation

Month 10-12: Audit Execution
├── Auditor tests operating effectiveness
├── Auditor samples evidence across the period
├── Exceptions documented and evaluated
├── Management provides representation letter
└── Report issued

Accelerated Type II (Bridge from Type I)

Month 1-3: Type I Audit
├── Complete Type I assessment
├── Receive Type I report
└── Begin observation period immediately

Month 4-9: Observation Period
├── Controls operate with evidence collection
├── Address any Type I findings
└── Prepare for Type II testing

Month 10-12: Type II Audit
├── Auditor tests operating effectiveness
└── Type II report issued

---

Cost Breakdown

Type I Costs

Cost Category	Range	Notes
Readiness assessment	$5K-$15K	Optional, but recommended for first-timers
Gap remediation	$10K-$50K	Depends on current maturity
Audit firm fees	$20K-$50K	Varies by scope, firm, and company size
Internal labor	$20K-$60K	Staff time for preparation and audit support
Tooling	$0-$20K	Compliance platforms, evidence management
Total	$55K-$195K

Type II Costs

Cost Category	Range	Notes
Readiness assessment	$5K-$15K	If not already done for Type I
Gap remediation	$15K-$75K	More thorough than Type I
Observation period monitoring	$10K-$30K	Internal effort for evidence collection
Audit firm fees	$30K-$100K+	Larger scope, more testing
Internal labor	$40K-$120K	Ongoing effort across the observation period
Tooling	$5K-$40K	Compliance platforms, automation tools
Total	$105K-$380K

Annual Renewal Costs (Type II)

Cost Category	Range
Audit firm fees	$25K-$80K
Internal labor	$30K-$80K
Tooling renewal	$5K-$30K
Remediation (if findings)	$5K-$30K
Total	$65K-$220K

---

Upgrade Path: Type I to Type II

Step 1: Receive Type I Report

Review the Type I report for:

Any exceptions or findings
Auditor recommendations
Control gaps identified during testing
Areas where design could be strengthened

Step 2: Address Type I Findings

Remediate any exceptions before starting the observation period
Strengthen control design based on auditor feedback
Document all changes and their effective dates

Step 3: Begin Observation Period

Start the clock on your observation period (minimum 3 months, recommend 6)
Implement evidence collection automation
Assign control owners and review cadences
Document any control changes during the period

Step 4: Maintain During Observation

Conduct monthly internal control reviews
Track and remediate any control failures
Keep evidence organized and timestamped
Prepare for auditor walkthroughs

Step 5: Type II Audit

Auditor tests a sample of evidence across the observation period
Auditor evaluates operating effectiveness
Exceptions are documented with management responses
Type II report issued

---

What Auditors Test Differently

Type I Testing

Test	What the Auditor Does
Inquiry	Asks control owners to describe how controls work
Inspection	Reviews policies, configurations, and documentation
Observation	May watch a control being executed (single instance)

Type II Additional Testing

Test	What the Auditor Does
Re-performance	Re-executes the control to verify it works correctly
Sampling	Selects samples from the full observation period
Walkthroughs	Traces a transaction end-to-end through all controls
Exception testing	Investigates any deviations found in samples
Consistency checks	Verifies controls operated the same way throughout the period

---

Report Distribution and Use

Who Receives the Report

SOC 2 reports are restricted-use documents under AICPA standards:

Your organization (the service organization)
Your auditor
User entities (customers) and their auditors
Prospective customers under NDA

Report Shelf Life

Report Type	Practical Validity	Market Expectation
Type I	6-12 months	Replace with Type II within 12 months
Type II	12 months from period end	Renew annually; gap > 3 months raises concerns

Bridge Letters

If there is a gap between your report period end and a customer's request date, you may issue a bridge letter (also called a gap letter) stating:

No material changes to the system since the report period
No known control failures since the report period
Management's assertion that controls continue to operate effectively

---

Decision Framework

START
  │
  ├─ Do you have existing controls operating for 6+ months?
  │   ├─ YES → Do customers require Type II specifically?
  │   │         ├─ YES → Go directly to Type II
  │   │         └─ NO  → Type I first (lower risk, validates design)
  │   └─ NO  → Type I first (build foundation)
  │
  ├─ Is there an urgent deal requiring SOC 2 in < 4 months?
  │   ├─ YES → Type I (fastest path to a report)
  │   └─ NO  → Evaluate maturity and go Type I or Type II
  │
  └─ Budget available for full Type II program?
      ├─ YES → Consider direct Type II if controls are mature
      └─ NO  → Type I first, budget Type II for next fiscal year

---

Common Mistakes in the Upgrade Path

Mistake	Consequence	Prevention
Starting observation before fixing Type I findings	Findings carry into Type II as exceptions	Remediate all Type I findings first
Choosing a 3-month observation period	Less convincing to customers; some reject < 6 months	Default to 6-month minimum observation
Changing auditors between Type I and Type II	New auditor must re-learn your environment; potential scope changes	Use the same firm for continuity
Not collecting evidence from day one of observation	Missing evidence for early-period controls	Start automated collection before observation begins
Treating the observation period as passive	Control failures go undetected until audit	Conduct monthly internal reviews during observation
Letting the Type I report expire before Type II is ready	Gap in coverage erodes customer confidence	Plan Type II timeline to overlap with Type I validity

#!/usr/bin/env python3
"""
SOC 2 Control Matrix Builder

Generates a SOC 2 control matrix from selected Trust Service Criteria categories.
Outputs in markdown, JSON, or CSV format.

Usage:
    python control_matrix_builder.py --categories security --format md
    python control_matrix_builder.py --categories security,availability --format json
    python control_matrix_builder.py --categories security,availability,confidentiality,processing-integrity,privacy --format csv
"""

import argparse
import csv
import io
import json
import sys
from typing import Dict, List, Any


# Trust Service Criteria control definitions
TSC_CONTROLS: Dict[str, Dict[str, Any]] = {
    "security": {
        "name": "Security (Common Criteria)",
        "controls": [
            {
                "id": "SEC-001",
                "tsc": "CC1.1",
                "description": "Management demonstrates commitment to integrity and ethical values",
                "type": "Preventive",
                "frequency": "Annual",
                "evidence": "Code of conduct, ethics policy, signed acknowledgments",
            },
            {
                "id": "SEC-002",
                "tsc": "CC1.2",
                "description": "Board of directors demonstrates independence and exercises oversight",
                "type": "Preventive",
                "frequency": "Quarterly",
                "evidence": "Board meeting minutes, oversight committee charters",
            },
            {
                "id": "SEC-003",
                "tsc": "CC1.3",
                "description": "Management establishes organizational structure, reporting lines, and authorities",
                "type": "Preventive",
                "frequency": "Annual",
                "evidence": "Org charts, RACI matrices, role descriptions",
            },
            {
                "id": "SEC-004",
                "tsc": "CC1.4",
                "description": "Organization demonstrates commitment to attract, develop, and retain competent individuals",
                "type": "Preventive",
                "frequency": "Annual",
                "evidence": "Training records, competency assessments, HR policies",
            },
            {
                "id": "SEC-005",
                "tsc": "CC1.5",
                "description": "Organization holds individuals accountable for internal control responsibilities",
                "type": "Preventive",
                "frequency": "Annual",
                "evidence": "Performance reviews, disciplinary policy, accountability matrix",
            },
            {
                "id": "SEC-006",
                "tsc": "CC2.1",
                "description": "Organization obtains and generates relevant quality information to support internal control",
                "type": "Detective",
                "frequency": "Continuous",
                "evidence": "Information classification policy, data flow diagrams",
            },
            {
                "id": "SEC-007",
                "tsc": "CC2.2",
                "description": "Organization internally communicates objectives and responsibilities for internal control",
                "type": "Preventive",
                "frequency": "Quarterly",
                "evidence": "Internal communications, policy distribution records, training materials",
            },
            {
                "id": "SEC-008",
                "tsc": "CC2.3",
                "description": "Organization communicates with external parties regarding matters affecting internal control",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Customer notifications, external communication policy, incident notices",
            },
            {
                "id": "SEC-009",
                "tsc": "CC3.1",
                "description": "Organization specifies objectives to identify and assess risks",
                "type": "Preventive",
                "frequency": "Annual",
                "evidence": "Risk assessment methodology, risk register, risk appetite statement",
            },
            {
                "id": "SEC-010",
                "tsc": "CC3.2",
                "description": "Organization identifies and analyzes risks to achievement of objectives",
                "type": "Detective",
                "frequency": "Annual",
                "evidence": "Risk assessment report, threat modeling documentation",
            },
            {
                "id": "SEC-011",
                "tsc": "CC3.3",
                "description": "Organization considers potential for fraud in assessing risks",
                "type": "Detective",
                "frequency": "Annual",
                "evidence": "Fraud risk assessment, anti-fraud controls documentation",
            },
            {
                "id": "SEC-012",
                "tsc": "CC3.4",
                "description": "Organization identifies and assesses changes that could impact internal control",
                "type": "Detective",
                "frequency": "Quarterly",
                "evidence": "Change impact assessments, environmental scan reports",
            },
            {
                "id": "SEC-013",
                "tsc": "CC4.1",
                "description": "Organization selects and performs ongoing and separate monitoring evaluations",
                "type": "Detective",
                "frequency": "Continuous",
                "evidence": "Monitoring dashboards, automated alert configurations, review logs",
            },
            {
                "id": "SEC-014",
                "tsc": "CC4.2",
                "description": "Organization evaluates and communicates internal control deficiencies",
                "type": "Corrective",
                "frequency": "Quarterly",
                "evidence": "Deficiency tracking log, management reports, remediation plans",
            },
            {
                "id": "SEC-015",
                "tsc": "CC5.1",
                "description": "Organization selects and develops control activities that mitigate risks",
                "type": "Preventive",
                "frequency": "Annual",
                "evidence": "Control matrix, risk treatment plans, control design documentation",
            },
            {
                "id": "SEC-016",
                "tsc": "CC5.2",
                "description": "Organization selects and develops general control activities over technology",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "IT general controls documentation, technology policies",
            },
            {
                "id": "SEC-017",
                "tsc": "CC5.3",
                "description": "Organization deploys control activities through policies and procedures",
                "type": "Preventive",
                "frequency": "Annual",
                "evidence": "Policy library, procedure documents, acknowledgment records",
            },
            {
                "id": "SEC-018",
                "tsc": "CC6.1",
                "description": "Logical access security controls over protected information assets",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Access control policy, IAM configuration, SSO/MFA settings",
            },
            {
                "id": "SEC-019",
                "tsc": "CC6.2",
                "description": "User access provisioning based on role and business need",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Provisioning tickets, role matrix, access request approvals",
            },
            {
                "id": "SEC-020",
                "tsc": "CC6.3",
                "description": "User access removal upon termination or role change",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Deprovisioning tickets, termination checklists, access removal logs",
            },
            {
                "id": "SEC-021",
                "tsc": "CC6.4",
                "description": "Periodic access reviews to validate appropriateness",
                "type": "Detective",
                "frequency": "Quarterly",
                "evidence": "Access review reports, user entitlement listings, review sign-offs",
            },
            {
                "id": "SEC-022",
                "tsc": "CC6.5",
                "description": "Physical access restrictions to facilities and protected assets",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Badge access logs, visitor logs, physical security configuration",
            },
            {
                "id": "SEC-023",
                "tsc": "CC6.6",
                "description": "Encryption of data in transit and at rest",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "TLS configuration, encryption settings, certificate inventory",
            },
            {
                "id": "SEC-024",
                "tsc": "CC6.7",
                "description": "Restrictions on data transmission and movement",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "DLP configuration, network segmentation, firewall rules",
            },
            {
                "id": "SEC-025",
                "tsc": "CC6.8",
                "description": "Controls to prevent or detect unauthorized software",
                "type": "Detective",
                "frequency": "Continuous",
                "evidence": "Endpoint protection config, software whitelist, malware scan reports",
            },
            {
                "id": "SEC-026",
                "tsc": "CC7.1",
                "description": "Vulnerability identification and management",
                "type": "Detective",
                "frequency": "Weekly",
                "evidence": "Vulnerability scan reports, remediation SLAs, patch records",
            },
            {
                "id": "SEC-027",
                "tsc": "CC7.2",
                "description": "Monitoring for anomalies and security events",
                "type": "Detective",
                "frequency": "Continuous",
                "evidence": "SIEM configuration, alert rules, monitoring dashboards",
            },
            {
                "id": "SEC-028",
                "tsc": "CC7.3",
                "description": "Security event evaluation and incident classification",
                "type": "Detective",
                "frequency": "Continuous",
                "evidence": "Incident classification criteria, triage procedures, event logs",
            },
            {
                "id": "SEC-029",
                "tsc": "CC7.4",
                "description": "Incident response execution and recovery",
                "type": "Corrective",
                "frequency": "Continuous",
                "evidence": "Incident response plan, incident tickets, postmortem reports",
            },
            {
                "id": "SEC-030",
                "tsc": "CC7.5",
                "description": "Incident recovery and lessons learned",
                "type": "Corrective",
                "frequency": "Continuous",
                "evidence": "Recovery records, lessons learned documentation, plan updates",
            },
            {
                "id": "SEC-031",
                "tsc": "CC8.1",
                "description": "Change management authorization and testing",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Change tickets, approval records, test results, deployment logs",
            },
            {
                "id": "SEC-032",
                "tsc": "CC9.1",
                "description": "Vendor and business partner risk management",
                "type": "Preventive",
                "frequency": "Annual",
                "evidence": "Vendor risk assessments, vendor register, SOC 2 reports from vendors",
            },
            {
                "id": "SEC-033",
                "tsc": "CC9.2",
                "description": "Risk mitigation through insurance and other transfer mechanisms",
                "type": "Preventive",
                "frequency": "Annual",
                "evidence": "Insurance policies, risk transfer documentation",
            },
        ],
    },
    "availability": {
        "name": "Availability",
        "controls": [
            {
                "id": "AVL-001",
                "tsc": "A1.1",
                "description": "Capacity management and infrastructure scaling",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Capacity monitoring dashboards, scaling policies, resource utilization reports",
            },
            {
                "id": "AVL-002",
                "tsc": "A1.1",
                "description": "System performance monitoring and SLA tracking",
                "type": "Detective",
                "frequency": "Continuous",
                "evidence": "Uptime reports, SLA dashboards, performance metrics",
            },
            {
                "id": "AVL-003",
                "tsc": "A1.2",
                "description": "Data backup procedures and verification",
                "type": "Preventive",
                "frequency": "Daily",
                "evidence": "Backup logs, backup success/failure reports, retention configuration",
            },
            {
                "id": "AVL-004",
                "tsc": "A1.2",
                "description": "Disaster recovery planning and documentation",
                "type": "Preventive",
                "frequency": "Annual",
                "evidence": "DR plan, BCP documentation, recovery procedures",
            },
            {
                "id": "AVL-005",
                "tsc": "A1.2",
                "description": "Business continuity management and communication",
                "type": "Preventive",
                "frequency": "Annual",
                "evidence": "BCP plan, communication tree, emergency contacts",
            },
            {
                "id": "AVL-006",
                "tsc": "A1.3",
                "description": "Disaster recovery testing and validation",
                "type": "Detective",
                "frequency": "Annual",
                "evidence": "DR test results, RTO/RPO measurements, test reports",
            },
            {
                "id": "AVL-007",
                "tsc": "A1.3",
                "description": "Failover testing and redundancy validation",
                "type": "Detective",
                "frequency": "Quarterly",
                "evidence": "Failover test records, redundancy configuration, test results",
            },
        ],
    },
    "confidentiality": {
        "name": "Confidentiality",
        "controls": [
            {
                "id": "CON-001",
                "tsc": "C1.1",
                "description": "Data classification and labeling policy",
                "type": "Preventive",
                "frequency": "Annual",
                "evidence": "Data classification policy, labeling standards, data inventory",
            },
            {
                "id": "CON-002",
                "tsc": "C1.1",
                "description": "Confidential data inventory and mapping",
                "type": "Detective",
                "frequency": "Quarterly",
                "evidence": "Data inventory, data flow diagrams, system classification",
            },
            {
                "id": "CON-003",
                "tsc": "C1.2",
                "description": "Encryption of confidential data at rest and in transit",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Encryption configuration, TLS settings, key management procedures",
            },
            {
                "id": "CON-004",
                "tsc": "C1.2",
                "description": "Access restrictions to confidential information",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Access control lists, need-to-know policy, access review records",
            },
            {
                "id": "CON-005",
                "tsc": "C1.2",
                "description": "Data loss prevention controls",
                "type": "Detective",
                "frequency": "Continuous",
                "evidence": "DLP configuration, DLP alerts/incidents, exception approvals",
            },
            {
                "id": "CON-006",
                "tsc": "C1.3",
                "description": "Secure data disposal and media sanitization",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Disposal procedures, sanitization certificates, destruction logs",
            },
            {
                "id": "CON-007",
                "tsc": "C1.3",
                "description": "Data retention enforcement and schedule compliance",
                "type": "Preventive",
                "frequency": "Quarterly",
                "evidence": "Retention schedule, deletion logs, retention compliance reports",
            },
        ],
    },
    "processing-integrity": {
        "name": "Processing Integrity",
        "controls": [
            {
                "id": "PRI-001",
                "tsc": "PI1.1",
                "description": "Input validation and data accuracy controls",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Validation rules, input sanitization config, error handling logs",
            },
            {
                "id": "PRI-002",
                "tsc": "PI1.1",
                "description": "Output verification and data integrity checks",
                "type": "Detective",
                "frequency": "Continuous",
                "evidence": "Reconciliation reports, checksum verification, output validation logs",
            },
            {
                "id": "PRI-003",
                "tsc": "PI1.2",
                "description": "Transaction completeness monitoring",
                "type": "Detective",
                "frequency": "Continuous",
                "evidence": "Transaction logs, reconciliation reports, completeness dashboards",
            },
            {
                "id": "PRI-004",
                "tsc": "PI1.2",
                "description": "Error handling and exception management",
                "type": "Corrective",
                "frequency": "Continuous",
                "evidence": "Error logs, exception handling procedures, retry mechanisms",
            },
            {
                "id": "PRI-005",
                "tsc": "PI1.3",
                "description": "Processing timeliness and SLA monitoring",
                "type": "Detective",
                "frequency": "Continuous",
                "evidence": "SLA reports, processing time metrics, batch job monitoring",
            },
            {
                "id": "PRI-006",
                "tsc": "PI1.4",
                "description": "Processing authorization and segregation of duties",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Authorization matrix, SoD controls, approval workflows",
            },
        ],
    },
    "privacy": {
        "name": "Privacy",
        "controls": [
            {
                "id": "PRV-001",
                "tsc": "P1.1",
                "description": "Privacy notice publication and data collection transparency",
                "type": "Preventive",
                "frequency": "Annual",
                "evidence": "Privacy policy, data collection notices, purpose statements",
            },
            {
                "id": "PRV-002",
                "tsc": "P2.1",
                "description": "Consent management and preference tracking",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Consent records, opt-in/opt-out mechanisms, preference center",
            },
            {
                "id": "PRV-003",
                "tsc": "P3.1",
                "description": "Data minimization and lawful collection",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Data collection audit, purpose limitation documentation, lawful basis records",
            },
            {
                "id": "PRV-004",
                "tsc": "P4.1",
                "description": "Purpose limitation and use restrictions",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Data use policy, purpose limitation controls, access restrictions",
            },
            {
                "id": "PRV-005",
                "tsc": "P4.2",
                "description": "Data retention schedules and disposal procedures",
                "type": "Preventive",
                "frequency": "Quarterly",
                "evidence": "Retention schedule, deletion logs, disposal certificates",
            },
            {
                "id": "PRV-006",
                "tsc": "P5.1",
                "description": "Data subject access request (DSAR) processing",
                "type": "Corrective",
                "frequency": "Continuous",
                "evidence": "DSAR log, response records, processing timelines",
            },
            {
                "id": "PRV-007",
                "tsc": "P5.2",
                "description": "Data correction and rectification rights",
                "type": "Corrective",
                "frequency": "Continuous",
                "evidence": "Correction request records, data update logs",
            },
            {
                "id": "PRV-008",
                "tsc": "P6.1",
                "description": "Third-party data sharing controls and notifications",
                "type": "Preventive",
                "frequency": "Continuous",
                "evidence": "Data sharing agreements, third-party inventory, DPAs",
            },
            {
                "id": "PRV-009",
                "tsc": "P6.2",
                "description": "Breach notification procedures",
                "type": "Corrective",
                "frequency": "Continuous",
                "evidence": "Breach response plan, notification templates, incident records",
            },
            {
                "id": "PRV-010",
                "tsc": "P7.1",
                "description": "Data quality and accuracy verification",
                "type": "Detective",
                "frequency": "Quarterly",
                "evidence": "Data quality reports, accuracy checks, correction logs",
            },
            {
                "id": "PRV-011",
                "tsc": "P8.1",
                "description": "Privacy program monitoring and compliance reviews",
                "type": "Detective",
                "frequency": "Quarterly",
                "evidence": "Privacy audits, compliance dashboards, complaint tracking",
            },
        ],
    },
}

VALID_CATEGORIES = list(TSC_CONTROLS.keys())


def build_matrix(categories: List[str]) -> List[Dict[str, str]]:
    """Build a control matrix for the selected TSC categories."""
    matrix = []
    for cat in categories:
        if cat not in TSC_CONTROLS:
            continue
        cat_data = TSC_CONTROLS[cat]
        for ctrl in cat_data["controls"]:
            matrix.append(
                {
                    "control_id": ctrl["id"],
                    "tsc_criteria": ctrl["tsc"],
                    "category": cat_data["name"],
                    "description": ctrl["description"],
                    "control_type": ctrl["type"],
                    "frequency": ctrl["frequency"],
                    "evidence_required": ctrl["evidence"],
                    "owner": "TBD",
                    "status": "Not Started",
                }
            )
    return matrix


def format_markdown(matrix: List[Dict[str, str]]) -> str:
    """Format control matrix as markdown table."""
    lines = ["# SOC 2 Control Matrix", ""]
    lines.append(
        "| Control ID | TSC | Category | Description | Type | Frequency | Evidence | Owner | Status |"
    )
    lines.append(
        "|------------|-----|----------|-------------|------|-----------|----------|-------|--------|"
    )
    for row in matrix:
        lines.append(
            "| {control_id} | {tsc_criteria} | {category} | {description} | {control_type} | {frequency} | {evidence_required} | {owner} | {status} |".format(
                **row
            )
        )
    lines.append("")
    lines.append(f"**Total Controls:** {len(matrix)}")
    return "\n".join(lines)


def format_csv(matrix: List[Dict[str, str]]) -> str:
    """Format control matrix as CSV."""
    output = io.StringIO()
    if not matrix:
        return ""
    writer = csv.DictWriter(output, fieldnames=matrix[0].keys())
    writer.writeheader()
    writer.writerows(matrix)
    return output.getvalue()


def format_json(matrix: List[Dict[str, str]]) -> str:
    """Format control matrix as JSON."""
    return json.dumps({"controls": matrix, "total": len(matrix)}, indent=2)


def main():
    parser = argparse.ArgumentParser(
        description="SOC 2 Control Matrix Builder — generates control matrices from selected Trust Service Criteria categories."
    )
    parser.add_argument(
        "--categories",
        type=str,
        required=True,
        help=f"Comma-separated TSC categories: {','.join(VALID_CATEGORIES)}",
    )
    parser.add_argument(
        "--format",
        type=str,
        choices=["md", "json", "csv"],
        default="md",
        help="Output format (default: md)",
    )
    parser.add_argument(
        "--json",
        action="store_true",
        help="Shorthand for --format json",
    )

    args = parser.parse_args()

    # Parse categories
    categories = [c.strip().lower() for c in args.categories.split(",")]
    invalid = [c for c in categories if c not in VALID_CATEGORIES]
    if invalid:
        print(
            f"Error: Invalid categories: {', '.join(invalid)}. Valid options: {', '.join(VALID_CATEGORIES)}",
            file=sys.stderr,
        )
        sys.exit(1)

    # Build matrix
    matrix = build_matrix(categories)

    if not matrix:
        print("No controls found for the selected categories.", file=sys.stderr)
        sys.exit(1)

    # Output
    fmt = "json" if args.json else args.format
    if fmt == "md":
        print(format_markdown(matrix))
    elif fmt == "json":
        print(format_json(matrix))
    elif fmt == "csv":
        print(format_csv(matrix))


if __name__ == "__main__":
    main()

#!/usr/bin/env python3
"""
SOC 2 Evidence Tracker

Tracks evidence collection status per control in a SOC 2 control matrix.
Reads a JSON control matrix (from control_matrix_builder.py) and reports
collection completeness, overdue items, and readiness scoring.

Usage:
    python evidence_tracker.py --matrix controls.json --status
    python evidence_tracker.py --matrix controls.json --status --json
"""

import argparse
import json
import sys
from datetime import datetime
from typing import Dict, List, Any


# Evidence status classifications
EVIDENCE_STATUSES = {
    "collected": "Evidence gathered and verified",
    "pending": "Evidence identified but not yet collected",
    "overdue": "Evidence past its collection deadline",
    "not_started": "No evidence collection initiated",
    "not_applicable": "Control not applicable to the environment",
}

# Expected evidence fields for a well-formed control entry
REQUIRED_FIELDS = ["control_id", "tsc_criteria", "description", "evidence_required"]


def load_matrix(filepath: str) -> List[Dict[str, Any]]:
    """Load a control matrix from a JSON file."""
    try:
        with open(filepath, "r") as f:
            data = json.load(f)
    except FileNotFoundError:
        print(f"Error: File not found: {filepath}", file=sys.stderr)
        sys.exit(1)
    except json.JSONDecodeError as e:
        print(f"Error: Invalid JSON in {filepath}: {e}", file=sys.stderr)
        sys.exit(1)

    # Accept both {"controls": [...]} and plain [...]
    if isinstance(data, dict) and "controls" in data:
        controls = data["controls"]
    elif isinstance(data, list):
        controls = data
    else:
        print(
            "Error: Expected JSON with 'controls' array or a plain array.",
            file=sys.stderr,
        )
        sys.exit(1)

    return controls


def classify_evidence_status(control: Dict[str, Any]) -> str:
    """Classify the evidence collection status for a control."""
    status = control.get("status", "Not Started").lower().strip()
    evidence_date = control.get("evidence_date", "")

    if status in ("not_applicable", "n/a", "not applicable"):
        return "not_applicable"
    if status in ("collected", "complete", "done"):
        return "collected"
    if status in ("pending", "in progress", "in_progress"):
        # Check if overdue
        if evidence_date:
            try:
                due = datetime.strptime(evidence_date, "%Y-%m-%d")
                if due < datetime.now():
                    return "overdue"
            except ValueError:
                pass
        return "pending"
    if status in ("overdue", "late"):
        return "overdue"

    return "not_started"


def generate_status_report(controls: List[Dict[str, Any]]) -> Dict[str, Any]:
    """Generate an evidence collection status report."""
    total = len(controls)
    status_counts = {s: 0 for s in EVIDENCE_STATUSES}
    by_category: Dict[str, Dict[str, int]] = {}
    issues: List[Dict[str, str]] = []

    for ctrl in controls:
        status = classify_evidence_status(ctrl)
        status_counts[status] = status_counts.get(status, 0) + 1

        category = ctrl.get("category", "Unknown")
        if category not in by_category:
            by_category[category] = {s: 0 for s in EVIDENCE_STATUSES}
        by_category[category][status] += 1

        # Flag issues
        if status == "overdue":
            issues.append(
                {
                    "control_id": ctrl.get("control_id", "N/A"),
                    "tsc_criteria": ctrl.get("tsc_criteria", "N/A"),
                    "description": ctrl.get("description", "N/A"),
                    "issue": "Evidence collection overdue",
                    "evidence_date": ctrl.get("evidence_date", "N/A"),
                }
            )
        elif status == "not_started":
            issues.append(
                {
                    "control_id": ctrl.get("control_id", "N/A"),
                    "tsc_criteria": ctrl.get("tsc_criteria", "N/A"),
                    "description": ctrl.get("description", "N/A"),
                    "issue": "Evidence collection not started",
                }
            )

        # Check for missing required fields
        missing = [f for f in REQUIRED_FIELDS if f not in ctrl or not ctrl[f]]
        if missing:
            issues.append(
                {
                    "control_id": ctrl.get("control_id", "N/A"),
                    "issue": f"Missing fields: {', '.join(missing)}",
                }
            )

    # Calculate readiness score
    applicable = total - status_counts.get("not_applicable", 0)
    collected = status_counts.get("collected", 0)
    readiness_pct = round((collected / applicable * 100), 1) if applicable > 0 else 0.0

    if readiness_pct >= 90:
        readiness_rating = "Audit Ready"
    elif readiness_pct >= 75:
        readiness_rating = "Minor Gaps"
    elif readiness_pct >= 50:
        readiness_rating = "Significant Gaps"
    else:
        readiness_rating = "Not Ready"

    return {
        "summary": {
            "total_controls": total,
            "status_breakdown": status_counts,
            "readiness_score": readiness_pct,
            "readiness_rating": readiness_rating,
            "report_date": datetime.now().strftime("%Y-%m-%d"),
        },
        "by_category": by_category,
        "issues": issues,
    }


def format_status_text(report: Dict[str, Any]) -> str:
    """Format the status report as human-readable text."""
    lines = ["=" * 60, "SOC 2 Evidence Collection Status Report", "=" * 60, ""]

    summary = report["summary"]
    lines.append(f"Report Date: {summary['report_date']}")
    lines.append(f"Total Controls: {summary['total_controls']}")
    lines.append(
        f"Readiness Score: {summary['readiness_score']}% ({summary['readiness_rating']})"
    )
    lines.append("")

    # Status breakdown
    lines.append("--- Status Breakdown ---")
    for status, count in summary["status_breakdown"].items():
        label = EVIDENCE_STATUSES.get(status, status)
        lines.append(f"  {status:15s}: {count:3d}  ({label})")
    lines.append("")

    # By category
    lines.append("--- By Category ---")
    for cat, statuses in report["by_category"].items():
        cat_total = sum(statuses.values())
        cat_collected = statuses.get("collected", 0)
        cat_pct = round(cat_collected / cat_total * 100, 1) if cat_total > 0 else 0
        lines.append(f"  {cat}: {cat_collected}/{cat_total} collected ({cat_pct}%)")
    lines.append("")

    # Issues
    if report["issues"]:
        lines.append(f"--- Issues ({len(report['issues'])}) ---")
        for issue in report["issues"]:
            ctrl_id = issue.get("control_id", "N/A")
            desc = issue.get("issue", "Unknown issue")
            lines.append(f"  [{ctrl_id}] {desc}")
    else:
        lines.append("--- No Issues Found ---")

    lines.append("")
    return "\n".join(lines)


def main():
    parser = argparse.ArgumentParser(
        description="SOC 2 Evidence Tracker — tracks evidence collection status per control."
    )
    parser.add_argument(
        "--matrix",
        type=str,
        required=True,
        help="Path to JSON control matrix file (from control_matrix_builder.py)",
    )
    parser.add_argument(
        "--status",
        action="store_true",
        help="Generate evidence collection status report",
    )
    parser.add_argument(
        "--json",
        action="store_true",
        help="Output in JSON format",
    )

    args = parser.parse_args()

    if not args.status:
        parser.print_help()
        print("\nError: --status flag is required.", file=sys.stderr)
        sys.exit(1)

    controls = load_matrix(args.matrix)
    report = generate_status_report(controls)

    if args.json:
        print(json.dumps(report, indent=2))
    else:
        print(format_status_text(report))


if __name__ == "__main__":
    main()

#!/usr/bin/env python3
"""
SOC 2 Gap Analyzer

Analyzes current controls against SOC 2 Trust Service Criteria requirements
and identifies gaps. Supports both Type I (design) and Type II (design +
operating effectiveness) analysis.

Usage:
    python gap_analyzer.py --controls current_controls.json --type type1
    python gap_analyzer.py --controls current_controls.json --type type2 --json
"""

import argparse
import json
import sys
from datetime import datetime
from typing import Dict, List, Any, Tuple


# Minimum required TSC criteria coverage per category
REQUIRED_TSC = {
    "security": {
        "CC1.1": "Integrity and ethical values",
        "CC1.2": "Board oversight",
        "CC1.3": "Organizational structure",
        "CC1.4": "Competence commitment",
        "CC1.5": "Accountability",
        "CC2.1": "Information quality",
        "CC2.2": "Internal communication",
        "CC2.3": "External communication",
        "CC3.1": "Risk objectives",
        "CC3.2": "Risk identification",
        "CC3.3": "Fraud risk consideration",
        "CC3.4": "Change risk assessment",
        "CC4.1": "Monitoring evaluations",
        "CC4.2": "Deficiency communication",
        "CC5.1": "Control activities selection",
        "CC5.2": "Technology controls",
        "CC5.3": "Policy deployment",
        "CC6.1": "Logical access security",
        "CC6.2": "Access provisioning",
        "CC6.3": "Access removal",
        "CC6.4": "Access review",
        "CC6.5": "Physical access",
        "CC6.6": "Encryption",
        "CC6.7": "Data transmission restrictions",
        "CC6.8": "Unauthorized software prevention",
        "CC7.1": "Vulnerability management",
        "CC7.2": "Anomaly monitoring",
        "CC7.3": "Event evaluation",
        "CC7.4": "Incident response",
        "CC7.5": "Incident recovery",
        "CC8.1": "Change management",
        "CC9.1": "Vendor risk management",
        "CC9.2": "Risk mitigation/transfer",
    },
    "availability": {
        "A1.1": "Capacity and performance management",
        "A1.2": "Backup and recovery",
        "A1.3": "Recovery testing",
    },
    "confidentiality": {
        "C1.1": "Confidential data identification",
        "C1.2": "Confidential data protection",
        "C1.3": "Confidential data disposal",
    },
    "processing-integrity": {
        "PI1.1": "Processing accuracy",
        "PI1.2": "Processing completeness",
        "PI1.3": "Processing timeliness",
        "PI1.4": "Processing authorization",
    },
    "privacy": {
        "P1.1": "Privacy notice",
        "P2.1": "Choice and consent",
        "P3.1": "Data collection",
        "P4.1": "Use and retention",
        "P4.2": "Disposal",
        "P5.1": "Access rights",
        "P5.2": "Correction rights",
        "P6.1": "Disclosure controls",
        "P6.2": "Breach notification",
        "P7.1": "Data quality",
        "P8.1": "Privacy monitoring",
    },
}

# Type II additional checks
TYPE2_CHECKS = [
    {
        "check": "evidence_period",
        "description": "Evidence covers the full observation period",
        "severity": "critical",
    },
    {
        "check": "operating_consistency",
        "description": "Control operated consistently throughout the period",
        "severity": "critical",
    },
    {
        "check": "exception_handling",
        "description": "Exceptions are documented and addressed",
        "severity": "high",
    },
    {
        "check": "owner_accountability",
        "description": "Control owners documented and accountable",
        "severity": "medium",
    },
    {
        "check": "evidence_timestamps",
        "description": "Evidence has timestamps within the observation period",
        "severity": "high",
    },
    {
        "check": "frequency_adherence",
        "description": "Control executed at the specified frequency",
        "severity": "critical",
    },
]


def load_controls(filepath: str) -> List[Dict[str, Any]]:
    """Load current controls from a JSON file."""
    try:
        with open(filepath, "r") as f:
            data = json.load(f)
    except FileNotFoundError:
        print(f"Error: File not found: {filepath}", file=sys.stderr)
        sys.exit(1)
    except json.JSONDecodeError as e:
        print(f"Error: Invalid JSON in {filepath}: {e}", file=sys.stderr)
        sys.exit(1)

    if isinstance(data, dict) and "controls" in data:
        return data["controls"]
    elif isinstance(data, list):
        return data
    else:
        print(
            "Error: Expected JSON with 'controls' array or a plain array.",
            file=sys.stderr,
        )
        sys.exit(1)


def detect_categories(controls: List[Dict[str, Any]]) -> List[str]:
    """Detect which TSC categories are represented in the controls."""
    tsc_values = set()
    for ctrl in controls:
        tsc = ctrl.get("tsc_criteria", "")
        if tsc:
            tsc_values.add(tsc)

    categories = set()
    for cat, criteria in REQUIRED_TSC.items():
        for tsc_id in criteria:
            if tsc_id in tsc_values:
                categories.add(cat)
                break

    # Always include security as it's required
    categories.add("security")
    return sorted(categories)


def analyze_coverage(
    controls: List[Dict[str, Any]], categories: List[str]
) -> Tuple[List[Dict], List[Dict], List[Dict]]:
    """Analyze TSC coverage and identify gaps."""
    # Map existing controls by TSC criteria
    covered_tsc = {}
    for ctrl in controls:
        tsc = ctrl.get("tsc_criteria", "")
        if tsc:
            if tsc not in covered_tsc:
                covered_tsc[tsc] = []
            covered_tsc[tsc].append(ctrl)

    gaps = []
    partial = []
    covered = []

    for cat in categories:
        if cat not in REQUIRED_TSC:
            continue
        for tsc_id, tsc_desc in REQUIRED_TSC[cat].items():
            if tsc_id not in covered_tsc:
                gaps.append(
                    {
                        "tsc_criteria": tsc_id,
                        "description": tsc_desc,
                        "category": cat,
                        "gap_type": "missing",
                        "severity": "critical" if cat == "security" else "high",
                        "remediation": f"Implement control(s) addressing {tsc_id}: {tsc_desc}",
                    }
                )
            else:
                ctrls = covered_tsc[tsc_id]
                # Check for partial implementation
                has_issues = False
                for ctrl in ctrls:
                    status = ctrl.get("status", "").lower()
                    if status in ("not started", "not_started", ""):
                        has_issues = True
                    owner = ctrl.get("owner", "TBD")
                    if owner in ("TBD", "", "N/A"):
                        has_issues = True

                if has_issues:
                    partial.append(
                        {
                            "tsc_criteria": tsc_id,
                            "description": tsc_desc,
                            "category": cat,
                            "gap_type": "partial",
                            "severity": "medium",
                            "controls": [c.get("control_id", "N/A") for c in ctrls],
                            "remediation": f"Complete implementation and assign owners for {tsc_id} controls",
                        }
                    )
                else:
                    covered.append(
                        {
                            "tsc_criteria": tsc_id,
                            "description": tsc_desc,
                            "category": cat,
                            "controls": [c.get("control_id", "N/A") for c in ctrls],
                        }
                    )

    return gaps, partial, covered


def analyze_type2_gaps(controls: List[Dict[str, Any]]) -> List[Dict[str, Any]]:
    """Additional gap analysis for Type II operating effectiveness."""
    type2_gaps = []

    for ctrl in controls:
        ctrl_id = ctrl.get("control_id", "N/A")
        issues = []

        # Check for evidence date coverage
        evidence_date = ctrl.get("evidence_date", "")
        if not evidence_date:
            issues.append(
                {
                    "check": "evidence_period",
                    "severity": "critical",
                    "detail": "No evidence date recorded",
                }
            )

        # Check owner assignment
        owner = ctrl.get("owner", "TBD")
        if owner in ("TBD", "", "N/A"):
            issues.append(
                {
                    "check": "owner_accountability",
                    "severity": "medium",
                    "detail": "No control owner assigned",
                }
            )

        # Check status for operating evidence
        status = ctrl.get("status", "").lower()
        if status not in ("collected", "complete", "done"):
            issues.append(
                {
                    "check": "operating_consistency",
                    "severity": "critical",
                    "detail": f"Control status is '{ctrl.get('status', 'Not Started')}' — operating evidence needed",
                }
            )

        # Check frequency is defined
        frequency = ctrl.get("frequency", "")
        if not frequency:
            issues.append(
                {
                    "check": "frequency_adherence",
                    "severity": "critical",
                    "detail": "No control frequency defined",
                }
            )

        if issues:
            type2_gaps.append(
                {
                    "control_id": ctrl_id,
                    "tsc_criteria": ctrl.get("tsc_criteria", "N/A"),
                    "description": ctrl.get("description", "N/A"),
                    "issues": issues,
                }
            )

    return type2_gaps


def build_report(
    controls: List[Dict[str, Any]],
    audit_type: str,
    categories: List[str],
    gaps: List[Dict],
    partial: List[Dict],
    covered: List[Dict],
    type2_gaps: List[Dict],
) -> Dict[str, Any]:
    """Build the complete gap analysis report."""
    total_criteria = sum(
        len(REQUIRED_TSC[c]) for c in categories if c in REQUIRED_TSC
    )
    covered_count = len(covered)
    gap_count = len(gaps)
    partial_count = len(partial)

    coverage_pct = (
        round(covered_count / total_criteria * 100, 1) if total_criteria > 0 else 0
    )
    critical_gaps = len([g for g in gaps if g.get("severity") == "critical"])

    if coverage_pct >= 90 and critical_gaps == 0:
        readiness = "Ready"
    elif coverage_pct >= 75:
        readiness = "Near Ready — address gaps before audit"
    elif coverage_pct >= 50:
        readiness = "Significant work needed"
    else:
        readiness = "Not ready — major build-out required"

    report = {
        "report_metadata": {
            "audit_type": audit_type,
            "categories_assessed": categories,
            "report_date": datetime.now().strftime("%Y-%m-%d"),
            "total_controls_assessed": len(controls),
        },
        "coverage_summary": {
            "total_criteria": total_criteria,
            "covered": covered_count,
            "partially_covered": partial_count,
            "missing": gap_count,
            "coverage_percentage": coverage_pct,
            "critical_gaps": critical_gaps,
            "readiness_assessment": readiness,
        },
        "gaps": gaps,
        "partial_implementations": partial,
        "covered_criteria": covered,
    }

    if audit_type == "type2":
        type2_issue_count = sum(len(g["issues"]) for g in type2_gaps)
        report["type2_operating_gaps"] = {
            "controls_with_issues": len(type2_gaps),
            "total_issues": type2_issue_count,
            "details": type2_gaps,
        }

    return report


def format_text_report(report: Dict[str, Any]) -> str:
    """Format the gap analysis report as human-readable text."""
    lines = [
        "=" * 65,
        "SOC 2 Gap Analysis Report",
        "=" * 65,
        "",
    ]

    meta = report["report_metadata"]
    lines.append(f"Audit Type:    {meta['audit_type'].upper()}")
    lines.append(f"Report Date:   {meta['report_date']}")
    lines.append(f"Categories:    {', '.join(meta['categories_assessed'])}")
    lines.append(f"Controls:      {meta['total_controls_assessed']}")
    lines.append("")

    # Coverage summary
    cov = report["coverage_summary"]
    lines.append("--- Coverage Summary ---")
    lines.append(f"  Total TSC Criteria:    {cov['total_criteria']}")
    lines.append(f"  Fully Covered:         {cov['covered']}")
    lines.append(f"  Partially Covered:     {cov['partially_covered']}")
    lines.append(f"  Missing:               {cov['missing']}")
    lines.append(f"  Coverage:              {cov['coverage_percentage']}%")
    lines.append(f"  Critical Gaps:         {cov['critical_gaps']}")
    lines.append(f"  Readiness:             {cov['readiness_assessment']}")
    lines.append("")

    # Gaps
    gaps = report.get("gaps", [])
    if gaps:
        lines.append(f"--- Missing Controls ({len(gaps)}) ---")
        for g in gaps:
            sev = g["severity"].upper()
            lines.append(
                f"  [{sev}] {g['tsc_criteria']}: {g['description']}"
            )
            lines.append(f"         Remediation: {g['remediation']}")
        lines.append("")

    # Partial
    partial = report.get("partial_implementations", [])
    if partial:
        lines.append(f"--- Partial Implementations ({len(partial)}) ---")
        for p in partial:
            ctrls = ", ".join(p.get("controls", []))
            lines.append(
                f"  [{p['severity'].upper()}] {p['tsc_criteria']}: {p['description']}"
            )
            lines.append(f"         Controls: {ctrls}")
            lines.append(f"         Remediation: {p['remediation']}")
        lines.append("")

    # Type II operating gaps
    if "type2_operating_gaps" in report:
        t2 = report["type2_operating_gaps"]
        lines.append(
            f"--- Type II Operating Gaps ({t2['controls_with_issues']} controls, {t2['total_issues']} issues) ---"
        )
        for detail in t2["details"]:
            lines.append(f"  [{detail['control_id']}] {detail['description']}")
            for issue in detail["issues"]:
                lines.append(
                    f"    - [{issue['severity'].upper()}] {issue['check']}: {issue['detail']}"
                )
        lines.append("")

    return "\n".join(lines)


def main():
    parser = argparse.ArgumentParser(
        description="SOC 2 Gap Analyzer — identifies gaps between current controls and SOC 2 requirements."
    )
    parser.add_argument(
        "--controls",
        type=str,
        required=True,
        help="Path to JSON file with current controls (from control_matrix_builder.py or custom)",
    )
    parser.add_argument(
        "--type",
        type=str,
        choices=["type1", "type2"],
        default="type1",
        help="Audit type: type1 (design only) or type2 (design + operating effectiveness)",
    )
    parser.add_argument(
        "--json",
        action="store_true",
        help="Output in JSON format",
    )

    args = parser.parse_args()

    controls = load_controls(args.controls)
    categories = detect_categories(controls)
    gaps, partial, covered = analyze_coverage(controls, categories)

    type2_gaps = []
    if args.type == "type2":
        type2_gaps = analyze_type2_gaps(controls)

    report = build_report(
        controls, args.type, categories, gaps, partial, covered, type2_gaps
    )

    if args.json:
        print(json.dumps(report, indent=2))
    else:
        print(format_text_report(report))


if __name__ == "__main__":
    main()

Related skills

Entra App RegistrationCorrectly register an application in Microsoft Entra ID, configure OAuth 2.0 flows, request the right API permissions, and generate working MSAL authentication snippets476k1.3k

Azure ComplianceRun automated Azure compliance scans, security posture checks, and Key Vault expiration audits before deploying.475k1.3k

Openclaw Secure Linux CloudDeploy and harden an OpenClaw agent instance on a Linux cloud server following battle-tested security defaults.270k72

Better Auth Best PracticesCorrectly configure Better Auth for secure authentication with database adapters, sessions, OAuth, email/password, and plugins in TypeScript projects.78.9k204

Firebase Security Rules AuditorAutomatically audit Firebase Firestore security rules for bypass vulnerabilities and logic gaps before deploying.77.7k388

Audit WebsiteRun comprehensive audits that surface SEO, performance, security, technical, and content issues with LLM-optimized reports and health scores.64.9k85

How it compares

Use soc2-compliance for SOC 2 evidence workflows rather than generic security checklists that omit TSC mapping and observation-period sampling rules.

FAQ

What does soc2-compliance help engineers collect?

The soc2-compliance skill helps engineers collect and organize SOC 2 Type I and Type II evidence showing control existence, design effectiveness against Trust Services Criteria, and for Type II, operating effectiveness across the observation period with sufficient samples.

What makes SOC 2 evidence acceptable to auditors?

The soc2-compliance skill states evidence must be relevant to the control, reliably generated by systems or independent parties, timely within the audit period, and sufficient in sample size to demonstrate consistent operation rather than self-reported claims.

Is Soc2 Compliance safe to install?

skills.sh reports 2 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

Securitycomplianceaudit

About

Soc2 Compliance by the numbers

Add your badge

How do you collect SOC 2 Type II audit evidence?

Who is it for?

When should I use this skill?

What you get

By the numbers

Files

SOC 2 Compliance

Table of Contents

Overview

What Is SOC 2?

Type I vs Type II

Who Needs SOC 2?

Typical Journey

Trust Service Criteria

Security (Common Criteria CC1-CC9) — Required

Availability (A1) — Optional

Confidentiality (C1) — Optional

Processing Integrity (PI1) — Optional

Privacy (P1-P8) — Optional

Control Matrix Generation

Matrix Structure

Control Naming Convention

Workflow

Gap Analysis Workflow

Phase 1: Current State Assessment

Phase 2: Gap Identification

Phase 3: Remediation Planning

Phase 4: Timeline Planning

Evidence Collection

Evidence Types by Control Category

Automation Opportunities

Continuous Monitoring

Audit Readiness Checklist

Pre-Audit Preparation (4-6 Weeks Before)

Readiness Scoring

Common Audit Findings

Vendor Management

Third-Party Risk Assessment

Vendor Risk Tiers

Subservice Organizations

Continuous Compliance

From Point-in-Time to Continuous

Implementation Steps

Annual Re-Assessment Cycle

Anti-Patterns

Tools

Control Matrix Builder

Evidence Tracker

Gap Analyzer

References

Cross-References

SOC 2 Evidence Collection Guide

Evidence Fundamentals

What Auditors Look For

Evidence Quality Criteria

Evidence Types

Evidence by Control Area

Access Management

Change Management

Incident Response

Vulnerability Management

Encryption and Data Protection

Backup and Recovery

Monitoring and Logging

Policy and Governance

Vendor Management

Evidence Automation

Automated Evidence Sources

Evidence Collection Script Pattern

Evidence Repository Structure

Sampling Methodology

Sample Sizes by Control Frequency

Key Sampling Rules

Type I vs Type II Evidence Differences

Common Evidence Pitfalls

SOC 2 Type II Audit Playbook

Key Difference from ISO Audits