For most of 2023 and 2024, a company could complete a SOC 2 audit by connecting a compliance platform, running automated checks, and handing a tidy export to a CPA firm. The process worked, at least on paper. Reports were issued. Sales teams waved SOC 2 badges at procurement. Enterprise deals closed.
Then the cracks appeared.
In early 2026, allegations surfaced that a major compliance automation platform had generated SOC 2 reports for hundreds of clients using fabricated evidence and controls that existed only in a database, not in the actual operating environment. The resulting scrutiny landed on CPA firms, on the AICPA's attestation standards, and on the entire ecosystem of automated compliance tooling. The industry's response was immediate: raise the bar, document the methodology, and treat every evidence artifact as if it would be reviewed by a regulator.
If you are preparing for a SOC 2 audit today, the requirements your CPA firm will impose look materially different from what they were two years ago. This post explains exactly what has changed and what you need to do about it.
Who Can Perform a SOC 2 Audit
Before examining what CPA firms require, it is worth being precise about who is allowed to issue a SOC 2 report. SOC 2 is governed by the AICPA's attestation standards, specifically AT-C Section 205 (Examination Engagements), which forms part of SSAE No. 18. Under these standards, a SOC 2 attestation report can only be signed by a licensed CPA firm. Not a cybersecurity consulting firm. Not a GRC platform. Not a fractional CISO.
The firm must hold active AICPA membership through its CPA partners, maintain independence from the audited entity, and have passed a recent AICPA peer review. Independence is not a formality: if the firm helped you design or implement the controls being tested, the engagement is compromised and the resulting report can be challenged. This is why working with a readiness firm that is separate from your attestation auditor is not just good practice. It is structurally necessary for a defensible report.
Certification bodies (CBs) operate under a parallel but distinct framework. If you are pursuing ISO 27001, your certificate is issued by an accredited CB, not a CPA firm. The CB must hold accreditation from a national body such as UKAS in the UK, DAkkS in Germany, or ANAB in the US. Both structures share one core principle: the entity issuing the assurance must be independent of the entity being assured.
The Five Things CPA Firms Are Now Scrutinizing
1. The Source and Chain of Custody of Every Evidence Artifact
In 2024, it was common practice for CPA firms to accept evidence exports directly from GRC platforms. A Vanta or Drata export would show a list of passing checks, and the auditor would test a sample. The implicit assumption was that what the platform reported reflected what was actually happening in the environment.
That assumption is no longer safe, and the more rigorous CPA firms have stopped making it. What they want now is traceability: evidence that can be tied back to its original source with a clear chain of custody. If a control requires quarterly access reviews, they want to see the actual review record, time-stamped, with the reviewer's identity attached, not a green checkbox in a dashboard that says the review happened. If a control requires log monitoring, they want to see log records, not a platform notification that the integration is active.
This matters for your readiness work. Every artifact in your evidence repository should be tagged with its source, the date it was collected, who collected it, and how it was verified. Platform exports are a starting point. They are not evidence by themselves.
2. Operating Effectiveness Over the Entire Audit Window
SOC 2 Type 2 covers a defined period, typically six to twelve months. A control that was operating on day one and broke down in month four is not operating effectively. A control that was configured in month eleven to address a gap found during readiness is not evidence of operating effectiveness for the prior ten months.
CPA firms are now sampling more aggressively across the full audit window. Where they previously might have tested a handful of incidents or access reviews at one point in time, they are now requesting samples from the beginning, middle, and end of the period. If you cannot produce evidence from across the entire window, you have a gap regardless of how clean your current environment looks.
The implication is structural: you cannot prepare for a SOC 2 Type 2 audit in the weeks before the auditor arrives. Evidence collection must be a continuous operation from the first day of your audit window to the last.
3. A Complete and Defensible System Description
The system description is Section 3 of your SOC 2 report. It is prepared by management and describes the system being audited, its components, its boundaries, and the controls in place. CPA firms are now reading system descriptions with more care than they used to, looking for internal consistency and completeness.
A system description that lists security controls that are not backed by actual operating evidence is a problem. So is a description that omits key infrastructure components or subservice organizations. When auditors test a control and find it does not match what the system description says, it raises a flag that affects the entire report.
Your system description should be written to accurately reflect what your environment actually does, not what you wish it did. It should be updated before the audit to reflect any material changes in your environment during the audit window.
4. Subservice Organization Due Diligence
Almost every SaaS company relies on subservice organizations: AWS, Azure, Stripe, Okta, Datadog, and so on. How these relationships are handled in a SOC 2 report has become a point of focus for CPA firms. When you use the carve-out method, you are asserting that your controls account for what your subservice organizations do not cover. When you use the inclusive method, the subservice organization's controls are included in scope and need to be substantiated.
CPA firms now routinely ask for evidence that you have reviewed your key subservice organizations' SOC 2 reports, that you understand what complementary user entity controls they expect you to implement, and that those controls are actually in place. If a critical vendor does not have a SOC 2 report, you need a documented risk assessment to justify why and what compensating controls you have applied.
5. Evidence of Management's Monitoring Activities
CC4 of the COSO framework requires management to evaluate and communicate the results of monitoring activities. This used to be satisfied with a brief paragraph in the system description and some policy documents. That is no longer sufficient.
CPA firms want to see evidence that management is actively monitoring controls, reviewing results, and responding to exceptions. This means board-level and management reporting on the state of security controls, documented exception handling when controls fail or produce anomalies, and records of the corrective actions taken. If your management team cannot demonstrate that it reviews control outputs regularly, you have a gap in CC4 that will appear in the auditor's findings.
What Certification Bodies Are Looking For in ISO 27001
Certification bodies conducting ISO 27001 Stage 2 audits have always been rigorous about documented evidence, but the post-scandal environment has sharpened their focus on a few specific areas.
First, internal audit quality. Under Clause 9.2, you are required to conduct internal audits at planned intervals. CBs are looking carefully at the internal audit reports, examining whether the audit was conducted by someone independent of the area being tested, whether the scope was comprehensive, and whether management actually reviewed and acted on the findings. A perfunctory internal audit report that covers every control in a single afternoon is a red flag.
Second, risk treatment evidence. Your risk assessment and Statement of Applicability are the backbone of your ISMS. CBs want to see that controls in your SoA are genuinely implemented and that your risk register reflects actual risks rather than being a theoretical exercise. They will sample controls from your SoA and ask you to demonstrate implementation, including operating records.
Third, nonconformity handling. If your Stage 1 audit identified any gaps or observations, CBs expect documented corrective actions with root cause analysis and evidence that the issue was actually resolved, not just acknowledged.
What This Means in Practice
The bottom line on automationGRC platforms remain useful for tracking controls and pulling initial evidence. They are not a substitute for a human-verified evidence repository. An auditor who cannot trace an artifact back to its source will treat it as missing.
The companies that are passing audits cleanly in 2026 have a few things in common. They started collecting evidence from day one of their audit window. They have a defined taxonomy for their evidence repository, with every artifact tagged to a specific criterion, control owner, and collection date. They verified platform exports against source systems before the auditor arrived. And they ran a dry run, usually with a readiness firm, before the real auditor showed up.
The companies that are struggling are the ones that assumed a passing GRC platform dashboard would translate into a clean audit opinion. The gap between what a platform reports and what an auditor will accept has widened significantly in the past twelve months.
Your CPA firm is not the enemy here. The rigor they are applying is appropriate. Evidence that cannot be defended is not evidence. Controls that exist only in a database are not controls. The firms that treat their SOC 2 as an ongoing operational discipline rather than an annual documentation exercise are the ones that will continue to pass as the standards tighten further.
How to Prepare
Start with your evidence repository design. Every control in your control matrix needs a named owner, a defined evidence artifact, a collection frequency, and a method of verification that goes beyond a platform checkbox. Build this structure before your audit window opens, not during it.
Map your controls to the Trust Services Criteria explicitly. CPA firms want to see that you understand why each control satisfies each criterion, not just that you have a list of controls. If a criterion is not addressed by any control in your environment, that is a gap that needs to be resolved before the audit window opens.
Document your subservice organization relationships. Review your key vendors' SOC 2 reports annually, note the complementary user entity controls they require, and verify that those controls are implemented in your environment. Keep records of those reviews.
Run a pre-audit dry run. Have someone independent review a sample of your evidence before the real auditor sees it. If the evidence cannot withstand scrutiny from a colleague, it will not withstand scrutiny from an auditor.
The standards are not going to relax. The post-Delve environment has changed what CPA firms can afford to accept. The companies that adapt now will find audits faster, cleaner, and less expensive than they used to be. The companies that don't will find them longer, more expensive, and more likely to produce findings they cannot explain to a customer.