Compliance automation platforms do a real job and do it well. They pull evidence out of your cloud accounts and identity provider on a schedule, they flag configuration drift, they give you a policy set to start from, and they map controls to the trust services criteria so you are not building a matrix from scratch. If you are a twenty-person company facing a first SOC 2, one of these tools will probably save you weeks.
What they cannot do is the examination. A SOC report is an attestation engagement performed under AICPA standards, and the opinion has to be issued by a licensed CPA firm. That is a licensing fact rather than a criticism of the software, and every serious platform in the category says so plainly — most of them will introduce you to audit firms precisely because they cannot sign the report themselves. The confusion tends to come from the dashboard, not from the vendor.
What these platforms do genuinely well
Worth being specific, because the value is concrete:
Continuous evidence collection. Integrations pull screenshots, configuration states and user lists automatically, on a recurring basis, with timestamps. For controls that live inside connected systems — MFA enforcement, encryption settings, logging configuration, branch protection rules — this is far better than a manual screenshot taken the week before fieldwork.
Drift detection. If someone disables MFA on an admin account or opens a security group, you find out in days rather than at the end of a twelve-month period. That is a genuine security benefit independent of the audit.
Policy scaffolding. A complete, coherent policy set as a starting point is worth having, provided you edit it to describe what you actually do.
Control mapping and task tracking. Knowing which criteria a control addresses, who owns it and what is overdue is administrative work someone would otherwise do in a spreadsheet.
Population assembly. Employee rosters, vendor inventories, device lists and access reviews all get easier when one system holds them.
None of that is trivial. Teams that use these tools well typically arrive at fieldwork with cleaner populations than teams that do not.
The line: a readiness dashboard is not an audit opinion
Here is the distinction that matters most, and it is worth stating without drama.
A platform’s readiness score measures your posture against the platform’s own control framework — its default control set, its integration checks, its interpretation of the criteria. That is a useful internal signal. It is not the auditor’s scope, the auditor’s control set, or the auditor’s judgement.
The examination works differently. You describe your system and the controls you have in place, your management asserts that description is fair and the controls are suitably designed and operating, and the service auditor forms an independent opinion by testing them. The auditor decides what constitutes sufficient appropriate evidence. A tool showing every control green does not commit any auditor to anything, and reaching fieldwork at 100% on a dashboard and still receiving exceptions is a common and entirely explicable outcome.
That is not the platform failing. It is two different measurements of two different things.
What the integrations cannot see
The tools are strongest where an API exists and weakest everywhere else. In practice that leaves several areas that stay manual regardless of what you have bought:
- Anything before you installed it. If your observation period starts in January and you connect the platform in April, the first quarter’s evidence has to come from your own logs, tickets and records. This catches people out more than any other item on the list.
- Systems with no integration. Legacy infrastructure, on-premises equipment, niche SaaS, anything under a subsidiary or an acquired team.
- Human processes. Board and management oversight, risk assessment meetings, security committee decisions, vendor due diligence judgement, disciplinary processes.
- Physical controls, where they are in scope.
- Tests that are events, not states. A business continuity exercise, an incident post-mortem, a tabletop, a penetration test remediation cycle. The tool can store the artefact; it cannot perform the exercise or judge whether it was meaningful.
- The system description itself. Nobody automates this. It is a narrative document about your services, infrastructure, people, data flows and subservice organisations, and it is one of the things the auditor opines on.
The judgement calls that stay with you
Some decisions cannot be delegated to software because they are decisions about your business:
Which criteria are in scope. Security is required; Availability, Confidentiality, Processing Integrity and Privacy are elective and each one adds real work. A platform will happily enable all five. Whether your buyers need them is a commercial judgement.
What your boundary is. Which entities, products, environments and subservice organisations sit inside the description. Get this wrong and everything downstream is wrong.
Whether a control is suitably designed for your risks. A control can be present, monitored and green while still not addressing the risk it exists for. Quarterly access reviews performed by the person who provisions the accounts will pass a checkbox and fail a design assessment.
What to do about an exception. Remediation, compensating controls, management response wording — all yours.
How auditors treat evidence a platform produces
Auditors do use platform-generated evidence, and many are comfortable with it. But it is treated as information produced by the entity, which means the auditor considers whether it is complete and accurate before relying on it.
Concretely, that can mean asking how a report is generated, checking a sample of platform output against the source system directly, or asking you to produce the underlying export alongside the dashboard view. A screenshot from a tool is not automatically stronger evidence than a screenshot from the source system; what makes evidence strong is the same as always — it shows what happened, when, and who did it, and its origin can be verified.
Firms also differ in how much platform output they accept and in what form. Ask your auditor early which integrations they are familiar with, what they will take directly from the tool, and what they will want independently. Agreeing that in planning is much cheaper than discovering it in month eleven.
One more honest point: continuous monitoring creates a record of failures as well as successes. If the tool flagged a control as failing for six weeks and nobody acted, that history exists. That is a good property of the tool and a reason to treat its alerts as work rather than noise.
Where the money gets saved, and when to skip the tool
The saving is real but it is not the audit fee. Audit fees are driven by scope, criteria, population sizes, number of systems and the state of your evidence. A well-run platform improves the last of those, which can reduce back-and-forth hours; it does not shrink your scope.
You can reasonably skip a platform if your environment is small and homogeneous, your populations are short enough to manage in a spreadsheet, and you have someone with the discipline to collect evidence on a schedule. Plenty of clean reports are produced that way. Conversely, the more systems, entities and people you have, the harder it is to justify doing it by hand.
What to do next
If you are already using a platform, run one test: pick three controls the dashboard shows as satisfied and try to produce, from the tool alone, evidence covering your full observation period, with dates and the source system identified. If any of the three has a gap at the start of the period or relies on a system with no integration, you have found your manual work list early.
Assurion is a licensed CPA firm and we work alongside whichever platform you use — the tool prepares the evidence, the examination is a separate piece of work.