I've owned SOX audit responsibilities. I know what it means to maintain evidence for external reviewers, to design controls that hold up under scrutiny rather than just existing on paper, and to close the gap between where your systems actually are and where an auditor needs them to be.
SOC2 is a different framework from SOX, but the operational pattern is the same. There's a defined control set. There's an external auditor. There's a gap between current state and compliance state, and the gap assessment is where IT managers spend most of their prep time — usually with a spreadsheet that goes stale the day after it's created, with no live connection to the systems it's supposed to be assessing.
Most IT teams going through their first SOC2 do it that way. The SOC2 Readiness Suite connects to your actual infrastructure, pulls compliance signals from live sources, and shows you a real-time readiness picture across all 59 controls before the auditor arrives.
Type I vs. Type II Changes What You're Actually Assessing
Before running any assessment, the tool asks which audit type you're targeting. This isn't cosmetic.
Type I is a point-in-time assessment: are controls designed and in place as of today? Type II covers a 12-month observation period: have controls been operating effectively, consistently, over time? The evidence requirements are completely different.
For Type I, you need to show a control exists. For Type II, you also need to show it's been operating for the entire observation window. A change management policy satisfies Type I if it exists. For Type II, you also need pull request review logs, change tickets, and deployment records spanning the observation period. That's a meaningfully different evidence collection task.
The tool scopes to your audit type from setup. Type II assessments include a configurable observation period with start and end dates. Every control card reflects which type of evidence is needed given your selection.
The 5 TSC Categories and What's Actually in Scope
SOC2 has 59 controls across 5 Trust Services Criteria categories. Security (CC) is mandatory for every SOC2. The other 4 are in scope only if relevant to your service commitments.
The breakdown: Security has 29 controls (CC1 through CC9), covering organizational structure, risk management, logical access, incident response, and change management. Availability has 3 controls around capacity management, environmental protections, and backup and recovery. Processing Integrity has 5 controls around data inputs, processing accuracy, and output validation. Confidentiality has 4 controls around data classification, disposal, encryption, and breach response. Privacy has 18 controls covering notice, consent, collection, use, retention, disclosure, and compliance monitoring.
Most SaaS companies need Security plus Availability at minimum. Privacy (P) is where GDPR and CCPA obligations tend to overlap with SOC2 requirements.
The tool lets you select exactly which categories are in scope. Every metric, every control card, every gap score is calculated against your scoped set, not the full 59.
What the Gap Assessment Shows Per Control
The assessment interface shows one card per control in your scoped set. Each card has the control ID, title, description, current status (compliant, partial, non-compliant), and the specific evidence signals driving that status.
The partial versus non-compliant distinction matters more than it looks. Partial means something is in place but incomplete — MFA is configured but enrollment is at 78% when the threshold is 95%, or branch protection is enabled on main but not on release branches. Non-compliant means the control doesn't exist. Those require different remediation paths. Partial is usually a configuration change. Non-compliant often requires building something new.
The dashboard gives category-level readiness at a glance: green is 80% or more compliant, amber is 50-79%, red is below 50%.
The 12 Connectors
Manual assessment of 59 controls across a real infrastructure stack takes days. The connector layer reduces that significantly by pulling compliance signals directly from your systems.
The tool has 12 connectors: Okta, AWS, GCP, Azure, Google Workspace, GitHub, Jamf, Kandji, Intune, Jira, Confluence, and manual CSV upload. Each maps specific signals to specific controls.
Okta populates MFA enrollment rate (CC6.1), inactive user counts, and termination access revocation timing (CC6.5). GitHub checks branch protection and PR review requirements (CC8.1) and secret scanning status. AWS pulls CloudTrail status, S3 encryption settings, and log retention configuration (CC7.2). Jamf, Kandji, and Intune report endpoint protection coverage and encryption rates (CC6.7, CC6.8).
All connectors run in demo mode with no credentials required — they return realistic synthetic data so you can see what the assessment looks like before connecting live systems.
Policy Generation for Gap Controls
For controls where the gap is "no written policy exists," the tool calls Claude to generate a draft scoped to that specific control.
CC9.2 (vendor risk management) is the control where this is most useful. A vendor risk management policy needs to say specific things: how vendors are classified, what security assessments are required for different tiers, how often reviews happen, what happens when a vendor fails assessment. Most companies have the process informally but not the written policy an auditor can review. The generated draft gives you a starting point with the right structure.
This is a draft, not a finished artifact. It needs legal review and customization to your actual practices. But starting from a structured draft rather than a blank document is the difference between an afternoon and a week for most IT managers writing compliance policies for the first time.
The tool is designed for IT Managers and Heads of IT at Series A and B companies where SOC2 is on the roadmap and nobody has done it before. Demo mode loads a pre-configured assessment with no credentials needed. The code is on GitHub.