A Fast SOC 2 Still Needs a History

Wanting less paperwork is reasonable. But if the document says someone reviewed access to customer data and nobody did, the buyer is making a decision on a false premise. The useful distinction is between making real evidence easier to collect and supplying an account of work that never happened.

The history inside the report

SOC 2 is an independent examination of a service provider’s systems and controls, such as how it restricts access to customer data. The AICPA’s SOC 2 guide distinguishes two kinds of report. Type 1 addresses the system description and whether controls were suitably designed as of a specified date. Type 2 also addresses whether those controls operated effectively throughout a specified period, and includes the auditor’s tests and results.

Suppose your process requires a manager to review access to customer data and remove inappropriate permissions. A current list of accounts establishes who has access now. It doesn’t establish what the manager reviewed when the process required it, what they decided, or whether the resulting removals happened. An AI-generated procedure can describe that review perfectly. It can’t make a missed review have occurred.

Evidence has to connect the procedure to the work: the accounts reviewed, the person who reviewed them, the decision, and any resulting changes. A dated review ticket linked to the account list and removal records gives the auditor something to examine. A completed form without that underlying work gives the auditor a claim to test, not a reason to accept it. The AICPA guide says inquiry alone is insufficient to establish operating effectiveness.

Even a well-documented review can rest on bad inputs. If the export omitted accounts that should have been reviewed, a manager could approve everything on the list and still miss inappropriate access. The guide warns that selecting items to test from incomplete or inaccurate records makes the results unreliable, using access-review reports as an example. Following the links is useful; checking what the source records include and exclude matters too.

There is room for legitimate speed here. In its February reporting on SOC quality, the Journal of Accountancy describes tools that pull evidence directly from company systems instead of requiring separate screenshots and spreadsheets. If your controls already operated and those records exist, better collection can reduce preparation work. The report’s turnaround time alone tells you little about the history it covers.

A missing form deserves a different response from a review that never happened. Where documentation was lost, the AICPA guide directs the auditor to evaluate other available evidence and whether other procedures can establish operation throughout the period. Those efforts may still leave insufficient evidence. Put the surviving records in front of the auditor with the gaps visible, rather than having a person or an AI fill them from imagination.

What the Delve dispute puts in question

On March 19, an anonymous author writing as DeepDelver alleged that compliance platform Delve supplied fabricated evidence, including records of board meetings that never happened, and reports containing auditor conclusions before client input. In its March 20 response, Delve denied producing fake evidence. It described its templates as starting points customers must review and modify, and said independent, licensed auditors test controls and issue final reports.

We haven’t independently verified the underlying audit work. Those accounts conflict, and neither establishes the validity of a particular customer’s report. Similar wording alone wouldn’t settle that question either: the AICPA itself publishes illustrative reports. A template can supply the format; the examination has to supply the basis for the conclusion.

That leaves a concrete question for anyone buying compliance software: can you follow a statement in your report back to something your company actually did, and then to the auditor’s work testing it?

Your company has a part in that chain. The AICPA guide identifies management as the responsible party, preparing the system description and providing a written assertion about it and the controls. Read that assertion before signing it, even if the platform shows every task complete. If a draft describes a review you never performed, correct it with the auditor before it becomes a report you give a customer.

Verify the firm behind the signature

Ask the platform which CPA firm will issue the report. Check its claimed licensing credentials with the relevant state accountancy board; NASBA’s directory provides the board contacts. Then speak directly with the person responsible for the examination.

A license check establishes a credential. The separate question is whether the firm will do the work your report requires. The Journal of Accountancy’s guidance recommends checking qualifications and peer review results, and asking about the examination’s scope, sampling procedures, and independence. For the access review, that means asking how the auditor will select reviews to test and what evidence it will inspect beyond management’s assurances. An expensive, manually prepared report has to withstand the same questions as an automated one.

Ask what happens if a review was missed. The AICPA guide directs the auditor to evaluate failed instances of a control and the significance of any resulting deficiency. A failed instance doesn’t automatically invalidate the examination, but it has to be evaluated, including its effect on the opinion. A guaranteed favorable conclusion would make that judgment meaningless.

Read a draft report against work you recognize. Pick an access-review claim, locate the records supporting it, and read the corresponding test and result. If you can’t connect them, ask the auditor to explain the gap. A check like this can catch a false statement about your own work; it leaves the wider examination to the auditor.

Agree on what the buyer will accept

Before paying for a report, agree with the buyer’s security reviewer on the service it must cover, the type of examination, and the period they need to see. Put those requirements beside the auditor’s proposed scope and dates. An accurately examined system or period can still be the wrong one for the buyer’s decision.

If you need to establish operating history, ask whether a Type 1 would satisfy their immediate requirement while you work toward Type 2. Get that acceptance in writing before buying an interim report. A Type 1 gives them information about control design at a point in time; they may reasonably require evidence of operation instead.

Have the auditor assess the records you already hold before assuming the Type 2 history has to start over. For newly introduced controls, assign owners and retain evidence as they operate.

If your team can keep that evidence complete and retrievable in its existing systems, it can prepare for the examination without a separate compliance platform. Where collection is a burden, judge the software by the work it actually removes and the source records it lets you inspect. Performing the controls and having them independently examined remain necessary either way.

If the buyer insists on operating history you don’t have, the sale remains blocked on that requirement. A candid conversation may change the terms, or it may leave the forecast short. The buyer can agree to accept less assurance. Give them that decision before you ask them to sign.