SOC 2 Type II has become the de facto baseline credential for SaaS vendors selling to enterprises. Accounting firms evaluating cloud-based audit tools routinely ask whether a vendor is SOC 2 compliant, and vendors routinely answer "yes." Neither party typically looks closely at what that report actually says, when the covered period ended, or what the exceptions section contains. The certification is treated as a binary — compliant or not — rather than as a detailed document worth reading.
For accounting firms, this matters more than it does for most enterprise software buyers. Client financial data — the raw general ledger, journal entry population, trial balance — is the most sensitive operational data most companies have. Before that data touches a cloud system your firm doesn't control, you should understand exactly what the vendor's SOC 2 report covers and what it doesn't.
What SOC 2 Type II Is
A SOC 2 Type II report is an attestation by an independent CPA firm that a service organization's controls over specified trust service criteria were operating effectively during a defined examination period. The typical examination period is six to twelve months. The report covers five potential Trust Services Categories: Security (always included), Availability, Processing Integrity, Confidentiality, and Privacy. A vendor that says they are "SOC 2 Type II certified for Security and Availability" has had an independent auditor verify that their security and availability controls operated effectively during the examination period.
Three things a SOC 2 report does not guarantee: that the controls will continue to operate effectively after the examination period ends, that the examination covered the specific system components you're using, and that there are no material weaknesses that were identified but described as not meeting the report's threshold for formal exception. The audit opinion language is the key — a "qualified opinion" or "modified opinion" means the auditor found something significant. Most reports have unqualified opinions, but the exceptions section is where the substance is, regardless of opinion type.
The Questions That Reveal Actual Data Handling Practices
Asking "do you have SOC 2 Type II?" is the wrong question. The questions that reveal actual data handling for accounting firm purposes:
Where does client data physically reside? The vendor should be able to tell you the cloud provider (AWS, Azure, GCP), the geographic region, and the specific services used for data storage. If the answer involves regions outside the United States, you have a legal and client notification question to address before proceeding. Many engagement letters and state CPA board regulations require client notification or consent for data processing outside specific jurisdictions.
Is client data processed on shared or dedicated infrastructure? Shared infrastructure means your client's data is stored on the same physical hardware as other customers' data. This is normal for cloud services and not inherently a problem, but the isolation architecture matters. Tenant isolation via database-level encryption with customer-specific keys is meaningfully different from tenant isolation via schema separation in a shared database. Ask specifically how tenant isolation is implemented and what the blast radius would be if another customer's credentials were compromised.
Who at the vendor company can access client data? The vendor's support team, engineers, and data science team are all potential access points. The question is what controls exist over that access. A well-designed system should have role-based access controls that limit data access to specific authorized personnel for specific documented purposes, with all access logged and reviewed. Ask for the access control policy and the most recent access log review date.
What happens to client data on contract termination? When an accounting firm stops using the platform, what happens to the client financial data that was processed through it? The vendor should have a documented data deletion policy with a specific timeline and a mechanism for the firm to verify deletion. Retention of client financial data after contract termination is a data protection problem and a potential independence issue.
How AuditPulsar's Architecture Addresses These Questions
We built AuditPulsar with the assumption that accounting firms would ask exactly these questions — and that the firms most concerned about data handling would be the most sophisticated potential customers. The architecture reflects that.
Client data never flows to AuditPulsar's infrastructure. The detection engine runs inside the accounting firm's own cloud tenant — either their AWS account or Azure subscription. The platform is deployed as a containerized application that the firm's IT team provisions in their environment using a Terraform configuration we provide. Our servers handle authentication and license management; they never see the client's financial data. The data stays in the firm's environment from ingestion through scoring through export.
This architecture means the relevant SOC 2 controls for data storage are not ours — they're the accounting firm's cloud provider's controls, which are already subject to the firm's own security posture. We are SOC 2 Type II certified for the components of the platform that do operate on our infrastructure (the authentication service, the license management service, the update delivery service), and that report is available under NDA for prospects in due diligence. But the report won't answer questions about client data handling because our infrastructure doesn't handle client data.
Reading the Exceptions Section
For any vendor whose architecture does involve processing client data on shared infrastructure, the SOC 2 exceptions section is where actual risk assessment starts. The exceptions section describes control deviations identified during the examination period — instances where the control didn't operate as described, or didn't operate at all during part of the period.
Not all exceptions are material. Common exception types include: control procedures that were documented in the vendor's system description but not performed during a specific period due to personnel changes, automated controls that had brief operational gaps due to system updates, and access reviews that were performed but on a delayed schedule relative to the policy requirement. These are operationally significant and worth tracking but don't necessarily indicate a data security risk.
Exceptions that warrant closer attention: user access to production data that wasn't reviewed on schedule (indicates that unauthorized data access may not have been detected), encryption at rest controls that had documented failures, and subservice organization (sub-processor) controls that weren't independently verified. For accounting firms, that last category is particularly relevant — it means the vendor is relying on a third party for some of its data handling, and the vendor's SOC 2 report may not provide full coverage of that third party's controls.
The Vendor Assessment Checklist
Before approving a cloud audit tool for use with client financial data, the partner responsible for the technology decision should verify:
Has the firm's engagement letter language been updated to disclose the use of this tool? Many engagement letter templates are silent on specific technology vendors. If client data will be processed by a third-party tool, the engagement letter should disclose this and obtain client acknowledgment.
Is the SOC 2 report current? The examination period should have ended within the past twelve months. A report with an examination period ending eighteen months ago is stale — it covers controls as they existed well before the current engagement, and a lot can change in a vendor's infrastructure in eighteen months.
Are the trust service categories covered appropriate for the data being processed? If you're processing client financial data, at minimum the Security and Confidentiality categories should be covered by the examination. A Security-only SOC 2 doesn't cover how the vendor handles the confidentiality of the data they're processing.
Has someone read the report, not just verified it exists? The report is a document with substantive content. It describes the vendor's control environment, the tests performed, and the results. Reading it — or delegating that reading to your firm's risk management function — is the only way to know what it actually says.
The Independence Consideration
One dimension that often goes unexamined: does the use of a specific audit tool create independence or objectivity issues? If the platform vendor has equity investors who are also audit clients, or if the vendor's data practices could create an undisclosed commercial relationship between the auditor and a party with a financial interest in the audit outcome, there's an independence question.
This is not hypothetical. Several audit technology vendors have received investment from entities affiliated with large accounting firms. When those firms use those tools on clients, the independence analysis requires examining whether the investment relationship creates an indirect financial interest that should be disclosed or that precludes use of the tool on certain engagements. The AICPA's independence rules and the PCAOB's independence requirements both have provisions that can be triggered by these arrangements.
The simplest protection: use tools where the vendor has no commercial relationship with the entities being audited and no financial ties to the audit firm's networks. SOC 2 certification is necessary but not sufficient — the full due diligence includes the commercial and independence dimensions that a data security certification doesn't address.