SOC testing is a formal audit of the internal controls a service organization maintains over data, operations, or financial reporting, conducted by a licensed CPA firm under standards set by the American Institute of Certified Public Accountants.1AICPA & CIMA. System and Organization Controls: SOC Suite of Services The auditor issues a report that your clients, prospects, and their own auditors use to gauge whether your organization actually does what it says it does. A clean report can close deals. A report full of exceptions can kill them.
Which SOC Report You Need
The AICPA maintains several SOC offerings, and each answers a different question.1AICPA & CIMA. System and Organization Controls: SOC Suite of Services For most organizations, the choice comes down to SOC 1 or SOC 2.
SOC 1 evaluates controls relevant to a client’s financial reporting. If you process payroll, handle transactions, or touch data that flows into someone else’s financial statements, SOC 1 is what your clients’ auditors will ask for. The engagement is performed under AT-C Section 320 of the AICPA’s attestation standards.2AICPA & CIMA. AICPA SSAEs – Currently Effective
SOC 2 examines controls related to security, availability, processing integrity, confidentiality, and privacy. Most SaaS companies, data centers, and cloud providers pursue SOC 2. The report is a restricted-use document that can only be shared with parties who have a legitimate need, typically under an NDA.
SOC 3 covers the same criteria as SOC 2 but produces a general-use report you can post publicly. The trade-off is less detail. Two specialized reports round out the suite: SOC for Cybersecurity evaluates an organization’s enterprise-wide cybersecurity risk management program, and SOC for Supply Chain examines controls within a production, manufacturing, or distribution system.3AICPA & CIMA. SOC for Cybersecurity
The deciding factor between SOC 1 and SOC 2 is straightforward. If your service affects your clients’ financial statements, you need a SOC 1. If the concern is data security and operational reliability, SOC 2 fits. Some organizations maintain both.
The Five Trust Services Criteria
SOC 2 and SOC 3 evaluate controls against the Trust Services Criteria the AICPA originally published in 2017 and revised in 2022.4AICPA & CIMA. 2017 Trust Services Criteria With Revised Points of Focus – 2022 Security is always included. The other four are optional, chosen based on what your service does and what your clients expect.
- Security. Whether the system is protected against unauthorized access, physical and logical. This is the baseline and appears in every SOC 2.
- Availability. Whether the system stays operational and accessible as promised in your service-level agreements.
- Processing integrity. Whether the system processes data completely, accurately, and on time. This matters most when you handle transactions or calculations for clients.
- Confidentiality. Whether information the organization has designated as sensitive stays protected from collection through disposal.
- Privacy. Whether personal information is collected, used, stored, shared, and destroyed in line with published privacy commitments.
Confidentiality and privacy sound similar and target different things. Confidentiality covers any data you designate as sensitive, such as trade secrets or intellectual property. Privacy applies specifically to personal information about identifiable individuals.
Type I vs. Type II Reports
Every SOC engagement produces either a Type I or Type II report, and the difference matters more than most organizations realize going in.
A Type I report evaluates whether controls are properly designed at a single point in time. The auditor looks at how the system is set up on that date and issues an opinion on the design. It answers whether your controls make sense on paper. Type I reports work well for first-time examinations because they establish a baseline without months of historical evidence.
A Type II report goes further. The auditor tests whether controls actually operated effectively over a sustained period, typically three to twelve months. It is one thing to have a policy requiring background checks on new hires. It is another to prove that every hire over the past six months actually received one. Nearly every sophisticated client will eventually want a Type II report, so most organizations treat their first Type I as a stepping stone.
The observation window matters. A three-month window technically qualifies, but many clients view anything under six months with skepticism. The common approach is a twelve-month period aligned with your fiscal year, which simplifies renewals and keeps the report continuously relevant.
Who Can Perform the Audit
Only a licensed CPA firm can issue a SOC report. This is a legal requirement in every state, not a preference. Firms that are not licensed CPA practices cannot produce a SOC 1 or SOC 2 report the AICPA or report users will accept. The firm must also be independent from the organization being examined, meaning no financial interest in the client and no advisory work that would compromise objectivity.
Within the firm, the engagement team needs specific experience evaluating control design and operating effectiveness. Auditors who spend their careers on financial statement audits do not automatically have the technical background to assess a cloud environment’s access controls. Many firms bring in IT specialists for the more technical testing, though the CPA remains responsible for the overall opinion.
How Auditors Test Controls
Auditors rely on four techniques, and most controls get tested with a combination rather than just one.
Inquiry is the starting point. The auditor interviews the people responsible for a control to understand the workflow. These conversations provide context, but no experienced auditor will rely on inquiry alone. If someone says “we review access logs weekly,” the auditor will want proof.
Observation means watching a process happen in real time. The auditor might stand in the server room and watch a technician follow the decommissioning protocol for retired hardware, verifying drives are wiped before equipment leaves the building. Observation is valuable for physical security controls and manual handoffs that do not generate automatic logs.
Inspection is where the auditor examines documented evidence: system logs, signed authorization forms, configuration screenshots, access review records. This is the workhorse method. The auditor pulls a sample of records and checks whether the control operated as described. For automated controls, inspection of the configuration and output logs is often the only practical testing method.
Re-performance is the most rigorous technique. The auditor personally executes the control to see whether it works. If a system is supposed to block unauthorized transactions above a certain dollar threshold, the auditor will try to push one through. If an access request is supposed to require manager approval, the auditor will submit one and verify the workflow enforces it. Re-performance provides the highest level of assurance because it removes reliance on the organization’s own records.
Sample Sizes
A question that catches many organizations off guard is how many records the auditor will pull. The AICPA’s sampling guidance ties sample sizes to how often a control operates. A control that runs once a quarter generates four data points per year. A daily control generates hundreds.
As rough benchmarks: a quarterly control (four occurrences a year) is typically tested at two instances; a monthly control at two to four; a twice-monthly control at three to eight; a weekly control at five to nine. For daily or continuous controls with large populations, auditors use professional judgment to determine a representative sample; there is no fixed number. Automated controls that fire identically every time are often tested with smaller samples than manual controls. If the auditor finds even one exception in a small sample, expect testing to expand significantly.
What to Prepare Before Fieldwork
The pre-audit phase is where organizations either set up a smooth engagement or create months of headaches. Three documents form the foundation.
The system description is a narrative explaining what your service does, what infrastructure and software support it, who operates it, and what data flows through it. A well-scoped description keeps the auditor focused on the systems that matter and prevents scope creep. Draft it with your auditor’s input before fieldwork begins.
The control matrix maps each internal control to the applicable Trust Services Criteria (for SOC 2) or control objectives (for SOC 1). Think of it as a spreadsheet telling the auditor which policy satisfies which requirement and where the evidence lives. Without a clean matrix, auditors spend billable hours hunting for connections you could have laid out in advance.
The management assertion is a formal letter signed by your leadership stating that the system description is accurate and that the controls were designed and operating effectively during the examination period. This is not a formality. The auditor’s opinion is framed as a response to your assertion, so inaccuracies undermine the entire report.
Beyond these, gather employee handbooks, change management logs, access provisioning and de-provisioning records, incident response logs, and vendor management documentation before the auditor’s first day on site. Every hour the auditor spends waiting for evidence is an hour you are paying for.
Readiness Assessments
Organizations going through their first SOC examination should strongly consider a readiness assessment first. It is a dry run: the auditor walks through your environment, maps existing controls to the relevant criteria, identifies gaps, and delivers a letter summarizing what needs to be fixed. That gives you time to remediate before the clock starts on your actual examination period, which is particularly important for Type II engagements where an exception early in the observation window can taint the entire report.
The Engagement and Typical Costs
The engagement formally begins with an engagement letter defining scope, timeline, applicable criteria, and fees. During fieldwork the auditor gathers evidence using the methods above and documents findings as they go. At the close of the testing period, your management team provides a representation letter confirming that all facts presented are accurate and complete and that no material events have been withheld.
Audit fees vary widely based on the number of Trust Services Criteria included, the complexity of your infrastructure, and the length of the observation window. A Type I report for a straightforward environment might cost $10,000 to $25,000. A Type II report for a mid-market organization with moderate complexity generally runs $20,000 to $50,000 for the audit itself. Once you factor in remediation, tooling, and internal staff time, the total budget for a first-time SOC 2 program can reach $100,000 or more for larger organizations. Numbers vary by auditor and location, but these ranges are realistic for planning.
Reading the Auditor’s Opinion
The final report includes the auditor’s opinion, and this is the section your clients turn to first. There are four possible outcomes.
- Unqualified opinion. The controls were suitably designed and operating effectively. Minor exceptions may appear in the detailed findings, but overall the criteria (or control objectives, for SOC 1) were met. This is the outcome you want.
- Qualified opinion. The auditor found a material issue with the description or the controls, but the problem is limited to a specific area rather than affecting the report as a whole.
- Adverse opinion. The auditor found material issues pervasive enough to affect the overall reliability of the controls. This is a serious problem and will likely trigger difficult conversations with clients.
- Disclaimer of opinion. The auditor was unable to obtain enough evidence to form any opinion. This usually reflects a breakdown in cooperation rather than a control failure.
Exceptions and a clean opinion are not mutually exclusive. Most SOC reports contain at least a handful of exceptions, such as a single access review completed a week late or a terminated employee whose account was deactivated after the required window. What matters is whether the exceptions are isolated or point to a systemic breakdown. Sophisticated readers of SOC reports know the difference.
Who You Can Share the Report With
SOC 2 reports are restricted-use documents. The intended audience is your own leadership, current customers, prospective customers with a legitimate need, and those customers’ auditors. Most organizations require recipients to sign an NDA. Posting a SOC 2 report publicly or emailing it to anyone who asks violates the restricted-use designation.
SOC 3 reports are general-use. You can post them on your website, include them in sales materials, or distribute them freely. The trade-off is that a SOC 3 report contains a high-level summary of the auditor’s opinion without the detailed control descriptions, testing procedures, and exception findings that make a SOC 2 report useful for due diligence.
SOC 1 reports follow the same restricted-use model as SOC 2. They are intended for management, user entities, and user entities’ auditors.
Vendors, Customer Responsibilities, and Coverage Gaps
Almost every service organization relies on third-party vendors for some part of its infrastructure. Your application might run on a major cloud provider. Customer data might pass through a third-party payment processor. Backups might sit in a managed data center. The SOC framework calls these vendors subservice organizations, and there are two ways to handle them in your report.
The carve-out method excludes the vendor’s controls from your audit scope. Your system description identifies the vendor and the services it provides, and the report points readers to the vendor’s own SOC report. This is the standard approach when using established cloud providers or SaaS platforms that already maintain their own SOC 2 reports. Your responsibility is to monitor the vendor: review their report annually, check for a clean opinion, and evaluate whether any noted exceptions affect your service. If a subservice organization has no SOC report, you need another monitoring approach such as vendor questionnaires or periodic review meetings.
The inclusive method brings the vendor’s controls inside your audit scope. The auditor tests both sets of controls and the results appear in a single report. The vendor must provide its own management assertion and representation letter. This works when the vendor’s operations are deeply intertwined with yours or when the vendor lacks its own SOC report and your clients need consolidated assurance. The downside is significant: broader scope, higher cost, and full vendor cooperation throughout the engagement.
Complementary User Entity Controls
A detail that catches many organizations off guard when they first receive a vendor’s SOC report is the section listing complementary user entity controls, commonly abbreviated as CUECs. These are controls that you, the customer, must implement for the vendor’s controls to work as designed.
A cloud provider’s SOC 2 report might state that the provider enforces role-based access at the infrastructure level, while the CUEC section specifies that your organization is responsible for configuring user roles and removing access for terminated employees. Ignore that responsibility and the provider’s controls cannot fully protect your data. Your own auditors may flag the gap.
When you receive a vendor’s SOC report, pull the CUEC section and work through each item. Determine which apply to the services you actually use, check whether your existing controls address them, assign ownership for any gaps, and document how each applicable CUEC is satisfied. Update this documentation every time you receive a new report, because CUECs can change between audit cycles.
Bridge Letters
SOC reports cover a defined period, and there is almost always a gap between the end of one reporting period and the date the next report is issued. Clients who need continuous assurance during that gap often ask for a bridge letter.
A bridge letter is a document signed by your management team asserting that your controls have continued to operate as described in the most recent SOC report and that no significant changes have been made since the audit ended. It is not an audit opinion and does not carry the weight of a full SOC report, but it gives clients something concrete to rely on while the next examination is in progress.
The industry standard is that a bridge letter should cover no more than three months. Beyond that, the assurance becomes too thin to be meaningful, and clients will reasonably push for the new report. The best way to minimize bridge letter requests is to time your audit cycle so the new report is ready before the old one goes stale, ideally with overlapping coverage that eliminates gaps entirely.