Blog · Published 2026-11-04
SOC 2 in an acquisition: what a buyer checks before closing, and what happens to the report after.
A SOC 2 report describes a company's controls as they were during the period the auditor examined, run by the people and systems in place then. An acquisition can change those people, systems and owners, so a buyer should check what the existing report covers, which customer contracts promise a report, and who will run the controls and commission the next examination after closing. The report does not transfer as a guarantee of the future.
What a SOC 2 report is, in plain words
SOC 2 is an examination by an independent CPA firm of a service organization's controls. The AICPA, which says it "promulgates the professional standards for SOC engagements", titles its guide for these engagements as reporting on controls relevant to "Security, Availability, Processing Integrity, Confidentiality, or Privacy" (AICPA SOC 2 page, read 4 November 2026). A report does not have to cover all five; the scope section says which ones it covers.
Reports come in two types. A Type 1 report addresses the design of controls at a point in time. A Type 2 report also addresses whether the controls operated over a period. The report itself states its type, its period and the system it covers, and those three facts are where diligence starts.
The criteria are not frozen. On the same page the AICPA lists exposure drafts of proposed 2027 SOC 2 Trust Services Criteria and Description Criteria, dated 26 October 2026. If you are buying a company whose next examination falls after any change takes effect, ask its auditor what the change means for that examination.
What to check in diligence
| Check | What to look at | Why it matters for the deal |
|---|---|---|
| Scope | Which system and which of the five categories the report covers. | A report on one product says nothing about another product the company also sells. |
| Type and period | Type 1 or Type 2, and the dates of the period examined. | An old period or a Type 1 report gives less assurance than customers may assume. |
| Exceptions | Any exceptions the auditor noted, and management's response. | An exception is a known weakness you will inherit. |
| Carved-out vendors | Subservice organizations, such as a hosting provider, excluded from the scope. | The company's security depends on vendors whose own reports you may need to read. |
| User entity controls | Controls the report expects customers to run themselves. | Shows where responsibility was placed on customers, and what customers may expect from you. |
| Contract promises | Customer contracts and security questionnaires that promise a current report or a certification. | A promise the company cannot keep after closing is a breach risk, not a compliance detail. |
| Who runs the controls | Named owners of key controls, such as access reviews and change management. | If the founder or one engineer runs them and leaves at closing, the next period starts without them. |
What changes after closing
Nothing in the report changes on the day of closing; it remains a description of a past period. What changes is the organization that has to produce the next one. Common points to plan for:
- Ownership and governance. Board, management and the people accountable for controls may change, and the next system description will need to reflect that.
- Systems and vendors. Moving the product onto the buyer's infrastructure, identity provider or tools changes the system the auditor examines.
- Gaps between periods. Customers who expect a current report may ask for a letter from management covering the time between the end of the last period and today. Ask how the company has handled that request before.
- Integration with a buyer's own program. If you already have a SOC 2 program, decide whether the acquired product joins your scope or keeps its own report for a while. Ask the auditors of both before you announce anything to customers.
- Cost and timing. We give no cost or duration; both depend on scope and auditor. Get a written proposal for the next examination during diligence, so it is in your plan and not a surprise.
When the target has no SOC 2 report
Many small software companies do not have one. That is not by itself a reason to walk away, but it changes the questions. Read the security questionnaires the company has answered for customers, because those answers are promises. Check the contracts for any obligation to obtain a report. Then estimate, with an advisor, what it would take to meet the customers' expectations after closing.
Security promises in contracts belong in the same review as the other contract terms in the software acquisition checklist. How your own deal documents should be protected during the process is a separate question, covered in deal document security and data residency.
Where a document-reading tool helps
A SOC 2 report, a security questionnaire and a set of customer contracts are documents, so the cross-check between them is reading work: does the contract promise what the report covers, and does the CIM describe security the way the report does? Deal OS reads the documents you upload and cites each finding to its page; it does not audit controls, and it is not a substitute for the auditor or a security specialist. See the sample brief and pricing.
Worked example from the sample brief
The sample brief is a synthetic fire and life-safety company, not a software business. These four findings are quoted from it because they are the same kind a software buyer meets: a data claim, a contract question and a recurring revenue definition. The contract and data points are the ones a SOC 2 review sits next to:
- Contract transfer left open by the seller. Contract assignability is unreviewed: "The seller has not undertaken a review of change-of-control or assignment provisions across the contract base" (CIM page 19).
- A data claim contradicted by the documents. On the management call the seller said "exporting the data out is no problem at all". The brief marks the statement contradicted, because the CIM says on page 16 that "the seller notes that data export from this system has not been tested."
- A data risk turned into a diligence step. The brief files the same point as missing information, "Core operating data may not be exportable", and says to test data export during diligence, not after close.
The example is Sentinel Fire & Safety, Inc., a synthetic company built to show the product. Nothing in it describes a real business, and the same output shape applies to a real data room. See the whole thing at /sample-brief.
Questions
Frequently asked questions.
Does a SOC 2 report transfer to the buyer in an acquisition?
The report stays a description of the controls during the period examined. It does not promise anything about the period after closing, when people, systems and owners may change.
How does an acquisition affect SOC 2 compliance reporting?
It can change the people who run controls, the systems in scope, the vendors and the governance described in the next report. Plan the next examination, and any interim letter customers expect, during diligence.
What should a buyer check in a target's SOC 2 report?
The scope and categories covered, the type and period, any exceptions and management's responses, carved-out vendors, the controls expected of customers, and who runs the key controls today.
Is it a problem if a small software company has no SOC 2 report?
Not by itself. Read the security questionnaires it has answered and the contract obligations it has accepted, and estimate with an advisor what meeting those promises would take after closing.
Are the SOC 2 criteria changing?
The AICPA SOC 2 page lists exposure drafts of proposed 2027 Trust Services Criteria and Description Criteria, dated 26 October 2026. Ask the target's auditor what any change means for its next examination.
See it on a deal.
Open a real brief on a synthetic deal without an account, or check how a single deal is priced.
