SOC 2 Requirements in Vendor Contracts (2026)

SOC 2 is the security assurance report that most enterprise buyers now ask technology vendors to produce before they sign. Written well into a vendor contract, a SOC 2 requirement gives the customer ongoing proof that a vendor's security controls actually work, not just a promise that they exist. Written badly, it asks for a report that does not cover the right things, or that the customer never reads. This guide explains what SOC 2 is, the difference between the report types and criteria, and how to require and rely on it in a vendor security addendum. ## What SOC 2 is SOC 2 (System and Organization Controls 2) is an attestation report produced under standards of the American Institute of Certified Public Accountants (AICPA). An independent auditor examines a service organisation's controls and reports on whether they meet the applicable Trust Services Criteria. It is not a certification you pass or fail, like ISO 27001; it is an auditor's report describing the controls and the auditor's opinion on them. That distinction matters in drafting: you require a vendor to provide a SOC 2 report, you do not require it to be SOC 2 certified, because there is no such certificate. SOC 2 is most common in North America and among global SaaS vendors. In other regions, ISO 27001 certification is often the equivalent ask. Many vendors hold both, and a well drafted clause can accept either. ## Type I versus Type II There are two kinds of SOC 2 report, and the difference is important. - SOC 2 Type I describes the vendor's controls and assesses whether they are suitably designed at a single point in time. It answers "are the right controls in place today?"

• SOC 2 Type II assesses whether those controls operated effectively over a period, usually six to twelve months. It answers "did the controls actually work, consistently, over time?" Type II is the meaningful one for enterprise assurance, because design without operation proves little. A customer that wants real comfort should require a Type II report covering a period of at least six, preferably twelve, months, and a fresh report each year so there is no gap between reporting periods. ## The five Trust Services Criteria A SOC 2 report covers one or more of five Trust Services Criteria. Only Security is mandatory; the others are included if relevant to the service. - Security (the common criteria). Protection of systems against unauthorised access. Always included.
• Availability. Whether the system is available for operation as agreed, relevant where uptime matters.
• Processing integrity. Whether processing is complete, valid, accurate, and timely, relevant for transaction or data-processing services.
• Confidentiality. Protection of information designated as confidential.
• Privacy. Collection, use, retention, and disposal of personal information in line with the vendor's privacy notice. When requiring SOC 2, specify which criteria the report must cover. For a vendor handling personal data, Security alone is often not enough; Confidentiality and Privacy, and sometimes Availability, should be in scope. ## How to require SOC 2 in a vendor contract A useful SOC 2 clause, usually in a security addendum or the DPA, should require the vendor to: - Maintain a SOC 2 Type II report covering at least the Security criteria, and the other named criteria relevant to the service, refreshed at least annually with no gap between periods;
• Provide the report on request (at least yearly), along with any bridge or gap letter covering the period between the last report and the current date;
• Remediate exceptions. Say what happens if the report contains qualified opinions or noted exceptions: the vendor must have, or produce, a remediation plan;
• Allow an alternative. Accept an equivalent, such as a current ISO 27001 certificate with its statement of applicability, where the vendor does not produce SOC 2;
• Support audit rights. Where the SOC 2 report is insufficient, give the customer a right to further information or, for higher-risk vendors, an audit, consistent with the DPA's Article 28 audit rights;
• Notify on loss or lapse. Require notice if the vendor loses or fails to renew its report or certification. ## Reading the report, not just collecting it A SOC 2 requirement only protects the customer if someone actually reads the report. The parts that matter are the auditor's opinion (is it unqualified?), the scope (which systems and criteria, and which period), the list of controls, the noted exceptions, and the complementary user entity controls, which are the things the report assumes the customer itself will do. A clause that requires the report but no review turns a security control into a filing exercise. ## What each side wants The customer wants a current Type II report covering the right criteria, provided each year, with exceptions remediated and a fallback audit right for high-risk cases. For vendors handling personal data, it wants the SOC 2 obligation aligned with the DPA's security and audit terms. The vendor wants to satisfy security diligence by providing its existing report rather than completing every customer's bespoke questionnaire or submitting to frequent on-site audits. A well drafted clause serves both: the report does the heavy lifting, and audits are reserved for where the report is insufficient. ## Common mistakes to avoid - Requiring the vendor to be "SOC 2 certified," which does not exist; require a SOC 2 report.
• Accepting a Type I report as ongoing assurance, when only Type II shows controls operated over time.
• Not specifying the criteria, so a report covers only Security when the service handles personal data.
• Allowing gaps between reporting periods, with no bridge letter to cover the interval.
• Collecting the report but never reading the exceptions or the complementary user entity controls.
• No remediation path for qualified opinions or noted exceptions.
• Treating SOC 2 as a substitute for a DPA and SCCs; it is security assurance, not a data processing contract or a transfer mechanism. ## Keeping security assurance current across vendors SOC 2 obligations are easy to write and hard to keep on top of. Across many vendors you need to know which owe a report, which criteria each covers, when each report expires, whether the last one had exceptions, and whether a renewal is overdue. Chasing annual reports and reading each one by hand is slow, and a lapsed report can mean an unassured vendor holding your data. An AI contract workspace that extracts security and assurance obligations and tracks the renewal dates across your vendor contracts turns that into a monitored list. Adira drafts, reviews, and tracks contracts, including security obligations and key dates, in one place. More at Adira. The guidance above stands on its own. ## Bottom line SOC 2 is an independent report on a vendor's security controls, not a certification. In a vendor contract, require a SOC 2 Type II report, covering the Security criteria plus any others relevant to the service, refreshed each year with no gap, a remediation path for exceptions, an ISO 27001 alternative, and a fallback audit right. Then actually read the report. Remember SOC 2 is security assurance only; where the vendor processes personal data you still need a DPA and, for cross-border transfers, SCCs. Get specialist advice for high-risk vendors.