Skip to main content

SOC 2 — System and Organization Controls 2

SOC 2 (System and Organization Controls 2) is an attestation report defined by the American Institute of Certified Public Accountants (AICPA). An independent CPA firm examines a service organization’s controls against the AICPA Trust Services Criteria and issues a detailed report on their design and, in the Type II variant, their operating effectiveness. For US buyers of cloud software, requesting a vendor’s current SOC 2 report is standard due diligence — and for SaaS ERP in particular, because the system holds financial records, employee data, and customer data, the vendor’s control environment effectively becomes part of your own.

The Trust Services Criteria

SOC 2 examinations are scoped against five criteria categories: Security (the common criteria, included in every SOC 2 report), Availability, Processing Integrity, Confidentiality, and Privacy. The service organization chooses which categories beyond Security are in scope, typically based on customer commitments. The criteria are aligned with the COSO internal-control framework. For an ERP vendor, Security plus Availability is a common baseline; Confidentiality and Processing Integrity appear frequently; Privacy remains the least commonly included category.

Type I vs. Type II

A Type I report assesses whether controls are suitably designed at a single point in time. A Type II report assesses design and operating effectiveness over a review period — commonly six to twelve months — with documented test procedures and results for each control. Type II therefore carries far more evidence value: it shows the controls actually ran, not merely that they exist on paper. Vendors early in their compliance journey often start with a Type I and move to annual Type II cycles. Because report periods end before your contract date, vendors issue bridge letters (gap letters) confirming no material control changes since the last period.

Why SOC 2 is standard due diligence for SaaS ERP

Three drivers make SOC 2 requests routine in US software procurement. First, financial audits: companies whose financial statements are audited must demonstrate oversight of service providers that process financial data, and the ERP vendor is the primary case. Second, flow-down: enterprise customers push security requirements into their suppliers’ contracts, so even a 150-person manufacturer gets asked about its vendors’ controls. Third, cyber-insurance and security questionnaires reference third-party attestations. A current SOC 2 Type II shortens all three conversations. Note that SOC 2 reports are restricted-use documents: vendors share them under NDA, today usually through a trust portal, rather than publishing them.

How to read a SOC 2 report

Four things matter more than the report’s existence. First, the auditor’s opinion — unqualified or qualified. Second, exceptions in the test tables and how management responded; a handful of minor exceptions with credible remediation is normal, repeated exceptions in access management are not. Third, complementary user entity controls (CUECs): controls the report assumes you, the customer, operate — typically user access reviews, single sign-on configuration, and monitoring of the application’s audit trail. Unassigned CUECs are a common audit finding on the buyer’s side. Fourth, subservice organizations: most SaaS ERP runs on AWS, Azure, or Google Cloud under the carve-out method, meaning hosting controls live in the hyperscaler’s own SOC reports, not the vendor’s. Also confirm the system description actually covers the product edition and hosting regions you are buying.

SOC 2 vs. ISO 27001 — and SOC 1, SOC 3

ISO 27001 is an international, certifiable standard for an information security management system, audited by accredited certification bodies; SOC 2 is an attestation report issued by a licensed CPA firm under AICPA standards. The outcomes differ in kind: an ISO 27001 certificate confirms a conforming management system in one page, while a SOC 2 report documents individual controls and test results across dozens of pages — which is why US due diligence favors SOC 2, and why vendors serving both markets often maintain both. SOC 1 covers controls relevant to customers’ financial reporting and matters when the vendor’s processing feeds your financial statements. SOC 3 is a general-use public summary without test detail; a SOC 3 badge on a website is not a substitute for the SOC 2 report in an evaluation. For US public-sector work, FedRAMP authorization is the relevant regime instead.

Selection criteria for US buyers

  • Ask for the Type II report, under NDA: a Type I or a public SOC 3 summary is a starting point, not evidence of operating effectiveness.
  • Check scope, period, and cadence: the report must cover the product you are buying, the period should be recent, and the vendor should attest annually with bridge letters in between.
  • Read exceptions and the opinion: qualified opinions and repeated access-control exceptions belong on the negotiation table, not in a filing cabinet.
  • Operationalize the CUECs: assign each complementary user entity control to an internal owner before go-live — your auditors will ask.
  • Map subservice organizations: know which controls sit with the hyperscaler and how the vendor monitors them.
  • Connect to data-privacy requirements: SOC 2 does not by itself satisfy privacy obligations; check how the vendor handles personal data separately (see data privacy in ERP).

Comparable terms

ISO 27001 is the closest international counterpart. SOC 1 and SOC 3 are sibling AICPA report types with different audiences. FedRAMP and StateRAMP govern cloud services sold to US government bodies. Workload-specific regimes such as HIPAA (health data) and PCI DSS (card data) can apply on top of SOC 2 depending on what the ERP processes.

Related Topics