Last month, a founder I know was 4 weeks from his SOC 2 Type II audit.
He had been using Vanta for 8 months. Policies were green. Training records were green. Access logs were green. Every dashboard said he was ready.
Then his auditor sent the list of evidence requests.
Specifically asked for:
- Quarterly vulnerability scan reports
- Penetration test results from the past 12 months
- Evidence of remediation tracking for identified vulnerabilities
- Proof that critical findings were resolved within SLA
His compliance platform had collected none of this.
They are not designed to.
They collect what humans do — sign documents, complete training, and request access. Not what your applications actually look like to an attacker.
He had 4 weeks to generate 12 months of security testing evidence.
This is the gap nobody warned him about. Here is what is actually in it.
The problem is not compliance workflows
This is the part people misunderstand.
Platforms like Vanta, Drata, Sprinto, and Secureframe are good products. They solve a real problem. Before them, startups tracked SOC 2 audit preparation in spreadsheets and Slack messages.
That was chaos.
These platforms organize policies, employee onboarding, access reviews, and audit workflows extremely well.
But SOC 2 audits are built around Trust Service Criteria controls like CC1.5, CC6.1, CC6.6, CC7.1, and CC7.2. Auditors do not just want policy statements saying security controls exist. They want evidence that the controls actually operated during the audit period.
That is where many startups get surprised.
Especially in India, where RBI cybersecurity audit expectations and DPDP compliance evidence requirements are becoming stricter, auditors are increasingly requesting technical proof rather than screenshots of policy pages.
We have seen this repeatedly while running continuous security scans for startups at Greyhound Security. We are not auditors — licensed CPA firms issue SOC 2 reports. Our role is to collect technical evidence that auditors later review.
The gap usually shows up in three places.
Gap 1 — Vulnerability scan history (Trust Service Criteria CC7.1)
Auditors usually request quarterly vulnerability scans of production systems.
Not just proof that scans ran.
The actual reports.
They want findings, severity ratings, remediation notes, timestamps, and evidence of remediation. They want to know whether vulnerabilities identified in March were still open in June.
Most compliance platforms only track whether a vulnerability management policy exists. Sometimes, there is a checkbox confirming that quarterly scans have happened.
That is not the same thing.
A SaaS company we worked with had technically been scanning its infrastructure for almost a year. But every quarter, the latest Nessus report overwrote the previous one in shared storage.
When the auditor requested 12 months of scan history, they had one report.
From the auditor’s perspective, the missing quarters did not exist.
This sounds small until you realize SOC 2 audits depend heavily on historical evidence. If you cannot prove a control operated continuously during the audit window, auditors may treat the control as ineffective.
Quarterly scanning also creates another problem: modern infrastructure changes too quickly.
Containers change. Cloud permissions drift. Dependencies update weekly. Quarterly scans leave 90-day blind spots.
The evidence gap becomes operational long before it becomes a compliance problem.
Gap 2 — Penetration test evidence (CC4.1, CC7.2)
This one shows up constantly.
Auditors want an independent penetration test performed within the past 12 months, including:
- Full technical report
- Executive summary
- Findings classification
- Remediation confirmation for high and critical issues
Most compliance platforms handle this as a file upload field.
Which makes sense. They are workflow systems, not testing systems.
The problem is that many startups never actually schedule the pentest.
In India, a manual pentest still typically costs Rs. 3-6 lakh and takes 4-6 weeks. Early-stage startups delay it because engineering priorities always feel more urgent.
A fintech startup we scanned had postponed its pentest for 14 months because of cost. Their assumption was that the compliance platform itself somehow represented their security testing evidence.
It did not.
The auditor flagged it immediately.
This is where founders get frustrated because the dashboard looked “ready” for months. But readiness in a workflow system is not the same as evidence readiness during an audit.
Those are completely different things.
Gap 3 — Continuous monitoring evidence (CC7.1, CC6.6)
This is the hardest category because the evidence is fragmented.
Auditors increasingly want proof that vulnerabilities are detected and addressed continuously, not just cleaned up before audit week.
That means they ask for the entire remediation chain:
- Vulnerability detected on date X
- Assigned to engineer Y
- Fixed in commit or configuration update Z
- Retested successfully on date Q
Most startups have pieces of this spread across Jira, Slack, GitHub, Notion, cloud dashboards, and someone’s memory.
One audit we observed involved the auditor sampling five vulnerabilities randomly from the audit period.
The company could produce complete remediation trails for only two.
Three had missing evidence.
One had no proof that the fix was ever retested.
The auditor issued a qualified opinion.
This is why “continuous monitoring” cannot be just a toggle in a compliance platform.
Auditors want the operational history behind the toggle.
What this actually means
The practical lesson here is not “stop using Vanta” or “replace Drata.”
That would be the wrong conclusion.
Compliance platforms excel at workflow coordination. Most startups should absolutely use them.
But they need to be paired with continuous technical evidence collection.
Three things matter:
First, run continuous vulnerability scanning instead of quarterly scans. Quarterly evidence breaks the moment infrastructure changes between scans. Continuous scanning gives you evidence at any moment.
Second, track remediation within a single system. Jira, Slack, Notion, and memory do not produce audit-ready evidence chains.
Third, map evidence to Trust Service Criteria controls from the start. Controls such as CC6.1, CC6.6, CC7.1, and CC7.2 have specific evidence requirements. Waiting until audit month to organize this mapping creates panic.
The startups that survive audits calmly are usually the ones collecting evidence continuously long before the auditor asks.
The real difference between “compliant” and “audit-ready.”
This is probably the cleanest way to describe the problem.
Many startups are compliant in intent.
Far fewer are audit-ready in evidence.
That difference only becomes visible when auditors begin sampling historical controls.
And by then, there is very little time to fix missing evidence from prior months.
At Greyhound Security, we run continuous AI-driven security scanning and generate SOC 2 audit evidence, mapped directly to the Trust Service Criteria controls, from every scan. We are not auditors, and we do not issue certifications — licensed CPA firms do that. Our goal is to help startups avoid the 4-week scramble at the end of the audit cycle. So far, we have run 63 scans, surfaced 394 real findings, and worked with paying customers across 5 countries. Greyhound is an IIT Bombay IDEAS-incubated. If your SOC 2 audit is still 6+ months away, this is the right time to properly build your evidence collection. Learn more at greyhoundsecurity.com or reach out at business@greyhoundsecurity.com.
Author Bio
Deepak Singh is co-founder of Greyhound Security
Leave a Reply