Your compliance platform reads APIs. Your auditor asks for things that do not live in one. That mismatch is where first audits slow down.
- SOC 2
- Audit evidence
- Compliance automation
The short answer
Compliance platforms collect evidence from systems with an API. They cannot collect manager sign-offs, permissions inside custom apps, console views that verify an export, or the reasoning behind a risk decision. Those sit in the three control families auditors flag most often.
This is not a flaw in any one product. It is what happens when a tool reads configuration data rather than watching work happen.
On this page
What SOC 2 evidence collection can and cannot reach
Split your evidence into two columns and the picture gets clear quickly. One column arrives on its own. The other is yours to produce, every time.
The right column is where fieldwork slows down.
Why auditor sampling sets the real deadline
A Type II examines an observation window, commonly twelve months. Auditors do not review every day of it. They sample, typically 25 to 40 dates per control, and ask for evidence covering each one. A sampled date with nothing behind it becomes a finding.
Which is why quarterly collection quietly fails. Four dates against thirty requests is not a coverage strategy.
The genuine case for automation, and it only holds for controls an API can reach.
Both things are true. Continuous collection beats quarterly screenshots decisively, and it covers roughly half your evidence. The half it misses is the half auditors flag most often.
The three control families where gaps cluster
Across SOC 2 engagements, the same three areas come up again and again.
Access provisioning
The API shows who has access right now. Auditors want quarterly reviews carrying manager sign-off, plus proof the export matches the live console.
Change management
Commits and merges are easy. The approval judgment behind them is not, and neither are changes made outside the pipeline.
Risk assessment
There is no API for reasoning. Your register, scoring rationale and decisions are documents somebody writes.
Where each control actually lives
| Control | System of record | What the API misses |
|---|---|---|
| CC6.1 logical access | Identity provider | Review sign-off, custom app permissions |
| CC6.6, CC6.7 vulnerability | Scanner | Remediation decisions, accepted-risk rationale |
| CC7.1 monitoring | Log aggregation or cloud audit log | Alert triage and what a human concluded |
| CC8.1 change management | CI/CD and Git host | Approval judgment, out-of-pipeline changes |
| Asset inventory | Device management and cloud accounts | Classification context, headcount reconciliation |
Why an export alone is not enough
Information Provided by the Entity is the reason. Auditors will not take a spreadsheet at face value, because you generated it. They want the source behind it.
Classification works the same way. An API confirms a storage bucket exists and how it is configured. It cannot show the bucket is classified correctly in your documentation, because that mapping is a decision rather than a config field.
Ask this in any vendor demo: show me continuous evidence collection for CC6.1 from our identity provider, with no screenshots and no manual export. If the answer involves a browser tab or a CSV upload, you are looking at a control tracker rather than evidence automation. Both are useful. They are not the same purchase.
Five SOC 2 evidence collection moves before fieldwork
None of these need a new vendor.
- Map every control to its system of recordThen mark which are API-reachable and which are not
- List the controls containing a human decisionSign-offs, approvals, classifications, alert triage
- Move manual evidence from quarterly to monthlySampling punishes a four-date year
- Capture metadata on every manual artifactSystem date and time, full URL, logged-in user, uncropped view
- Agree evidence formats with your auditor during planningThe answer changes your workload, so get it early
Item four trips up more teams than the rest combined. Manual evidence is accepted when it is verifiable. A cropped screenshot with no timestamp is not evidence, whoever produced it.
Where automation genuinely wins
Across a twelve-month window under sampling, daily automated collection beats quarterly manual work outright. Teams commonly report saving 100 to 200 hours on a first cycle. That is the correct reason to buy.
Where you may not need it yet
Below roughly five engineers, manual is sometimes faster than integrating a platform. Break-even arrives when systems in scope exceed what one person can hold in their head.
How Osto approaches this
The gap exists because controls and evidence sit in different places. A platform reading your tooling through an API is always one step removed from what the tooling did.
Osto runs the controls and the compliance mapping in the same platform. Endpoint and device control, code security, cloud posture and web protection all report into one place, so more of the evidence trail is native rather than reconstructed from an API read of someone else’s product. Cross-module correlation covers ground that separate API reads cannot join up.
That closes part of the gap, not all of it. Controls turning on a human decision, the sign-offs and classifications and accepted risks, remain yours to document no matter what you buy.
See which of your controls actually produce evidence
A free assessment maps your controls to their systems of record and shows which ones leave a trail an auditor can sample.
Frequently asked questions
What evidence can compliance automation not collect?
Anything without an API. Manager sign-off on access reviews, permissions inside custom or legacy applications, console views that corroborate an export, data classification decisions, risk assessment reasoning, and approval judgment on changes. Infrastructure and identity configuration are well covered. Application-level and decision-based evidence are not.
Why do SOC 2 auditors still ask for screenshots?
Because of Information Provided by the Entity requirements. An export you generated is not self-verifying, so auditors often want to see the live console showing the same values. They also need visual evidence for controls inside applications that have no API to query.
How many dates does an auditor sample in a SOC 2 Type II?
Commonly 25 to 40 dates per control across the observation window, usually twelve months. The auditor picks the dates, not you, so quarterly evidence will miss most of them. Any sampled date without evidence is a finding.
Which SOC 2 controls have the most evidence gaps?
Access provisioning and deprovisioning (CC6.1 to CC6.3), change management (CC8.1), and risk assessment (CC3.1 to CC3.3). Each combines API-readable state with a human decision or an interface view that no API exposes.
Does a compliance platform make me audit-ready?
It means part of your evidence is collected continuously. Readiness also needs the non-API evidence, the controls genuinely operating, and agreement with your auditor on formats. A dashboard showing green describes what the platform can see, not your full audit position.
Is manual evidence acceptable to SOC 2 auditors?
Yes, when it carries the metadata that makes it verifiable: system date and time, the full URL, the logged-in user context, and an uncropped view. What fails is cropped, undated evidence, and a single snapshot offered as proof of a control operating across a whole period.
Related reading: SOC 2 readiness checklist · SOC 2 evidence collection · SOC 2 controls CC1 to CC9 · SOC 2 Type 1 vs Type 2
Accuracy note: Control references follow the SOC 2 Trust Services Criteria. Sampling ranges, commonly cited gap areas and evidence-format expectations reflect published audit and industry analysis current to August 2026, and vary by audit firm, scope and control implementation. Confirm requirements with your own auditor during planning. Osto helps companies deploy controls and reach audit readiness; SOC 2 attestations are issued by accredited independent auditors.