name: soc2-compliance-audit
description: Walks an organization through a structured SOC 2 Type II self-audit, organized by Trust Service Criteria. Produces a gap analysis, evidence-collection checklist, and remediation plan. Use when preparing for a SOC 2 audit, performing periodic internal compliance review, or building toward initial SOC 2 readiness for a SaaS startup. Outputs a structured assessment grounded in the AICPA Trust Service Criteria.
SOC 2 Compliance Audit Checklist
Author: Audrent Version: 1.0.0 Last reviewed: 2026-05-01 License: MIT
What this skill does
Walks an organization through a structured self-assessment of SOC 2 Type II readiness, organized by the AICPA Trust Service Criteria (Security — required for all SOC 2 reports — plus optionally Availability, Processing Integrity, Confidentiality, and Privacy). For each criterion, produces a checklist of controls, evidence-collection prompts, gap analysis against typical implementations, and a prioritized remediation plan.
This skill is designed for SaaS startups and growing technology companies preparing for their first SOC 2 audit, building toward audit readiness, or performing periodic internal compliance review between audits. It produces output a CTO, security engineer, or compliance lead can hand directly to their auditor (or use to scope the engagement).
What this skill does NOT do
Critical for honest customer expectations:
- This skill is not a substitute for a SOC 2 auditor. SOC 2 reports are issued only by licensed CPA firms. This skill helps you prepare for that engagement — it does not replace it. Anyone claiming an "AI-issued SOC 2 report" is misrepresenting what SOC 2 is.
- It is not legal advice. Specific compliance interpretations, especially for novel business models or non-standard control implementations, require qualified legal counsel and a CPA.
- It does not assess whether your specific evidence is sufficient. The auditor will evaluate evidence quality and operating effectiveness over the audit period. This skill helps you collect and organize evidence; the auditor decides if it's adequate.
- It does not generate audit reports. The output is a self-assessment, not a SOC 2 report. SOC 2 reports follow specific AICPA formatting requirements that only auditors produce.
- It assumes you have basic SOC 2 context. This skill is most useful to a CTO or security lead who has at least scoped the SOC 2 engagement and understands the basic framework. If you're at "what is SOC 2" stage, read AICPA's overview first or engage a compliance consultant.
When to invoke this skill
Use this skill when:
- Your company has decided to pursue SOC 2 Type II certification and you want to scope the work before engaging an auditor.
- You're 3-9 months into a Type II audit period and want to verify your controls are operating effectively before the auditor reviews them.
- You're between audits (Type II audits cover a 6-12 month period; readiness should be continuous).
- You've been asked by an enterprise prospect for a SOC 2 report and you want to assess how far you are from being able to provide one.
- Your team has limited compliance experience and you need a structured starting point.
Do not invoke this skill for:
- Issuing actual SOC 2 reports (engage a CPA firm — Deloitte, KPMG, Schellman, Insight Assurance, Prescient Assurance, A-LIGN, etc.).
- Complex compliance frameworks beyond SOC 2 — for ISO 27001, FedRAMP, HIPAA, PCI-DSS, use framework-specific tools or consultants.
- Defending an audit finding or arguing scope with an auditor (engage a compliance lawyer or your audit firm's own consulting arm).
SOC 2 framework primer (skip if you already know this)
SOC 2 (System and Organization Controls 2) is an AICPA framework for evaluating service organizations' controls over the systems they use to process customer data. There are five Trust Service Criteria (TSC):
- Security — protection against unauthorized access. Required for every SOC 2 report.
- Availability — system uptime and accessibility per agreed terms. Optional but commonly included for SaaS.
- Processing Integrity — system processes data completely, accurately, timely. Optional; relevant for transactional systems.
- Confidentiality — protection of confidential information. Optional; relevant if customer data goes beyond standard PII.
- Privacy — handling of personal information per the AICPA Privacy Framework. Optional; complex; consider only if you process significant personal data.
A Type I report assesses the design of controls at a single point in time. A Type II report assesses operating effectiveness over a period (typically 6-12 months). Type II is what enterprise customers usually require.
This skill defaults to assessing Security only (the required minimum), with optional sections for Availability and Confidentiality (the most common additions for SaaS). Processing Integrity and Privacy are out of scope for this skill — assess separately with framework-specific guidance if relevant.
Scoping questions (ask these before assessing)
Before performing the assessment, gather these answers from the user. They determine which controls apply.
- What is the audit scope? What systems, services, and data flows are in scope? (Typically: production environment for the customer-facing product, plus supporting infrastructure.)
- What Trust Service Criteria are being assessed? Security only? Security + Availability? Other combinations?
- What is the audit period? Type I (single point in time) or Type II (typically 6-12 months)?
- What is the company's stage? Pre-revenue / under 50 employees / 50-500 / 500+? Controls expectations scale with maturity.
- What technology stack and cloud providers are in use? (AWS / GCP / Azure / on-prem? Kubernetes? Serverless? Database choices?)
- Are there existing controls already? (HR onboarding processes, code review requirements, access management tooling?)
- What is the timeline target? Audit readiness in 3 months / 6 months / 12 months?
The Security Trust Service Criterion (required)
The Security TSC has nine common criteria (CC1-CC9) that map to controls. For each, the assessment walks through:
CC1 — Control Environment: Tone at the top, organizational integrity, ethical values, board oversight.
Controls to assess:
- Documented Code of Conduct and acknowledgment by employees
- Documented organizational chart with reporting lines
- Documented job descriptions for all roles, especially security-relevant roles (CTO, security lead, infrastructure)
- Background checks for new hires (with documented policy)
- Annual security awareness training for all employees, with completion tracking
- Disciplinary action policy for policy violations
- Documented mission, values, and ethics statements
Evidence to collect:
- Employee handbook with Code of Conduct
- Signed Code of Conduct acknowledgments (HR system records)
- Org chart (current and dated)
- Background check policy and provider records
- Security awareness training completion records (LMS or similar)
- Termination/disciplinary policy
Common gaps for early-stage companies:
- No formal Code of Conduct beyond the team handbook → recommend creating, having all employees sign annually
- Background checks not performed → recommend implementing (Checkr, Sterling, Goodhire are common providers)
- Security awareness training inconsistent or absent → recommend KnowBe4, Hoxhunt, or similar SaaS provider with quarterly micro-trainings
CC2 — Communication and Information: Policies, procedures, and information sharing.
Controls to assess:
- Documented Information Security Policy, reviewed and approved annually by management
- Documented Acceptable Use Policy for all systems
- Documented Incident Response Plan with named roles
- Documented Business Continuity Plan and Disaster Recovery Plan
- Channels for employees to report security concerns (anonymous option preferred)
- Annual review and approval of all security policies
Evidence to collect:
- Information Security Policy (current version, with approval date and approver)
- Acceptable Use Policy (signed by employees on hire)
- Incident Response Plan (with most recent test results)
- BCP/DRP (with most recent test results)
- Whistleblower policy / anonymous reporting mechanism
- Policy review meeting minutes
Common gaps:
- Policies exist informally but lack formal approval workflow → implement annual review meeting with documented approval
- Incident Response Plan is theoretical, never tested → conduct tabletop exercise quarterly
- BCP/DRP not tested → conduct annual recovery test, document results
CC3 — Risk Assessment: Identifying, analyzing, and responding to risks.
Controls to assess:
- Annual formal risk assessment (preferably aligned with NIST or ISO frameworks)
- Risk register with identified risks, likelihood, impact, treatment, owner
- Vendor risk assessment process (assessing third parties handling sensitive data)
- Fraud risk assessment as a discrete category
- Risk treatment plan with deadlines and owners
Evidence to collect:
- Most recent risk assessment document
- Risk register (current version)
- Vendor risk assessments for top 10 vendors by data sensitivity
- Risk treatment plan with status updates
Common gaps:
- No formal risk assessment, just informal awareness → conduct first formal assessment using a template (NIST SP 800-30 or AICPA TSP guidance)
- Vendor risk assessment ad hoc or absent → implement Vanta, Drata, SecurityScorecard, or similar tooling for vendor reviews
- Risk register tracked but not updated → quarterly review with named owners
CC4 — Monitoring Activities: Continuous monitoring of controls and changes.
Controls to assess:
- Continuous monitoring of access logs, security events, system performance
- Centralized logging across production systems (SIEM or equivalent)
- Alerting on security-relevant events (failed authentications, privilege escalations, configuration changes)
- Regular vulnerability scans (automated, at least monthly)
- Regular penetration testing (annually, by qualified third party)
- Change management process with approval before production changes
Evidence to collect:
- SIEM or logging platform configuration (Datadog, Splunk, Sumo Logic, AWS CloudWatch, etc.)
- Sample alert configurations
- Vulnerability scan results (most recent)
- Penetration test report (most recent, redacted as appropriate for sharing)
- Change management ticketing records (sample tickets showing approval flow)
Common gaps:
- Logging exists but no centralized SIEM → implement at least basic centralization (CloudWatch + alerts is a starting point)
- No formal vulnerability scanning → implement Snyk, Tenable, or AWS Inspector
- No penetration testing → engage a firm (Cobalt, Bishop Fox, NCC Group, smaller boutiques) for at least annual testing
CC5 — Control Activities: Implementation of controls in policies, procedures, and technology.
Controls to assess:
- Logical access controls (least privilege, role-based access, MFA on all sensitive systems)
- Physical access controls (office, data centers — often inherited from cloud provider)
- Change management with separation of duties (developer can't deploy without independent approval, or developer can deploy but a separate review process exists)
- Segregation of duties for sensitive operations
- Endpoint security controls (MDM, antivirus, disk encryption)
Evidence to collect:
- IAM policies in cloud providers (AWS IAM, GCP IAM, Azure AD)
- MFA enforcement screenshots
- Change management ticketing system records
- MDM enrollment records (Jamf, Kandji, Microsoft Intune, etc.)
- Disk encryption verification (FileVault for Mac fleet, BitLocker for Windows)
Common gaps:
- IAM not following least-privilege (developers have production database access "just in case") → implement break-glass access patterns (developers can't access production by default; can request elevated access with justification, time-limited, audited)
- MFA not universal → enforce on all SaaS tools handling company data, not just primary systems
- No MDM → implement at least basic MDM with disk encryption and screen-lock policies
CC6 — Logical and Physical Access Controls: Specific access management practices.
Controls to assess:
- Centralized identity provider (SSO via Okta, Microsoft Entra, Google Workspace, Auth0)
- MFA enforced on identity provider (mandatory, not optional)
- Access provisioning workflow (request → approval → implementation, all logged)
- Access reviews quarterly (manager confirms each report's access is still appropriate)
- Access termination on employee departure (verified within 24 hours, ideally automated through SSO)
- Privileged access management (separate accounts for admin tasks; just-in-time elevation)
Evidence to collect:
- SSO configuration showing all production systems integrated
- MFA enforcement policy
- Access review records (quarterly, by manager, signed)
- Termination checklist showing access removal verification
- Privileged access logs (sample)
Common gaps:
- SSO covers some but not all systems → list every SaaS, integrate the gaps
- Quarterly access reviews missing → implement (Vanta, Drata, BambooHR can automate the workflow)
- Termination access removal not tracked → integrate offboarding into IT ticketing
CC7 — System Operations: Operational controls over the production environment.
Controls to assess:
- Production change management with documented approval, testing, rollback plan
- Code review required before production deployment (no force-push to main, branch protections enforced)
- Deployment automation with audit trail
- Incident management process with documented response times
- Backup and restore procedures, tested at least annually
- Capacity planning and monitoring
Evidence to collect:
- GitHub/GitLab branch protection settings (screenshots)
- Sample PRs showing review and approval before merge
- CI/CD pipeline configuration
- Incident response records (sample tickets, post-mortems)
- Backup test results (most recent)
- Capacity dashboards / runbooks
Common gaps:
- Force-push allowed to main → enable branch protection
- No required reviewers → enforce at least 1 reviewer for production code
- Backups exist but never tested → schedule annual restoration test, document
- Incidents handled but never written up → start writing post-mortems for any production incident
CC8 — Change Management: Specifically the change-management process.
Controls already covered in CC5 and CC7 — at the audit level, the auditor will look for documented evidence that changes follow the documented process. Evidence overlaps with CC5/CC7.
CC9 — Risk Mitigation: Specifically mitigation strategies for identified risks.
Overlaps with CC3 risk assessment. Evidence overlaps.
Optional: Availability TSC
If Availability is in scope, additional controls include:
- Documented availability commitments (SLA in customer agreements)
- Monitoring of system availability with alerting on threshold breaches
- Capacity management (current and forecast)
- Backup and recovery procedures with RTO/RPO targets
- Disaster recovery testing at least annually with documented results
Evidence: status pages, SLA records, monitoring dashboards, DR test reports.
Common gaps: SLA documented in marketing but not measured technically → instrument with synthetic checks (Pingdom, Datadog Synthetics, Checkly).
Optional: Confidentiality TSC
If Confidentiality is in scope:
- Data classification policy (e.g., Public / Internal / Confidential / Highly Confidential)
- Encryption at rest (database, S3 buckets, backups) and in transit (TLS 1.2+)
- Data retention and disposal procedures
- Customer data handling specific to confidentiality commitments
Evidence: classification policy, encryption verification (database parameter screenshots, S3 default encryption), retention schedules, data destruction logs.
When invoked, produce a structured assessment with these sections:
# SOC 2 Self-Assessment — [Company Name]
Date: [YYYY-MM-DD]
Audit period under assessment: [Type I single point | Type II date range]
TSCs in scope: [Security | Security + Availability | etc.]
Assessor: [name / role of person performing assessment]
## Executive summary
- Overall readiness rating: [Ready for audit | Material gaps | Significant gaps | Not yet ready]
- Critical gaps requiring immediate attention: [count]
- Estimated remediation timeline: [weeks / months]
- Recommended next step: [Engage auditor | Remediate then engage | Hire compliance lead | etc.]
## Per-Criterion Findings
### CC1 — Control Environment
Status: [Compliant | Partial | Gap | Critical Gap]
Implemented controls:
- [list of controls confirmed in place]
Gaps identified:
- [specific gap, severity, recommended action]
Evidence collected:
- [list of evidence verified during this self-assessment]
Evidence missing:
- [list of evidence not yet available]
[Repeat for CC2 through CC9, plus any optional TSCs]
## Prioritized Remediation Plan
Critical (must fix before engaging auditor):
1. [gap, owner, timeline]
2. [...]
High (must fix during audit period):
1. [...]
Medium (improve over time):
1. [...]
## Tooling Recommendations
[Specific recommendations for compliance automation: Vanta, Drata, Secureframe, Tugboat Logic. SOC 2 prep without compliance tooling is possible but takes 3-5x more time at typical SaaS scale.]
## Recommended Next Steps
1. Address critical gaps (timeline)
2. Engage auditor for scoping (recommended firms based on size/budget)
3. Begin Type II audit period start date target: [date]
4. Build continuous-readiness practice (don't lose readiness between audits)
Operating principles for this skill
- Be honest about gaps. Customers paying for compliance assessment need accurate information, not encouragement. If they're not ready, say so clearly with specific reasons.
- Prioritize controls by audit-blocking severity. Some gaps must close before an auditor can complete their work; others are improvements over time. Distinguish clearly.
- Recommend specific tooling. "Use compliance automation" is not actionable; "Use Vanta or Drata, expect $5-15K/year" is. Recommend the right tool category for the company's stage.
- Map to actual auditor expectations. Auditor will ask "show me X" — list what auditors actually request, in their format, not abstract control descriptions.
- Acknowledge legitimate alternatives. SOC 2 has flexibility in how controls are implemented. A small startup may meet a control via different means than a large enterprise. Don't insist on enterprise-pattern controls when a smaller alternative is acceptable.
- Honest about timeline. A pre-readiness company is typically 3-9 months from audit-ready, depending on starting state. Don't promise "audit in 6 weeks" — mislead-once, lose-trust-forever.
- Author: Audrent
- Version: 1.0.0
- License: MIT
- Source of truth:
audrent.com/skills/soc2-compliance-audit (when published) - Provenance: Authored by the Head of Agent Commerce at Audrent. Grounded in AICPA SOC 2 Trust Service Criteria framework. No third-party code, no external dependencies, no network calls. Complete contents are in this single SKILL.md file.
- Reporting issues / suggested improvements:
[email protected]