- SOC 2 is trust, not just compliance: SOC 2 and ISO 27001 together now account for over 85% of certifications selected by technology companies. Enterprise customers increasingly require SOC 2 before signing contracts with SaaS vendors. The report is evidence of controls that protect customer data — assembled once a year under audit pressure, or generated continuously as a byproduct of operational discipline.
- Five Trust Services Criteria, one mandatory: Security (the Common Criteria) is required in every SOC 2 report. Availability, Processing Integrity, Confidentiality, and Privacy are selected based on what the organization's services require and what customers contractually demand. Most SaaS companies certify against Security and Availability at minimum.
- What IT teams are accountable for: The Common Criteria CC6 (Logical and Physical Access), CC7 (System Operations), and CC8 (Change Management) are the three sections where ITAM and ITSM produce the evidence auditors test most rigorously — asset inventory, access provisioning and revocation, incident response records, and change approval trails.
- The audit evidence problem: Most IT organizations have the controls in place but cannot produce the evidence quickly. Asset records in one system, access logs in another, change records in a third — manual assembly under audit pressure is slow, error-prone, and reveals gaps that continuous operations would have closed long before the auditor arrived.
- Type I vs Type II: SOC 2 Type I tests whether controls exist at a point in time. Type II tests whether controls operated effectively over a defined period — typically 6 or 12 months. Enterprise customers require Type II. Type II means your controls must be real and operational, not assembled for the audit.
- WorkVerge: ITAM, ITSM, and access governance in a single platform — producing the audit trail that SOC 2 requires as a byproduct of normal IT operations, not as a pre-audit assembly project.
Introduction: Why SOC 2 Is Now a Sales Requirement
SOC 2 began as a voluntary framework for demonstrating data security controls to enterprise customers. In 2026, it has become a de facto sales prerequisite for B2B SaaS companies. According to Sprinto's 2026 Business ROI of Compliance report, SOC 2 and ISO 27001 together account for over 85% of certifications selected by technology companies, and enterprise procurement teams regularly include SOC 2 Type II as a vendor qualification requirement before contracts are signed. Failing to achieve it or maintain it costs deals — in some sales cycles, it costs the deal before a conversation about product capabilities ever begins.
For IT leaders, the SOC 2 accountability is concentrated in three areas of the Trust Services Criteria: the controls governing logical access (who has access to what systems and how that access is provisioned and revoked), system operations (how incidents are detected, logged, and resolved), and change management (how changes to production systems are reviewed, approved, and documented). These are not abstract governance requirements. They are the operational processes that ITSM and ITAM own — and auditors test them with more rigor and specificity than most IT teams expect when they first go through the process.
This guide maps the specific SOC 2 requirements that IT operations must satisfy, the evidence that auditors actually test, and how to structure ITAM and ITSM operations to produce that evidence continuously rather than scrambling to assemble it in the six weeks before each audit cycle.
SOC 2 Structure: What the Framework Actually Requires
SOC 2 is organized around five Trust Services Criteria (TSC) defined by the AICPA. Understanding the structure prevents the common mistake of treating SOC 2 as an undifferentiated compliance burden rather than a specific set of testable controls.
| Trust Services Criterion | Required? | What It Covers | Typical IT Scope |
|---|---|---|---|
| Security (CC) | Mandatory | Access controls, change management, risk assessment, incident response, vendor management | All ITSM and ITAM processes |
| Availability (A) | Optional — usually selected | Performance monitoring, disaster recovery, incident response for availability events | Infrastructure monitoring, SLA tracking |
| Processing Integrity (PI) | Optional — selected by data processors | Complete, accurate, timely processing of data | Transaction integrity controls |
| Confidentiality (C) | Optional | Protection of confidential information throughout its lifecycle | Data classification, access restrictions |
| Privacy (P) | Optional — required for personal data processors | Collection, use, retention, and disposal of personal information | Data governance, deletion processes |
Most B2B SaaS companies certify against Security and Availability at minimum. Adding Confidentiality is appropriate when handling customer proprietary data. Adding Privacy is appropriate when handling personal data of individuals. The scope of your certification should match what your customers contractually require — certifying against all five criteria when your customers only require Security and Availability adds audit cost and scope without customer-facing benefit.
SOC 2 Type I reports on whether controls are designed appropriately at a single point in time. SOC 2 Type II reports on whether those controls operated effectively over a defined period — typically 6 or 12 months. Enterprise procurement teams almost universally require Type II, because Type I only confirms that controls exist, not that they actually work. Type II means the controls must have been operational throughout the review period — auditors test samples from across the period, not just from audit week. An organization that assembles evidence manually each audit cycle and finds gaps in the middle of the period cannot cure those gaps retroactively. The evidence either exists from the operating period or it does not.
The Common Criteria: What IT Operations Must Cover
The Security TSC's Common Criteria (CC) sections are where ITAM and ITSM produce the most evidence that auditors test. Three CC sections are particularly significant for IT operations.
CC6 is the section most directly tested by auditors examining IT operations, and it is the section where most findings originate. The criteria require that access to systems and data be restricted to authorized users, that access is provisioned based on defined roles, that access is reviewed periodically, and that access is revoked promptly when employment ends or roles change. Auditors test these with sample requests: "Show me the access provisioning records for 5 employees hired in the past year." "Show me the access revocation records for 5 employees terminated in the past year." "Show me evidence of your last access review."
What This Requires From IT
A complete record of access provisioning events — who requested access, who approved it, when it was provisioned, and to which systems. A complete record of access revocation events — when termination was triggered, which systems were revoked, and within what time period. Evidence of periodic access reviews — not a policy stating that reviews happen quarterly, but actual records showing that reviews were conducted and that identified over-provisioning was remediated. Ghost access — the security and compliance risk covered in detail in Why Ghost Access Is Your Biggest Security Threat — is a CC6 finding. Automated offboarding workflows that immediately revoke access on termination close this finding structurally rather than relying on a manual process that may have delays.
CC7 covers how the organization detects, responds to, and resolves security incidents and operational anomalies. Auditors test whether the organization has defined incident response procedures, whether incidents are documented and tracked through resolution, whether response times meet defined targets, and whether post-incident reviews produce documented remediation actions. The ITSM incident management process is the primary evidence source for CC7 — incident records, resolution timelines, escalation trails, and problem management records that show systemic issues are identified and addressed rather than repeatedly resolved at the symptom level.
What This Requires From ITSM
A structured incident record for every security-relevant incident, with documented classification, response actions, resolution timestamp, and post-incident notes. SLA performance data showing that incident response time targets are consistently met. Evidence of escalation procedures being followed for high-priority incidents. Problem management records showing that recurring incidents trigger root cause analysis rather than repeated one-off resolution. The ITSM incident management framework that produces this evidence is built on the ITIL foundation covered in What is ITSM? Complete Guide to IT Service Management in 2026.
CC8 requires that changes to production systems be reviewed and approved before implementation, that changes are tested before deployment, and that unauthorized changes are detected. Auditors select a sample of changes from the review period and verify that each one has an approved change record, evidence of testing, and an authorized approver. The ITSM change management process — change requests, CAB approvals, implementation records, and post-implementation reviews — is the evidence source. Missing or incomplete change records for sampled changes are a direct CC8 finding.
The Asset Inventory Connection
CC8 also requires that the organization knows what systems exist — you cannot demonstrate that all changes to production systems go through the change management process if you cannot enumerate what production systems are. This is where ITAM feeds the SOC 2 picture: a comprehensive, current asset inventory provides the scope definition against which change management coverage can be demonstrated. An organization that claims all production systems go through change management but cannot prove it has a complete asset inventory of production systems has a gap that auditors will find. The asset inventory requirements are detailed in IT Asset Management: Complete Guide.
Structuring Evidence for Continuous Audit Readiness
The most reliable SOC 2 programs are those that treat audit evidence as a byproduct of normal operations rather than a pre-audit assembly project. Every access provisioning event generates a record. Every incident generates a structured ticket. Every change generates an approval trail. The evidence exists because the operational processes that created it were running correctly — not because someone worked backwards from an audit request to reconstruct what happened.
Evidence Category 1: Asset Inventory Records
A current, complete inventory of all systems in scope — hardware, software, cloud resources, and SaaS applications — with ownership, classification, and lifecycle status. AICPA's updated points of focus require accurate network and data flow diagrams and a comprehensive inventory of hardware and software. Auditors use the register to verify that controls cover all in-scope systems and that access is revoked for terminated staff. A static spreadsheet updated annually is insufficient evidence in environments where assets change regularly — auditors need to see that the inventory is current as of the review period end date, not as of the last time someone had capacity to update the spreadsheet.
Evidence Category 2: Access Provisioning and Revocation Logs
Structured records of every access grant and revocation during the review period, with timestamps, approvers, and the specific systems affected. The audit sample test for CC6 requires showing these records for 5–10 sampled employees. If provisioning and revocation happen through automated workflows with full execution logs, the evidence is a report. If it happens through manual processes documented in email threads, tickets, and Jira comments, the evidence assembly is a research project — and gaps are more likely because the manual process had exceptions that were handled informally.
Evidence Category 3: Change Management Records
Every change to production systems should have a corresponding change record showing what changed, who approved it, when it was implemented, and whether testing was completed. Auditors sample changes from the review period — typically 20–40 samples for a 12-month Type II review — and verify the record exists and is complete for each. ITSM change management workflows that require approval before a change can be marked as implemented produce this evidence automatically for every change. Organizations that use informal change processes and document after the fact consistently have incomplete records for some sampled changes.
Evidence Category 4: Access Review Records
Documentation that periodic access reviews were conducted — who reviewed which systems, when, what findings were identified, and how identified over-provisioning or inappropriate access was remediated. Auditors test not just that reviews happened but that identified issues were acted on within a reasonable timeframe. An access review that found 20 over-provisioned accounts and shows no subsequent revocation activity is a finding even if the review itself was conducted. The Software Access Reviews: How to Run Them Without Spreadsheets guide covers the operational process in detail.
The Five Most Common IT-Related SOC 2 Findings
| Finding Category | Specific Issue | SOC 2 Criterion | Prevention |
|---|---|---|---|
| Access revocation gap | Former employees with active access at time of sample testing | CC6.2, CC6.3 | Automated offboarding workflow triggered on HRIS termination record |
| Incomplete change records | Production changes with no change ticket or missing approval | CC8.1 | ITSM change management required before deployment; automated enforcement |
| Stale asset inventory | Systems in scope not appearing in asset inventory; known systems not in CMDB | CC6.1, CC8.1 | Continuous automated discovery rather than periodic manual audit |
| Access review not conducted | No documented evidence of periodic access review during review period | CC6.3 | Scheduled access review workflow with documented output and remediation records |
| Incident response gaps | Security incidents with no formal record; SLA performance not documented | CC7.2, CC7.3 | All incidents through ITSM; structured records required for closure |
Access revocation gaps and stale asset inventories are the two most common findings across SOC 2 Type II audits in 2026. Both are structural failures that automated operations close — not discipline failures that policy reminders fix.
How WorkVerge Produces SOC 2 Evidence Continuously
WorkVerge's unified ITAM, ITSM, and access governance architecture produces SOC 2 audit evidence as a byproduct of normal operations — not as a separate compliance program that runs in parallel with operational work.
- Complete, Current Asset Inventory (CC6.1, CC8.1): WorkVerge's continuous discovery — agent-based for endpoints, API-based for cloud, SSO-based for SaaS applications — maintains an always-current inventory of in-scope systems. When an auditor asks for a complete inventory of production systems as of a specific date, WorkVerge generates the report from the live record rather than from a spreadsheet that may not reflect the date in question. The discovery methodology is in How to Automate Asset Discovery: Save 20 Hours/Month.
- Access Provisioning and Revocation Audit Trail (CC6.2, CC6.3): Every access provisioning and revocation event executed through WorkVerge Workflows generates a structured execution log — timestamp, triggering event (HRIS record), systems affected, and approver where approval is required. The automated offboarding workflow fires on the HRIS termination record, revokes access across connected SaaS applications, and logs every action. The CC6 sample test for terminated employees becomes a report filtered by termination date, not a research exercise across email threads and manual tickets.
- Change Management Records (CC8.1): Every change processed through WorkVerge ITSM generates a change record with the approver, timestamp, implementation status, and post-implementation review. WorkVerge's change management workflow requires approval before a change can be marked as implemented — enforcing the process rather than relying on compliance after the fact. The 40-sample CC8 test becomes a filtered export from the ITSM change log.
- Incident Response Records (CC7.2, CC7.3): Every incident processed through WorkVerge ITSM has a structured record — classification, severity, response timeline, resolution timestamp, and linked problem record for recurring issues. SLA performance is tracked automatically against defined response time targets. The CC7 evidence export requires no manual assembly — the ITSM records are the evidence.
- Access Review Workflow (CC6.3): WorkVerge's software access visibility module supports scheduled access reviews with structured output — a documented record of who reviewed which systems, what was found, and what was remediated. Review completion and remediation timelines are captured in the platform, producing the evidence that auditors require beyond the review having been scheduled.
For the broader compliance context connecting asset management to SOC 2, ISO 27001, and HIPAA requirements, see ITAM Implementation Roadmap: Getting Started in 90 Days.
Conclusion: Audit Readiness Is an Operational State, Not a Pre-Audit Sprint
The organizations that find SOC 2 Type II audits straightforward are not those with the most sophisticated compliance programs. They are those whose IT operations generate structured evidence as a natural output of how they work — where access events are logged because the provisioning system logs them, where change records exist because the ITSM change management workflow requires them, where asset inventories are current because discovery is continuous rather than periodic.
The organizations that find audits stressful are those where the evidence must be assembled from multiple systems with different data models, where gaps appear because manual processes had exceptions, and where the 6-week period before audit submission is consumed by evidence assembly rather than verification. The structural difference between these two states is not effort — it is architecture. Building IT operations on a platform that produces audit evidence continuously is not a compliance investment. It is an operational efficiency investment that has compliance as a byproduct.