SOC2 for CRM: What It Means and Why Your Vendor Needs It

When evaluating a CRM platform, you will inevitably encounter the claim "SOC2 certified" or "SOC2 compliant." It appears on pricing pages, in security documentation, and in sales conversations as a shorthand for "we take security seriously." But most buyers — and, candidly, most CRM vendors' own sales teams — cannot explain what SOC2 actually certifies, what it does not, and why it matters specifically for the customer data your CRM holds. Understanding SOC2 properly is the difference between ticking a procurement checkbox and genuinely assessing whether your vendor protects your data.

This guide explains SOC2 in plain English: what it is, how the audit works, what the Trust Service Criteria mean in practice, and what to look for when your CRM vendor waves the SOC2 badge. It also explains why SOC2 alone is necessary but not sufficient — and what additional protections matter for Australian businesses operating under the Privacy Act.

What SOC2 actually is

SOC2 (System and Organization Controls 2) is a reporting framework developed by the American Institute of Certified Public Accountants (AICPA). It is not a certification in the way ISO 27001 is a certification — it is an audit report produced by an independent CPA firm that evaluates a service organisation's controls against five Trust Service Criteria:

• Security (the "Common Criteria" — required in every SOC2 report): protection against unauthorised access, both physical and logical.
• Availability: the system is available for operation and use as committed or agreed.
• Processing Integrity: system processing is complete, valid, accurate, timely and authorised.
• Confidentiality: information designated as confidential is protected as committed or agreed.
• Privacy: personal information is collected, used, retained, disclosed and disposed of in conformity with commitments.

A SOC2 report can cover any combination of these criteria, but only Security is mandatory. Many vendors' SOC2 reports cover Security alone, which means the audit evaluated whether they have reasonable controls to prevent unauthorised access — but said nothing about availability, data integrity, confidentiality or privacy handling. When a vendor says "SOC2 compliant," your first question should be: "Which Trust Service Criteria does your report cover?"

Type I versus Type II: the distinction that matters

SOC2 reports come in two types, and the difference is critical:

• Type I evaluates the design of controls at a specific point in time. It answers: "Did the organisation have the right controls in place on this date?" It says nothing about whether those controls actually worked over time.
• Type II evaluates the design and operating effectiveness of controls over a defined period — typically 6 to 12 months. It answers: "Did the controls work consistently throughout this period?"

A Type I report is a snapshot. A Type II report is evidence of sustained discipline. When evaluating a CRM vendor, always ask for a Type II report. A vendor with only a Type I may have put controls in place for the audit date but not maintained them. The Type II report is what demonstrates that security is an ongoing operational practice, not a one-off exercise.

What SOC2 means for your CRM data

For a CRM platform specifically, the SOC2 Security criterion evaluates controls in areas directly relevant to your customer data:

• Access controls: How does the vendor restrict who can access the system and the data within it? This includes authentication mechanisms (MFA, password policies), role-based access, and how they manage employee access to customer environments.
• Network security: How is data protected in transit and at rest? Encryption standards, firewall configurations, intrusion detection.
• Incident management: Does the vendor have documented, tested procedures for detecting, responding to and reporting security incidents?
• Change management: How are changes to the platform tested, approved and deployed? Uncontrolled changes are a common source of security vulnerabilities.
• Monitoring and logging: Does the vendor maintain audit trails and actively monitor for anomalous access patterns?

When these controls are in place and verified by an independent auditor, you have reasonable assurance that the vendor is protecting your customer data against unauthorised access. That assurance matters — it is the baseline that allows you to trust a third-party platform with the personal information your business is legally responsible for under the Privacy Act.

What SOC2 does not cover

SOC2 is necessary but not sufficient, and understanding its limitations is as important as understanding its strengths:

• SOC2 does not evaluate data residency. A vendor can have a perfect SOC2 report while replicating your data across data centres in the US, Europe and Asia. SOC2 says nothing about where data physically lives — which is precisely the question APP 8 of the Privacy Act asks.
• SOC2 does not evaluate local legal compliance. The report assesses the vendor's internal controls, not their compliance with the Australian Privacy Act, the APPs, or the NDB scheme. A SOC2-compliant US vendor may still fail your APP 8, APP 11 or NDB obligations.
• SOC2 does not evaluate AI data handling. If the vendor routes customer data to AI model providers for processing, SOC2 may or may not cover those sub-processors depending on the scope of the audit. Always ask whether AI processing is within the SOC2 boundary.
• SOC2 does not evaluate your configuration. The report covers the vendor's controls. If you leave MFA disabled, grant every user admin access, or export data to insecure locations, the vendor's SOC2 report provides no protection.

What to ask your CRM vendor about SOC2

Armed with this understanding, here are the questions that separate a meaningful SOC2 from a marketing badge:

• "Is this a Type I or Type II report?" Only Type II demonstrates sustained effectiveness.
• "Which Trust Service Criteria are covered?" Security alone is the minimum. Availability, Confidentiality and Privacy coverage is stronger.
• "Can we review the report?" SOC2 reports are typically shared under NDA. A vendor that refuses to share the report at all is waving a badge they will not let you verify.
• "Does the audit scope include AI processing and sub-processors?" If customer data flows to third-party AI providers, those flows should be within the SOC2 boundary.
• "Where does the audit say data is stored and processed?" SOC2 may describe the infrastructure in scope — check whether it includes Australian data centres.

Fulcrum CRM is built with SOC2-ready security architecture: encryption at rest (AES-256) and in transit (TLS 1.2+), role-based access controls, comprehensive audit logging, and Australian data hosting. The platform's security posture is designed to satisfy the SOC2 Trust Service Criteria — not as a marketing badge, but as the operational foundation that Australian businesses need to meet their own Privacy Act obligations. For a deeper look at how these technical controls work in practice, see our CRM security and data protection guide.

SOC2 in the context of Australian compliance

For Australian businesses, SOC2 is one layer in a compliance stack, not the whole stack. Your obligations under the Privacy Act — data residency (APP 8), security (APP 11), breach notification (NDB scheme) — require protections that SOC2 alone does not guarantee. The strongest posture combines a SOC2-verified vendor with Australian data residency, documented AI data flows, and your own CRM configuration disciplines: MFA enforced, least-privilege access, audit logging enabled, and retention rules set.

Think of SOC2 as the vendor's commitment to security hygiene, and your CRM configuration as your commitment to using that secure platform responsibly. Both are necessary. Neither alone is sufficient. For more on how the Privacy Act specifically applies to your CRM, see our guide on CRM and the Privacy Act in 2026. And to see how Fulcrum CRM's security features compare to the alternatives, visit our pricing and features page.