SOC 1 and SOC 2: Which Report Does Your Organization Need?

SOC 1 governs controls relevant to your customers' financial reporting; SOC 2 governs controls relevant to security, availability, processing integrity, confidentiality, and privacy. The decision rule is straightforward: if your service affects how a client records or reports financial transactions, you need a SOC 1 report. If clients or prospects are asking how you protect their data or keep your systems running, you need SOC 2. Many technology and financial services providers eventually need both, but most organizations start with one.

On report types: a Type I opinion confirms that your controls are designed appropriately at a specific point in time. A Type II opinion confirms that those controls operated effectively across an observation period, typically six to twelve months. Enterprise buyers almost always require Type II before signing a contract.

Your first internal conversation should go to finance or your external auditor if SOC 1 is the likely path. For SOC 2, start with your security or compliance lead.

Table of Contents

• What is a SOC report and where does the requirement come from?
• How do SOC 1 and SOC 2 compare side by side?
• What does SOC 1 actually examine?
• What do the Trust Services Criteria cover in SOC 2?
• Type I vs Type II: which one do you actually need?
• When does an organization need both SOC 1 and SOC 2?
• What do SOC controls look like in practice, and how do they map to other frameworks?
• How do you prepare for a SOC 1 or SOC 2 audit?
• Common gaps, remediation tasks, and realistic timelines
• Key Takeaways
• The real gap most organizations miss in SOC readiness
• CisoSafe helps regulated organizations reach SOC readiness faster
• Official references and suggested further reading

What is a SOC report and where does the requirement come from?

A SOC (System and Organization Controls) report is a formal attestation issued by a licensed CPA firm under standards set by the American Institute of Certified Public Accountants (AICPA). The CPA firm is independent of your organization, which is what gives the report credibility with customers, auditors, and regulators.

The AICPA governs three distinct report types:

• SOC 1: Examines controls at a service organization that are likely to be relevant to user entities' internal control over financial reporting (ICFR). Intended audience: user entity finance teams and their external auditors.
• SOC 2: Assesses controls relevant to the Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, and Privacy. Intended audience: customers, security teams, vendor managers, and regulators.
• SOC 3: A public-facing summary of SOC 2 findings, containing less detail and designed for general distribution rather than confidential sharing under NDA.

The governing attestation standard is SSAE 18 (Statements on Standards for Attestation Engagements), which the AICPA issues and updates. Trust Services Criteria, published separately by the AICPA, define the specific control categories that SOC 2 auditors test. Neither SOC 1 nor SOC 2 is a government-mandated regulation, but both frequently become contractual requirements in enterprise procurement.

One critical clarification: a SOC report is an attestation, not a certification. Calling it a "SOC 2 certification" is technically inaccurate under AICPA standards. The report contains a management assertion and an auditor's opinion — readers should evaluate the opinion type and any noted exceptions, not treat the report as a simple pass/fail badge.

How do SOC 1 and SOC 2 compare side by side?

The table below captures the dimensions that finance, security, and procurement teams actually use when deciding which report to request or pursue.

A few takeaways for initial selection:

• If your clients are asking their external auditors to review your controls as part of their own audit, SOC 1 is almost certainly the report they need from you.
• If a procurement team or security questionnaire asks for evidence of your data protection posture, SOC 2 is the answer.
• If you process payroll, manage investment records, or handle financial transactions on behalf of clients, SOC 1 is the baseline. SOC 2 may still be requested separately by security teams at those same clients.

What does SOC 1 actually examine?

SOC 1 focuses on ICFR — the controls at your organization that could affect the accuracy of your clients' financial statements. Finance teams and external auditors request it because they need to rely on your controls when forming their own audit opinion on a client's books.

Service providers that commonly need SOC 1 reports include:

• Payroll processors: Controls over payroll calculation, disbursement authorization, and general ledger feeds directly affect how clients record compensation expenses.
• Fund administrators and transfer agents: Controls over net asset value calculations, shareholder records, and trade settlement affect investment company financial statements.
• Loan servicers and mortgage processors: Payment processing, escrow management, and delinquency reporting feed into lender financial records.
• Benefits administration platforms: Premium remittance and claims data flow into employer financial statements.

The controls auditors examine in a SOC 1 engagement typically include:

• Logical access controls to financial applications and databases (who can read, write, or approve transactions)
• Change management procedures for financial systems (how updates are tested and approved before deployment)
• Transaction authorization and segregation of duties (who initiates vs. who approves a payment or journal entry)
• Data backup and recovery for financial records
• Reconciliation procedures and exception reporting

SOC 1 reports are shared under NDA with user entities and their auditors. They are not public documents, and they are not appropriate for sharing with customers who simply want to know whether your platform is secure. That is what SOC 2 is for.

What do the Trust Services Criteria cover in SOC 2?

SOC 2 is built on the AICPA's Trust Services Criteria, and Security is the only mandatory criterion. The remaining four are optional, included when they are relevant to the services you provide and the commitments you make to customers.

Auditors examining a SOC 2 engagement typically request: system description documents, network diagrams, configuration screenshots, access provisioning and deprovisioning logs, change-control records, incident response logs, and penetration test results. The more mature your evidence collection process, the shorter the audit fieldwork window.

Pro Tip: Select only the Trust Services Criteria that reflect actual commitments in your customer contracts or service-level agreements. Including Privacy when you do not handle personal data adds scope, cost, and audit risk with no corresponding benefit.

Customers, security teams, vendor managers, and regulators use SOC 2 reports for vendor risk decisions. A clean, unqualified SOC 2 Type II opinion from a reputable CPA firm often replaces dozens of individual security questionnaires in enterprise procurement cycles.

Type I vs Type II: which one do you actually need?

The difference is about what the auditor is opining on, not about which report type is harder.

Type I confirms that your controls are suitably designed to meet the relevant criteria as of a specific date. The auditor reviews your policies, procedures, and control configurations, but does not test whether those controls ran consistently over time. A Type I engagement is faster to complete and costs less. It is a reasonable starting point for organizations that are new to SOC reporting or that need to demonstrate a baseline before committing to a longer observation period.

Type II confirms both design and operating effectiveness across a defined observation period. Observation periods commonly run six to twelve months, though some engagements use a shorter initial window of three to six months for a first-time Type II. The auditor samples evidence from throughout the period, which means gaps in logging, inconsistent access reviews, or undocumented exceptions will surface.

1. Start with Type I when your control environment is new, when you are preparing for a first-time audit, or when a prospect needs a quick signal of your security posture before a longer engagement.
2. Move to Type II when enterprise buyers require it as a procurement condition, when your controls have been operating consistently for at least six months, or when you are renewing an existing SOC 2 and want to demonstrate sustained effectiveness.
3. Skip Type I entirely if your controls are already mature and well-documented. Some organizations with strong existing programs go directly to Type II and complete the observation period faster.

Enterprise buyers commonly require Type II for procurement acceptance because a Type I opinion alone does not tell them whether your controls actually ran as designed. A vendor with a Type I report and no Type II is often treated the same as a vendor with no report at all in high-stakes procurement.

Auditor opinions on a Type II report are either unqualified (controls operated effectively with no material exceptions) or qualified (one or more control failures were noted). A qualified opinion is not automatically disqualifying, but buyers will read the exceptions carefully. Addressing exceptions before the audit fieldwork period ends is far less costly than explaining them to a procurement committee afterward.

When does an organization need both SOC 1 and SOC 2?

Some service providers genuinely need both reports because they serve two distinct stakeholder groups with different questions. A CFO and their external auditor want to know whether your controls protect the accuracy of financial statements. A CISO or vendor risk manager wants to know whether your controls protect customer data. Those are different questions, and a single report does not answer both.

Integrated attestation programs can test overlapping controls simultaneously, which reduces duplicate evidence requests and lowers overall audit burden. The key is coordinating scope and timing with your CPA firm upfront.

Common scenarios where both reports become necessary:

• A benefits administration platform that processes payroll data (SOC 1) and also stores employee health information (SOC 2 with Privacy criterion)
• A fund administrator that manages financial records (SOC 1) and operates a client-facing portal with sensitive investor data (SOC 2)
• A cloud infrastructure provider whose services affect clients' financial systems (SOC 1) and whose security posture is evaluated by enterprise security teams (SOC 2)

When not to pursue both:

• Your service has no direct impact on client financial statements. SOC 2 alone is sufficient.
• Your only stakeholder asking for a report is an external auditor reviewing ICFR. SOC 1 alone covers the requirement.
• Budget and timeline constraints make parallel engagements impractical. Sequence them: SOC 1 first if financial reporting is the immediate driver, SOC 2 first if procurement is stalling.

The same access control that restricts who can modify financial records (a SOC 1 control) often maps directly to the Security criterion in SOC 2. Documenting it once and referencing it in both report scopes is standard practice in integrated programs.

What do SOC controls look like in practice, and how do they map to other frameworks?

Trust Services Criteria translate into concrete technical and process controls that most security-conscious organizations already have in some form. The gap is usually documentation and consistency, not the controls themselves.

Common technical controls and their Trust Services Criterion mapping:

• Identity and access management (IAM): Maps to Security. Controls include role-based access, least-privilege provisioning, MFA enforcement, and quarterly access reviews.
• Centralized logging and monitoring: Maps to Security and Availability. Controls include SIEM integration, log retention policies, and alert thresholds for anomalous activity.
• Network segmentation: Maps to Security. Controls include firewall rule sets, VLAN configurations, and documented network diagrams.
• Backup and recovery: Maps to Availability. Controls include automated backup schedules, tested recovery procedures, and documented RTO/RPO targets.
• Change management: Maps to Processing Integrity. Controls include change request workflows, testing requirements, and approval gates before production deployment.
• Encryption: Maps to Confidentiality. Controls include encryption standards for data at rest and in transit, key management procedures, and certificate lifecycle management.

Alignment with NIST CSF and ISO 27001: The Security criterion in SOC 2 overlaps substantially with NIST Cybersecurity Framework functions (Identify, Protect, Detect, Respond, Recover) and with ISO 27001 Annex A controls. Organizations that have already mapped controls to NIST CSF or hold an ISO 27001 certification can reuse much of that documentation for SOC 2 evidence. The audit scope and testing methodology differ, but the underlying control library is largely the same.

For auditors to test a control, it must be documented in a policy or procedure, implemented in a system or process, and supported by evidence that it ran as described. A control that exists in practice but lacks documentation is, from an auditor's perspective, a gap.

Pro Tip: Scope your SOC 2 system description carefully. Including every internal tool and system inflates audit scope and cost. Focus on systems that store, process, or transmit in-scope data, and document the boundary explicitly in your system description.

How do you prepare for a SOC 1 or SOC 2 audit?

Preparation is where most organizations either save significant time and cost or create expensive problems for themselves. A formal readiness assessment is the highest-ROI pre-audit activity: it identifies gaps before auditors do, prevents qualified opinions, and reduces rework during fieldwork.

Pre-audit readiness checklist

1. Governance and ownership: Assign a named control owner for each in-scope control. Auditors will ask who is responsible.
2. Policy inventory: Confirm that written policies exist for information security, access management, change management, incident response, and business continuity. Undated or unsigned policies are a common finding.
3. Evidence inventory: Identify what evidence exists for each control and where it lives. Gaps in logging or missing approval records are the most common audit surprises.
4. Technical controls baseline: Run a vulnerability scan and review access provisioning records before the audit window opens. Remediate critical findings.
5. Scope definition: Document which systems, applications, and data flows are in scope. A clear system description prevents scope creep during fieldwork.
6. Auditor selection: Choose a licensed CPA firm with SOC experience in your industry. Ask for sample reports and references from similar-sized clients.

Realistic timeline

• Readiness assessment: 4–12 weeks, depending on the maturity of your existing control environment.
• Remediation sprints: 4–16 weeks for organizations with significant gaps in policy, logging, or access controls.
• Type I engagement: 4–8 weeks from kickoff to report issuance.
• Type II observation period: 6–12 months, followed by 4–8 weeks of auditor fieldwork and reporting.

Primary cost drivers

• Number of in-scope systems and applications
• Number of Trust Services Criteria included
• Maturity of existing controls (more gaps = more remediation = more cost)
• Auditor rate card vs. bundled readiness and audit services
• Whether you use a vCISO or internal staff to manage evidence collection

Questions to ask at kickoff

• What is included in your readiness assessment, and will you provide a gap report?
• How do you handle exceptions found during the observation period?
• What evidence formats do you accept, and how do you collect it?
• What is your process if a control fails during the observation window?

SOC reporting is not a statutory requirement but frequently becomes a contractual necessity. Failing to produce a requested report can stall enterprise procurement and, in regulated industries, signal a risk posture that buyers are not willing to accept.

Common gaps, remediation tasks, and realistic timelines

The most consistent finding in readiness assessments is not a missing firewall or a failed penetration test. It is missing documentation. Controls that exist in practice but are not written down, approved by management, or supported by evidence trails are the primary source of qualified opinions and remediation rework.

The most common gaps, in rough order of frequency:

• Missing or informal policies: Information security policies that have never been formally approved, version-controlled, or distributed to staff.
• Inadequate logging: Systems that generate logs but do not retain them long enough, do not centralize them, or do not have alerting configured.
• Incomplete evidence trails: Access reviews that happened verbally, change approvals that were never documented, or incident response actions that were not logged.
• Immature change control: Developers pushing changes directly to production without a documented approval workflow.

Typical remediation tasks and their relative effort:

• Policy drafting: Moderate effort, fast turnaround. A vCISO or compliance consultant can produce a policy library in two to four weeks.
• IAM improvements: Moderate to high effort. Implementing MFA, cleaning up stale accounts, and formalizing access reviews takes four to eight weeks depending on the number of systems.
• Log centralization: High effort for organizations without a SIEM. Deploying and tuning a logging solution can take six to twelve weeks.
• Formalized change management: Moderate effort. Implementing a ticketing-based change workflow in an existing tool like Jira or ServiceNow is typically a two to four week project.

Pro Tip: Fix high-impact, low-effort controls first. Formalizing your access review process and getting management sign-off on your security policy costs almost nothing and closes two of the most common audit findings before the auditor arrives.

Type II observation periods run six to twelve months, which means a control failure in month two of a twelve-month window creates a finding that cannot be retroactively corrected. Starting remediation before the observation period opens is not optional for organizations that want a clean opinion.

Key Takeaways

SOC 1 maps to financial reporting controls (ICFR) and is requested by auditors; SOC 2 maps to security and data protection controls under the AICPA Trust Services Criteria and is requested by customers, security teams, and procurement.

The real gap most organizations miss in SOC readiness

The conventional wisdom on SOC compliance tends to focus on controls: build MFA, centralize your logs, write your policies, and you are ready. That framing is not wrong, but it misses the more consequential variable, which is evidence consistency over time.

A Type II audit is not a snapshot. It is a twelve-month record of whether your controls actually ran as documented. Organizations that treat SOC readiness as a one-time project, complete their remediation, and then let evidence collection slip during the observation period are the ones that end up with qualified opinions on controls they genuinely have in place. The auditor cannot give credit for a control that ran nine months out of twelve without documented exceptions and management responses for the three months it did not.

The second underestimated factor is auditor independence. SOC reports carry weight precisely because the CPA firm issuing them has no financial interest in your compliance outcome. A vendor that offers to "certify" your SOC 2 status is not issuing a SOC report under AICPA standards. That distinction matters to every enterprise buyer who knows how to read a report.

For most regulated organizations, the practical answer is to treat SOC readiness as an ongoing operational discipline, not a project with a finish line. A vCISO embedded in your security program can maintain evidence collection, monitor control performance, and coordinate with your CPA firm year-round, which is a materially different outcome than scrambling to reconstruct twelve months of evidence two weeks before the audit window closes.

CisoSafe helps regulated organizations reach SOC readiness faster

Regulated organizations in legal, energy, and healthcare sectors face a specific challenge: SOC readiness requires sustained operational discipline, but most do not have a full-time CISO to own it. CisoSafe fills that gap directly.

CisoSafe's vCISO retainer model gives your organization a dedicated security leader who manages SOC readiness from gap assessment through auditor coordination, without the cost of a full-time executive hire. The AI-powered compliance platform automates evidence collection across 50+ frameworks, tracks control performance in real time, and generates audit-ready documentation. For organizations pursuing SOC 2 for the first time or preparing for a Type II renewal, CisoSafe's readiness assessments identify the specific gaps most likely to produce a qualified opinion and prioritize remediation by impact and effort.

Services include vCISO retainers, SOC readiness assessments, evidence collection automation, policy development, and direct auditor coordination. CisoSafe serves clients across the United States. To discuss your SOC readiness timeline and scope, schedule a discovery call with the CisoSafe team.

Official references and suggested further reading

The sources below are the authoritative starting points for SOC compliance research. Each one serves a different purpose in the compliance process.

• AICPA SOC Suite of Services: — The AICPA's central resource page for all SOC engagements. Start here for the official standards, CPA firm guidance, and links to the Trust Services Criteria publication. This is the primary source for understanding what the AICPA requires of both service organizations and auditors.

• PwC SOC Reporting Overview: — PwC's practitioner-level overview of the full SOC suite, including guidance on integrated attestations and when organizations need both SOC 1 and SOC 2. Useful for procurement teams and CFOs evaluating vendor risk programs.

• Infosec Institute: SOC 1 vs SOC 2 vs SOC 3 Overview: — A clear comparison of all three SOC report types, including the distinction between the confidential SOC 2 and the public SOC 3. Useful for organizations deciding which report type to share with different stakeholder groups.

• CisoSafe: SOC 2 Compliance Explained for Business Leaders: CisoSafe's internal guide for business stakeholders who need to understand SOC 2 requirements, typical controls, and what enterprise buyers expect. A practical complement to the AICPA's technical standards.

Recommended

• SOC 2 Compliance Explained for Business Leaders
• SOC 2 Compliance for Law Firms: 2026 Guide
• OT Cybersecurity for Regulated U.S. SMBs: 2026 Guide
• Best Complianta.co Alternatives for US Businesses 2026