SOC 2 Compliance Guide: Requirements & Audit Prep

SOC 2 is an attestation framework from the American Institute of CPAs (AICPA) that evaluates how a service organization controls data security, availability, and privacy. If your company stores, processes, or transmits customer data, a SOC 2 report is what enterprise buyers will ask for before signing a contract.

This guide covers everything IT, security, and compliance teams need to know: the Trust Services Criteria, how to choose between Type 1 and Type 2 reports, a realistic audit preparation timeline, and how device management controls map directly to audit evidence requirements.

What is SOC 2?

SOC 2 produces an auditor's opinion report, not a certificate or certification. There is no certifying body, no pass/fail score, and no badge you earn after completing a checklist. An independent CPA firm reviews your controls over a defined period, then issues a report expressing an opinion on whether those controls were suitably designed (Type 1) or operating effectively over time (Type 2).

That distinction matters because several vendors in the market incorrectly call SOC 2 a "certification." Calling it that with an enterprise prospect who has a sophisticated security team will immediately undermine your credibility.

Key facts to internalize:

• SOC 2 is governed by the AICPA's Trust Services Criteria (TSC), last significantly updated in 2017 with revised Points of Focus
• Your organization selects which TSC categories apply to your services
• The Security category (Common Criteria) is mandatory for all SOC 2 engagements
• Reports are typically shared under NDA with customers and prospects, not published publicly
• SOC 2 Type 2 reports cover a minimum 6-month observation period, though 12 months is standard for mature programs

For a broader look at how SOC 2 fits into your overall compliance posture, see our article on SaaS compliance.

The Five Trust Services Criteria Categories

The AICPA organizes SOC 2 around five TSC categories. Security is required. The other four are optional based on what your service commitments include.

1. Security (Required)

Covers the protection of system resources against unauthorized access. This is where most of your control work lives. The Security category is organized into nine Common Criteria groups (CC1 through CC9) spanning governance, communication, risk assessment, monitoring, logical access, system operations, change management, risk mitigation, and third-party management.

2. Availability

Covers whether the system is available for operation and use as committed or agreed. Relevant for SaaS companies with uptime SLAs. Controls here include capacity planning, incident response, backup and recovery, and performance monitoring.

3. Processing Integrity

Covers whether system processing is complete, valid, accurate, timely, and authorized. Most relevant for payment processors, data pipelines, and financial platforms where accuracy of outputs is a customer commitment.

4. Confidentiality

Covers whether information designated as confidential is protected as committed or agreed. Overlaps heavily with Security but focuses specifically on data classification, encryption of confidential data, and contractual obligations around data handling.

5. Privacy

Covers whether personal information is collected, used, retained, disclosed, and disposed of in accordance with the entity's privacy notice. If you handle personal data of individuals, this category aligns closely with GDPR and other privacy regulations.

Most mid-market SaaS companies start with Security only, then add Availability and Confidentiality as their customer base matures and enterprise contract requirements become more specific.

SOC 2 Type 1 vs Type 2: Which Report Do You Need

This is the most common decision point for teams preparing their first SOC 2 engagement.

SOC 2 Type 1

• Evaluates whether controls are suitably designed at a single point in time
• No observation period required
• Can be completed in 8-12 weeks after readiness work is done
• Tells prospects: "We have the right controls in place as of this date"
• Weaker signal than Type 2 but useful as a first step

SOC 2 Type 2

• Evaluates whether controls are operating effectively over a period of time (minimum 6 months, typically 12)
• Requires continuous evidence collection throughout the audit period
• Takes 9-18 months from program launch to report issuance depending on your starting point
• Tells prospects: "Our controls work consistently, not just on audit day"
• The standard expectation for enterprise sales cycles

Which to Choose

If a prospect is asking for SOC 2 right now and your pipeline requires it to close deals, a Type 1 can unblock sales while your Type 2 observation period runs. Many companies get a Type 1 in Q1, then begin their 12-month Type 2 observation period immediately after. By Q1 of the following year, they have a Type 2 report.

If you have 12-18 months before compliance is a sales blocker, skip Type 1 and go straight to Type 2. Enterprise buyers give Type 2 significantly more weight.

Common Criteria: The CC Control Framework

The Common Criteria (CC1-CC9) form the backbone of the Security category and are relevant to every SOC 2 engagement. Here is what each covers and why it matters for IT teams:

CC6 and CC7 are where IT teams carry the most direct responsibility. Access controls, endpoint configuration, vulnerability management, and security event monitoring all live in these criteria groups.

How to Prepare for a SOC 2 Audit: A Realistic Timeline

Most auditors recommend a readiness assessment before the audit observation period begins. Here is a practical timeline for a mid-market SaaS company targeting a SOC 2 Type 2 report:

Months 1-2: Scoping and Readiness Assessment

• Define which TSC categories apply to your service commitments
• Identify in-scope systems, infrastructure, and personnel
• Conduct a gap assessment against the Common Criteria
• Document which controls exist, which need to be built, and which need evidence collection processes
• Select your CPA firm (auditor) early, as reputable firms book out 3-6 months

Months 2-4: Control Implementation

• Build or formalize policies: information security policy, acceptable use, access control, incident response, change management, vendor management
• Implement technical controls: MFA enforcement, endpoint management, encryption at rest and in transit, logging and monitoring
• Establish evidence collection workflows: automated where possible, documented manual processes where not
• Complete a SOC 2 compliance checklist against each applicable criterion

Months 4-16: Observation Period (Type 2)

• Maintain consistent control operation, not just at audit start
• Collect continuous evidence: access reviews, vulnerability scan results, training completion records, change logs, incident logs
• Conduct quarterly internal reviews to identify control failures before auditors do
• Perform at least one full access review cycle during the period

Months 16-18: Audit Fieldwork and Report Issuance

• Provide auditors with requested evidence packages
• Respond to auditor inquiries within agreed timeframes (delays here extend the audit)
• Review draft report for factual accuracy before final issuance

The single biggest reason companies miss their audit timelines: underestimating the evidence collection burden during the observation period. Controls that run automatically and log their operation are dramatically easier to evidence than manual processes that require someone to remember to screenshot something every quarter.

SOC 2 Audit Checklist: Evidence IT Teams Must Collect

Auditors request evidence for every control in scope. For IT-owned controls, this typically includes:

Access Control (CC6)

• MFA enrollment reports showing all users are enrolled
• Quarterly access reviews with documented approvals and removals
• Offboarding records showing timely access termination (typically within 24-48 hours of departure)
• Privileged access logs
• Device enrollment and compliance status reports

Endpoint Security (CC6, CC7)

• MDM enrollment records showing all in-scope devices are managed
• Endpoint configuration compliance reports (disk encryption enabled, firewall active, screen lock enforced)
• Vulnerability scan results and remediation tracking
• Patch management logs showing OS and application updates applied within defined SLAs
• Antivirus or EDR deployment confirmation

Vulnerability Management (CC7)

• Scheduled scan frequency records
• Findings reports with severity ratings
• Remediation timelines and closure evidence
• For critical/high findings: documentation that they were addressed within your defined SLA

Incident Management (CC7)

• Incident log with dates, severity, response actions, and resolution
• Post-incident review documentation for significant events
• Evidence that the incident response plan was followed

Change Management (CC8)

• Change request tickets with approvals
• Code review records
• Production deployment logs
• Rollback procedures

Vendor Management (CC9)

• Vendor inventory with risk classification
• Security questionnaires or SOC 2 reports from critical vendors
• Vendor contracts with appropriate security terms

For teams running macOS and iOS devices, endpoint evidence is particularly important to get right. Auditors increasingly ask for configuration baseline evidence, not just enrollment counts. A CIS compliance checklist for macOS maps directly to the configuration hardening evidence auditors expect for CC6 and CC7.

Endpoint Security Controls and SOC 2 Evidence

This is the area most SOC 2 guides skip entirely, and it is where IT teams at Apple-heavy companies run into the most friction.

Every device in scope for SOC 2 needs to demonstrate:

1. Enrollment in a management system (auditors want to see that all devices are accounted for, not just that an MDM exists)

2. Configuration compliance (disk encryption, screen lock timeout, firewall, local admin restrictions)

3. Patch currency (OS and application patch levels within your defined SLA)

4. Security software deployment (EDR, antivirus, or endpoint protection tool present and active)

5. Access logging (login events, privilege escalation, failed authentication attempts)

For macOS environments, these controls are straightforward to implement and evidence with a capable MDM platform. 

Endpoint hardening at the OS level is also directly auditable. Auditors can and do ask for configuration profiles, not just a statement that you enforce encryption. Our endpoint hardening guide covers the specific settings that map to Common Criteria expectations.

Vulnerability management evidence is another high-friction area. Scanners produce reports, but auditors want to see what you did with the findings. Connecting your CVE prioritization and remediation process to a documented SLA (critical findings resolved within 7 days, high within 30, for example) and then evidencing adherence to that SLA is what separates a clean audit from one with exceptions.

SOC 2 for SaaS Companies: What Enterprise Buyers Actually Review

When a large enterprise sends you a security questionnaire or requests your SOC 2 report, they are not just checking a compliance box. Their security team will read the report. Here is what they focus on:

Exceptions and Qualifications: Any control exceptions noted by the auditor will be flagged. A single exception that is well-explained and remediated is usually acceptable. Multiple exceptions across the same control area suggest systemic weakness.

Complementary User Entity Controls (CUECs): SOC 2 reports include a section listing controls that your customers must implement for the system to operate securely. Enterprise buyers review these carefully. If your CUECs are extensive or vague, expect follow-up questions.

Subservice Organizations: Auditors list the third-party providers included in or excluded from scope (AWS, Stripe, etc.). Sophisticated buyers will ask whether your critical subservice providers have their own SOC 2 reports and whether you reviewed them.

Report Date and Period: A Type 2 report with a 12-month period ending 18 months ago will get questions. Enterprise security teams track report currency. Annual renewal keeps your report credible.

Scope Boundaries: Buyers read the system description carefully. If your production environment is in scope but your staging environment is not, and a recent breach involved staging data, that gap will surface.

Multi-Framework Efficiency: SOC 2 and ISO 27001

Many mid-market companies pursuing SOC 2 also face pressure to achieve ISO 27001 certification, particularly from European customers or global enterprises that prefer ISO to AICPA frameworks.

The good news is that control overlap between SOC 2 and ISO 27001 is substantial. Both frameworks require:

• A formal information security policy
• Risk assessment and treatment processes
• Access control management
• Incident management
• Supplier/vendor management
• Business continuity planning
• Security awareness training

The primary architectural difference is that ISO 27001 requires an Information Security Management System (ISMS) with a defined scope and a formal certification audit by an accredited body. SOC 2 does not require an ISMS but relies on the CPA firm's attestation.

If you are pursuing both frameworks simultaneously, structure your control library around one framework and map to the other. ISO 27001 Annex A controls map reasonably well to SOC 2 Common Criteria, though the mapping is not perfectly 1:1. Running both programs in parallel from a shared evidence base is significantly more efficient than running them independently.

The NIST Cybersecurity Framework (CSF) 2.0 and NIST 800-53 also share substantial control overlap with SOC 2. Organizations in federal contracting or pursuing FedRAMP authorization often find that a mature SOC 2 program gives them 60-70% of the control implementation work already done.

How Iru Approaches SOC 2 Compliance

Most compliance automation platforms treat device-level controls as an afterthought. They connect to your cloud infrastructure and HR systems but leave a gap between your MDM and your evidence library. For Apple-heavy IT environments, that gap is where audit pain lives.

Iru combines Apple-first MDM with compliance automation, which means the device management data that auditors want for CC6 and CC7 flows directly into your evidence collection workflow without manual exports or screenshots. Enrollment status, configuration compliance, patch levels, disk encryption state, and security software deployment are all captured automatically and mapped to the relevant Trust Services Criteria.

Some specifics that matter for SOC 2 programs:

Automated evidence collection across 10 frameworks. Iru supports SOC 2, ISO 27001, ISO 27701, ISO 42001, HIPAA, GDPR, PCI DSS, NIST 800-53, NIST CSF 2.0, and CMMC from a single control library. If you are pursuing SOC 2 now and ISO 27001 next year, your control implementation work carries forward.

70+ native connectors for continuous monitoring. Rather than collecting evidence point-in-time, Iru pulls data continuously from your connected tools, so your evidence library stays current throughout the Type 2 observation period. The target is 100 connectors by end of Q2 2026.

Device compliance as audit evidence. For macOS and iOS fleets, Iru translates MDM configuration profiles and compliance checks directly into the policy-level evidence auditors expect. When an auditor asks for proof that all endpoints have FileVault enabled, the answer is a timestamped compliance report, not a manual export from a separate system.

Migration from existing GRC tools. Organizations moving from Drata or Vanta can upload existing control mappings and evidence, preserving investment in prior compliance work while gaining the device management integration that those platforms lack.

Choosing the Right Approach for Your SOC 2 Program

SOC 2 is a multi-year commitment. The report you issue in year one is the baseline; what enterprise buyers evaluate is whether your program is mature and continuously improving. Here is how to set your program up to scale:

Start with the right scope. Over-scoping your first audit creates unnecessary evidence burden. Under-scoping creates gaps that sophisticated buyers will find. Work with your auditor to define a scope that matches your actual service delivery environment.

Automate evidence collection from day one. Every manual evidence collection process is a risk: risk of human error, risk of missing a collection cycle, and risk of inconsistent evidence format. Automation does not eliminate all manual work, but it reduces the surface area where audits fail.

Treat the observation period as an operational test. Control failures during the observation period become exceptions in your report. Quarterly internal reviews during the observation period catch failures before auditors do. Build that review cadence into your security program as standard operating procedure.

Choose an auditor for fit, not just price. CPA firms with strong technology sector experience understand SaaS architectures, cloud infrastructure, and modern development practices. A firm that primarily audits manufacturing companies will spend more time asking foundational questions, which extends your audit timeline and cost.

Plan for annual renewal from the start. A SOC 2 Type 2 report covers a specific period. Letting it lapse for 18 months and then rushing to renew before a major deal closes is a common and avoidable situation. Build annual renewal into your security program budget and calendar.

If you are starting your SOC 2 journey and want a structured checklist to work through, our detailed SOC 2 compliance checklist covers each control area with specific implementation guidance.

SOC 2 gets easier when enforcement and evidence live in the same place. Iru offers device management and compliance as separate products or as one — whichever matches where you are today. Book a demo.